Terminologi med förklaringar
Terminologi med förklaringar innehåller en begreppsmodell för krav samt förklaringar av termerna i modellen och de företeelser termerna beskriver. Modellen ramas in av och kompletteras med ytterligare termer som tillför ett systemlivscykelperspektiv och som tillsammans med modellen etablerar en sammanhängande begreppsapparat för krav och kravhantering.
Innehållsförteckning
Innehållet på sidan är uppdelat i nedanstående avsnitt:
- Begreppen term och begrepp
- Målgrupp, principer och antaganden
- Systembegreppet och systems engineering
- Grundläggande kravbegrepp
- Kravhierarkier och krav på olika abstraktionsnivåer
- Prioritetsskalor och prioritering av krav
- Spårbarhet och kravglidning
- Kravaktiviteter
- Kravtyper, kategorier och klassificering
- Kravmodeller
- Kravnotationer
- Egenskaper för krav och kravmängder
- Kravattribut och kravmängdsattribut
- Kravrelaterade arbetsprodukter
- Kravroller
- Avslutning — relationen mellan metodik, termer och terminologin
Källhänvisningar och översättningar
Källhänvisningar i terminologin anges huvudsaklingen på tre olika sätt:
- Hämtat från indikerar att termen med dess definition har hämtats direkt ur den angivna källan och återges på originalspråk utan omskrivning.
- Översatt från indikerar att definitionen för den svenska termen är en översättning av motsvarande definition på originalspråket. Översättningar från engelska har om inget annat anges gjorts av Patrik Sternudd.
- Referens
indikerar en referens i en vidare bemärkelse. Till exempel:
- Den refererade källan definierar en term eller beskriver ett begrepp som, utan att ha översatts från källan, helt eller delvis motsvarar den svenska termen.
- Den refererade källan beskriver ett relaterat koncept i löpande text utan att det namnges som en term eller ett begrepp.
Alla typer av källhänvisningar kan ha förtydligande kommentarer. Dessa ingår i förekommande fall i den detaljerade informationen för respektive term.
Typografiska konventioner
Håller du musen över en hyperlänkad term i löptexten visas den länkade termens definition. Klickar du på en länkad term eller källa kommer du till en sida där all information om objektet visas.
Definitioner för centrala termer återges i ljusblå rutor.
Citering och utformning av referenser
Vägledning för citering och utformning av referenser finns här.
Begreppen term och begrepp
I Svensk kravterminologi används orden begrepp och term enligt följande:
- Med begrepp avses den bakomliggande meningen eller betydelsen av den företeelse eller det koncept som är associerat till ett givet ord.
- Med term avses ett fackord som har en tillhörande definition.
Ett specifikt ord kan således samtidigt vara ett begrepp och en term. Att etablera en term med en tillhörande definition kan ses som en avgränsning eller precisering av alla möjliga innebörder av ett begrepp med samma namn.
Målgrupp, principer och antaganden
Ambitionen är att Svensk kravterminologi ska vara relevant för alla som arbetar med krav oavsett bransch. För att kunna göra det måste den ta höjd för de mest utmanande fallen. Terminologin är därför utformad för att stödja skapande, vidareutveckling och förvaltning av komplicerade eller komplexa system där defekter kan få stora konsekvenser för människor, miljö och ekonomi.
Mer precist utgår terminologin från nedanstående scenario:
- Systemen är företrädesvis tekniska eller sociotekniska och syftar till att tillgodose ett eller flera specifika verksamhetsbehov.
- Det finns ett flertal aktörer med olika behov och intressen inblandande i ett systems livscykel. Sammansättningen av aktörer kan variera över tid och kan bestå av företag, myndigheter och andra typer av organisationer.
- Det finns i regel ett behov att kunna övertyga beställaren eller ett oberoende certifieringsorgan att de krav som ställs är uppfyllda både vid färdigställandet och under användningsfasen.
Att terminologin är anpassad för de mer krävande fallen gör den på intet sätt irrelevant för enklare situationer. Skillnaden ligger framför allt i vilka kvalitetsegenskaper som appliceras samt integrationen mellan kravprocesserna och övriga livscykelprocesser. Oavsett verksamhet tillhandahåller terminologin termer och definitioner som gör det lättare att kommunicera kring behov och krav både internt och mellan olika intressenter.
Principer
Terminologin genomsyras av tre huvudsakliga principer:
- Terminologin ska utgå från ett system- och systemlivscykelperspektiv.
- Terminologin ska i möjligaste mån vara kompatibel med befintliga standarder och annan teoribildning.
- Terminologin ska utveckla området i de fall befintlig teoribildning är omodern eller otillräcklig för terminologins syfte.
Dessa principer gör det naturligt att tillämpa teori och erfarenhet från systems engineering-disciplinen. Genom att så långt som möjligt eftersträva kompatibilitet med de standarder som finns inom området ökar relevansen för terminologin samtidigt som dubbelarbete i form av återuppfunna hjul undviks. Det finns tre systemlivscykelstandarder som har särskild koppling till terminologins innehåll.
- ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes.
- ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering.
- ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description.
Den första standarden i listan, ISO/IEC/IEEE 15288, utgör ett sammanhållande ramverk inom systemlivscykelfamiljen.
softwareinnebär inte att standarderna handlar om programvaror eller it-produkter. Det kombinerande namnet
systems and software engineeringanvänds för en hel serie av relaterade standarder och är enligt uppgift en effekt av mångårigt harmoniseringsarbete inom området för system- och mjukvarustandarder.
Utöver standarder i systemlivscykelfamiljen har inspiration hämtats från standarder inom området för systemsäkerhet (på engelska safety
eller functional safety
) då även dessa fäster stor vikt vid krav och systemlivscykler. Dessutom ligger de system som behandlas i sådana standarder i linje med användningsområdet för terminologin. Exempel på systemsäkerhetsstandarder är ISO 26262-serien för fordonsindustrin och DO-178C/ED-12C för avionikområdet.
Antaganden om system- och kravarbetet
I Svensk kravterminologi görs följande antaganden om system- och kravarbetet:
- Det etableras tidigt i systemlivscykeln en formaliserad överenskommelse om omfattningen av det system som ska tas fram eller vidareutvecklas. Överenskommelsen görs mellan de intressenter som finansierar systemarbetet eller på annat sätt möjliggör systemets existens. I den överenskomna systemomfattningen ingår som minimum de intressentbehov som ska tillgodoses samt de specifika intressentkrav som i övrigt ska realiseras. Den överenskomna omfattningen förväntas vidare hållas aktuell under systemarbetet samt ligga till grund för systemets verifiering och validering.
- Både beställaren och leverantören specificerar och förvaltar krav under systemets livscykel.
- Kravprocesserna och deras aktiviteter är inte separerade från omvärlden utan samverkar med övriga systemlivscykelprocesser.
- Det finns processer som säkerställer att arkitekturbeskrivningen och systemets kravmängd speglar varandra. Detta kan exempelvis ske genom att arkitekturarbetet drivs genom kravnedbrytning eller att kravmängden löpande uppdateras för att spegla arkitekturella vägval för systemet.
- Systemarbetet sker ofta i projektform.
- När uttrycken överenskommen systemomfattning, överenskomna intressentbehov eller överenskomna intressentkrav används i Svensk kravterminologi är det den ovan beskrivna överenskommelsen som avses.
- Arbetsprodukter i form av en intressentbehovssammanställning och en intressentkravssammanställning kan ingå i eller utgöra underlag för den överenskomna systemomfattningen. Vilken information som behöver ingå i övrigt, vilka intressenter som behöver vara delaktiga samt hur formaliseringen genomförs behöver dock anpassas för respektive projekt, system och organisation.
- Antagandet att systemarbetet ofta sker i projektform gör att delar av terminologin tangerar projektledningsmetodiken och dess teoribildning. Projektledningsmetodiken som helhet inklusive dess betydelse för framgångsrika systemprojekt ligger dock utanför terminologin, varför koncept och begrepp som i huvudsak hör till projektledningsområdet endast ingår om det behövs för sammanhanget.
Avseende antagandet om samverkande systemlivscykelprocesser finns det några processer i ISO/IEC/IEEE 15288:2015 som är av särskild betydelse i sammanhanget:
- Arkitektur- och designprocesserna.
Antagande: Kravarbetet är en integrerad del i utformningen av systemet, där den kompletta kravmängden växer fram tillsammans med systemets arkitektur.
- Verifierings- och valideringsprocesserna.
Antagande: En viktig del av verifierings- och valideringsaktiviteterna (
V&V
) för systemet är att leverantören övertygar beställaren om att ställda krav är uppfyllda.
Utöver de ovanstående nämnda processerna kommer kravprocesserna sannolikt att behöva samverka med ytterligare ett antal processer under systemets livscykel. Bland dessa kan projektledningsprocessen samt affärsprocesserna som reglerar överenskommelser mellan beställare och leverantörer nämnas. För en mer heltäckande bild av olika systemlivscykelprocesser hänvisas till ISO/IEC/IEEE 15288:2015.
Systembegreppet och systems engineering
Utgångspunkten för Svensk kravterminologi är att kravarbetet är en del i arbetet att skapa, vidareutveckla eller förvalta ett system av någon form. ISO/IEC/IEEE 15288:2015 definierar system enligt följande:
Definitionen är avsiktligt bred för att den ska vara tillämpbar oavsett bransch. Definitionen begränsar därför varken typ, antal eller storlek på de ingående systemelementen. Till exempel kan ett systemelement utgöras av människor vilket i förekommande fall innebär att systemet som helhet faller inom kategorin sociotekniska system:
De flesta system har gränsytor eller beroenden till andra system. För att undvika missförstånd i situationer där flera olika system förekommer används termen systemet-i-fokus för att indikera det specifika system som är i centrum för diskussionen eller arbetet:
Systems engineering
För att konstruera och upprätthålla komplexa tekniska och sociotekniska system genom hela deras livscykler krävs strukturerade processer och arbetsmetoder grundade i både teori och empiri. Disciplinen för detta heter på engelska systems engineering. Någon självklar och intuitiv svensk översättning är svår att finna, inte minst eftersom den mest uppenbara kandidaten systemteknik sedan lång tid tillbaka har en annan innebörd inom ingenjörsvetenskaperna. Till följd av svårigheterna med att hitta en lämplig översättning följer terminologin tills vidare etablerad praxis och använder systems engineering också som det svenska namnet på disciplinen.
Enligt uppgifter från flera källor lyckades inte den tekniska kommitté som tog fram den svenska översättningen av 2002 års version av ISO/IEC 15288 med titel Systems engineering -- System life cycle processes komma överens om en bra översättning till begreppet systems engineering. Titeln på den svenska standarden exkluderade därför den delen av den engelska titeln.
Den efterföljande versionen från 2008 gavs en längre titel som inkluderade mjukvaruaspekter: Systems and software engineering -- System life cycle processes.
I samband med fastställandet som svensk standard översattes endast titeln, där systems and software engineering
blev system- och programvarukvalitet
. Denna översättning är dock problematisk. För det första omfattar de engelska begreppen mycket mer än enbart kvalitet och för det andra är det någorlunda vedertaget att översätta software engineering
till programvaruteknik.
Från och med den tredje utgåvan 2015 sker inget fastställande som svensk standard och därmed heller ingen översättning av vare sig titel eller innehåll.
I sammanhanget är det relevant att konstatera att även om standarderna sedan lång tid tillbaka beskriver centrala processer och aktiviteter inom systems engineering så är det först i 2015 års version som begreppet får en egen definition. Föregående versioner använder framför allt begreppet i titlarna för respektive standard. Att ISO/IEC inte definierat begreppet tidigare betyder däremot inte att innebörden varit oklar. Bland annat har INCOSE (International Council on Systems Engineering) genom åren etablerat och utvecklat både definitionen och mer förklarande beskrivningar av begreppet. INCOSE är också i hög grad involverade i utvecklingen av både ISO 15288 och disciplinen i sin helhet.
Processer, aktiviteter och arbetsprodukter
Inom det ramverk som ISO/IEC/IEEE 15288:2015 utgör exekveras ett antal samverkande livscykelprocesser för att producera systemet-i-fokus. I varje sådan process utförs ett antal aktiviteter:
Att aktiviteterna i en process utförs i en sekvens ska inte tolkas som att aktiviteten eller den överordnade processen endast utförs en enda gång eller i en specifik fas under systemets livscykel. Vissa aktiviteter kommer att utföras i större omfattning i vissa faser, men de behöver också ofta helt eller delvis itereras i ett senare skede.
Resultatet från en aktivitet i en process benämns arbetsprodukt:
En arbetsprodukt är en typ av artefakt som kan utgöra ett systemelement lika gärna som en specifikation som reglerar delar av systemets utformning.
Inom projektledningsområdet används begreppet leverabel för vissa viktiga artefakter som tas fram under projektets gång. Projektets leverabler förväntas vara specificerade i projektdirektiv eller andra styrande projektdokument och vara överenskomna med projektets intressenter. Om ett projekt utgör formen för eller på annat sätt ingår i arbetet för att ta fram eller vidareutveckla ett system kan en artefakt på samma gång vara en arbetsprodukt inom en systemlivscykelprocess och en leverabel inom projektet.
Arkitektur och design
En term med nära kopplingar till systembegreppet är arkitektur:
Arkitekturen för befintliga såväl som framtida system kan speglas i en arkitekturbeskrivning. Alla system har en arkitektur oavsett om den är beskriven eller inte. En arkitekturbeskrivning enligt ISO/IEC/IEEE 42010:2011 består av ett antal vyer som beskriver systemet utifrån olika perspektiv.
Arkitekturen och arkitekturbeskrivningen behöver i sin tur detaljeras ytterligare för att de ingående systemelementen ska kunna realiseras både fristående och som delar i helheten. En sådan detaljering benämns design:
Grundläggande kravbegrepp
I det här avsnittet introduceras ett antal grundläggande kravbegrepp som används genomgående i terminologin. Några av begreppen nämns endast översiktligt i sitt sammanhang till andra begrepp för att sedan beskrivas mer utförligt i kommande avsnitt.
Intressenter och behov
Nya tekniska eller sociotekniska system uppstår inte utan anledning. När resurser avdelas för att ta fram ett nytt system eller vidareutveckla ett befintligt system är det i regel för att helt eller delvis tillgodose ett eller flera behov:
De aktörer som har eller företräder de behov som systemet-i-fokus ska bidra till att tillgodose, samt aktörer som på annat sätt har inflytande över systemet, benämns intressenter. Respektive intressents behov i relation till systemet benämns intressentbehov. De olika intressenterna har olika behov såväl som varierande grad av inflytande. De intressenter vars inflytande är avgörande för systemets existens och användande benämns nyckelintressenter.
| Term | Definition |
|---|---|
| Intressent | En individ eller organisation som påverkas av, eller har inflytande över, ett systems utformning eller existens. |
| Intressentbehov | Ett behov som en given intressent önskar få tillgodosett genom systemet-i-fokus. |
| Nyckelintressent | En intressent vars inflytande är avgörande för existensen eller nyttjandet av systemet-i-fokus. |
Definitionen av intressent är bred. Vilka som är intressenter för ett givet system kan också förändras över tiden. Ett exempel på intressenter som kan tillkomma senare i systemlivscykeln är leverantörer. Dessa företräder i regel inte några av de behov som ska tillgodoses genom systemet-i-fokus men de kan istället ha intressen rörande exempelvis teknikval vilket påverkar systemets utformning och totala livscykelkostnad.
För att identifiera och prioritera relevanta intressenter genomförs en intressentanalys. Resultatet av analysen dokumenteras i en intressentförteckning. De identifierade behov som prioriteras för att tillgodoses genom systemet-i-fokus dokumenteras i en intressentbehovssammanställning:
- En otillräcklig intressentanalys kan i slutändan påverka acceptansen för och nyttan av det framtagna systemet. Ett exempel på en brist är felaktig klassificering av nyckelintressenter som har mandat och uppgift att bevaka att specifika krav är uppfyllda innan systemet får användas. Att hantera sådana intressenters krav som önskemål snarare än tvingande krav kommer sannolikt att leda till stora problem. Ett annat exempel är att misslyckas med att identifiera en eller flera viktiga användargrupper.
- Intressentförteckningen kan innehålla mer information än enbart en lista med intressenternas namn. Några exempel är kategorisering, inbördes prioritering samt kontaktuppgifter till företrädare för de olika intressenterna.
- Generellt kommer de tillgängliga resurserna i form av ekonomi, personal och tid att vara otillräckliga för att omhänderta alla intressenters samtliga behov. Att åstadkomma en intressentbehovssammanställning som kan ingå i eller utgöra underlag för en överenskommen systemomfattning kommer därför att kräva prioriteringar, förhandlingar och kompromisser mellan de nyckelintressenter samt andra viktiga intressenter vilkas behov inte kommer att kunna tillgodoses fullt ut.
- Även om intressentbehovssammanställningen enbart innehåller de behov som vid en viss tidpunkt prioriterats för att tillgodoses genom systemet-i-fokus kan det vara lämpligt att bevara de arbetsprodukter som innehåller övriga identifierade intressentbehov eftersom förutsättningarna för systemet kan förändras under dess livscykel. Att bevara samtliga identifierade behov är särskilt relevant för mjukvarubaserade system där funktionalitet planeras tillföras i kommande versioner.
Krav och kravmängder
De tidigare beskrivna begreppen system, behov och intressenter skapar en lämplig inramning för begreppet krav. I enlighet med den vägledande principen att anamma ett systems engineering-perspektiv utgår Svensk kravterminologi från ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering:
Relationen mellan behov och krav förtjänar ett förtydligande eftersom båda definitionerna använder ordet krav. Ett behov utgör det inneboende kravet på upphävandet av bristen, medan ett krav med utgångspunkt från bristen i fråga uttrycker formerna eller medlet för upphävandet.
I Svensk kravterminologi används, i relation till de framtagna arbetsprodukterna, företrädesvis verbet tillgodose kopplat till behov, samt verben realisera eller uppfylla kopplat till krav.
Beroende på omfattningen av ett behov kan fler än ett krav behövas för att uttrycka behovet i fråga. En samling av krav som grupperas tillsammans, exempelvis för att specificera ett sådant behov, benämns kravmängd:
Omfattningen för en kravmängd varierar beroende på kriterierna för den konceptuella relationen som anges i definitionen, vilka i sin tur avgörs av syftet med mängden. Suffixet mängd används med dess matematiska innebörd vilket bland annat innebär att en kravmängd kan vara tom. Utifrån hur mängderna definieras kan ett givet krav också tillhöra eller inordnas i flera samtidigt existerande kravmängder.
- En kravmängd kan exempelvis bestå av en grupp av krav i kravspecifikation eller ett kravhanteringssystem lika gärna som den samlade mängden krav en organisation har för ett helt verksamhetsområde.
- En tom kravmängd som företeelse kan användas för att resonera kring eller skapa platshållare för en samling krav av viss typ där de faktiska kraven ännu inte specificerats.
- I tidigare versioner av Svensk kravterminologi innehöll kravmängdsdefinitionen en begränsning i form av att en kravmängd var tvungen att innehålla minst två krav. Utgångspunkten för begränsningen var ett ställningstagande att ett solitärt krav inte utgör en samling. Som framgår ovan finns det dock praktiska användningsområden även för tomma mängder, samt att det i övrigt är önskvärt att harmonisera terminologin med hur mängdbegreppet generellt används inom ingenjörsvetenskaperna.
Både krav och kravmängder kan ha egenskaper samt tilläggsinformation i form av kravattribut och kravmängdsattribut. Egenskaperna benämns specifikt kravegenskaper respektive kravmängdsegenskaper. Till stöd för kravarbetet kan ett krav klassificeras utifrån en eller flera kravtyper. Vidare har varje krav en livscykel, vilken benämns kravlivscykel:
Att kravlivscykeln gäller i en specifik kontext innebär att ett uttrycksmässigt identiskt krav kan förekomma med separata livscykler både i en kravmängd för ett givet system och i en kravmängd som förvaltas i syfte att kunna användas för flera olika system eller projekt. Ett uttrycksmässigt identiskt krav med separata livscykler kan även förekomma i den samlade kravmängden för ett och samma system. I ett praktiskt perspektiv initieras livscykeln när kravet går från att vara outtalat eller implicit till att vara explicit utifrån definitionerna i nedanstående tabell.
| Term | Definition |
|---|---|
| Explicita krav | Uttryck där det tydligt framgår att det som förmedlas utgör krav. |
| Implicita krav | Uttryck som underförstått förmedlar en förväntan om att vissa behov eller önskemål ska tillgodoses. |
| Outtalade krav | Behov, önskemål eller förväntningar som inte förmedlas vare sig explicit eller implicit. |
Ett krav görs explicit genom att det specificeras med en för ändamålet lämplig notation. En notation som används för att specificera krav benämns kravnotation. Vilken notation som är lämplig beror på kravets abstraktionsnivå och användningsområde inklusive målgrupp. Genom kravnedbrytning och kravförfining av ett krav på högre abstraktionsnivå till ett eller flera mer precisa underliggande krav skapas en kravhierarki. Kravet som nedbrytningen utgår ifrån utgör hierarkins toppnivåkrav.
- I Svensk kravterminologi används, om inget annat anges, termen krav underförstått med innebörden explicita krav. Detta undantar inte vikten av att identifiera de outtalade och implicita kraven och deras bakomliggande behov. För sent eller inte alls identifierade outtalade eller implicita krav riskerar att ur beställarens eller andra intressenters synvinkel göra det framtagna systemet oanvändbart för dess avsedda syfte.
- Det går att diskutera både filosofiskt och praktiskt vad kriteriet är för att något ska anses vara ett explicit krav. Till exempel skulle en ljud- eller videoupptagning där en intressent säger att denne önskar något kunna anses vara ett krav. Den princip som Svensk kravterminologi följer är dock att ett explicit krav förutsätter en skriftlig artefakt vars syfte tillräckligt uppenbart är att förmedla krav, samt att kravet självt antingen är direkt formulerat så att det framgår att det är ett krav alternativt är återgivet i en sådan kontext. Det är däremot fullt möjligt att ett sådant krav uttrycker att ett system ska kunna fungera enligt vad som förmedlas i inspelningen. På samma sätt utgör ett användningsscenario i sig självt inget krav även om innehållet är väl lämpat för att förmedla en nyckelintressents behov. Scenariot behöver därför åtföljas av exempelvis ett intressentkrav som med vald notation uttrycker att systemet-i-fokus ska möjliggöra det användande som scenariot beskriver.
Från behov till krav
Efter att de intressentbehov som ska tillgodoses genom systemet-i-fokus har sammanställts behöver de omsättas i explicita toppnivåkrav som ligger till grund för fortsatt kravnedbrytning och förfining. Dessa krav benämns intressentkrav och inkluderar i förekommande fall även specifika krav som utan direkt koppling till ett behov är av betydelse för en given intressent:
- Det finns en avsiktlig skillnad i definitionerna mellan intressentbehov och intressentkrav avseende att endast behoven avgränsas till att uppnås genom systemet-i-fokus. Skälet är att intressentkraven utöver att specificera krav på det faktiska systemet också kan reglera processerna som används för att ta fram systemet.
- Termen toppnivåkrav används i första delen av definitionen till följd av ett antagande om att systemlivscykeln utgår från ett antal identifierade behov som sedan omsätts i krav, vilka i sin tur bryts ner ytterligare. Intressentkraven utgör därmed den första nivån av krav varifrån den totala kravmängden för systemet utgår. Samtidigt skapar den andra delen av definitionen utrymme för att vissa intressenter kan ha specifika krav som behöver ingå i den totala kravmängden för systemet-i-fokus eller dess systemlivscykelprocesser.
- Även om leverantörer också är intressenter ställer de i den rollen inte krav på systemet. Däremot kan de ge upphov till ett stort antal ytterligare krav genom att bryta ner och förfina de krav som ställts av andra intressenter. För att omhänderta denna nyans används verbet ställs avsiktligt i andra delen av definitionen. På motsvarande sätt är första delen av definitionen kopplad till intressentbehoven. Utan dessa distinktioner skulle intressentkrav som begrepp omfatta samtliga krav, vilket skulle göra begreppet överflödigt.
På motsvarande sätt som intressentbehoven för systemet-i-fokus kan samlas i en intressentbehovssammanställning kan intressentkraven samlas i en intressentkravssammanställning:
- Tillägget i definitionen som inkluderar systemets livscykelprocesser avser krav som ställs på hur systemet ska tas fram samt eventuella krav som reglerar det färdiga systemets användning och förvaltning.
- Intressentbehovssammanställningen och intressentkravssammanställningen kan ses som en helhet som utgör kravdimensionens del i att definiera syfte och omfattning för systemet-i-fokus. För en fullständig definition av systemomfattningen behövs dock ytterligare arbetsprodukter, där exempelvis ett kontextdiagram kan vara relevant.
- Spårbarhet till ett eller flera specifika behov bör finnas för varje krav. Därför bör respektive krav i kravsammanställningen kopplas till behov i behovssammanställningen. Om det i arbetet med att ta fram kravsammanställningen identifieras intressentkrav som inte kan spåras till specifika behov i behovssammanställningen kan det vara en indikation på att behovssammanställningen behöver itereras ytterligare.
- Arbetet med att specificera och validera kraven i intressentkravssammanställningen bidrar till att systemet-i-fokus i slutändan kommer att kunna accepteras av dess intressenter. När behoven i intressentbehovssammanställningen omsätts i krav kan det till exempelvis visa sig att behoven innehåller motstridigheter som gör de resulterande kraven omöjliga att tillgodose i ett och samma system. Om några av dessa krav och deras bakomliggande behov tas bort för att lösa konflikten kan det leda till att de intressenter vars behov inte längre kommer att tillgodoses drar tillbaka resurser och engagemang för systemets utveckling eller införande. Motsvarande situation kan uppstå för tvingande krav som ställs direkt av en nyckelintressent oavsett koppling till ett bakomliggande behov. En viktig del i arbetet med intressentkravssammanställningen kommer därför vara att genom dialog och kompromisser hantera de konflikter som uppstår till följd av motstridiga behov alternativt otillräckliga resurser för att realisera den totala kravmängden på utsatt tid.
- Intressentbehovssammanställningen och intressentkravssammanställningen kan beroende på organisation och processer ha andra namn eller ingå som delar i andra arbetsprodukter. Suffixet sammanställning har vidare valts istället för specifikation för att förmedla att det handlar om en sammanställning av flera intressenters krav snarare än kraven från en specifik intressent, samt att begreppet kravspecifikation i offentlig verksamhet ofta associeras till sådana specifikationer som utgör underlag i en upphandling.
Begreppsmodell
Begreppsmodellen nedan visar ett antal centrala relationer mellan krav och ett urval andra termer som ingår i Svensk kravterminologi och som definierar strukturen för ett krav och dess omgivande sammanhang. Termerna och relationerna ska ses i kontexten av ett godtyckligt men specifikt system (systemet-i-fokus).
Modellen använder notationen för ett UML v2.5 klassdiagram. En kort vägledning kring hur relationerna ska läsas ges nedan:
- Relationerna med pilar ska läsas i den riktning som pilarna indikerar.
- Ett viktigt begrepp i UML är multiplicitet, som innebär ett intervall med en nedre och övre gräns.
- När multipliciteten för en utgående relation är en etta ska det läsas som
varje [term]
alternativten/ett [term]
. - När multipliciteten för en relation innehåller en asterisk (*) avses ett ändligt icke-negativt heltal. En ensam asterisk är därmed kortform för 0..* vilket läses som
noll eller flera
.
Nedan följer några förtydliganden till modellen och relationerna.
- Att en intressent utöver att ha behov också kan ge upphov till direkta intressentkrav framgår av relationen mellan intressent och krav.
- Relationerna mellan system och arkitektur samt mellan arkitekturbeskrivning och arkitektur förmedlar att alla system har en och endast en arkitektur och att denna arkitektur kan beskrivas genom en eller flera arkitekturbeskrivningar.
- En kravhierarki består av ett toppnivåkrav och ett eller flera krav på lägre abstraktionsnivå. Kraven på varje lägre abstraktionsnivå skapas genom kravnedbrytning eller kravförfining. Eftersom krav på lägre abstraktionsnivå har en relation till sig självt samt att toppnivåkrav i sin tur är ett krav kan en kravhierarki ses som en rekursiv struktur där varje krav i en kravhierarki som har krav på lägre abstraktionsnivåer kan utgöra toppnivåkravet i en underordnad kravhierarki.
- Multipliciteten mellan kravmängd och kravhierarki är en följd av att flera kompletta kravmängder kan sättas ihop i en kravhierarki lika väl som att de ingående kraven i en eller flera kravmängder kan fördelas över flera olika kravhierarkier.
Kravhantering och kravteknik
Svensk kravterminologi innehåller två termer som utgör samlingsnamn för de olika aktiviteter som bedrivs inom kravområdet, kravhantering respektive kravteknik, där den förstnämnda är det allmänna samlingsnamnet för aktiviteter inom kravprofessionen:
Termen kravteknik har en annan dimension och avser ingenjörsdisciplinen samt det vetenskapliga forskningsområdet som på engelska heter requirements engineering:
Definitionerna för kravhantering och kravteknik är översatta från ISO/IEC/IEEE 29148:2011, där kravhantering motsvarar den engelska termen requirements management
och kravteknik requirements engineering
. Suffixet teknik har valts eftersom det sedan tidigare används inom ingenjörsvetenskaperna.
Det är samtidigt bra att känna till att ordet engineering
i det engelska språket ofta används i en vidare bemärkelse, varför det inte är ovanligt att requirements engineering
på engelska används utan koppling till ingenjörsvetenskaper eller annan akademisk teoribildning.
Kravhierarkier och krav på olika abstraktionsnivåer
En kravhierarki är en kravmängd där de ingående kraven har en strukturell relation till varandra som primärt skapas genom rekursiv kravnedbrytning och kravförfining:
Definitionen av toppnivåkrav möjliggör också att en eller flera delhierarkier etableras som delar i en total kravhierarki. Kraven i varje sådan delhierarki utgör en egen kravmängd. Varje delhierarki kan på motsvarande sätt ha underordnade delhierarkier.
Det framgår i andra avsnitt att ett krav kan tillhöra flera kravmängder. Kravhierarkier är ett exempel på när detta är aktuellt, eftersom ett krav kan tillhöra både den totala kravhierarkin och en delhierarki. Samma krav kan dessutom tillhöra andra mängder utifrån exempelvis kravets typ eller andra kravattribut.
Genom den rekursiva nedbrytningen och förfiningen blir kraven mer detaljerade ju längre ner i hierarkin de befinner sig vilket gör att det finns en relation mellan nivåerna i hierarkin och de ingående kravens abstraktionsnivå.
Utöver kategorisering av krav utifrån fackområden kan krav också kategoriseras och benämnas i relation till dess abstraktionsnivå. Några exempel på benämningar med successivt ökande detaljeringsgrad är systemkrav, delsystemkrav, komponentkrav och modulkrav. Namngivningen på de olika nivåerna och storleken av respektive delmängd, oavsett om dessa är organiserade i en kravhierarki eller inte, varierar beroende på den totala kravmängdens syfte och omfattning samt projekt- och organisationsspecifika processer.
En typ av krav som har relationer till både abstraktionsnivåer och kravhierarkier är mål, som definieras enligt nedan:
Mål reglerar framför allt vad och varför snarare än detaljer kring hur. Mål behöver därför brytas ner i mer detaljerade krav för att de ska kunna realiseras. Ett mål kan också brytas ner i ett eller flera delmål. Delmålen bryts i sin tur ner i ytterligare delmål alternativt i specifika krav. Mål kan därmed vara lämpliga som toppnivåkrav i kravhierarki.
- Genom att mål uttrycks på hög abstraktionsnivå kan de även användas som en brygga mellan intressentbehoven och mer specifika tekniska krav. Ett mål kan utgöra ett intressentkrav och ett eller flera sådana mål kan ingå i eller utgöra grunden i en intressentkravssammanställning.
- Mål som koncept och begrepp förekommer bland annat i systemsäkerhetsstandarden ISO 26262, där resultatet från en genomförd riskanalys omsätts i mål som systemet ska upprätthålla. Målen ska enligt standarden sedan brytas till ner mer detaljerade krav. Andra exempel på hur mål kan användas och formuleras finns inom assuransstandarden Goal Structuring Notation Community Standard (Version 3) och i kapitlet Goal Orientation in Requirements Engineering i boken Requirements Engineering: From System Goals to UML Models to Software Specifications.
En effekt av kravhierarkins struktur är att den kravmängd som hierarkin utgör automatiskt är spårbar, vilket är en kravmängdsegenskap som annars är svår att skapa eller upprätthålla. Genom att varje underliggande nivå detaljerar det överordnade kravet blir det enkelt att få svar på varför varje krav under toppnivåkravet behövs samtidigt som risken för kravglidning minskar. Den inbyggda spårbarheten förenklar även analysen av vilka andra krav i hierarkin som påverkas om ett krav i den tas bort eller inte realiseras.
Avslutningsvis kan det, beroende på den organiserade kravmängdens omfattning, på olika nivåer i kravhierarkin uppstå implicita eller explicita skiljelinjer mellan ansvarsområden. Skiljelinjerna kan vara både organisatoriska och kompetensmässiga. Ett exempel på en kompetensmässig skiljelinje är övergången från systemkrav till hård- eller mjukvarukrav. Ett exempel på organisatorisk skiljelinje är övergången från en beställare till en leverantör. Sådana skiljelinjer kan göras explicita genom att skapa delhierarkier och formellt fördela ansvaret för den fortsatta nedbrytningen av dessa till olika aktörer.
Prioritetsskalor och prioritering av krav
Den samlade kravmängden för ett givet system är ofta omfattande. De ingående kraven kommer utöver varierande uttrycksform och omfång också ha varierande prioritet. Olika intressenter, inklusive leverantörer, kan dessutom komma att tillskriva ett och samma krav olika prioritet. För att etablera en gemensam uppfattning om hur viktigt ett givet krav är kan ett mått på prioritet tilldelas och kopplas till kravet i fråga. En angiven nivå av prioritering har alltid, explicit eller implicit, en relation till en annan högre eller lägre nivå. För undvika missförstånd kring de olika måtten och deras inbördes ordning kan en prioritetsskala användas:
En prioritetsskala kan vara utformad på olika sätt. Till exempel kan sifferskalor som 1–4 användas. Det förekommer också binära skalor bestående av exempelvis ska- och börkrav. Ett tredje exempel är, i fallande ordning, kritiskt–prioriterat–önskvärt.
Utöver ordningen på måtten behöver det också vara tydligt för alla som använder prioriteringen vad respektive mått innebär. Till exempel skulle måttet kritiskt som nämns i det föregående stycket kunna ges innebörden krav vars realisering är avgörande för att systemet-i-fokus ska vara relevant för en eller flera intressenter
. En sådan innebörd kan även kopplas till ett element i en sifferskala.
- Prioritetsskalor bör väljas med omsorg. Att till exempel enbart använda en binär skala innebär att den totala kravmängden delas upp i två delmängder där samtliga krav i respektive delmängd ges samma inbördes prioritet. En sådan förenkling av verkligheten ger begränsat stöd för det fortsatta arbetet och undantar sannolikt inte behovet av dialog kring vilka specifika krav som exempelvis nyckelintressenterna tycker är viktigast att få realiserade så tidigt som möjligt.
- Underlag för prioritering kan finnas i form av tidigare genomförd kategorisering av kraven utifrån kravtyper. Till exempel kan krav i kategorin tvingande krav vara kandidater för högre prioritet. Definitionen för tvingande krav kan även ligga till grund för ett eget prioritetsmått ingående i en prioritetsskala.
- Prioritering är oavsett verksamhet en aktivitet som är lika viktig som svår att genomföra. Om en majoritet av kraven ges högsta prioritet är prioriteringen sannolikt till begränsad nytta. Det är dessutom ett mycket resurskrävande arbete att för ett system prioritera samtliga krav på även de lägre abstraktionsnivåerna. Det kan därför vara lämpligt att anpassa systemlivscykelprocesserna avseende vilka krav som behöver prioriteras samt hur den genomförda prioriteringen ska användas. En möjlig anpassning kan vara att underliggande krav i en kravhierarki automatiskt får samma prioritet som toppnivåkravet.
Spårbarhet och kravglidning
Med spårbarhet avses förutsättningar för att avgöra om och på vilket sätt ett givet intressentbehov, genom ett antal successivt mer detaljerade krav, har tillgodosetts eller planeras att tillgodoses genom exempelvis ett systemelement ingående i systemet-i-fokus. Spårbarheten är dubbelriktad och inkluderar i andra riktningen förutsättningar att få information om på vilket sätt ett givet systemelement bidrar till att tillgodose ett eller flera av de intressentbehov som ingår i den överenskomna systemomfattningen.
Spårbarhetsbegreppet har med andra ord en större omfattning än enbart relationer mellan krav och utgör ett exempel på när flera olika systemlivscykelprocesser behöver interagera för att uppnå önskad effekt. Samtidigt är kärnan i Svensk kravterminologi termen krav, varför definitionen för spårbarhet utgår från ett godtyckligt men specifikt krav istället för ett behov eller en artefakt.
- I definitionen avser formuleringen och annan information till exempel delar i en arkitekturbeskrivning som ett krav allokerats till. Formuleringen eller aktiviteter i slutet av definitionen avser sådana krav som endast indirekt realiseras i systemet-i-fokus, vilket exempelvis kan vara fallet för processkrav och assuranskrav.
- I definitionen slutar spårbarhetskedjan i de artefakter där kravet realiseras. Beroende på organisation och processer kan kedjan utökas till att också omfatta artefakter som förmedlar kravuppfyllnaden.
- Även om spårbarhet i sin helhet finns i en kontext som omfattar det system som ska tas fram eller vidareutvecklas kan konceptet användas mer avgränsat. Ett exempel på detta är kravmängdsegenskapen spårbar som specificerar att spårbarhet ska finnas mellan de krav som ingår i mängden utan att ställa krav på spårbarhet till krav, behov eller artefakter utanför den aktuella mängdens omfattning.
- I de fall processer och strukturer saknas för att uppnå spårbarhet för den samlade kravmängden för systemet-i-fokus kan till exempel begränsad spårbarhet mellan enskilda krav och intressentbehov etableras, exempelvis genom kravattribut som bakgrund och källa. Med begränsad avses i sammanhanget att den både är enkelriktad och att den saknar kedjan av mellanliggande krav.
Utan tillräcklig spårbarhet är det svårt att identifiera och förhindra kravglidning, vilket är ett oönskat tillstånd som i ett systemsammanhang innebär förekomst av krav utöver den överenskomna systemomfattningen. Kravglidning definieras i Svensk kravterminologi enligt nedan:
Definitionen utgår från en godtycklig kravmängd. I en kontext av ett specifikt system med överenskomna intressentbehov avses den samlade kravmängden för systemet och dess livscykelprocesser. Kravglidning kan, utöver när krav läggs till i en kravmängd, uppstå om ett krav tas bort samtidigt som andra krav som enbart syftar till att uppnå det borttagna kravet behålls. Ett annat exempel är när en kravmängd, som i sin egen rätt är fri från kravglidning, inkluderas i en större kravmängd vars syfte bara delvis överensstämmer med den inkluderade mängdens syfte.
Kravglidning innebär att tid och kraft läggs på att specificera och förvalta krav som inte leder mot de överenskomna och därmed prioriterade intressentbehoven. I de fall de osanktionerade kraven innehåller motsägelser eller andra konflikter gentemot övriga krav kan kravglidningen i kombination med otillräcklig spårbarhet även leda till att krav som är avgörande för ett eller flera intressentbehov trängs ut eller specificeras suboptimalt.
- I relation till övriga systemlivscykelprocesser leder kravglidning till kaskadeffekter när resurser läggs på att realisera och verifiera innebörden av de osanktionerade kraven. För ett projekt eller system i sin helhet kan kravglidningen medföra förseningar, kostnadsökningar eller att prioriterad funktionalitet och kvalitet måste tas bort till följd av att de resurser som avdelats för systemarbetet används till annat än vad som överenskommits. Det kan också innebära löpande kostnader i efterföljande systemlivscykelfaser för att utbilda på, hantera och förvalta den osanktionerade funktionaliteten.
- Osanktionerad funktionalitetstillväxt kan uppstå oberoende av kravglidning, bland annat om komponenter som ska ingå i systemet skapas utan att beakta gällande krav. Sådan funktionalitet kan identifieras genom att spårbarhetskedjan från en viss komponent eller funktion inte går att följa hela vägen till ett överenskommet intressentbehov.
- Kravglidning och osanktionerad funktionalitetstillväxt relaterar till de engelska begreppen
feature creep
ochscope creep
som förekommer inom mjukvaruutvecklingsområdet respektive projektledningsmetodiken.
Kravaktiviteter
I tabellen nedan finns en lista över de kravrelaterade aktiviteter som förekommer i Svensk kravterminologi. Aktiviteterna är listade i bokstavsordning och inte utifrån när de genomförs inom ett systems eller projekts livscykel. En del av aktiviteterna är egna deldiscipliner inom kravtekniken med tillhörande akademisk forskning.
| Aktivitet | Definition |
|---|---|
| Intressentanalys | En aktivitet där relevanta intressenter för systemet-i-fokus, samt deras relation till systemet, identifieras. |
| Kravallokering | En aktivitet där ett eller flera krav kopplas till planerade eller befintliga arkitektur- och systemelement, samt till övriga artefakter och processaktiviteter som respektive krav ska realiseras genom. |
| Kravanalys | En deldisciplin inom kravteknik som innebär att gå igenom en kravmängd och identifiera och hantera konflikter mellan kraven i mängden, uttrycka kraven så att både kraven och kravmängden uppfyller de önskvärda egenskaperna, samt tillföra de attribut som ska finnas för kraven i mängden. |
| Kravfångst | En deldisciplin inom kravteknik som identifierar de krav som de relevanta intressenterna har på systemet-i-fokus. |
| Kravförfining | En aktivitet där ett krav på en högre abstraktionsnivå genom precisering av detaljer, villkor och begränsningar resulterar i ett krav på en lägre abstraktionsnivå. |
| Kravförvaltning | De aktiviteter som säkerställer att krav och kravmängder, med tillhörande attribut, hålls aktuella med bibehållna egenskaper. |
| Kravnedbrytning | En aktivitet där ett krav på en högre abstraktionsnivå delas upp i minst två krav på en lägre abstraktionsnivå. |
| Kravvalidering | En aktivitet som säkerställer att en kravmängd speglar det eller de behov dess intressenter har för den resulterande produkten. |
| Kravverifiering | En aktivitet som säkerställer att ett krav eller en kravmängd har de egenskaper och attribut som specificerats. |
- Ett annat ord som används för kravfångst är kravinsamling, men inget
av orden speglar det engelska begreppet
requirements elicitation
tillräckligt väl. Svensk kravterminologi använder kravfångst eftersom insamling i högre utsträckning riskerar att leda tankarna till att explicita krav med önskade kvalitetsegenskaper är något som finns färdigt och bara är att samla in, vilket är missvisande för det faktiska arbetet som aktiviteten omfattar. - Kravverifieringen kan underlätta för kravvalideringen genom att exempelvis skapa förtroende för att en kravmängd är komplett och tillförlitlig.
- Definitionen för kravvalidering utgår från en kravmängd och nämner inte, till skillnad från kravverifiering, enskilda krav explicit. Motivet är att förmedla att ett antal krav kan behöva analyseras som en helhet för att svara på om det som uttrycks kommer att realisera intressenternas faktiska behov. Samtidigt ingår kravvalidering av enskilda krav implicit genom att en kravmängd kan bestå av ett enda krav.
Kravallokering
Kravallokering är en aktivitet som kopplar ihop kraven för ett givet system med systemets olika beståndsdelar samt eventuella övriga kravställda artefakter. Aktiviteten interagerar med andra systemlivscykelprocesser som arkitektur-, design- och implementationsprocesserna till den grad att det går att hävda att kravprocessen framför allt är stödjande genom att tillhandahålla de krav som ska allokeras. Oavsett hur processerna implementeras finns det i aktiviteten en kravdimension som är viktig för den helhet som Svensk kravterminologi beskriver, varför den i terminologin listas som en kravaktivitet. Definitionen för kravallokering återges nedan:
- I definitionen används ordet planerade för att förmedla kopplingen till arkitektur- och designprocesserna inklusive möjligheten att inom dessa processer använda de överenskomna intressentbehoven och intressentkraven för att driva systemutformningen.
- Genom att arkitekturelement kommer först i den sammansatta formuleringen arkitektur- och systemelement tydliggörs dels relationen till arkitektur- och designprocesserna ytterligare, dels skapas kopplingen mellan kraven och arkitekturbeskrivningen som framgår i begreppsmodellen som finns i avsnittet om grundläggande kravbegrepp.
- Formuleringen samt till övriga artefakter och processaktiviteter ingår för att inkludera allokering av exempelvis processkrav och assuranskrav samt exempelvis krav på utformningen av systemdokumentationen. Allokering till en processaktivitet innebär implicit att en artefakt i form av en processbeskrivning sannolikt behöver revideras, men eftersom implicita förhållanden är riskabla i kravsammanhang nämns processaktiviteter explicit för att tydliggöra omfattningen.
Validering och verifiering av krav respektive system
Validering och verifiering har olika innebörd beroende på om aktiviteterna avser krav eller system. Inom systems engineering syftar validering till att säkerställa att rätt system skapas, medan verifiering säkerställer att systemet som skapas är korrekt.
Inom kravhanteringen är det inte systemet som sådant som är i fokus för aktiviteterna, utan istället de krav som ligger till grund för systemet. Kravvalidering syftar till att säkerställa att det är rätt krav utifrån intressenternas behov, medan kravverifieringens syfte är att säkerställa att de krav som finns är uttryckta på rätt sätt och med rätt kvalitet.
Även om validerings- och verifieringsaktiviteterna skiljer sig för system och krav så har de relationer till varandra:
- Inom systems engineering innebär verifiering ofta att säkerställa att systemet tas fram enligt specifikation, det vill säga att det uppfyller ställda krav. För att verifieringen ska kunna genomföras måste kraven ha tillräckligt bra kvalitet, vilket säkerställs genom kravverifiering.
- Avseende validering har aktiviteterna på systemnivån en ännu närmare relation till kravvalideringen. Givet att kravvalideringen säkerställer att den kravmängd som specificerar de behov systemet ska tillgodose överensstämmer med intressenternas faktiska behov borgar realiseringen av dessa krav för att det är rätt system som tagits fram. Den korrekta realiseringen säkerställs i sin tur av verifieringen på systemnivån.
I en kontext av verifiering av system utifrån ställda krav är termen kravuppfyllnad relevant, som ibland förenklat skrivs utan prefixet krav alternativt i uttryck som uppfyller ställda krav
.
Termen definieras enligt nedan:
Formuleringen i vilken utsträckning i definitionens inledning gör termen till ett mått som kan förmedla olika grad av uppfyllnad. För enskilda krav innebär dock uttrycket kravet är uppfyllt
generellt att det är fullständigt uppfyllt. Oavsett val av skala förutsätter bedömningen att de krav som omfattas är verifierbara, vilket är en kravegenskap som innebär att ett krav är uttryckt på ett sådant sätt att det kan verifieras.
Till stöd för bedömningen av kravuppfyllnad såväl som verifieringsarbetet i stort kan ett krav,
exempelvis genom kravattributet acceptanskriterium, kompletteras med mer detaljerad information om hur bedömningen förväntas gå till inklusive vilka underlag, artefakter eller aktiviteter som den ska baseras på.
Definitionerna för verifierbarhetsegenskapen och attributet för acceptanskriterier återges nedan, där orden uppfyllt och verifierats förmedlar några av de relationer som finns mellan de olika termerna inom verifieringsområdet:
| Term | Definition |
|---|---|
| Verifierbart | Kravet är uttryckt så att det är praktiskt möjligt att subjektivt eller objektivt avgöra i vilken utsträckning det är uppfyllt. |
| Acceptanskriterium | En informationsmängd som specificerar vad som ska vara utfört eller existera, inklusive hur detta ska ha verifierats, för att kravet ska anses vara uppfyllt. |
- I definitionen för kravuppfyllnad ingår formuleringen eller genom annat utfört arbete i syfte att inkludera exempelvis processkrav. Verifieringen av sådana krav kan i sin tur kräva att en eller flera artefakter som påvisar att ett moment som kravställts har genomförts. Det är således skillnad på de artefakter som ingår det färdiga systemet och de artefakter som krävs för att kunna kontrollera uppfyllnaden av den sammanlagda kravmängden.
- Avseende olika grad av uppfyllnad kan procentuella mått för enskilda krav vara önskvärda om exempelvis kraven är mätbara eller om det finns ett särskilt behov av uppföljning som en del av systemarbetet. För en kravmängd kan ett procentuellt mått avse andelen krav i mängden som är uppfyllda till en specificerad nivå.
- Uttrycket
att verifiera krav
används både för kravverifiering och för verifiering där systemet eller dess ingående artefakter kontrolleras avseende kravuppfyllnad. Risken för sammanblandning av valideringsaktiviteterna är däremot mindre eftersom uttrycketatt validera krav
inte har motsvarande koppling till realiseringen av kraven.
Kravtyper, kategorier och klassificering
Termen kravtyp definieras enligt nedan:
Termen och det bakomliggande konceptet fyller två samtidiga syften i Svensk kravterminologi:
- Namnet på respektive kravtyp utgör ett kategorinamn som möjliggör klassificering av krav utifrån dess typ.
- Kravtyp som koncept innebär en struktur för att resonera kring olika typer av krav och deras relaterade termer.
Eftersom båda användningsområdena relaterar till grupper av krav är namnen på kravtyperna och tillhörande definitioner skrivna i pluralform. I de kommande delavsnitten följer ytterligare detaljer om kategorier och klassificering av krav, en förteckning av kravtyper med tillhörande kommentarer samt fördjupningar av utvalda kravtyper inom områdena användbarhet, säkerhet och assurans.
Kategorisering och klassificering av krav
I Svensk kravterminologi används verben kategorisering och klassificering av krav synonymt och med innebörden att ett eller flera krav indelas i en eller flera kategorier baserade på kravtyper. De olika kategorierna kan i sin tur organiseras hierarkiskt med underkategorier eller på andra sätt ha beroenden till varandra. Vissa av kravtyperna och därmed kategorierna kan dessutom sägas utgöra eller existera i separata dimensioner, där det är naturligt att ett givet krav samtidigt tillhör flera av dessa.
- Tre exempel på olika dimensioner, med en kravtyp ur varje dimension, är kompetensområde (användbarhetskrav), abstraktionsnivå (toppnivåkrav) och källa (lagkrav).
- Några exempel på inbördes relationer mellan kategorier är att tvingande krav kan delas upp i lagkrav och regelverkskrav. Ett regelverkskrav kan på samma gång vara ett cybersäkerhetskrav. Parallellt kan cybersäkerhetskrav tillsammans med användbarhetskrav, systemsäkerhetskrav och informationssäkerhetskrav klassificeras som olika typer av kvalitetskrav.
Vilka kategorier som är tillämpbara i varje givet fall beror dels på typen och omfattningen av systemet-i-fokus, dels på de projekt och organisationer som hanterar kravmängden. Kategorierna och klassificering av krav utifrån dem har inget egenvärde utan syftar till att stödja systemlivscykelprocesserna. Kategorier och metoder för hur de ska användas bör därför väljas med detta som vägledande princip. Exempel på användningsområden är rubriker i en specifikation eller kravattribut i ett kravhanteringssystem som gör det möjligt att snabbt hitta samtliga krav som tillhör en eller flera kategorier.
Förteckning över kravtyper
I tabellen nedan finns en lista över de kravtyper som förekommer i Svensk kravterminologi och som inte har markerats med användning avrådes eller använd med försiktighet. Kravtyperna i terminologin är framför allt valda på grund av att de används för att förklara olika koncept i terminologin, inklusive konceptet med kravtyper och kategorier. Det finns därmed ett stort antal ytterligare kravtyper och kategorier som kan vara aktuella för olika system, projekt eller organisationer.
| Kravtyp | Definition |
|---|---|
| Användbarhetskrav | Krav som för en given artefakt specificerar nivå och utformning av dess användbarhet. |
| Assuranskrav | Krav som syftar till att skapa assurans. |
| Cybersäkerhetskrav | Krav som för en given artefakt specificerar nivå och utformning av dess cybersäkerhet. |
| Härledda krav | Krav som inte har uppstått genom kravnedbrytning eller kravförfining, utan som på annat sätt har skapats för att täcka en lucka som annars skulle uppstå i en kravmängd. |
| Informationssäkerhetskrav | Krav som specificerar nivå och utformning av informationssäkerhet. |
| Intressentkrav | Intressentbehov omsatta till ett eller flera toppnivåkrav samt specifika krav som på olika abstraktionsnivåer ställs direkt av en given intressent. |
| Kvalitetskrav | Krav som reglerar inneboende kvaliteter för en given artefakt eller process. |
| Lagkrav | Krav som specificerar hur regleringar i en eller flera lagar ska omhändertas av systemet-i-fokus eller dess systemlivscykelprocesser. |
| Mål | Krav uttryckta på formen av effekter, egenskaper eller tillstånd som ska uppnås eller upprätthållas. |
| Organisationskrav | Krav som reglerar utformning av en eller flera organisatoriska enheter som ska ingå i, använda eller förvalta systemet-i-fokus. |
| Processkrav | Krav som reglerar de processer som används för att konstruera och producera en given artefakt. |
| Regelverkskrav | Krav som specificerar hur regleringar i ett eller flera regelverk ska omhändertas av systemet-i-fokus eller dess systemlivscykelprocesser. |
| Systemkrav | Krav som på systemnivå specificerar utformning, beteende eller egenskaper för systemet-i-fokus. |
| Systemsäkerhetskrav | Krav som för en given artefakt specificerar nivå och utformning av dess systemsäkerhet. |
| Toppnivåkrav | Krav på den högsta abstraktionsnivån i en given kontext. |
| Tvingande krav | Krav som inte är förhandlingsbara till sin existens eller uppfyllnad. |
- Kravtypen mål existerar parallellt med de flesta övriga kravtyper. Till exempel kan ett antal användbarhetskrav vara nedbrutna från ett överordnat mål som därmed kan sägas vara ett användbarhetsmål. För att hålla Svensk kravterminologi så lättanvänd som möjligt listas dock övriga kravtyper endast en gång och med suffixet krav.
- Användbarhetskrav, cybersäkerhetskrav och systemsäkerhetskrav utgör olika typer av kvalitetskrav vars definitioner är kopplade till motsvarande egenskap. Definitionerna kommer från andra källor och beskriver egenskaperna på systemnivå. Under framtagandet av systemet kommer kraven att behöva brytas ner till krav på delsystem och komponenter, varför definitionerna för kravtyperna i Svensk kravterminologi är uttrycka att gälla för artefakter i allmänhet. Vidare uttrycker kravtypsdefinitionerna att kraven ska ange till vilken nivå egenskaperna ska uppnås. Syftet är att redan från början förmedla att de nämnda egenskaperna generellt inte uppnås i absoluta termer utan istället till en angiven nivå.
- Informationssäkerhetskrav har likheter med de ovan nämnda kraven avseende kvalitetsegenskapen och att det handlar om till vilken grad den ska uppnås men skiljer sig genom att grundegenskapen avser en informationsmängd och inte ett system. Informationssäkerhetskrav kan således också vara en delmängd av processkraven som exempelvis reglerar framtagandet av systemet-i-fokus.
- Organisationskrav kan dels användas för sociotekniska system där en organisatorisk enhet ingår i systemet-i-fokus, dels användas i sådana fall där en aktör av olika skäl har mandat att utfärda regler kring organisatoriska förutsättningar för ett systems användande. Det sistnämnda fallet har ofta kopplingar till lagar, förordningar, föreskrifter eller standarder. Generellt skiljer sig realiseringen av organisatoriska krav markant från övriga krav genom att det inte är leverantörerna utan istället de intressenter som ska använda eller förvalta systemet som behöver omhänderta kraven.
- Explicita, implicita och outtalade krav existerar på en högre abstraktionsnivå och listas därför inte som kravtyper. Att klassificera ett krav ingående i en kravmängd som outtalat eller implicit är dessutom något av en konceptuell motsägelse eftersom kravet i samma ögonblick som det specificeras övergår till att vara explicit.
Användbarhet och användarvänlighet
I vardagligt tal används ofta begreppet användarvänlighet i relation till exempelvis it-produkter. Ibland uttrycks det som en önskvärd egenskap i en kravspecifikation eller beställning, men kanske mer vanligt som något som saknas i ett befintligt system. I dessa sammanhang används begreppet ofta i absolut bemärkelse: antingen är systemet användarvänligt, eller så är det det inte. Verkligheten är sällan så enkel. De aspekter som brukar avses med användarvänlighet finns i olika grader. Uppfattningen om ett systems användarvänlighet beror sannolikt också på om det används till vad det är framtaget för eller till något helt annat. Ett annat och större problem är att begreppet saknar en vedertagen och precis definition. I boken Användarcentrerad systemdesign från 2002 (s. 57) skriver författarna (Göransson och Gulliksen):
Alla människor kan förhålla sig till användarvänlighet, men när man skall försöka att konkretisera vad man menar blir det mycket svårare.
Göranssons och Gulliksens bok utgår istället från begreppet användbarhet.
Förutom en tydlig definition som underlättar framtagandet av mätbara krav med precisa acceptanskriterier motsvarar användbarhet i större utsträckning engelskans usability
, vilket är det begrepp som vanligen används i det engelska fackspråket.
Termen usability
med tillhörande definition samt riktlinjer för hur det uppnås i olika sammanhang är dessutom standardiserade genom ISO 9241-11:2018 och relaterade standarder.
Termen med tillhörande definition är i all väsentlighet författarnas (Göranssons och Gulliksens) översättning av usability
med tillhörande definition i ISO 9241-11:1998, med skillnaden att system och tjänster har lagts till för att överensstämma med 2018 års utgåva av standarden (ISO 9241-11:2018).
Genom ordet utsträckning i definitionens inledning framgår det explicit att användbarhet inte ska ses som en binär egenskap som antingen existerar fullt ut eller är helt frånvarande. Detta återspeglas och tydliggörs ytterligare i definitionen för användbarhetskrav genom att den anger att det är en nivå av användbarhet som specificeras:
En annan viktig aspekt i definitionen för användbarhet är att de tre beståndsdelarna kopplas till, och bara behöver gälla för, en specificerad användare [...] att uppnå specifika mål [...] i ett givet användningssammanhang
. Detta ger nedanstående fördelar:
- Att redan från början specificera vilka användare systemet ska utformas för underlättar utvecklingsarbetet såväl som verifiering och validering.
- Om de specifika målen motsvarar eller är nedbrutna från intressentkraven inriktas användbarhets- och utvecklingsarbetet mot de behov som är viktigast för verksamheten. Därmed minskar också risken att systemet optimeras för teoretiska situationer som kanske aldrig uppstår.
- Genom att koppla kraven till givna användningssammanhang blir kraven i betydligt högre utsträckning verifierbara och de kan i många fall även göras mätbara.
- Användningssammanhangen kan till exempel uttryckas i form av användningsscenarier och användningsfall. Dessa arbetsprodukter kan också vara en del av acceptanskriterierna vid validering. De specifika användarna kan exempelvis uttryckas som personor.
- Avgränsningen utesluter inte att utvecklingsprocessen innehåller generella designregler som gäller för utformning av samtliga logiska och fysiska gränssnitt.
Användbarhetsdefinitionen består vidare av tre delar som var och en kan utgöra toppnivåkravet i en kravhierarki, som genom kravnedbrytning kan detaljeras till den nivå det är nödvändigt:
| Beståndsdel | Definition |
|---|---|
| Effektivitet | Resursåtgång i förhållande till uppnådda resultat. |
| Ändamålsenlighet | Noggrannhet och fullständighet med vilken användarna uppnår givna mål. |
| Tillfredsställelse | Den utsträckning till vilken en användares fysiska, kognitiva och emotionella reaktioner som uppstår vid användandet av systemet, produkten eller tjänsten möter dennes behov och förväntningar.(1) |
| (1) | Definitionen ur ISO 9241-11:2018 är översatt med tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO 9241-11:2018. |
- Effektivitet
med tillhörande definition är ursprungligen hämtad från Användarcentrerad systemdesign och är där författarnas översättning av
efficiency
med tillhörande definition i ISO 9241-11:1998. I 2018 års utgåva av standarden gjordes definitionen mer kortfattad, vilket föranledde motsvarande förändring i Svensk kravterminologi. - Tillfredsställelse
och dess definition ingår också i Användarcentrerad systemdesign, men i 2018 års utgåva av standarden ISO 9241-11 ändrades definitionen så mycket att en ny översättning blev nödvändig. Den nya versionen är mer heltäckande. Dock kan den föregående versionen (s. 62 i boken) möjligen vara enklare att förstå vid första genomläsningen (
Frånvaro av obehag samt positiva attityder vid användningen av ett givet system
). - Ändamålsenlighet
med tillhörande definition är hämtad från Användarcentrerad systemdesign och är författarnas översättning av
effectiveness
med tillhörande definition i ISO 9241-11:1998, vilken är identisk med definitionen i 2018 års utgåva av standarden. - Angående översättningarna av de engelska termerna
effectiveness
ochefficiency
kan det noteras att det svenska språket normalt inte gör någon skillnad mellan dessa två aspekter. Istället brukar båda termerna översättas till effektivitet med förlust av den ursprungliga distinktionen som konsekvens. För att möjliggöra så hög precision som möjligt i kravsammanhang utgår Svensk kravterminologi från Gulliksens och Göranssons översättningar där effektivitet kopplas till mängden förbrukade resurser (inklusive arbetstid) och ändamålsenlighet kopplas till precisionen i det utförda arbetet.
Olika typer av säkerhetskrav
Innebörden av säkerhet och säkerhetskrav har beroende på sammanhanget en mycket stor spännvidd. Detta kan illustreras genom termerna systemsäkerhet respektive cybersäkerhet. Suffixet är gemensamt men prefixen placerar begreppen inom två olika områden med skilda ursprung och traditioner. Dessa två områden benämns på engelska safety respektive security och båda översätts i regel till svenskans säkerhet, med resulterande förlust av språklig precision och risk för missförstånd. För att förklara de principiella skillnaderna mellan områdena är återigen systemsäkerhet och cybersäkerhet bra exempel:
- Grovt förenklat handlar systemsäkerhet inom engelskans safety om att förhindra att ett system till följd av konstruktionsfel eller fallerande komponenter orsakar skador på människor, egendom eller miljö. Inom systemsäkerhetsområdet kan exempelvis sannolikhetsberäkningar användas för att bedöma hur länge vissa komponenter eller delsystem håller och vid behov dubblera eller tredubbla dessa för att minska risken för olyckor.
- Cybersäkerhet och andra discipliner som faller under engelskans security handlar istället om att förhindra skadliga effekter till följd av medvetna antagonistiska handlingar. För cybersäkerhetsområdet är därför sannolikhetsberäkningar inte lika relevanta eftersom utfallet, utöver systemets konstruktion, också är beroende av antagonistens intention och förmåga. Att dubblera en kritisk komponent leder inte heller automatiskt till bättre säkerhet eftersom antagonisten ofta och med relativ enkelhet kan utnyttja samma svaghet en gång till.
De ovanstående principerna är förenklingar och det finns som alltid specialfall och undantag. Ett exempel är informationssäkerhet, som har en traditionell hemvist inom security men som omfattar skydd mot både antagonistiska hot och icke-antagonistiska händelser som kan påverka informationen.
Det finns även relationer och beroenden mellan områdena. Till följd av den fortsatta digitaliseringen får allt fler system och funktioner gränsytor mot omvärlden, vilket i många fall gör cybersäkerhet till en nödvändig förutsättning för systemsäkerhet. Därmed kommer cybersäkerhetskrav att uppstå vid kravnedbrytningen från exempelvis mål som specificerats för att uppnå önskad nivå av systemsäkerhet. Vidare är både cybersäkerhet och systemsäkerhet kvaliteter som är lika kritiska som svåra att verifiera och validera, där det ytterst handlar om förtroende och medvetna riskhanteringsbeslut. För att uppnå nödvändigt förtroende kan assuranskrav och därtill relaterade metoder för att visa kravuppfyllnad användas.
Utöver system-, informations- och cybersäkerhet tillkommer ytterligare områden som exempelvis brand- och elsäkerhet (som kan placeras inom safety) samt personalsäkerhet (som kan placeras inom security). Även om en heltäckande lista av alla yrkesområden som relaterar till olika typer av säkerhet ligger utanför Svensk kravterminologi visar de nyss nämnda exemplen att en viss försiktighet med säkerhetsbegreppet är nödvändig för att undvika missförstånd. Svensk kravterminologi rekommenderar därför att de mer specifika kravtyperna för respektive disciplin eller deldisciplin används där så är möjligt och att termen säkerhetskrav undviks i alla situationer där det inte är fullständigt uppenbart vad det är som avses.
Assuranskrav och assuransfall
Assuransbegreppet är nära kopplat till ett behov av att övertyga en oberoende granskare och i slutändan beställaren, eventuellt i kombination med ett certifieringsorgan, att systemet-i-fokus upprätthåller en eller flera önskade kvaliteter. Assurans är därför en dimension som ligger lika nära verifiering och validering som ett systems arkitektur och dess funktionalitet. Kärnan i begreppet liksom i definitionen är ett välgrundat förtroende för ett tillstånd som uttrycks genom en utfästelse:
En sådan utfästelse är i praktiken ett krav som uttrycks som en logisk utsaga. En utfästelse är därmed en form av assuranskrav men kravtypen inkluderar även exempelvis processkrav som reglerar hur det välgrundade förtroendet ska uppnås.
- Ett exempel på mycket hög abstraktionsnivå är en utfästelse om att systemet-i-fokus är tillräckligt säkert för användning i ett eller flera definierande sammanhang.
- Vad som är tillräckligt säkert beror bland annat på vilken risknivå certifieringsorganet och ytterst det omgivande samhället accepterar. Inom systemsäkerhetsområdet gäller generellt att ju större risken för personskador och dödsfall bedöms vara, desto hårdare blir kraven på leverantören avseende systemutformning och bevisföring.
- Behovet att kunna påvisa tillräckligt säkerhet har stor påverkan på hur system kan utformas och hur projekt kan bedrivas. Inom systemsäkerhetsområdet förekommer exempelvis branschspecifika krav där tillverkaren ska kunna visa att kritiska system är framtagna med processer och metoder som anpassats för aktuell risk- eller konsekvensnivå. Dessa processer och metoder regleras genom olika standarder och att i efterhand försöka påvisa efterlevnad är i det närmaste omöjligt. Detta innebär att krav-, design-, implementations- och verifieringsprocesserna från början måste utformas för att genom systemets livscykel kunna övertyga oberoende granskare om systemets och processernas ändamålsenlighet.
En struktur som underlättar att både uttrycka assuranskrav i form av utfästelser och att skapa förtroende för deras uppfyllnad är assuransfall:
Ett assuransfall kan förenklat beskrivas som en kombination av en kravhierarki och de artefakter som behövs för att verifiera kraven. Utfästelsen på toppnivån utgör således ett toppnivåkrav som kan brytas ner eller förfinas till mer detaljerade utfästelser.
- Även om ett assuransfall är en arbetsprodukt är det i regel kopplat till en metod där assuransfallet påbörjas tidigt i systemlivscykeln och därefter byggs på allt eftersom systemarkitekturen och de olika systemelementen tar form.
- Ett assuransfall kan ses som en generalisering av det ursprungliga konceptet
safety case
som, vilket namnet antyder, kommer från systemsäkerhetsområdet. Metoden förekommer exempelvis i systemsäkerhetsstandarder inom flyg- och fordonsbranschen. - Toppnivån för ett assuransfall kallas, beroende på standard, antingen utfästelse (
claim
) eller mål (goal
). Definitionen av mål är i Svensk kravterminologi framtagen för att vara kompatibel med bland annat assurans- och systemsäkerhetsområdet. - Mer information om assuransfall inklusive notationer och stöd för tillämpning finns exempelvis i ISO/IEC/IEEE 15026-2:2022 samt GSN Community Standard v3.
Kravmodeller
Delar av begreppsmodellen i avsnittet om grundläggande kravbegrepp kan användas som en metamodell som beskriver ett kravs olika beståndsdelar och till dessa kompletterande information. I ett projekt eller en organisation som hanterar krav behöver metamodellen omsättas i en eller flera skräddarsydda modeller som definierar struktur och villkor för de krav som ingår i en specifik kravmängd. En sådan skräddarsydd modell benämns kravmodell:
- Skillnaden mellan metamodellen och kravmodellen är att den första definierar att ett krav kan ha egenskaper och kravattribut. I den faktiska kravmodellen specificeras vilka egenskaper och kravattribut kraven ska ha. Detsamma gäller exempelvis val av notationer med tillhörande formalitetsgrader.
- Eftersom en kravmodell är anpassad för en specifik kravmängd kan det i en verksamhet eller inom ett systems livscykel behövas flera kravmodeller, exempelvis anpassade för olika abstraktionsnivåer eller kompetensområden.
Kravnotationer
Termerna notation och kravnotation definieras enligt nedan:
| Term | Definition |
|---|---|
| Notation | En beskrivningsteknik avsedd för ett specifikt syfte. |
| Kravnotation | En notation som används för specificering av krav. |
Skillnaden i hur definitionerna är formulerade med avsedd respektive används är avsiktlig. Motivet är att många av de notationer som används för att specificera krav antingen är generella eller ursprungligen framtagna för ett annat syfte. Om termen kravnotation hade definierats så att kravspecificering utgjorde det primära syftet skulle definitionens omfattning bli så snäv att den praktiska nyttan skulle begränsas.
Notationer kan kategoriseras utifrån formalitetsgrad (formell, semiformell eller informell) och presentationsform (grafisk eller textuell). En notation har dock alltid en formalitetsgrad och en presentationsform. En presentationsform anses i Svensk kravterminologi vara grafisk även om de grafiska elementen innehåller text. Formalitetsgraden har tre olika nivåer, som bestäms utifrån notationens syntax och semantik:
| Formalitetsgrad | Definition |
|---|---|
| Formell notation | En beskrivningsteknik vars syntax och semantik är fullständigt definierad.(1) |
| Semiformell notation | En beskrivningsteknik vars syntax är fullständigt definierad men där semantiken kan vara ofullständig.(1) |
| Informell notation | En beskrivningsteknik som saknar fullständigt definierad syntax.(1) |
| (1) | Definitionen ur ISO 26262-1:2011 är översatt med tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO 26262-1:2011. |
För att formalitetsgraderna ska vara användbara krävs tydliga definitioner för fullständigt definierad syntax och semantik:
Formalitetsgraden och presentationsformen är oberoende av varandra. Några exempel på notationer ges i tabellen nedan. Notationen naturligt språk bör nämnas särskilt eftersom den utan tvekan är den mest använda.
| Notation | Presentationsform | Formalitetsgrad |
|---|---|---|
| Naturligt språk | Textuell | Informell |
| Begränsat naturligt språk | Textuell | Informell eller semiformell beroende på hur språket har begränsats. |
| Unified Modeling Language (UML) | Grafisk | Semiformell |
| Första ordningens logik (FOL) | Textuell | Formell |
| Petrinät | Grafisk | Formell |
- Det innevarande avsnittet är till del baserat på översatt material från kapitel två och sju i examensarbetesrapporten Unambiguous Requirements in Functional Safety and ISO 26262: Dream or Reality?.
- Formalitetsgraden i en notation har inget att göra med stilnivån i ett textstycke. Ett formellt skrivet dokument är alltså inte samma sak som ett eller flera krav uttryckta med formell notation. Här finns dock en överhängande risk för sammanblandning och missförstånd. Särskild försiktighet bör iakttas kring formuleringar som formella specifikationer eftersom det i litteraturen används i båda fallen.
Kravschabloner och kravmönster
Två termer som är lätta att blanda ihop är kravschablon och kravmönster, där endast den förstnämnda egentligen kan sägas ha en direkt koppling till notationer. I Svensk kravterminologi ges termerna följande definitioner då dessa tycks stämma bäst överens med begreppsbildningen inom den akademiska forskningen:
Ordet mönster har valts eftersom den engelska motsvarigheten (pattern
) är väletablerad inom arkitektur (Christopher Alexander) och mjukvara (Gang of Four
, med deras klassiska bok som har inspirerats av Christopher Alexander).
Den engelska termen requirement patterns
har även fått fotfäste inom den akademiska kravteknikforskningen, med en betydelse motsvarande den ovanstående definitionen för kravmönster.
När det gäller kravschablon kallas det även för kravmall, men termen schablon förespråkas av två skäl:
- Den traditionella betydelsen av schablon förefaller semantiskt vara närmare det engelska begreppet
boilerplate
som det beskrivs i Requirements Engineering (Hull m.fl.). - Det bedöms vara enklare att hålla isär termerna kravschablon och kravmönster än vad det är att skilja på termerna kravmönster och kravmall.
Egenskaper för krav och kravmängder
Både krav och kravmängder kan ha en eller flera egenskaper som kan existera enskilt eller i relation till andra krav, till associerade kravattribut och kravmängdsattribut samt till sådana artefakter och system vars existens kraven är framtagna för att bidra till. Dessa egenskaper benämns kravegenskap respektive kravmängdsegenskap och beskrivs närmare i de kommande delavsnitten.
Egenskaperna existerar i olika utsträckning och påverkas bland annat utifrån hur kraven är uttryckta samt bidraget från enskilda krav till en större helhet när dessa grupperas tillsammans i en kravmängd. De kravegenskaper och kravmängdsegenskaper som är önskvärda för en given samling krav kan specificeras genom en för ändamålet anpassad kravmodell. Att samlingen med dess ingående krav uppfyller specificerade egenskaper säkerställs genom aktiviteten kravverifiering.
Egenskaper för enskilda krav
En egenskap för ett enskilt krav benämns kravegenskap och definieras enligt nedan:
De kravegenskaper som ingår i Svensk kravterminologi listas i nedanstående tabell.
| Kravegenskap | Definition |
|---|---|
| Atomärt | Kravet kan inte delas upp i ytterligare krav på samma abstraktionsnivå. |
| Entydigt | Kravet har en och endast en möjlig semantiskt tolkning. |
| Explicit | Kravet uttrycker enbart det som ska realiseras eller på annat sätt uppnås. |
| Fullständigt | Kravet innehåller tillsammans med dess kravattribut all information som är nödvändig för förståelsen för vad som ska realiseras eller på annat sätt uppnås. |
| Genomförbart | Kravet är möjligt att realisera inom organisationens eller projektets givna ramar. |
| Korrekt | Kravet är fritt från interna motsägelser och andra felaktigheter samtidigt som de semantiska och syntaktiska reglerna för dess notation är uppfyllda. |
| Mätbart | Kravet är uttryckt så att det är praktiskt möjligt att kvantifiera i vilken utsträckning det är uppfyllt. |
| Nödvändigt | Kravets frånvaro innebär att ett överenskommet intressentbehov inte kan tillgodoses eller att ett överordnat krav i en kravhierarki inte kan realiseras. |
| Verifierbart | Kravet är uttryckt så att det är praktiskt möjligt att subjektivt eller objektivt avgöra i vilken utsträckning det är uppfyllt. |
| Ändamålsenlig notation | Kravet är uttryckt i en notation som är lämplig för kravets användningsområde och abstraktionsnivå. |
Entydighetsegenskapen är ett av de begrepp som förekommer i princip i all litteratur och alla standarder inom området. Ibland uttrycks det som dess negation, det vill säga att krav inte ska vara tve- eller mångtydiga. I Svensk kravterminologi har entydigt valts som namn på termen eftersom det blir mer konsekvent i relation till de övriga kravegenskaperna samt att det generellt är bättre att uttrycka det önskade tillståndet framför negationen av ett eller flera oönskade tillstånd.
I vilken utsträckning entydighet kan uppnås beror till stor del på valet av kravnotation. Till exempel konstateras utmaningarna med den inneboende tvetydigheten i naturligt språk redan i 1984 års utgåva av IEEE Std 830-1998 -- IEEE Recommended Practice for Software Requirements Specifications. För att uppnå entydighet utifrån ordets innebörd krävs en notation som har både fullständigt definierad syntax och fullständigt definierad semantik.
- I andra källor uttrycks kravegenskapen fullständigt ofta utan tillägget avseende kravattribut. Detta kan lätt leda till ett motsatsförhållande till kravegenskapen explicit. Genom att placera tilläggsinformation som exempelvis syfte eller bakomliggande analyser i ett eller flera kravattribut kan egenskaperna explicit och fullständigt istället komplettera varandra.
- Angående korrekthetsegenskapen kan motsägelser exempelvis uppstå när en gemensam definitionslista uppdateras i syfte att förtydliga eller specificera ett annat krav. Ett annat exempel på felaktigheter är saknade eller inkompatibla enheter och storheter.
- Kravegenskapen nödvändigt förekommer ofta med en mer generell definition i andra källor. För att dra nytta av den sammanhängande begreppsapparat som är ett av målen för Svensk kravterminologi har egenskapen i terminologin getts en definition som relaterar till intressentbehoven samt metoden att utgå från toppnivåkrav som successivt detaljeras till lämplig abstraktionsnivå.
- Kravegenskaperna verifierbarhet och mätbarhet är likartade men uttrycker en skillnad i precision. Ett krav som inte är mätbart kan fortfarande vara verifierbart. Verifierbarhetsegenskapen innehåller i sin tur två nivåer genom att kravuppfyllnaden kan avgöras på subjektiva eller objektiva grunder. Objektiva grunder är generellt att föredra men är inte alltid praktiskt möjligt. Formuleringen praktiskt möjligt avser att verifieringen och de artefakter som ligger till grund för den måste kunna genomföras inom de tidsmässiga och övriga resursramar som är tillgängliga för systemarbetet. Oavsett precision kan kravet behöva kompletteras med kravattributet acceptanskriterium som beskriver former för hur kravuppfyllnaden ska bedömas.
I det dagliga kravarbetet kommer, även med stöd av en kravmodell, avvägningar av i vilken utsträckning de olika egenskaperna ska uppnås att behöva göras. Vissa av egenskaperna, exempelvis entydighet är till exempel svåra eller omöjliga att uppnå med de metoder som oftast används för att specificera krav. I andra fall kan egenskaper dragna till sin spets leda till merarbete och minskad överblick över kravmängden. Ett exempel är egenskapen atomärt där det ibland kan underlätta förståelsen och samtidigt minska antalet krav genom att använda konjunktioner för att kombinera mer än ett villkor i ett och samma krav. Kravhantering är därmed en konstform där teoretiska kunskaper behöver kombineras med beprövad erfarenhet samt omsättas i metodik och processer anpassade för respektive projekt och organisation.
Egenskaper för kravmängder
En egenskap för en kravmängd benämns kravmängdsegenskap och definieras enligt nedan:
De kravmängdsegenskaper som ingår i Svensk kravterminologi listas i nedanstående tabell.
| Kravmängdsegenskap | Definition |
|---|---|
| Förvaltningsbar | Kravmängden är strukturerad på ett sätt som gör det enkelt att lägga till, ändra och ta bort krav i den. |
| Komplett | Kravmängden innehåller samtliga krav som behövs för att den ska uppfylla sitt syfte. |
| Konsistent | Kravmängden innehåller inga krav som säger emot något annat krav i mängden och varje enskild företeelse benämns på samma sätt i samtliga krav där den förekommer. |
| Restriktiv | Kravmängden innehåller enbart krav som behövs för att den ska uppfylla sitt syfte. |
| Spårbar | Kravmängden är strukturerad så att det finns spårbarhet mellan de krav som ingår i mängden. |
| Tillförlitlig | Det finns assurans för att kravmängden är lämplig att använda i enlighet med sitt syfte. |
| Väldefinierad | Kravmängden är tydligt definierad avseende sitt syfte, användningsområde och omfattning. |
- Flera av kravmängdsegenskapernas definitioner hänvisar till kravmängdens syfte. Dessa egenskaper förutsätter därmed egenskapen väldefinierad. Den information som gör en kravmängd väldefinierad kan exempelvis representeras genom kravmängdsattributet kravmängdsdefinition.
- Kravmängdsegenskaperna komplett och restriktiv är båda direkt kopplade till kravmängdens syfte och samverkar avseende kravmängdens totala kvalitet. Om båda egenskaperna är uppfyllda innehåller kravmängden precis de krav som behövs för att uppnå syftet med mängden. Om ingen av dem är uppfyllda är kravmängden ofullständig samtidigt som den innehåller krav som inte bidrar till syftet för mängden.
Namnet på kravmängdsegenskapen konsistent har valts dels för att det liknar den engelska motsvarigheten, dels för att det uttrycker ett önskat läge direkt istället för att som i exempelvis motsägelsefritt ange ett negerat oönskat läge. En koncis beskrivning av ordets generella innebörd finns i Nationalencyklopedin (NE), med Östen Dahl som författare:
konsiste'nt (latin consi'stens, presens particip av consi'sto
bli stående
,stanna
m.m.), motsägelsefri, om utsaga som inte innehåller eller ur vilken inte kan härledas någon motsägelse.- Restriktivitetsegenskapen har en relation till det oönskade tillståndet kravglidning genom att begreppen utgör motsatta sidor av samma grundläggande förhållande. Uttryckt annorlunda innebär en icke-restriktiv kravmängd att kravglidning föreligger.
- Kravmängdsegenskapen spårbar är avgränsad till att enbart gälla spårbarhet mellan de krav som ingår i mängden och inte till krav eller artefakter utanför mängden i fråga.
- Om en kravmängd är organiserad i en kravhierarki där hierarkins toppnivåkrav utgör grunden för kravmängdens syfte kommer kravmängden, förutsatt korrekt kravnedbrytning och kravförfining, automatiskt att vara både spårbar och restriktiv. När den rekursiva kravnedbrytningen genomförts till den nivå syftet anger kommer kravmängden också att vara komplett.
- Tillförlitlighetsegenskapen har likheter med, men går utöver, kravmängdsegenskapen komplett. Bland annat behövs någon form av evidens för att kravmängden faktiskt är komplett. Vidare kan kravmängdens användningsområde förutsätta att ett antal individuella kravegenskaper är uppfyllda, exempelvis relaterat till kravens korrekthet och verifierbarhet. Till stöd för att uppnå önskad tillförlitlighet kan kravverifiering utifrån en för kravmängden framtagen kravmodell genomföras.
Kravattribut och kravmängdsattribut
Ett kravattribut utgör tilläggsinformation som kopplas till ett krav utan att utgöra en del av det faktiska kravet. På motsvarande sätt är ett kravmängdsattribut tilläggsinformation som kopplas till en kravmängd utan att utgöra ett krav i den aktuella kravmängden.
- Inom kravområdet inklusive standarden ISO/IEC/IEEE 29148:2011 används begreppet attribut med ovanstående innebörd, det vill säga i betydelsen av tilläggsinformation som kopplas till en entitet, istället för att som i ordinarie språkbruk vara en inneboende del av entiteten i fråga. Till följd av de skilda betydelserna bör termen attribut utan preciserande prefix användas med försiktighet och i förekommande fall på ett sådant sätt att det av sammanhanget framgår vilken av de två betydelserna det är som avses. För att minska risken för missförstånd hänvisar definitionen av attribut i Svensk kravterminologi till kravattribut och kravmängdsattribut.
- Även om tilläggsinformationen i form av kravattribut inte är en del av det faktiska kravet kan informationen i attributen vara avgörande för att förstå kravets bakgrund och övriga sammanhang.
Kravattribut
Kravattribut definieras enligt nedan:De kravattribut som ingår i Svensk kravterminologi listas i nedanstående tabell. Kravattributen är beskrivna i singular men ett givet attribut kan med olika innehåll förekomma flera gånger kopplat till ett och samma krav. Innehållet i ett kravattribut kan även bestå av en lista eller en förteckning, vilket exempelvis är fallet för attributet revisionshistorik. En anpassad uppsättning kravattribut med regler för hur dessa uttrycks kan specificeras genom en kravmodell.
| Kravattribut | Definition |
|---|---|
| Acceptanskriterium | En informationsmängd som specificerar vad som ska vara utfört eller existera, inklusive hur detta ska ha verifierats, för att kravet ska anses vara uppfyllt. |
| Bakgrund | En eller flera referenser till artefakter som beskriver de behov och förväntningar som ligger till grund för kravet. |
| Källa | En uppgift om från vilken intressent eller artefakt som kravet kommer. |
| Prioritet | Ett mått på kravets betydelse för en given intressent, uttryckt i en prioritetsskala. |
| Revisionshistorik | En förteckning över de förändringar av kravet som skett under dess livscykel. |
| Stabilitet | Ett mått på sannolikheten att kravet kommer att förbli oförändrat under ett givet tidsintervall. |
| Status | En uppgift om kravets tillstånd i dess aktuella kontext. |
| Svårighetsgrad | Ett mått på hur svårt kravet bedöms vara att realisera. |
| Syfte | En beskrivning av den effekt som kravet genom dess realisering förväntas uppnå eller bidra till. |
| Typ | En uppgift om vilken kravtyp som kravet tillhör. |
| Unik identifierare | En identitetsbeteckning som i en given kontext gör det möjligt att entydigt referera till kravet. |
| Ägare | En uppgift om vem som är kravägare för kravet i dess aktuella livscykel. |
- Den uppsättning kravattribut som behövs i ett givet fall beror på de processer som används. Utöver de kravattribut som listas i Svensk kravterminologi finns ytterligare förslag i litteratur och standarder. Därutöver kan exempelvis organisations- eller systemspecifika attribut vara aktuella. Det finns dock inget egenvärde i att ha många kravattribut. Det faktiska innehållet för attributen behöver, för varje enskilt krav, först specificeras och därefter förvaltas under kravets fortsatta livscykel. Valen av attribut bör därför ske utifrån den bedömda nyttan av varje attribut avvägt mot de resurser som behövs för attributets specifikation och förvaltning multiplicerat med det bedömda antalet krav med attributet i fråga.
- Exempel på artefakter som kan utgöra kravets källa är lagar och förordningar, organisationsinterna regelverk samt kravsamlingar som skapats i syfte att inkluderas i kravmängden för flera olika system. Referensen bör vara så specifik som möjligt och i förekommande fall inkludera unika identifierare.
- I definitionen för attributet prioritet ingår förtydligandet för en given intressent eftersom olika intressenter ofta tilldelar ett och samma krav olika betydelse utifrån sina respektive behov eller ansvarsområden. Om inte intressenten i fråga tydligt framgår av sammanhanget kan det vara lämpligt att i attributet eller kravmodellen specificera vems prioritering det är som avses.
- Omfattningen av attributen revisionshistorik och stabilitet kan även utökas till att inkludera ett urval av kravets attribut.
- Exempel på värden för attributet status är inkommet, ofullständigt, preliminärt, godkänt, behöver revideras och upphävt.
- Om attributet svårighetsgrad används behöver ett vägval göras om bedömningen enbart ska avse realiseringen eller om den också ska omfatta verifiering inklusive påvisandet av kravets fullständiga uppfyllnad.
- Om attributet ägare anger en organisation bör attributet om möjligt kompletteras med en specifik individ som företräder organisationen för kravet i fråga. Motsvarande kan vara aktuellt även för attributet källa, som i vissa fall också sammanfaller med kravets ägare.
- Beroende på arbetsmetodik kan även attribut som beroende och uppfyllnad vara aktuella. Dessa kräver dock antingen att information från andra källor med viss regelbundenhet hämtas och analyseras manuellt eller ett systemstöd som kan hantera en kedja av relationer mellan kraven och arkitekturbeskrivningen, mellan arkitekturbeskrivningen och de framtagna systemelementen samt, i fallet uppfyllnad, mellan systemelementen och resultaten från verifieringsprocessen.
- Ett exempel på projekt- eller processpecifik tilläggsinformation som kan lagras som kravattribut är om vissa krav behöver omformuleras med andra notationer än vad kravet är uttryckt i, vilket kan vara aktuellt för att underlätta kommunikation med specifika målgrupper.
Kravmängdsattribut
Kravmängdsattribut definieras enligt nedan:Hur de olika kravmängdsattributen ska namnges och definieras beror i stor utsträckning på respektive organisations processer och systemstöd i form av exempelvis kravhanteringssystem. Därför ingår för närvarande bara kravmängdsattributet kravmängdsdefinition i Svensk kravterminologi, vilket listas i nedanstående tabell.
| Kravmängdsattribut | Definition |
|---|---|
| Kravmängdsdefinition | En specificering av kravmängdens syfte, användningsområde och omfattning. |
Några ytterligare tänkbara kravmängdsattribut kan vara vem som förvaltar kravmängden, tidpunkt för senaste ändring och när samtliga krav i mängden senast kontrollerats avseende uppfyllande av en eller flera krav- eller kravmängdsegenskaper.
Kravrelaterade arbetsprodukter
I tabellen nedan finns en lista över olika kravrelaterade arbetsprodukter som kan komma att tas fram eller användas under ett systems livscykel. Vilka arbetsprodukter som är relevanta för ett givet system eller projekt kommer bland annat att bero på systemets komplexitet samt valet arbets- och kontraktsformer. Arbetsprodukterna har även olika relevans och användningsområden beroende på var i livscykeln ett projekt eller system befinner sig.
| Arbetsprodukt | Definition |
|---|---|
| Användarberättelse | En kort beskrivning av en uppgift som en specifik användare vill utföra i systemet-i-fokus för att uppnå ett specifikt syfte. |
| Användningsfall | En steg för steg-beskrivning av hur en aktör interagerar med systemet-i-fokus för att lösa en specifik uppgift. |
| Användningsfallsdiagram | En grafisk representation som visar systemet-i-fokus tillsammans med ett eller flera associerade användningsfall. |
| Användningsscenario | Ett scenario som beskriver hur systemet-i-fokus används i en specifik situation för att lösa ett eller flera verksamhetsbehov. |
| Arkitekturbeskrivning | En beskrivning av ett systems arkitektur. |
| Assuransfall | En verifierbar artefakt som tillhandahåller ett övertygande och giltigt argument för att en utfästelse är sann baserat på konkreta evidens i en angiven kontext.(1) |
| Design | En konkretisering av arkitekturen för ett system som preciserar utformningen av ett eller flera systemelement och till dessa associerade egenskaper, relationer och gränssnitt till sådan detaljnivå att de krav som allokerats till systemelementen i fråga kan realiseras i fysiska eller logiska arbetsprodukter. |
| Evidens | En artefakt som objektivt styrker att en utfästelse är sann. |
| Intressentbehovssammanställning | En artefakt innehållande de intressentbehov som ska tillgodoses genom systemet-i-fokus. |
| Intressentförteckning | En förteckning över de intressenter som är relevanta för systemet-i-fokus, inklusive information om de olika intressenternas relation till systemet. |
| Intressentkravssammanställning | En artefakt innehållande en konsistent samling krav som utgör de sammanlagda intressentkrav som systemet-i-fokus och dess systemlivscykelprocesser ska realisera. |
| Kontextdiagram | En grafisk representation som visar systemgränsen för systemet-i-fokus, vilka stödsystem systemet-i-fokus är beroende av, samt andra aspekter både inom och utanför systemgränsen som är relevanta för att sätta systemet-i-fokus i sitt sammanhang. |
| Kravmodell | En modell för krav som, anpassad för en specifik kravmängd, specificerar form och egenskaper för de ingående kraven samt deras tilläggsinformation i form av kravattribut med tillhörande villkor. |
| Kravspecifikation | Ett eller flera dokument som innehåller ett eller flera krav som har strukturerats för ett särskilt syfte. |
| Persona | En verklighetstrogen och levande beskrivning av en fiktiv person. |
| (1) | Definitionen ur ISO/IEC/IEEE 15026-2:2022 är översatt med tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO/IEC/IEEE 15026-2:2022. |
- En persona kan helt eller delvis vara baserad på en verklig person. I sådana fall är det bra att inhämta samtycke från personen i fråga. Detta gäller särskilt för eventuella porträtt eller fotografier.
- Begreppen användningsfall och användningsfallsdiagram har kopplingar till UML (Unified Modelling Language). Därför används också UML-begreppet aktör i definitionen för användningsfall. (En aktör är inte synonymt med en mänsklig användare, utan kan till exempel vara ett annat system.)
- Skillnaden mellan ett användningsscenario och ett användningsfall är framför allt att de förekommer på olika abstraktionsnivåer. Användningsscenariot fokuserar på ett verksamhetsbehov som ska tillgodoses med hjälp av systemet-i-fokus, medan ett användningsfall i regel används för att på en detaljerad teknisk nivå specificera interaktioner mellan en aktör och systemet-i-fokus eller en av dess ingående delar. Ett och samma användningsscenario kan därför ha flera relaterade användningsfall. Detta kan exemplifieras med ett användningsscenario som beskriver hur en hotellreceptionist hjälper en redan incheckad kund som önskar byta rum. För att göra detta behöver receptionisten bland annat använda hotellets bokningssystem. Receptionistens interaktion med bokningssystemet för att registrera bytet beskrivs av ett eller flera användningsfall.
- Användarberättelser är vanligt förekommande i mjukvarubranschens agila metoder. En vanlig uttrycksform är
Som en [...] vill jag [...] för att [...]
. Det går att diskutera huruvida en användarberättelse är en arbetsprodukt eller en kravnotation. Uttrycksformen ovan (eller egentligen reglerna för den) kan sägas vara en kravschablon, och innehållet är typiskt ett krav på en hög abstraktionsnivå. Begreppet listas trots allt här för att tydliggöra skillnaden (och därigenom minska risken för förväxling) gentemot användningsfall och användningsscenarier. - Ett begrepp som avsiktligt har exkluderats från listan över arbetsprodukter är användarfall. När det används brukar innebörden vara den samma som för användningsfall eller användningsscenario. Svensk kravterminologi förespråkar därför att någon av dessa termer används istället. Även rent språkligt förefaller prefixet användnings lämpligare eftersom innebörden beskriver användning snarare än användare.
Kravroller
I tabellen nedan finns en lista över de kravrelaterade roller som förekommer i Svensk kravterminologi.
| Roll | Definition |
|---|---|
| Beställare | En intressent som anskaffar eller upphandlar en produkt eller en tjänst från en leverantör.(1) |
| Intressent | En individ eller organisation som påverkas av, eller har inflytande över, ett systems utformning eller existens. |
| Kravägare | En individ eller organisation som bestämmer över existensen och utformningen av ett specifikt krav i en given kontext. |
| Leverantör | En organisation eller individ som ingår en överenskommelse med en beställare om att tillhandahålla en produkt eller en tjänst.(1) |
| Nyckelintressent | En intressent vars inflytande är avgörande för existensen eller nyttjandet av systemet-i-fokus. |
| (1) | Definitionen ur ISO/IEC/IEEE 15288:2015 är översatt med tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO/IEC/IEEE 15288:2015. |
Avslutning — relationen mellan metodik, termer och terminologin
Kontraktsform såväl som projekt- och utvecklingsmetodik påverkar hur olika kravaktiviteter kan genomföras och därmed vilka kravtyper och kravnotationer som är lämpliga. Den metodik som används avgör även vilka egenskaper för krav och kravmängder som är möjliga att uppnå. Med andra ord finns det beroenden mellan metodiken och uppsättningen termer med tillhörande definitioner. Valet av kravtermer i ett givet projekt bör därför väljas med omsorg för att stödja aktiviteterna i de samverkande livscykelprocesserna.
Relationen är dubbelriktad. De kravtermer som används i ett projekt eller i en process påverkar, oavsett om de väljs explicit eller slentrianmässigt, hur kravarbetet bedrivs och därmed också arbetsprodukterna och det resulterande systemet. Om termerna är anpassade för en annan projektmetodik än den som används är risken överhängande att kravprocesserna blir inkompatibla med övriga processer samt leder till konflikter mellan beställaren och leverantören, såväl som till interna konflikter inom respektive part.
Som avslutning på Terminologi med förklaringar presenteras därför, tillsammans med den tänkta metodik som genomsyrar terminologin, varför vissa begrepp som förekommer i andra källor är exkluderade eller är markerade med användning avrådes alternativt använd med försiktighet. Avsnittet är skrivet som en förklarande bilaga och kommer sist för att det dels beskriver varför terminologin ser ut som den gör snarare än att införa nya termer, dels för att kunna referera till de koncept och termer som presenterats i de föregående delarna.
Av de två inledande avsnitten i Terminologi med förklaringar framgår att kravprocesserna förväntas interagera med övriga systemlivscykelprocesser samt att terminologin är anpassad för att stödja arbetet med komplicerade eller komplexa tekniska och sociotekniska system. Detta innebär att system- och kravarbetet behöver kunna hantera de nedanstående faktorerna:
- Ett eller flera av intressenternas behov och krav kommer att ändras under både utvecklings- och användningsfasen. Detta sker dels för att beställaren enskilt och i dialog med leverantören ökar sin förståelse för behoven allt eftersom systemet tar form, dels för att den verksamhet som systemet ska stödja inte är statisk utan förändras i takt med omvärlden.
- De tillgängliga resurserna för att producera och förvalta systemet under hela dess livslängd är ändliga, vilket medför att prioriteringar mellan olika krav och intressenter kommer att behöva hanteras under systemlivscykeln.
- Varje krav som införs för ett projekt eller system medför en kostnad för att hantera kravet under dess livscykel, vilket omfattar allt ifrån kravfångst och specifikation med tillhörande kvalitetssäkring till verifiering och dokumentation av att kravet är omhändertaget i det resulterande systemet.
De ovanstående antagandena och faktorerna leder till en viktig princip att det endast undantagsvis är möjligt eller önskvärt att beställaren som första steg i anskaffningsprocessen skapar en komplett kravspecifikation som sedan lämnas över till leverantören för implementation, som slutligen återkommer med en färdig produkt som förhoppningsvis löser intressenternas behov. Detta gäller särskilt för system där viktiga systemelement utgörs av mjukvara.
Ett exempel på undantag är när beställaren själv ansvarar för designen men utkontrakterar tillverkningen. Detta kan också ske för specifika delkomponenter som exempelvis mekaniska delar eller kretskort.
Den metodik som Svensk kravterminologi utgår ifrån innebär istället att beställaren och leverantören samarbetar under framtagningen och att båda parters kravprocesser interagerar med övriga livscykelprocesser. Både krav- och övriga processer förutsätts vara utformade utifrån en förståelse om att krav både kommer att tillkomma och förändras under arbetets gång. Detta förhållningssätt är långt ifrån nytt. Redan i den första utgåvan från 1984 av IEEE Std 830-1998 -- IEEE Recommended Practice for Software Requirements Specifications framgår att beställaren och leverantören bör samarbeta med att ta fram programvaruspecifikationen. I standarden framgår också att det kan vara omöjligt att specificera alla detaljer från början och att det behöver finnas former för att på ett kontrollerat och uppföljningsbart sätt hantera förändringar.
Vidare innebär det iterativa arbetssätt som Svensk kravterminologi utgår från att systemets arkitektur och därmed arkitekturbeskrivningen är i centrum för utvecklingen. Framtagningen av arkitekturbeskrivningen förväntas ske parallellt med kravnedbrytningsaktiviteter där kraven med dess acceptanskriterier kopplas till de systemelement som på olika nivåer i arkitekturen realiserar kraven.
Om det till följd av systemsäkerhetskrav eller assuranskrav är nödvändigt att visa att användning av systemet inte medför oacceptabel risk för förlust av människoliv eller andra värden är metodiken kompatibel med nyttjande av assuransfall. Även assuransfall förutsätter ett iterativt arbetssätt som integreras med övriga processer genom att den argumentation som tas fram bland annat ger upphov till krav på arkitekturens utformning samt specifika krav som behöver realiseras i ett eller flera systemelement. Den dokumentation som resulterar från verifieringsprocessen kan i sin tur utgöra evidens i assuransfallet.
- Huruvida assuransfallet och dess innehåll i sig används som en del av kravmängden, arkitekturbeskrivningen eller som en fristående arbetsprodukt som föder de två förstnämnda behöver avgöras inom varje projekt. Det avgörande är att utforma de olika processerna på ett sådant sätt att dubbelarbete undviks samtidigt som spårbarhet upprätthålls och konflikter mellan olika krav kan identifieras och hanteras.
- På samma sätt som assuransfallet kan inkludera artefakter från den generella verifieringsprocessen, kan den sistnämnda stödjas av evidens som tagits fram för assuransfallet. Även här behöver processerna utformas för att stödja varandra istället för att leda till dubbelarbete.
Sammantaget utgår Svensk kravterminologi från en metodik som, med eller utan assuransfall, innebär att kraven successivt och iterativt bryts ner och förfinas till dess att alla avgörande designval är gjorda, med etablerad spårbarhet mellan kraven på de olika nivåerna och till dessa relaterade arbetsprodukter. Detta gör det möjligt att följa varje intressentkrav och andra toppnivåkrav hela vägen ner till det färdiga systemets olika beståndsdelar. Kravhierarkin som därmed uppstår innebär att den högsta nivån förmedlar vad som ska göras, vilket i nästa nivå omsätts till hur det löses, vilket i sin tur utgör flera nya vad för nästa underliggande hur-nivå. Hierarkin fortsätter på motsvarande sätt till dess att ingen ytterligare nedbrytning behövs.
Vilken part som genomför vilka delar av kravnedbrytningen och till vilken nivå är upp till varje enskilt projekt att ta ställning till. Beställaren bör dock alltid se till att intressentkraven är nedbrutna och förfinade till lämplig nivå utifrån vald kontraktsform samt sina egna och leverantörens styrkor och svagheter.
Metodiken med kravnedbrytning och den resulterande kravhierarkin ska inte tolkas som en vattenfallsmodell där varje nivå måste vara färdig innan nästa nivå kan påbörjas och utan möjlighet att gå tillbaka. Som redan har nämnts förväntas krav- och arkitekturarbetet ske iterativt. Detta kan göras på olika sätt beroende på typen av system och andra förutsättningar. Till exempel kan arbetet initialt utgå från ett särskilt prioriterat intressentkrav där de mellanliggande nivåerna endast specificeras översiktligt eller genom antaganden, för att sedan på lägre nivåer detaljera och utvärdera viktiga designval. Därefter kan en ny iteration påbörjas där de mellanliggande nivåerna detaljeras och med tillhörande arkitektur- och systemelement.
Vidare så kommer konflikter mellan krav att uppstå i nedbrytningen. Dessutom kan insikter nås om att vissa krav inte kan realiseras utifrån hur systemarkitekturen har utformats. Båda dessa fall kan innebära att ett eller flera krav behöver förändras, vilket i förlängningen kan medföra att ett av de överenskomna intressentkraven inte längre går att realisera. I ett sådant läge kan en ny överenskommelse om omfattningen för systemet-i-fokus behöva nås med berörda intressenter, vilket i sin tur kommer att påverka ett flertal underliggande krav samt de arkitektur- och systemelement som dessa påverkar. För att genomföra de nödvändiga förändringarna krävs därmed ytterligare iterationer för att vidareutveckla redan framtagna arbetsprodukter.
Ovanstående översiktligt beskrivna metodik genomsyrar Svensk kravterminologi och utgör grunden för valet av termer med tillhörande definitioner samt begreppsmodellen som beskriver dess relationer. Eftersom metodiken gör ett antal antaganden om hur arbetet bedrivs är det också naturligt att den i några fall är svår att förena med vissa begrepp och koncept från andra utvecklingsmetoder, liksom begrepp och koncept som funnits länge och ibland används av gammal hävd snarare än av explicita vägval. Två exempel på sådana utmaningar avhandlas i de följande delavsnitten.
Lösningsoberoende krav kontra begränsningar
En egenskap för krav som ibland förespråkas, särskilt när det gäller mjukvaruutveckling, är att krav ska vara lösningsoberoende eller (synonymt) lösningsfria. Motivet, vilket i sig är eftersträvansvärt, är att inte i förväg låsa det fortsatta arbetet till den eventuella lösning som kravställaren initialt ser framför sig. Om en sådan egenskap införs för krav i allmänhet medför det dock två konsekvenser:
- Kraven får aldrig brytas ner till en sådan nivå att det framgår hur de ska realiseras.
- Alla tänkbara lösningar måste kunna accepteras av beställaren.
Den första konsekvensen innebär annorlunda uttryckt att kraven inte får brytas ner till en sådan detaljnivå att några faktiska designval görs. Därmed ska krav enbart tas fram av beställaren och hållas på de högre abstraktionsnivåerna, vilket i princip förutsätter att bland annat arkitektur- och implementeringsprocesserna är frikopplade från kravprocesserna.
Avseende den andra konsekvensen bör en beställare naturligtvis, för att optimera effekten av leverantörens kompetens, avhålla sig från onödiga begränsningar. Samtidigt finns det många fall då det är nödvändigt att begränsa lösningsmängden. I de fall beställaren har specifika krav på utformningen och inte kan acceptera produkten om dessa krav inte uppfylls vinner båda parter på att detta förmedlas till leverantören från början, eftersom leverantören slipper lägga resurser på att utvärdera olika alternativ som ändå kommer att förkastas. Några exempel där lösningsmängden kan behöva begränsas är:
- När beställaren använder ett specifikt kommunikationsgränssnitt i ett system för att integrera komponenter från olika leverantörer.
- När beställaren har valt att standardisera alla nya system på en gemensam grundplattform.
- När beställaren själv måste förhålla sig till ett eller flera tvingande krav, exempelvis till följd av författningar eller standarder.
- När beställaren av olika skäl vill undvika att en leverantör lägger resurser på att specificera och realisera viss funktionalitet som, utan begränsningen, kan tolkas ingå i det möjliga utfallsrummet för ett eller flera ställda krav.
Således fyller lösningsbegränsande krav en viktig funktion i utformningen av komplicerade eller komplexa system, varför någon egenskap för lösningsoberoende eller lösningsfria krav inte ingår i Svensk kravterminologi. Givet en arkitektur- och kravdriven metodik där kravnedbrytning och kravförfining används är det istället naturligt att krav på olika nivåer i hierarkin tillför olika typer av begränsningar, oavsett om det är beställaren eller leverantören som ansvarar för den aktuella nivån.
En åtgärd för att kunna införa egenskapen skulle kunna vara att göra de outtalade delarna explicita genom att i definitionen skriva att det enbart gäller beställarens krav på högre abstraktionsnivåer samt att de ska vara fria från onödiga begränsningar istället för alla begränsningar. En sådan egenskap får dock så många interna villkor och variationer att den blir svår att namnge, definiera eller för den delen bedöma huruvida den är uppfylld. Det bakomliggande motivet uppnås därför troligen bättre genom kvalitetssäkringsaktiviteter i kravprocesserna.
De problematiska kravtyperna funktionella och icke-funktionella krav
Två kravtyper med ursprung från mjukvaruområdet är funktionella respektive icke-funktionella krav. Utifrån att namnet icke-funktionella krav innehåller en negation i förhållande till funktionella krav är det naturligt att förhållandet speglas i definitionen:
| Kravtyp | Definition |
|---|---|
| Funktionella krav | Krav som i detalj reglerar transformationen av indata till utdata, inklusive ordningen på nödvändiga operationer samt hantering av parametrar och avvikelser. |
| Icke-funktionella krav | Krav som inte tillhör mängden funktionella krav. |
Grunden i att förstå båda begreppen ligger därmed i definitionen för de funktionella kraven. Det motsvarande engelska begreppet går åtminstone tillbaka till 1984 års utgåva av standarden IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1984) och vidareutvecklades i 1993 respektive 1998 års utgåvor (IEEE Std 830-1998). De funktionella kraven utgör i standarden en specifik delmängd (se definitionen) av detaljerade krav på mjukvarufunktioner ingående i en specifikation av en mjukvaruprodukt.
- IEEE Std 830-1998 godkändes för fortsatt giltighet 2009 och har därefter ersatts av ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering. ISO-standarden har, som del i systemlivscykelstandarderna, en bredare ansats än enbart mjukvara samtidigt som exemplen och begreppen från IEEE Std 830 i många fall behållits.
- Några exempel på övriga typer av detaljerade krav som beskrivs i standarden är prestandakrav, externa gränssnitt, designbegränsningar samt attribut programvaran ska uppvisa (tillgänglighet, säkerhet, portabilitet m.fl.).
- IEEE Std 830 beskriver funktionalitet på olika abstraktionsnivåer. Utöver de detaljerade funktionella kraven inkluderas även avsnitt på högre abstraktionsnivåer som beskriver produktens syfte och övergripande funktionalitet.
- Begreppet funktionella krav används ibland betydligt vidare än vad IEEE Std 830 beskriver, vilket medför risk för missförstånd. En bidragande orsak är sannolikt att begreppet funktion har flera olika användningsområden och omfattar allt ifrån den mycket specifika innebörden inom matematik till ett systemelement som har en specifik roll i ett system eller till och med en funktion inom en organisation.
Utifrån den ovanstående beskrivningen torde de funktionella kraven vara på en sådan abstraktionsnivå att de kan allokeras till lämpliga systemelement i arkitekturbeskrivningen, vilket gör att de hör hemma i arkitektur- och implementationsprocesserna snarare än processen som identifierar och dokumenterar intressenternas behov och krav. Det är i sammanhanget värt att ha i åtanke att begreppet funktionella krav förefaller vara sprunget ur en rekommenderad dokumentstruktur för specificera en komplett mjukvaruprodukt, snarare än en vägledning för hur enskilda krav ska kategoriseras. Utifrån att det kommer finnas många andra krav på motsvarande detaljnivå som är närliggande men faller utanför definitionen finns en risk att begreppet och kravtypen skapar mer förvirring än klarhet. Det bör därför användas med försiktighet och endast när det fyller ett tydligt behov.
Avseende begreppet icke-funktionella krav så förekommer det inte i någon av IEEE-standardens versioner. Någon litteraturanalys kring när det börjar användas första gången har inte genomförts inom ramen för författandet av Svensk kravterminologi men utifrån hur det brukar användas, inklusive omnämnandet i ISO/IEC/IEEE 29148:2011 förefaller det ha uppkommit ur ett behov att komplettera kravspecifikationer med vissa typer av kvalitetskrav. Begreppet är dock problematiskt:
- Utifrån namnet ska kategorin omfatta alla krav utöver de funktionella, vilket dels inkluderar ett antal tekniskt detaljerade krav på samma abstraktionsnivå som de funktionella, dels samtliga krav på högre abstraktionsnivåer. Den avsedda innebörden stämmer således inte med namnets semantiska betydelse.
- Att kategorisera krav utifrån vad det inte är, samtidigt som utfallsrummet är omfattande, innebär att ett antal tydliga underkategorier oavsett kommer att behövas, vilket leder till att begreppet icke-funktionella krav som bäst blir en extra nivårubrik i en kravspecifikation eller ett extra attribut som måste fyllas i och förvaltas i ett kravhanteringssystem.
- Mängderna för funktionella respektive icke-funktionella krav finns helt eller delvis på olika abstraktionsnivåer, vilket gör det svårt att hantera dem i relation till varandra. Vad som anses vara ett icke-funktionellt krav kan vara ett krav på högre abstraktionsnivå som ännu inte brutits ner till en sådan detaljnivå där det kan visa sig utgöra ett eller flera krav som kan kategoriseras som funktionella.
- Begreppet riskerar att skapa en uppfattning att alla krav kan eller i värsta fall bör delas upp som antingen funktionella eller icke-funktionella. Utifrån den ovanstående problematiken med alternativa tolkningar av innebörden av både funktionella och icke-funktionella krav i kombination med de skilda abstraktionsnivåerna kommer ett sådant kategoriseringsarbete kräva en hel del tankearbete och ändå riskera att skapa förvirring i det fortsatta arbetet.
Sammantaget finns det ett antal problem och risker med att använda typerna funktionella respektive icke-funktionella krav. Detta gäller oavsett om de används för att strukturera kravmängder eller om de används som mental modell för att förklara vilken roll eller betydelse olika typer av krav har. Därför är kravtypen icke-funktionella krav markerad med användning avrådes och kravtypen funktionella krav markerad med används med försiktighet. Istället förordas mer precisa kravtyper som i förekommande fall också förmedlar till vilken nivå som kravnedbrytningen har genomförts.
Om intentionen är att i en kravspecifikation förmedla en blandad samling kvalitetskrav kan dessa exempelvis samlas under typen och därmed rubriken kvalitetskrav. Beroende på typ och antal av krav kan det även vara aktuellt att ha mer specifika kategorier, antingen som egna områden eller underordnat kvalitetskraven. Exempel på sådana kategorier är cybersäkerhet och användbarhet. Beroende på abstraktionsnivå kan dessa sedan behöva behöver brytas ner eller förfinas, vilket till exempel ger upphov till krav på arkitekturen och dess ingående systemelement samt krav på hur systemet ska tas fram (processkrav) eller bevisas vara ändamålsenligt (assuranskrav).
Förtydliganden, bakomliggande argumentation och annan tilläggsinformation återges i ljusgrå rutor.