Krav

Beskrivning

Arkitektur-perspektiv

Verksamhets-område

Publicerad / Version

Beskrivning

Arkitektur-perspektiv

Verksamhets-område

Publicerad / Version

Elementet krav finns i metamodell strategi och kan relatera till alla andra element i ramverket. I detta kapitel beskrivs hur relationerna ser ut utifrån elementet krav’s perpektiv. Även definition av struktur för ett krav finns med och med hjälp av den definitionen så har vi etablerat en kravkatalog som kommer att fyllas successivt med de krav som medlemmarna bidrar med.

Strategi

Alla

2022-03-04 / 117

Innehållsförteckning


Inledning

Krav kan användas i sammanhang som t.ex. i upphandlingar, vilket är särskilt vanligt förekommande inom offentlig sektor på grund av lagen om offentlig upphandling LOU. Kravställning i samband med upphandlingar är svårt samtidigt som det är avgörande om resultatet av en upphandling ska bli lyckad eller inte. Det svåra ligger i att kunna formulera krav som är stringenta, inte kan tolkas på olika sätt samtidigt som de är utvärderingsbara ur ett upphandlingsperspektiv.

Krav kan även användas i förändringshantering för att säkerställa att resultatet är förenligt med intressenters behov och förväntningar. Beroende på vad som ska förändras så behöver krav kunna relateras till alla andra element i våra arkitekturmodeller (se vidare nedan). I dessa sammanhang kan mätbara krav vara att föredra för att möjliggöra verifiering av kravet. Detaljeringsnivå på krav anpassas till vilket element som påverkas.

Arkitektur är en viktig del av kravställning genom att komplettera och förtydliga det textuella kravet men arkitekturbeskrivningen kan även utgöra själva kravställningen.

Sidvägledning

Vi börjar med att beskriva hur krav förhåller sig till andra element i ramverket. Längre ned på denna sida finns listat vilka beståndsdelar ett krav består av, d.v.s. vilka fält som ska ingå i en kravpost.

Vi har inspirerats av de kvalitetsegenskaper i ISO 25010 och dess specificeringar som kan vara ett bra stöd om man vill försäkra sig om att alla nödvändiga aspekter av krav för ett informationssystem är tillgodosett.

På undersidan Utökad relationsmodell har vi gjort en mer omfattande relationsansats utifrån elementet krav och dess omvärld samt att beskriva de begrepp som relaterar till krav inom kravdomänen.

 

Elementet krav och dess relationer till metamodellerna strategi och verksamhet

 

Relationen mellan Mål och Intressent samt mellan Intressent och Krav finns inte beskriven i Metamodell Strategi, men tas upp här som hjälp till förståelse av kravområdet.

Notera att relationen kopplad till Kravställningsbart element i ovanstående figur är generisk och kan preciseras med hjälp av relationsbeskrivningen Hur relaterar krav till andra element i arkitekturramverket längre ned på sidan. Där framgår också vilka elementtyper som kan vara kravställningsbara.

 

 

 

För den som vill ha en mer utvecklad bild över hur krav relaterar till sin omvärld hittar den här

Elementdefinitioner

De lilafärgade elementen i ovanstående modell är hämtade från metamodell strategi och förklaras där.

Begrepp

Definition

Exempel

Källor

Begrepp

Definition

Exempel

Källor

Kravställningsbart element

Valfritt annat arkitekturelement som vi ska tillämpa krav på.

Process, Applikationsfunktion, Teknisk funktion, Säkerhetsåtgärd eller annat tillämpligt element

 

Relationer till element i arkitekturramverkets metamodell

Källelement

Relation

Målelement

Källa

Källelement

Relation

Målelement

Källa

Krav

härleds till

Krav

SysML

Krav

härleds ur

Krav

SysML

Krav

beror av

Krav

SysML

Krav

uppfylls av

Kravställningsbart element

Relationen här är en av flera möjliga relationer. För mer information om denna och övriga relationer se tabell nedan.

Kravställningsbart element

uppfyller

Krav

Relationen här är en av flera möjliga relationer. För mer information om denna och övriga relationer se tabell nedan.

Princip

härleds till

Krav

SysML

Krav

härleds ur

Princip

SysML

Standard

härleds till

Krav

SysML

Krav

härleds ur

Standard

SysML

Mål

härleds till

Krav

SysML

Krav

härleds ur

Mål

SysML

Mål

härleds ur

Intresse

Metamodell strategi

Intresse

härleds till

Mål

Metamodell strategi

Mål

inriktar

Intressent

Definierat av arbetsgrupp

Intressent

sätter

Mål

Definierat av arbetsgrupp

Intresse

härleds till

Krav

Metamodell strategi

Krav

härleds ur

Intresse

Metamodell strategi

Intresse

härleds till

Behov

Metamodell strategi

Behov

härleds ur

Intresse

Metamodell strategi

Intresse

är relevant för

Intressent

Metamodell strategi

Intressent

har

Intresse

Metamodell strategi

Intressent

ställer

Krav

Definierat av arbetsgrupp

Krav

tillhör

Intressent

Definierat av arbetsgrupp

Intressent

har

Behov

Metamodell strategi

Behov

är relevant för

Intressent

Metamodell strategi

Behov

härleds till

Krav

Metamodell strategi

Krav

härleds ur

Behov

Metamodell strategi

Behov

påverkas av

Begränsning

Metamodell strategi

Begränsning

påverkar

Behov

Metamodell strategi

Krav

påverkas av

Begränsning

Metamodell Strategi

Begränsning

påverkar

Krav

Metamodell Strategi

Hur relaterar krav till andra element i arkitekturramverket

Då krav kan relateras till många typer av element i ramverket så har vi fokuserat på att beskriva de vanligaste relationerna som krav kan ha till dessa. Vi har utgått från UAF , mappat dessa mot OMG System modeling language och valt ut de vanligast förekommande relationsbegreppen. Dessa är översatta till svenska för att underlätta hanteringen.

Relation

Beskrivning

Källa

Diagram

Relation

Beskrivning

Källa

Diagram

Beroende

En relation som beskriver ett beroende mellan ett krav och ett modellelement av valfri typ. 

Relationen har en svag representation genom att den saknar begränsningar (constraints). Därför rekommenderas i första hand att använda andra typer av relationer (se nedan) om möjligt.

Trace:

OMG Systems Modeling Language v1.5, s.166

UAF v1.1, Domain metamodel, kapitel 8.1.13, sid 96

UAF v1.1, Framework profile, kapitel 4.1.11, sid 233

 

Trace Dependency (SysML 1.5):

TraceCallout (SysML 1.5):

 

Uppfyller

En relation mellan ett krav och ett modellelement som talar om att modellelementet ska uppfylla kravet. 

Exempel på detta kan vara att elementet tekniskt gränssnitt kan uppfylla ett textuellt krav för detta.

(Se även tabell för Kravställningsbara element nedan.)

Satisfy:

OMG Systems Modeling Language v1.5, s.164

UAF v1.1, Domain metamodel, kapitel 8.1.13, sid 96

UAF v1.1, Framework profile, kapitel 4.1.11, sid 233

 

Satisfy Dependency (Sys ML 1.5):

SatisfyCallout (Sys ML 1.5):

 

Preciserar

En relation mellan ett krav och en eller flera arkitekturvyer som beskriver mer detaljer om ett krav.

Exempel på detta kan vara användning av användningsfalls- eller aktivitetsdiagram för att detaljera ett funktionellt krav beskrivet i text. Det omvända kan även gälla genom att ett textbaserat krav kan användas för att detaljera ett mer övergripande modellelement.

Refine: 

OMG Systems Modeling Language v1.5, s.165

UAF v1.1, Domain metamodel, kapitel 8.1.13, sid 96

UAF v1.1, Framework profile, kapitel 4.1.11, sid 233

 

Refine Dependency (SysML 1.5):

RefineCallout (SysML 1.5):

 

Härleder

En relation mellan två krav (ett härlett krav och ett källkrav), där det härledda kravet genereras eller antas av källkravet.

Resultatet av en genomförd kravanalys innebär ofta att flera härledda krav kan relateras till ett och samma källkrav, vanligen i en överliggande nivå i systemhierarkin. Andra exempel på källkrav kan vara från standarder och lagrum.

Derive:

OMG Systems Modeling Language v1.5, s.164

Derive Dependency (SysML 1.5):)

DeriveCallout (SysML 1.5):

Verifierar

En relation mellan ett krav och en arkitekturvy som kan avgöra om ex. systemet uppfyller kravet. Exempelvis en testfallsbeskrivning.

 

Verify:

OMG Systems Modeling Language v1.5, s.165

UAF v1.1, Domain metamodel, kapitel 8.1.13, sid 96

UAF v1.1, Framework profile, kapitel 4.1.11, sid 233

Verify dependency (SysML 1.5):

VerifyCallout (SysML 1.5):

 

Följande tabell listar vilka typer av element i våra metamodeller som kan uppfylla ett krav.

Kravställningsbart element

Arkitekturlager

Kravställningsbart element

Arkitekturlager

Fas

Strategi

Förmåga

Strategi

Aktör

Organisation

Roll

Organisation

Organisation

Organisation

Verksamhetsobjekt

Organisation

Verksamhetsfunktion

Organisation

Process

Organisation

Verksamhetstjänst

Organisation

Begrepp

Information

Informationsobjekt

Information

Dataentitet

Information

Applikation

Teknik

Applikationsfunktion

Teknik

Applikationstjänst

Teknik

Nod

Teknik

Kommunikationsnätverk

Teknik

Teknikfunktion

Teknik

Teknisk tjänst

Teknik

Utrustning

Teknik

Arbetspaket

Realisering

Säkerhetsåtgärd

Säkerhet

Kravstruktur

För att kunna samla krav i en kravkatalog så behöver vi definiera vilka delar ett krav ska bestå av och hur dessa ska specificeras. I nedanstående tabell har vi gjort en första ansats och förklarar och exemplifierar samtliga fält i en kravpost.

Vi har valt att inte ha med ska/bör/önskvärd som kriterie för ett krav p.g.a. att vi anser att det är upp till användande organisation att sätta dessa kriterier för de krav de väljer att använda.

Förklaring av färgkodningen i tabellen nedan

Grå: Den del av kravet som främst intresserar verksamheten i kravställningsarbetet.

Blå: Arkitektens värdebidrag till kravet.

Röd: Används i den lokala hanteringen av kravkatalog. Dessa kolumner är normalt tomma i den nationella instansen av kravkatalogen (om det inte finns en rekommendation) och fylls på vid lokal användning av krav.

Fältnamn

Beskrivning

Exempel

Fältnamn

Beskrivning

Exempel

Krav-ID

Unik alfanumerisk identifierare av ett krav i kravkatalogen.

ISÄK011, AG0034, 000123

Ändringsdatum

Ange datum för då kravet skapades. Varje gång som ett befintligt krav ändras så ändrar man även ändringsdatum.

2021-01-01

 

Kravformulering

Textuell formulering av kravet.

Systemet ska använda den centrala behörighetshantering som upphandlande myndighet använder sig av.

Kravområde

Det område inom verksamhet eller IT-miljö som kravet avser. Kan motsvaras av arkitekturdomäner i en organisation.

Informationssäkerhet, Socialtjänst, IT-arbetsplats, Systemintegration,

Kravtyp

Kategorisering av krav.

Icke-funktionellt IT-krav, Leverantörskrav, Realiseringskrav

Beskrivning av krav

Vilket kontext som avses och vilken konsekvens kravet medför.

Ny funktionalitet i systemstöd som inbegriper central behörighetshantering

Taggning för krav

Tagg utöver ovanstående fälts innehåll för att möjliggöra bättre filtrering vid sökning i kravkatalogen. Möjlighet ges då att “skära informationsmängden på annan ledd”. Flera taggningar är möjliga på ett krav.

eArkiv, UI,

Kvalitetsegenskap enligt ISO 25010

Den kvalitetsegenskap som kravet eventuellt relaterar till

<Prestanda effektivitet>
<Kompatibilitet>

Påverkade arkitekturelement

Det kravställningsbara elementet som uppfyller kravet samt element som indirekt påverkas.

Avser kravet ett arbetsstöd så kan ex. kravställningsbart elementet vara process och ett indirekt påverkat element vara aktör

Motiverande arkitekturelement

Avser element som styrker av kravet påverkat arkitekturelement eller kravområde. Här används relationen Preciserar mellan kravet och det element som motiverar kravet.

Ex. Princip, Standard, Nytta, Begränsning, Intresse

<Lag: nn> <Princip: nn>

Relaterad informationsklassning

Om kravet har en relaterad informationsklassning så ska ni ange er organisations informationsklassningsnivå här.

Ex. 0, 1, 2, 3, 4

Relaterad driftsform

Om ett krav är avsett för en specifik driftsform så anges den här. Om en specifik driftsform inte är relevant så är detta fält tomt.

Egen drift, köp av tjänst, oberoende av driftsform.

Ägare av kravet

Roll (person) i organisationen som är ansvarig för kravet och som godkänner ändringar i kravet.

Domänarkitekt, Verksamhetschef, Upphandlingschef

Författare till kravet

Vem har skrivit kravet. Person och/eller organisation.

“Kal P Dahl, Region Skåne”

Verifieringsmetod

Vald metod(er) för att säkerställa (bevisa) att ett krav uppfylls.

Test, Demo, Jämförelse, Analys, Stickprov, Simulering, Inspektion

Verifieringsstatus

Är själva kravet verifierat? Dvs kontrollerat map att det är nödvändigt, osammansatt, entydigt, specificerat, lösningsoberoende, komplett, uppnåeligt, verifierbart, spårbart etc.

OK / Ej OK

Go / NoGo

Prioritet av krav

Hur viktigt är kravet utifrån intressenternas perspektiv? Viktig information om/när projektet av tidsmässiga, ekonomiska eller andra anledningar måste förändra scope.

1 / 2 / 3

a / b / c

Valideringsstatus

Är själva kravet validerat? Dvs kontrollerat map att det tydligt kommunicerar ett behov eller förväntning hos en legitim intressent på ett språk som kan begripas av en utvecklare eller leverantör.

Nej / Pågår / Ja