Krav
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 |
|---|---|---|---|
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 |
|---|---|---|---|
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 | |
Intresse | härleds till | Mål | |
Mål | inriktar | Intressent | Definierat av arbetsgrupp |
Intressent | sätter | Mål | Definierat av arbetsgrupp |
Intresse | härleds till | Krav | |
Krav | härleds ur | Intresse | |
Intresse | härleds till | Behov | |
Behov | härleds ur | Intresse | |
Intresse | är relevant för | Intressent | |
Intressent | har | Intresse | |
Intressent | ställer | Krav | Definierat av arbetsgrupp |
Krav | tillhör | Intressent | Definierat av arbetsgrupp |
Intressent | har | Behov | |
Behov | är relevant för | Intressent | |
Behov | härleds till | Krav | |
Krav | härleds ur | Behov | |
Behov | påverkas av | Begränsning | |
Begränsning | påverkar | Behov | |
Krav | påverkas av | Begränsning | |
Begränsning | påverkar | Krav |
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 |
|---|---|---|---|
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: | 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 | 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 |
|---|---|
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 |
|---|---|---|
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> |
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 |