Logotyp för Svensk kravterminologi

Terminologi med förklaringar

Här sätts de viktigaste termerna i ett sammanhang för att tydliggöra hur de relaterar till varandra. Där så är relevant ges motiveringar till varför en viss term eller definition väljs framför eventuella alternativ som idag också förekommer.

Innehållsförteckning

Innehållet på sidan är uppdelat i nedanstående avsnitt:


Källhänvisningar och översättningar

Källhänvisningar i terminologin anges på två olika sätt:

  • Ö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 beskriver samma begrepp, men med ett annat namn eller annorlunda definition.
    • Den refererade källan innehåller en text som citeras direkt i terminologin.
    • Den refererade källan innehåller en text som skrivits om för att passa som definition i terminologin. Skälet till en sådan omskrivning kan vara att öka precisionen genom att använda andra befintliga termer i terminologin alternativt att få definitionen att harmonisera med gällande standarder.

Både översättningar och referenser 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.

En central term

Definitioner för centrala termer återges i ljusblå rutor.

Kommentar

Förtydliganden, bakomliggande argumentation och annan tilläggsinformation återges i ljusgrå rutor.


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 vara applicerbar för framtagning och förvaltning av komplexa system eller produkter där felaktigheter kan få stora konsekvenser för människor, miljö och ekonomi.

Mer precist utgår terminologin från nedanstående scenario:

  • Kravarbetet är en del i arbetet att etablera eller förvalta ett system av någon form.
  • Det finns ofta många aktörer med olika intressen och agendor inblandande i ett systems livscykel. Sammansättningen av aktörer kan variera över tid och kan bestå av företag, myndigheter såväl som andra organisationer, samtliga av varierande storlek.
  • Systemen är företrädesvis sociotekniska, vilket innebär att de består av både människor och teknik.
  • Det finns i regel ett behov att på ett övertygande sätt kunna påvisa att samtliga krav som ställts på systemet är uppfyllda.

Ovanstående gör på intet sätt terminologin irrelevant för mindre komplexa situationer. Skillnaden ligger framför allt i vilka kvalitetsegenskaper som appliceras samt integrationen mellan kravprocesserna och övriga livscykelprocesser. Oavsett verksamhet erbjuder terminologin termer och definitioner som gör det lättare att kommunicera både internt och externt.

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 och samma 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.

Principer

Det finns fyra viktiga principer som genomsyrar terminologin:

  1. Terminologin ska vara användbar för verkliga projekt och system.
  2. Terminologin ska utgå från ett system- och systemlivscykelperspektiv.
  3. Terminologin ska i möjligaste mån vara kompatibel med befintliga standarder och annan teoribildning.
  4. Terminologin ska utveckla området i de fall befintlig teoribildning är omodern eller otillräcklig för terminologins syfte.

En central konsekvens av dessa principer är att krav inte förväntas existera som enbart teoretiska objekt, utan alltid i ett sammanhang.

Antaganden om system- och kravarbetet

Det som beskrivits ovan leder till några antaganden om hur arbetet bedrivs:

  1. Framtagandet av nya system antas oftast ske i projektform.
  2. Kraven och uppfyllandet av dem är ett naturligt sätt att kommunicera aktuell status för ett system mellan beställaren, leverantören och övriga intressenter.
  3. Det är inte bara beställaren, utan också i hög grad leverantören som specificerar och förvaltar krav under systemets livscykel.
  4. Kravprocesserna och deras aktiviteter existerar inte i en isolerad bubbla, utan samverkar med övriga livscykelprocesser för systemet.
  5. 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.
Kommentar

På grund av antagandet att systemarbetet ofta sker i projektform tangerar delar av terminologin projektledningsmetodiken och dess egen teoribildning. Behovet av samverkan mellan kravspecialister och andra nyckelkompetenser inom ramen för ett projekt beskrivs exempelvis i essän Tio framgångsfaktorer för lyckade it-projekt. Essän är skriven författaren till Svensk kravterminologi och innehållet utgår till stor del från terminologins centrala tema om ett systemlivscykelperspektiv.

Oavsett projektledningsmetodikens betydelse för framgångsrika projekt och system är den dock inte huvudämnet för terminologin. Området kommer därför inte att hanteras närmare förutom i de fall det är nödvändigt för sammanhanget.

Tongivande standarder

De principer och antaganden som ligger bakom Svensk kravterminologi gör det naturligt att tillämpa teori och erfarenhet från systems engineering-disciplinen. Genom att försöka hålla innehållet i terminologin kompatibel med de standarder som finns området ökar relevansen för terminologin samtidigt som dubbelarbete i form av återuppfunna hjul undviks. Det finns tre standarder som har särskild koppling till terminologins innehåll:

Kommentar
Det faktum att ovanstående standarder har titlar som innehåller ordet software innebär inte att standarderna handlar om programvaror eller it-produkter. Det kombinerande namnet systems and software engineering anvä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 ovanstående standarder 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 både krav och systemlivscykler. Dessutom ligger de system som behandlas i sådana standarder i linje med målen för terminologin. Exempel på systemsäkerhetsstandarder är ISO 26262-serien för fordonsindustrin och DO-178C/ED-12C för avionikområdet.

Systembegreppet och systems engineering

Utgångspunkten för Svensk kravterminologi är att kravarbetet är en del i arbetet att etablera eller förvalta ett system av någon form. ISO 15288:2015 definierar system enligt följande:

Definition av system
en kombination av interagerande element som är organiserade för att uppnå ett eller flera uttalade syften.

Det finns tre viktiga aspekter i definitionen. Det första är att det finns ett eller flera underliggande syften med ett system. Det andra är att ett system består av ett antal underliggande element, och det tredje är att definitionen inte säger någonting om vad dessa element egentligen är.

Definitionen är vidare avsiktligt bred för att den ska vara tillämpbar oavsett bransch, och det finns inte heller något i den som säger att ett system nödvändigtvis är tekniskt. Ett system kan till exempel vara administrativt och bestå av olika processer. Svensk kravterminologi är dock, som tidigare nämnts, anpassad för sociotekniska system:

Definition av sociotekniskt system
ett system där både både människor och tekniska artefakter ingår som systemelement.

Huruvida ett system är sociotekniskt eller enbart tekniskt beror på vilken roll människorna har i det. Ett tågsätt kan betraktas som ett tekniskt system, medan tågsättet tillsammans med föraren kan betraktas som element i ett sociotekniskt system vars syfte är att transportera resenärer eller gods mellan önskade platser. Ytterligare element i ett sådant system skulle kunna vara de rutiner och regelverk som säkerställer att föraren har rätt utbildning och är vid god fysisk hälsa.

Kommentar
Att människor ingår som element i sociotekniska system ska inte förväxlas med systemens användbarhet. Användbarhet är en inneboende egenskap i ett system eller ett systemelement, och den är förvisso minst lika viktig i sociotekniska system som i andra system. Däremot har användbarheten inget att göra med huruvida systemet är sociotekniskt eller inte.

I järnvägsexemplet ovan räknas tänkbara systemelement av olika typer upp. Eftersom ett system till syvende och sist är en mänsklig abstraktion finns det ingen absolut sanning i vad som ska ingå eller inte ingå i ett givet system. Ska endast föraren ingå i systemet i järnvägsexemplet, eller omfattas även övrig personal? Ingår signalsystemet, eller är det ett stödjande eller ett helt fristående system? Hur systemgränsen väljs påverkar både systemets komplexitet och dess typ. Den som konstruerar loket i tågsättet kan lika gärna se det som ett fristående system där föraren är en användare snarare än ett element i ett större system.

Olika intressenter kan alltså ha olika systemperspektiv för samma verkliga företeelser. Det är därför viktigt att de som arbetar med att konstruera ett givet system är överens om var dess gränser går. För att till exempel undvika missförstånd i situationer där flera olika system behandlas används begreppet systemet-i-fokus för att indikera ett specifikt system med en tillhörande lika specifik livscykel.

Ytterligare två begrepp som är viktiga och som relaterar till system är arkitektur och arkitekturbeskrivningar. Alla system har en arkitektur, oavsett om den är beskriven eller ej. Vidare kan ett system kan ha flera olika arkitekturbeskrivningar. Varje arkitekturbeskrivning består i sin tur av ett antal vyer, som beskriver systemet utifrån olika perspektiv. Ett sådan vy kan till exempel visa hur krav av en viss typ har allokerats till olika systemelement. Mer information om arkitekturbegreppet och framför allt arkitekturbeskrivningar återfinns i ISO 42010:2011.

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 som relaterar till 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 använder terminologin tills vidare systems engineering också som det svenska namnet på disciplinen, vilket förefaller vara accepterad praxis i sammanhanget.

Definition av systems engineering
ett tvärvetenskapligt tillvägagångssätt som fastlägger de sammanlagda tekniska och styrningsmässiga arbetsinsatser som krävs för att omsätta intressenternas behov, förväntningar och villkor i en lösning, samt upprätthålla denna lösning under hela dess existens.
Kommentar

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 exkluderar därför den del av den engelska titeln som innehåller begreppet.

Den efterföljande versionen från 2008 fick en längre originaltitel som inkluderade mjukvaruaspekter, nämligen Systems and software engineering -- System life cycle processes. I samband med fastställandet som svensk standard översattes inte innehållet utan endast titeln, där systems and software engineering översattes till system- och programvarukvalitet. Denna översättning är dock inte oproblematisk. 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.

Den tredje utgåvan (år 2015) gavs aldrig ut i en svensk version. Därmed är varken titeln eller innehållet översatt till svenska.

För att förstå utvecklingen ovan är det bra att känna till att även om standarderna sedan lång tid tillbaka beskriver centrala processer och aktiviteter inom systems engineering så är det faktiskt först i 2015 års utgåva som begreppet får en egen definition. Föregående versioner använder annars främst begreppet i titlarna i innevarande och relaterade standarder. 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.

Samverkan med övriga livscykelprocesser

Terminologin gör några antaganden rörande kravprocessernas samverkan med några av de övriga livscykelprocesserna inom systems engineering-området. Kravprocesserna kommer sannolikt samverka med fler processer än de som framgår här (bland annat affärsprocesserna i form av kravspecifikationer och överenskommelser mellan beställare och leverantörer), men nedanstående har särskild betydelse för terminologins utformning och tolkning:

  • Arkitektur- och designprocesserna.

    Antagande: Kravarbetet är en integrerad del i framtagningen av systemet; den kompletta kravmängden växer fram tillsammans med arkitekturen.

  • Verifierings- och valideringsprocesserna.

    Antagande: En viktig del av verifierings- och valideringsaktiviteterna (V&V) för systemet att leverantören övertygar beställaren om att samtliga krav är uppfyllda.

Dessa samverkande processer förväntas bland annat åstadkomma följande:

  1. En spårbar kravmängd för systemet-i-fokus.
  2. Tydlighet i vilken del av systemet-i-fokus som ett givet krav realiseras.
  3. Överensstämmelse mellan abstraktionsnivåerna för kraven och arkitekturbeskrivningen, det vill säga ett mer detaljerat krav allokeras till ett systemelement på motsvarande detaljeringsnivå i systemnedbrytningen.

Grundläggande kravbegrepp

I detta avsnitt introduceras några av de mest grundläggande kravbegreppen. En del av begreppen är så omfattande att de har egna avsnitt som följer efter detta. Andra tenderar att återkomma i flera sammanhang, medan vissa enbart nämns i förbigående.

Intressenter

Att konstruera ett system som inte kommer till användning eller som försvårar för verksamheten istället för att hjälpa den är både ett slöseri med resurser och motivationssänkande för alla inblandade parter. Det är därför viktigt att veta vilka behov ett givet system ska tillgodose. De som har eller företräder dessa behov, eller på annat sätt har inflytande över systemet, benämns intressenter:

Definition av intressent
en individ eller organisation som påverkas av, eller har inflytande över, ett systems utformning eller existens.

För att kunna identifiera och prioritera de intressenter som är relevanta för ett givet system genomförs en intressentanalys. Under intressentanalysen grupperas intressenterna förslagsvis i kategorier som väljs i syfte att underlätta det fortsatta kravarbetet. Kategoriseringen kan till exempel utgå från hur intressenterna kommer att påverkas av systemet eller vilket inflytande de har över systemet. Resultatet från intressentanalysen dokumenteras i en intressentförteckning.

Kommentarer
  1. Intressentförteckningen kan naturligtvis innehålla ytterligare information. Två exempel är inbördes prioritering mellan intressenterna och kontaktuppgifter till företrädare för de olika intressenterna.
  2. Brister i intressentanalysen utsätter systemet och projektet för omfattande risk för misslyckande. Ett exempel på en sådan brist är felaktig klassificering av intressenter 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 istället för tvingande krav kommer sannolikt att leda till stora problem. Ett annat exempel är att misslyckas med att identifiera en eller flera viktiga användargrupper.

Kravhantering och kravteknik

Som samlingsnamn för de olika aktiviteter som bedrivs inom kravområdet finns två olika termer som för närvarande förefaller att användas synonymt, nämligen kravhantering och kravteknik. De skillnader som kan skönjas är att kravhantering är mer frekvent förekommande i allmänhet, och att kravteknik används mer i akademiska sammanhang. I Svensk kravterminologi får termerna definitioner som speglar detta, vilket också ger kompatibilitet med ISO 29148:2011.

Kommentar
ISO 29148:2011 skiljer på aktiviteterna inom professionen (requirements management) och den vetenskapliga disciplinen (requirements engineering). Det är dock inte ovanligt att requirements engineering används i båda fallen, inte minst inom mjukvaruområdet. Svenska språket har här en fördel genom att suffixet -teknik ofta används för ämnen inom ingenjörsvetenskaperna.

Kravhantering är således det allmänna samlingsnamnet för aktiviteter inom kravprofessionen:

Definition av kravhantering
de aktiviteter som säkerställer att krav identifieras, dokumenteras, förvaltas, kommuniceras och spåras genom livscykeln för ett system, en produkt eller en tjänst.

Några exempel på aktiviteter är kravfångst, kravanalys, kravvalidering och kravförvaltning.

Avseende termen kravteknik förespråkar Svensk kravterminologi att den används för det vetenskapliga forskningsområdet som på engelska heter requirements engineering, samt för de kravrelaterade deldisciplinerna inom systems engineering och programvaruteknik. Precis som för kravhantering är definitionen översatt från ISO 29148:2011.

Definition av kravteknik
en tvärvetenskaplig disciplin som genom att sammanbinda de beställande och de levererande domänerna med varandra etablerar och förvaltar de krav som systemet-i-fokus ska uppfylla.
Kommentarer
  1. Kravteknik kan ses som en deldisciplin till både systems engineering och programvaruteknik. Programvaruteknik kan i sin tur ses som en deldisciplin till systems engineering. Hur disciplinerna hänger ihop kan exemplifieras med arbetet att konstruera en bärraket som ska placera en satellit i omloppsbana. Systems engineering används för att hantera helheten, inklusive integrationen av de olika delarna. Programvaruteknik används för framtagning av den mjukvara som kommer att ingå i systemet, och kravteknik används för att etablera och förvalta kraven på både mjukvaru- och systemnivån. På systemnivån ingår det även att koordinera och följa kraven mellan de olika deldisciplinerna (där programvaruteknik endast är en av dessa).
  2. Givet ansatsen som presenterades i avsnittet om målgrupp och principer tar Svensk kravterminologi höjd för att vara applicerbar inom kravteknikområdet, med antagandet att både definitioner och den sammanhängande strukturen därmed är till nytta för kravhantering i alla dess former.

Krav och kravmängder

Med det större sammanhanget på plats är det hög tid att definiera det mest centrala begreppet av dem alla, nämligen ordet krav. Det finns några olika alternativa definitioner som alla har liknande innebörd, men som fokuserar på olika aspekter beroende på i vilket sammanhang de förekommer. I enlighet med den vägledande principen att anamma ett systems engineering-perspektiv använder Svensk kravterminologi definitionen från ISO 29148:2011:

Definition av krav
ett uttryck som förmedlar ett behov med dess begränsningar och villkor.

Krav kan vara både explicita, implicita och outtalade. När de dokumenteras sker det med en eller flera kravnotationer. Ett och samma krav kan alltså återges på olika sätt. Om så sker måste det framgå vilken av notationerna som har företräde vid tolkning av kravet.

En avgränsad samling av krav benämns kravmängd. Hur stor avgränsningen är varierar från fall till fall. En kravmängd kan exempelvis vara samtliga krav i en kravspecifikation, en del av en specifikation, eller den samlade mängden krav en organisation har för ett helt verksamhetsområde.

Ett av de viktigaste begreppen inom kravteknik är spårbarhet. Spårbarhet handlar ytterst om att veta varför ett givet krav existerar. Utan spårbarhet blir kravmängden osammanhängande och med överhängande risk för motsägelser, dubletter, eller krav som har kommit med vid något tillfälle men som egentligen inte behövs eller önskas av någon av systemets intressenter.

Både kravmängder och enskilda krav kan ha egenskaper och attribut. När det föreligger risk för sammanblandning eller missförstånd bör de fullständiga termerna kravegenskap respektive kravmängdsegenskap (och motsvarande för attribut) användas. Många av de mer vedertagna egenskaperna beskriver kvalitetsaspekter, medan attributen ofta används för att kategorisera kraven och därmed göra dem lättare att hitta i en kravmängd.

Krav kan vidare kategoriseras utifrån kravtyp. Verbet kategoriseras i föregående mening indikerar att begreppet egentligen är ett attribut, men det fyller en så pass viktig funktion när vi pratar om krav att det är värt att lyftas fram i sin egen rätt. Ett annat sådant egentligen-attribut är prioritet.

Kraven i en kravmängd kan organiseras i en kravhierarki. En sådan hierarki skapas genom kravnedbrytning och kravförfining. Som ett led av nedbrytningen och förfiningen dokumenteras kraven på olika abstraktionsnivåer, där kraven blir mer precisa ju längre ner i hierarkin de befinner sig.

Kravmängden för ett givet system kan dokumenteras och bevaras på olika sätt. I en organisation med mogen kravteknik används sannolikt ett kravhanteringssystem.

Kommentar
Att en organisation använder ett kravhanteringssystem innebär inte per automatik mogenhet inom kravteknik. Det finns generellt en övertro på att nya it-system kommer att lösa de svåra kravproblemen i en verksamhet. I praktiken måste man veta hur man kan och vill arbeta innan man inför systemstöd. Denna övertro på att it-system nästan magiskt kan lösa verksamhetsproblem är förstås (och tyvärr) inte unik för kravområdet.

Oavsett hur kravmängden förvaltas är det inte osannolikt att den förr eller senare kommer att användas som en del i en beställning eller upphandling för att anskaffa det tilltänkta systemet. I sådana lägen införlivas kraven ofta i en kravspecifikation.

Krav finns dock på olika nivåer, och kan uttryckas och representeras på olika sätt beroende på syfte och användningsområde. Krav som används i en beställning skiljer sig sannolikt från de krav som används på lägre nivå i arkitekturbeskrivning och som syftar till att förmedla beteenden och egenskaper internt i systemet.

Begreppsmodell

Begreppsmodellen i detta avsnitt visar relationen mellan krav och ett urval andra centrala begrepp i Svensk kravterminologi. Många av begreppen i modellen beskrivs mer ingående i kommande avsnitt.

  • I modellen används notationen för ett UML v2.5 klassdiagram. Ett viktigt begrepp i UML är multiplicitet, som innebär ett intervall med en nedre och övre gräns.
  • Begreppen och relationerna ska ses i kontexten av ett godtyckligt men specifikt system (systemet-i-fokus).
  • Relationerna med pilar ska endast läsas i den riktning som pilarna indikerar.
  • När multipliciteten för en utgående relation är en etta ska det läsas som varje [begrepp] alternativt en/ett [begrepp].
  • 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..*.
begreppsmodell
Kommentar
Som alltid när det gäller modeller måste en avgränsning göras så att onödigt stor detaljrikedom inte gör modellen svårförståelig. På grund av detta visas till exempel inte den relation som förmedlar att mål är en kravtyp.

Förtydliganden till modellen och relationerna

  1. En intressent kan ha behov såväl som direkta krav som inte uppenbart går att härleda till ett tydligt behov. Ett exempel på det sistnämnda är lag- eller regelverkskrav. Någonstans bakom dessa krav finns det oftast ett behov, men vem som har behovet i fråga är inte helt självklart. Däremot är ofta den myndighet som har tillsynsansvar för lagen eller regelverket är en viktig intressent. För att undvika konstlade behov finns därför den direkta relationen mellan intressenter och krav.
  2. En kravmängd består, i enlighet med dess definition, av minst två krav. En kravmängd kan organiseras i en kravhierarki, men en kravhierarki kan också innehålla krav från flera kravmängder.
  3. En kravhierarki består av ett mål och ett eller flera krav på lägre abstraktionsnivå. Dessa krav kan i sin tur ha krav på lägre abstraktionsnivåer. (Notera att Krav på lägre abstraktionsnivå har en relation till sig självt.) Kraven på varje lägre abstraktionsnivå skapas genom kravnedbrytning eller kravförfining.
  4. En kravhierarki är en rekursiv struktur. Varje krav i en kravhierarki som har krav på lägre abstraktionsnivåer kan i sin tur utgöra målet i en annan mindre kravhierarki.
  5. Ett och samma krav kan uttryckas med flera olika notationer. En notation har dock alltid en formalitetsgrad och en presentationsform. (En presentationsform är grafisk även om de grafiska elementen innehåller text. Modellen ovan är ett exempel på detta.)
  6. Distinktionen mellan arkitektur och arkitekturbeskrivning syftar till att tydliggöra att alla system har en arkitektur, oavsett om den är beskriven eller ej. Ett system kan sedan ha flera olika arkitekturbeskrivningar. Mer information om arkitekturbeskrivningar återfinns i ISO 42010:2011.

Hierarkier och krav på olika abstraktionsnivåer

En kravhierarki definieras enligt följande:

Definition av kravhierarki
en hierarkisk struktur bestående av ett mål, samt från målet nedbrutna och förfinade krav.

Termen mål fyller därmed en viktig funktion i strukturen genom att det i någon mening blir ett ankare att hänga upp underliggande (nedbrutna och förfinade) krav på.

Genom att låta varje mål utgöra början av (eller toppen på) en egen kontext blir det möjligt att definiera mål på olika nivåer i en större hierarki. De olika kontexterna blir samtidigt egna avgränsade hierarkier. (Se även förtydligandena till begreppsmodellen om att en kravhierarki är en rekursiv struktur.)

På ett eller flera ställen i hierarkin finns sannolikt också skiljelinjer mellan ansvarsområden. Dessa skiljelinjer 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.

Kommentarer

Det går att diskutera var den totala hierarkin egentligen börjar. I praktiken sker förhoppningsvis inte framtagning eller förändring av ett system isolerat från omvärlden. Till exempel finns det sannolikt ett antal verksamhetsmål inom varje intressents organisation. Huruvida dessa ska vara en del av den totala hierarkin, spåras på annat sätt, eller inte hanteras alls måste avgöras från fall till fall.

  1. Att spåra intressentmålen till verksamhetsmålen är förhållandevis enkelt om alla intressenter finns i samma organisation och det därmed finns en uppsättning verksamhetsmål. När så inte är fallet blir arbetet mer omfattande, och i värsta fall står de olika intressenternas mål i konflikt med varandra.
  2. Verksamhetsmål kan, precis som andra krav, brytas ner i mer detaljerade delmål eller krav som exempelvis åläggs olika organisationsenheter att uppnå.

I en kontext av nya eller förändrade system finns intressentmålen högst upp i den totala hierarkin för systemet-i-fokus:

Definition av intressentmål
mål som beskriver essensen av systemet-i-fokus. Dessa är av sådan dignitet att om de inte uppfylls, kommer systemet helt eller till stor del att sakna värde för den eller de intressenter som äger målen.

Eftersom intressentmålen ofta har hög abstraktionsnivå kommer de sannolikt behöva brytas ner eller förfinas till en underliggande nivå med systemkrav. I samband med detta kan även av härledda krav uppstå.

Kommentar
Härledda krav kräver viss försiktighet eftersom de kan vara en indikation på att det antingen saknas krav på överliggande nivåer eller, ännu värre, en indikation på kravglidning.

Som synes ovan kommer ett givet krav att benämnas olika beroende på vilken nivå i en hierarkin det befinner sig. Dessa namn ger ledtrådar till både kravets avsändare och målgrupp, och i förlängningen också kravets abstraktionsnivå. Högst upp i hierarkin är kraven typiskt mer visionära, medan de för varje underordnad nivå blir allt mer detaljerade. Beroende på vilken abstraktionsnivå som är aktuellt kan en särskild kravnotation vara mer eller mindre lämplig. Långt ner i hierarkin, där kraven ofta behöver vara precisa kan formella eller semiformella notationer vara att föredra.

Namngivningen på de olika nivåerna och storleken (framför allt djupet) på hierarkin kan i övrigt variera beroende på fackområde och vilka standarder och metoder en given organisation tillämpar. Några exempel på begrepp och nivåer som förekommer är delsystemskrav , systemelementskrav, komponentkrav och modulkrav.

Kravtyper

Kravtyp nämndes tidigare som sätt att kategorisera krav. Kravtyperna kan till exempel användas för att strukturera en kravmängd så att det blir lätt att hitta i den, eller som rubrikindelning i en kravspecifikation. Vilka specifika typer som används kommer att vara organisations- och projektberoende, vilket gör det svårt att åstadkomma en allmängiltig och heltäckande lista. Detta till trots finns det några generella kravtyper som kan vara värda att nämna.

I tabellen nedan finns en sammanställning över de kravtyper som förekommer i Svensk kravterminologi och som inte har markerats med användning avrådes.

Kravtyp Definition
AnvändbarhetskravKrav som reglerar användbarhet.
AssuranskravKrav som syftar till att skapa assurans.
Funktionella kravKrav som beskriver konkret och påtaglig funktionalitet i ett system.
Härledda kravKrav som inte har uppstått genom nedbrytning eller förfining, utan som istället har skapats för att täcka en lucka som annars skulle uppstå i kravmängden.
InformationssäkerhetskravKrav som reglererar riktighet, tillgänglighet, konfidentialitet och oavvislighet för ett system eller en process.
IntressentmålMål som beskriver essensen av systemet-i-fokus. Dessa är av sådan dignitet att om de inte uppfylls, kommer systemet helt eller till stor del att sakna värde för den eller de intressenter som äger målen.
It-säkerhetskravKrav som reglerar tekniska aspekter av informationssäkerhetskrav i ett system.
KvalitetskravKrav som beskriver inneboende kvaliteter för ett system eller en artefakt.
LagkravKrav som är uttryckta direkt i, eller härledda från, lagar och förordningar.
MålEtt krav på den högsta abstraktionsnivån i en given kontext.
OrganisationskravKrav som ställs på den organisation som ska använda eller förvalta systemet-i-fokus.
ProcesskravKrav på processen som används för att konstruera och producera systemet-i-fokus.
ProjektmålMål som ett projekt ska uppnå.
RegelverkskravKrav som är uttryckta i, eller nedbrutna alternativt härledda från, ett regelverk.
SystemkravKrav som gäller för ett system som en helhet, det vill säga när man betraktar systemet som en svart låda.
SystemsäkerhetskravKrav som syftar till att uppnå systemsäkerhet.
SäkerhetskravKrav som reglerar en eller flera aspekter av säkerhet.
Tvingande kravKrav som inte är förhandlingsbara till sin existens eller uppfyllnad.
VerksamhetsmålDe mål en given organisation har för sin verksamhet.
Kommentarer
  1. Ett krav kan ha flera kravtyper.
  2. Hur kravtyperna bäst representeras beror på användningsområdet. I en kravspecifikation kan en kravtyp vara en rubrik där ett antal underliggande krav tillhörande typen listas, medan det i ett kravhanteringssystem förmodligen är bättre att använda attribut.
  3. Kravtyperna kan, beroende på verksamhet och komplexitet, delas in i både över- och undertyper. Till exempel kan tvingande krav delas upp i lag- och regelverkskrav.
  4. Explicita, implicita och outtalade krav existerar på en högre abstraktionsnivå och listas därför inte som kravtyper i detta sammanhang.

Användbarhet och användarvänlighet

I vardagligt tal används ofta begreppet användarvänlighet i relation till företrädesvis it-system. Ibland som en önskvärd egenskap i en kravspecifikation eller beställning, men kanske oftare som något som saknas i ett befintligt system. Detta innebär att begreppet ofta används 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, och kan i hög utsträckning bero på om systemet används för vad det är avsett 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.

Svensk kravterminologi följer Göranssons och Gulliksens rekommendation och förordar istället det närliggande begreppet användbarhet. Förutom en tydlig definition som underlättar framtagandet av mätbara krav med tydliga acceptanskriterier motsvarar termen 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 till den relaterade standarder.

Definition av användbarhet
den utsträckning till vilken en specificerad användare kan använda ett system, en produkt eller en tjänst för att uppnå specifika mål med ändamålsenlighet, effektivitet och tillfredsställelse, i ett givet användningssammanhang.
Kommentarer
  1. 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 senaste utgåvan av standarden (ISO 9241-11:2018).
  2. I sammanhanget av Svensk kravterminologi är egentligen produkt och tjänst överflödiga tillägg, eftersom dessa ingår i systembegreppet. Den något längre versionen gör dock ingen skada, samtidigt som den stämmer bättre med aktuell standard.

Genom definitionens inledande den utsträckning är det tydligt att det handlar om en skala till skillnad från en egenskap vars existens antingen är sann eller falsk.

En annan viktig aspekt i definitionen ä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 både utveckling och validering.
  • Om de specifika målen motsvarar eller är nedbrytna från intressentmålen 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.
Kommentarer
  1. 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.
  2. 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 toppen på en kravhierarki och som genom kravnedbrytning kan detaljeras till den nivå det är nödvändigt:

Beståndsdel Definition
EffektivitetResursåtgång i förhållande till uppnådda resultat.
TillfredsställelseDen 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)
ÄndamålsenlighetNoggrannhet och fullständighet med vilken användarna uppnår givna mål.
(1)  Definitionen har översatts från ISO 9241-11:2018 av Patrik Sternudd och används med vederbörligt tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO 9241-11:2018.
Kommentarer
  1. 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 senaste utgåvan av standarden (2018) har definitionen kortats ner, vilket föranlett motsvarande förändring i Svensk kravterminologi.
  2. Tillfredsställelse och dess definition ingår också i Användarcentrerad systemdesign, men i den senaste utgåvan av standarden har definitionen ändrats så mycket att en ny översättning varit nödvändig. Den nya versionen är förutom att den finns i en gällande standard också 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).
  3. Ä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. Definitionen är identisk i senaste utgåvan av standarden.
  4. Angående översättningarna av de engelska termerna effectiveness och efficiency kan det noteras att det svenska språket normalt inte gör någon distinktion mellan dessa två aspekter; båda brukar istället översättas till effektivitet. I det här fallet är detta otillräckligt. Svensk kravterminologi har valt att använda Gulliksens och Göranssons översättningar, där effektivitet kopplas till mängden förbrukade resurser (inklusive arbetstid), medan ändamålsenlighet används för att uttrycka precisionen i det utförda arbetet.

Utifrån ovanstående resonemang förordar alltså Svensk kravterminologi att termen användbarhet används istället för användarvänlighet. Detta gäller i särskilt hög utsträckning vid krav- och systemarbete. Däremot kommer säkerligen användarvänlighet att fortsätta användas i dagligt tal, inte minst i diskussioner med exempelvis verksamhetsföreträdare och användare.

Olika typer av säkerhetskrav

Innebörden av säkerhet och säkerhetskrav har en mycket stor spännvidd beroende på sammanhanget. Detta kan illustreras genom informationssäkerhetskrav och systemsäkerhetskrav. Dessa till synes mycket lika termer används av två specialistdiscipliner som har helt skilda traditioner. På engelska är skillnaden mer påtaglig; informationssäkerhet hör till security medan systemsäkerhet hör till safety.

Skillnaden mellan systemsäkerhet (safety) och säkerhet (security)

Grovt förenklat kan systemsäkerhet (safety) sägas handla om hur ett system ska konstrueras för att det inte till följd av konstruktionsfel eller komponenter som går sönder ska orsaka skador eller förlust av människoliv, egendom eller miljö. Inom systemsäkerhetsområdet kan man exempelvis använda sannolikhetsberäkningar för hur länge vissa komponenter håller, och vid behov dubblera komponenter eller delsystem för att skapa redundans.

Inom it-säkerhetsområdet och andra discipliner som faller under engelskans security är sådana sannolikhetsberäkningar mycket svårare därför att utgångspunkten är att det alltid finns en antagonistisk motståndare som aktivt letar efter de svagaste punkterna i syfte att kringgå de skyddsmekanismer som systemet har. Om det finns informationssäkerhetskrav som reglerar konfidentialitet är det inte heller alltid önskvärt att dubblera funktionerna, eftersom det kan göra att de skyddsvärda tillgångarna blir mer lättillgängliga för motståndaren.

Situationen kompliceras ytterligare av de senaste årens insikter inom systemsäkerhetsdisciplinen att adekvat informations- och it-säkerhet i allt högre utsträckning är nödvändig för att inte åsidosätta systemsäkerheten. Detta innebär att informationssäkerhetskrav troligen kommer uppstå vid kravnedbrytningen från mål som krävs för att uppnå önskad nivå av systemsäkerhet.

En annan relaterad kravtyp som förekommer i båda disciplinerna är assuranskrav.

Definition av assurans
ett välgrundat förtroende för att en utfästelse är eller kommer att bli sann.

Assurans är en dimension som ligger närmare verifiering och validering än specifik funktionalitet. Förenklat kan man säga att assuranskrav typiskt innebär att det är leverantörens ansvar att övertyga en extern och oberoende granskare att systemet-i-fokus är tillräckligt säkert för användning i ett eller flera definierande sammanhang.

Kommentarer
  1. Vad som är tillräckligt säkert beror bland annat på vilken risknivå certifieringsorganet och ytterst det omgivande samhället tycker är acceptabelt. Inom systemsäkerhetsområdet gäller generellt att ju större risken för personskador och dödsfall bedöms vara, desto hårdare krav på leverantören avseende både systemutformning och bevisföring.
  2. Även om assuranskrav oftast inte ställer krav på specifik funktionalitet har de i regel mycket stor påverkan på hur system kan utformas eller projekt bedrivas. Inom systemsäkerhetsområdet förekommer ofta krav på att tillverkaren ska kunna påvisa att kritiska system är framtagna med processer och metoder som anpassats för gällande risknivå. Vilka metoder som är tillåtna är inte sällan föreskrivna i regelverk eller standarder, och att i efterhand försöka påvisa sådan efterlevnad är i det närmaste omöjligt.

Utöver informations- och systemsäkerhet som diskuteras ovan tillkommer ytterligare discipliner som verksamhets- och livsmedelssäkerhet (som ligger närmare safety) och säkerhetsskydd (som hör till security). Att skapa och upprätthålla en heltäckande lista av alla yrkesområden som relaterar till säkerhet ligger dock utanför Svensk kravterminologi, men de nyss nämnda exemplen visar att viss försiktighet ä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.

Den överflödiga typen icke-funktionella krav

En uppdelning som av hävd är djupt rotad är funktionella respektive icke-funktionella krav. Denna uppdelning är dock problematisk:

  • Icke-funktionella krav säger inte vad det är för krav, bara vad det inte är. För att få en användbar klassificering kommer ett antal underkategorier sannolikt att behövas, vilket leder till att begreppet bara blir en extra nivårubrik i en kravspecifikation eller ett extra attribut som måste fyllas i och förvaltas i ett kravhanteringssystem.
  • Uppdelningen riskerar att leda till att allt eller för stort fokus läggs på de funktionella kraven. (Vi har de viktiga funktionella kraven, och så det där andra som vi tittar på i mån av tid...) Naturligtvis måste systemet innehålla den kravställda funktionaliteten för att systemet över huvud taget ska kunna accepteras av beställaren eller kunden, men även en produkt som saknar förväntad kvalitet riskerar att få ett minst sagt svalt mottagande.
  • Det som benämns icke-funktionella krav är ibland snarare krav på högre abstraktionsnivåer, det vill säga mål eller rent av intressentmål. Sådana mål behöver brytas ner eller förfinas, vilket till exempel ger upphov till både krav på specifika funktioner och krav på hur systemet ska tas fram. Det sistnämnda skulle förvisso kunna kallas för icke-funktionella krav, men det är betydligt mer informativt att använda kravtypen processkrav.
Kommentar

Användning av begreppet icke-funktionella krav utan underliggande kategorier i en kravspecifikation kan vara en varningssignal för att kraven inte har analyserats, förfinats och brutits ner i tillräcklig utsträckning. Detta tycks vara särskilt vanligt för informationssäkerhetskrav och användbarhetskrav.

Risken är att resultatet blir diffusa önskemål som lämnas över till leverantören i mer eller mindre omedvetet hopp om att denne ska förstå vad beställaren egentligen är ute efter. Genom att istället benämna dessa som mål blir det tydligt att ytterligare kravarbete är nödvändigt.

Även om icke-funktionella krav sannolikt kommer att finnas kvar som begrepp under överskådlig framtid, inte minst i äldre litteratur, är rekommendationen från Svensk kravterminologi att istället använda så precisa och beskrivande kravtyper som möjligt:

Inte heller kravtypen funktionella krav finns med i ovanstående exempel. Skälet för det är att exemplen utgår från intressenternas behov istället för specifika funktioner. Vid en kravnedbrytning av behoven (målen) och de önskade kvaliteterna kommer sannolikt ett antal funktionella krav att uppstå. (Gör de inte det är det förmodligen inte ett tekniskt eller sociotekniskt system som utformas.) Dessa krav kan vid behov tilldelas attributet funktionella krav, exempelvis i syfte att förenkla verifiering av att alla sådana krav faktiskt allokerats till minst ett delsystem eller en komponent.

Kommentar
Vem som ska genomföra vilka delar av kravnedbrytningen är upp till varje enskilt projekt att ta ställning till. Om uppdelningarna i exemplen skulle användas i en kravspecifikation bör beställaren bryta ner kraven till en lämplig nivå utifrån vald kontraktsform samt sin egen och leverantörens kunskap och kompetens.
I vissa fall, kanske särskilt i krav- eller systemrelaterade diskussioner, kan ett överordnat samlingsnamn för flera olika kvalitetsrelaterade kravtyper vara användbart. För detta ändamål föreslås termen kvalitetskrav:
Definition av kvalitetskrav
krav som beskriver inneboende kvaliteter för ett system eller en artefakt.
Kommentar
Kvalitetskrav kan omfatta ett system i sin helhet såväl som dokumentation eller annan utdata som har producerats som ett led i framtagningen av systemet i fråga.

Prioritetsskalor

Kravattributet prioritet förmedlar hur viktigt ett krav är. För att prioritetsattributet ska vara användbart måste det finnas en prioritetsskala:

Definition av prioritetsskala
en ordinalskala, det vill säga en ordnad mängd av element, där varje element förmedlar ett mått av prioritet.

En prioritetsskala kan vara utformad på olika sätt. Till exempel kan sifferskalor som 1–4 användas. Många inom det offentliga är säkerligen bekanta med den den binära skalan skall- och börkrav. Ett tredje exempel är nödvändigt–prioriterat–önskvärt (önskvärt har i exemplet lägst prioritet).

Kommentarer
  1. Oavsett skala är det viktigt att innebörden av de olika stegen i skalan är tydligt definierade.
  2. Prioritetsskalor bör väljas med omsorg. Att enbart använda en binär skala kan exempelvis leda till en stort antal krav som alla har samma prioritet.

Kravnotationer

För att förenkla definitionen av kravnotation definieras först grundbegreppet notation:

Definition av notation
en beskrivningsteknik avsedd för ett specifikt syfte.

En kravnotation är därmed en beskrivningsteknik avsedd för krav. Notationer kategoriseras utifrån formalitetsgrad (formell, semiformell eller informell) och presentationsform (grafisk eller textuell). Formalitetsgraden har tre olika nivåer, som bestäms utifrån notationens syntax och semantik:

Formalitetsgrad Definition
Formell notationEn beskrivningsteknik vars syntax och semantik är fullständigt definierad.(1)
Semiformell notationEn beskrivningsteknik vars syntax är fullständigt definierad men där semantiken kan vara ofullständig.(1)
Informell notationEn beskrivningsteknik som saknar fullständigt definierad syntax.(1)
(1)  Definitionen har översatts från ISO 26262-1:2011 av Patrik Sternudd och används med vederbörligt 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 är det nödvändigt att ha tydliga definitioner för fullständigt definierad syntax och semantik:

syntaxen för ett språk L är fullständigt definierad om och endast om det, för varje uttryck U, med säkerhet går att avgöra huruvida U tillhör L eller inte.
semantiken är uttryckt som, eller går entydigt att översätta till, ett matematiskt system.

Formalitetsgraden och presentationsformen är oberoende av varandra; det finns grafiska och textuella notationer av olika formalitetsgrad. 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
Kommentarer
  1. En stor del av innehållet i avsnittet består av översatt material från kapitel två och sju i examensarbetesrapporten Unambiguous Requirements in Functional Safety and ISO 26262: Dream or Reality?.
  2. Definitionerna av formalitetsgraderna är hämtade från ISO 26262-1:2011 eftersom det är den enda standarden som Svensk kravterminologi har kännedom om som gör en ansats att definiera begreppen på ett enhetligt sätt och med inbördes distinktion. (Se även inledningen för en kort notis om olika standarders relevans för Svensk kravterminologi.)
  3. Begreppet notation med tillhörande definitioner är inte specifikt för kravteknik utan lika tillämpligt inom andra områden inom systems engineering. De specifika notationerna i varje deldisciplin kan förstås skilja sig åt, även om det går att uppnå effektivitets- och kvalitetsfördelar genom att använda gemensamma eller samverkande notationer.
  4. 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 det en överhängande risk för sammanblandning och förvirring. Ett exempel på när man måste vara särskilt försiktig är när författare använder begrepp som formella specifikationer eftersom det kan användas 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:

Definition av kravschablon
ett begränsat naturligt språk anpassat för att formulera krav i, där ett antal fixa språksegment med luckor för systemspecifika värden kan kombineras enligt fördefinierade regler.
Definition av kravmönster
ett eller flera krav som återkommer i flera projekt eller system.
Kommentar

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:

  1. Den traditionella betydelsen av schablon förefaller semantiskt vara närmare det engelska begreppet boilerplate som det beskrivs i Requirements Engineering (Hull m.fl.).
  2. 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 och attribut

Notera att samtliga egenskaper och attribut inte är tillämpliga i varje organisation och projekt. Detta gäller särskilt för vissa av attributen.

Angående lösningsoberoende krav och begränsningar

När man läser om kvalitetsegenskaper för krav står det ofta att krav ska vara lösningsfria eller lösningsoberoende. Ett vanligt (och bra) motiv är att man inte i förväg ska låsa sig till den eventuella lösning som kravställaren ser framför sig. Det finns dock två stora problem med att säga att en sådan egenskap alltid ska gälla:

  1. Det förutsätter att alla tänkbara lösningar är acceptabla för beställaren.
  2. Det förutsätter en utvecklingsprocess utan strukturerad kravnedbrytning.

Som beställare bör man givetvis avhålla sig från onödiga begränsningar, men det finns många fall då det är fullt befogat att begränsa lösningsmängden. Om beställaren har absoluta krav på gränssnitt eller utformning och inte kan acceptera produkten om dessa krav inte uppfylls är det rimligt att tydliggöra detta för leverantören. Ett typexempel är kommunikationsgränssnitt mellan komponenter från olika underleverantörer som ska integreras i ett system. Ett annat exempel är en organisation som valt att standardisera alla nya system på en gemensam grundplattform; då spelar det ingen roll om leverantören förespråkar en annan plattform som är tekniskt överlägsen, den kommer ändå inte att accepteras.

Kommentar
Kom ihåg att system har en mycket bred definition och att kravteknik inte bara handlar om mjukvara. Exemplet ovan skulle mycket väl kunna handla som spårvidden i svensk järnväg. Att låta en underleverantör fritt välja spårvidden på en del av bansträckningen förefaller minst sagt olämpligt, och om denna begränsning framgår från början slipper leverantören lägga tid på att utvärdera olika alternativ som ändå kommer att förkastas.

Angående det andra antagandet finns det branscher där det av olika skäl är nödvändigt att kunna följa varje toppnivåkrav (mål) hela vägen ner till den färdiga produkten. Detta innebär att varje kravnivå successivt bryts ner och förfinas till dess att alla designval är gjorda, och att spårbarheten mellan nivåerna upprätthålls. Kraven på den lägsta nivån i hierarkin kan dock omöjligen vara lösningsoberoende och samtidigt så detaljerade att inga ytterligare designval behöver göras.

Kommentar
Ett krav som förfinar en lösning innebär i högsta grad en begränsning i och med att det exkluderar alla andra tänkbara lösningar utom just den som specificeras. Från ett filosofiskt perspektiv kan man dessutom hävda att ett krav till sin natur måste vara en begränsning om det ska tillföra något.

Givet en kravdriven utvecklingsprocess där kravnedbrytning och kravförfining används kommer kraven på varje nivå i hierarkin att begränsa kraven och arkitekturen på de underliggande nivåerna. Dessutom har sannolikt en omfattande begränsning gjorts på ett tidigt stadium i systemets livscykel, nämligen beslutet att verksamhetsbehovet ska lösas med just någon form av tekniskt eller sociotekniskt system.

Således, begränsningar och kravnedbrytning fyller en viktig funktion i utformningen och verifieringen av komplicerade eller komplexa system. På grund av detta inkluderas inte någon egenskap för lösningsoberoende eller lösningsfria krav i Svensk kravterminologi.

Kommentar
Krav som begränsar systemets utformning kan hanteras som attribut kopplade till ett krav istället för krav i sin egen rätt. Vilket alternativ som är bäst beror framför allt på hur krav- och arkitekturprocesserna samverkar, samt om det finns ett behov av att kunna visa att samtliga krav är uppfyllda. Om det sistnämnda är fallet kan det vara bättre att hantera dem som krav, eftersom det kan vara svårt att åstadkomma och upprätthålla spårbarhet för både krav och dess tilldelade attribut.

Egenskaper för enskilda krav

I tabellen nedan finns en lista över kravegenskaper.
Kravegenskap Definition
AtomärtKravet kan inte delas upp i två eller fler olika krav på samma abstraktionsnivå som kravet självt.
EntydigtDet finns en och endast en semantisk tolkning av kravets uttryck.
ExplicitDet framgår vad som är själva kravet, det vill säga vad som måste uppfyllas, och vad som är tilläggsinformation såsom syfte eller bakomliggande analyser som har lett fram till kravet.
FullständigtKravet innehåller all information som är nödvändig för att förstå det behov som kravet uttrycker.
GenomförbartDet är möjligt att realisera kravet inom organisationens eller projektets givna ramar.
KorrektKravet uppfyller de semantiska och syntaktiska reglerna för den valda notationen samt är fritt från motsägelser och andra felaktigheter.
MätbartDet finns en objektiv skala som kan användas för att avgöra om och, beroende på skalan, i vilken utsträckning, kravet är uppfyllt.
NödvändigtFrånvaro av kravet innebär att ett eller flera överenskomna intressentmål för systemet-i-fokus inte kommer att uppnås.
VerifierbartDet är praktiskt möjligt att verifiera att det producerade systemet uppfyller kravet.
Ändamålsenlig notationKravets notation är anpassad efter kravets abstraktionsnivå och målgrupp.
Kommentarer
  1. Entydighetesegenskapen är ett av de 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. Termen entydigt används istället för alternativen eftersom det bland annat blir mer konsekvent i relation till de övriga kravegenskaperna. Dessutom är det i kravsammanhang god sed att uttrycka vad man vill ha snarare än vad man inte vill ha.
  2. Den valda kravnotationen påverkar i stor utsträckning hur lätt eller svårt det är att uppnå entydighet. Även om det till exempel kan framstå som enkelt att skriva krav i naturligt språk så är det långt ifrån lika enkelt (teoretiskt är det omöjligt) att få dessa krav att bli entydiga eftersom naturligt språk saknar fullständigt definierad syntax och semantik. Detta ska inte tolkas som att naturligt språk alltid är dåligt, men man måste vara medveten om begränsningarna i de verktyg och metoder man använder.
  3. 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.
  4. Notera skillnaden mellan verifierbara och mätbara krav ovan. Ett krav kan vara verifierbart utan att ha ett objektivt acceptanskriterium.
  5. Egenskapen nödvändigt skulle lika gärna kunna klassificeras som ett element i en prioritetsskala, men ISO 29148:2011 klassificerar det som en egenskap. Därför listas det tills vidare som en egenskap även i Svensk kravterminologi.

Attribut för enskilda krav

I tabellen nedan finns en lista över kravattribut.
Kommentar
Attributen är i första hand till för den organisation som äger och förvaltar kraven. Detta betyder bland annat att även om viss information är viktig för förvaltningen av kravmängden så måste den inte nödvändigtvis ingå i en kravspecifikation som används för inom ramen för en upphandling.
Kravattribut Definition
AcceptanskriteriumVad som måste vara utfört eller existera för att kravet ska anses vara uppfyllt.
BeroendenRelationer till andra krav som också måste realiseras för att det givna kravet ska få avsedd verkan.
KravtypEtt samlingsnamn eller en kategorisering för krav som konceptuellt hör ihop.
KällaDen intressent eller det regelverk (lag, författning, intern föreskrift) som kravet kommer ifrån.
PrioritetHur viktigt kravet är för systemets intressenter, uttryckt i en prioritetsskala.
RevisionshistorikInformation om när, hur, varför och av vem ett krav har skapats eller ändrats. Revisionshistoriken innehåller information om alla förändringar av kravet och dess attribut som har skett under hela kravets livscykel.
StabilitetEtt mått på sannolikheten att kravets semantiska innehåll inte kommer att ändras inom ett givet tidsintervall. (Borttagning av kravet i sin helhet ses som en semantisk ändring.)
StatusKravets tillstånd i dess livscykel.
SvårighetsgradHur svårt kravet bedöms vara att realisera.
SyfteVad kravets ägare vill uppnå med kravet. Syftet ger i någon mening svar på varför kravet existerar.
Unik identifierareInformation som gör det möjligt att särskilja krav från varandra och hitta ett specifikt krav i en kravmängd.
ÄgareDen intressent som har gett upphov till kravet. Ägarskapet kan, men behöver inte, sammanfalla med källan för kravet.
Kommentar
Statusattributet kan även vara lämpligt att använda som steg i ett arbetsflöde i kravhanteringsprocessen. Några exempel på värden som kan vara relevanta är inkommet, ofullständigt, preliminärt, godkänt och behöver revideras.

Egenskaper för kravmängder

I tabellen nedan finns en lista över kravmängdsegenskaper.
Kravmängdsegenskap Definition
FörvaltningsbarKravmängden är strukturerad och lagrad på ett sätt som gör det enkelt att lägga till och ta bort krav ur mängden, samt att skapa nya revisioner av ett givet krav i mängden.
KomplettDe krav som finns på en underliggande nivå i hierarkin uppfyller tillsammans det överordnade kravet.
KonsistentFör alla krav i mängden gäller att inget krav säger emot något annat, och att endast ett begrepp används för ett givet fenomen.
SpårbarDet går, för varje krav i mängden, att identifiera vilket hierarkiskt överordnat krav som har gett upphov till kravet i fråga, samt vilka hierarkiskt underordnande krav kravet i fråga har gett upphov till.
TillförlitligDet finns assurans för att kravmängden i sin helhet går att använda till det den är ämnad för.
TillräckligSamtliga, för systemet-i-fokus, nödvändiga (se kravegenskapen nödvändigt) krav ingår i kravmängden.
Kommentar

Valet av termen konsistent kan vara värt att motivera närmare, eftersom det inte är helt ovanligt med åsikten att det inte är ett svenskt ord. Ordet finns dock både i Nationalencyklopedin (NE) och Svenska Akademiens ordbok. I Nationalencyklopedin definierar Östen Dahl termen enligt följande:

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.

Eftersom ordet konsistent är mycket likt den engelska motsvarigheten och dessutom redan har viss acceptans inom åtminstone it-området förespåkar Svensk kravterminologi att det används framför något av alternativen. Vidare beskriver ordet det önskade läget istället för att som exempelvis motsägelsefritt utgå från hur det inte ska vara.

Aktiviteter

I detta avsnitt listas några av de vanligt förekommande aktiviteterna inom kravtekniken.

Aktiviteterna är listade i bokstavsordning och inte utifrån när de sker i ett systems eller projekts livscykel. En del aktiviteter är egna deldiscipliner med tillhörande akademiska forskningsområden.

Notera särskilt att kravaktiviteterna under ett systems livscykel inte följer en sekventiell tidsaxel där resultatet från varje aktivitet är fryst för all framtid. Att hantera kraven på det sättet kommer nästan garanterat att leda till ett system som inte realiserar intressentmålen. Vissa aktiviteter kommer att utföras i större omfattning i vissa faser i ett systems livscykel, men de behöver också ofta helt eller delvis itereras i ett senare skede.

Aktivitet Definition
IntressentanalysEn aktivitet där samtliga relevanta intressenter för systemet-i-fokus, samt deras relation till systemet, identifieras.
KravanalysEn 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ångstEn deldisciplin inom kravteknik som identifierar de krav som de relevanta intressenterna har på systemet-i-fokus.
KravförvaltningDe aktiviteter som säkerställer att krav och kravmängder, med tillhörande attribut, hålls aktuella med bibehållna egenskaper.
KravvalideringEn aktivitet som säkerställer att en kravmängd speglar det eller de behov dess intressenter har för den resulterande produkten.
KravverifieringEn aktivitet som säkerställer att ett krav eller en kravmängd har de egenskaper och attribut som specificerats.
Kommentar
Kravfångst används idag synonymt med kravinsamling. Det kan framhållas att inte något av orden speglar det engelska begreppet requirements elicitation tillräckligt väl, men av dessa alternativ förordas ändå kravfångst eftersom det inte på samma sätt som kravinsamling leder tankarna till att krav är något som finns färdigt och bara är att samla in.

Mer om kravvalidering och kravverifiering

Termerna kravvalidering och kravverifiering samt deras relation till begreppen validering och verifiering inom systems engineering och programvaruteknik behöver sannolikt en närmare förklaring.

Inom systems engineering och programvaruteknik syftar validering till att säkerställa att rätt system skapas, medan verifiering säkerställer att systemet som skapas är korrekt. Inom kravtekniken är inte systemet som sådant i fokus för aktiviteterna, utan istället de krav som ligger till grund för systemet. Denna distinktion är viktig att ha i åtanke. Kravvalidering handlar således om att säkerställa att det är rätt krav utifrån intressenternas perspektiv, 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.

Validerings- och verifieringsaktiviteterna samverkar mellan disciplinerna. (Detta är fullt naturligt eftersom kravteknik kan ses som en deldisciplin inom både systems engineering och programvaruteknik). Inom programvaruteknik och systems engineering är verifiering ofta synonymt med att säkerställa att systemet tas fram enligt specifikation, det vill säga att det uppfyller ställda krav. För att man ska kunna göra det måste förstås kraven ha tillräckligt bra kvalitet, vilket säkerställs genom kravverifiering.

Validering är generellt en betydligt svårare utmaning än verifiering. Hur och när i livscykeln valideringen sker beror i hög utsträckning på vilken utvecklingsmetodik som används, men en fördjupad diskussion om detta ligger utanför Svensk kravterminologi. Det går dock inte att nog understryka vikten av att intressentmålen löpande valideras gentemot den verksamhet systemet-i-fokus ska användas i, eftersom man annars riskerar att få fel system, även om det tas fram enligt konstens alla regler och verifieras mot sin specifikation.

Notera för övrigt skillnaderna i definitionerna mellan kravverifiering och kravvalidering: den förstnämnda innebär att verifiering går att genomföra på enstaka krav, medan validering sker för en kravmängd som är relaterad till ett specifikt behov. Skillnaden är avsiktlig, och även om det i vissa fall kan gå att validera ett enstaka krav är det ytterst svårt att göra det om kravet inte förekommer i en kravmängd som har ett specifikt syfte. Till exempel går det oftast att verifiera huruvida ett godtyckligt krav är entydigt eller inte, men det är svårt att validera samma krav utan att veta vilka behov det förväntas möta.

Kommentarer
  1. Skiljelinjen mellan verifiering respektive validering kan ibland vara svår att dra, inte minst för krav på de lägre abstraktionsnivåerna. Om en kravmängd är både komplett och spårbar underlättar det kravvalideringen, samtidigt som de nämnda egenskaperna hanteras inom kravverifieringen. Om det dessutom går att belägga att inte några nödvändiga krav saknas är det värt mycket för både krav- och systemvalideringen.
  2. Varning för språkförbistring! Att verifiera krav kan syfta på att kontrollera om ett system (ofta under framtagande) uppfyller ställda krav, lika gärna som att kontrollera om ett eller flera krav uppfyller önskade egenskaper. Risken för missförstånd rörande validering av krav förefaller inte vara lika stor, men det är viktigt att vara medveten (och överens!) om huruvida det görs med utgångspunkt från ett specifikt system eller mer generellt (exempelvis i ett regelverk som gäller för samtliga system en given kontext).

Arbetsprodukter

I tabellen nedan finns en lista över olika kravrelaterade arbetsprodukter som kan komma att tas fram under ett systems livscykel. Vilka specifika arbetsprodukter som tas fram för ett givet system kommer att variera från fall till fall, och bland annat bero på systemets komplexitet samt valet av arbets- och kontraktsformer.

Arbetsprodukterna har även, utöver projekt- och kontraktsform, olika relevans beroende på var i livscykeln systemet-i-fokus befinner sig.

Arbetsprodukt Definition
AnvändarberättelseEn 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ändningsfallEn steg för steg-beskrivning av hur en aktör interagerar med systemet-i-fokus för att lösa en specifik uppgift.
AnvändningsfallsdiagramEn grafisk representation som visar systemet-i-fokus tillsammans med ett eller flera associerade användningsfall.
AnvändningsscenarioEtt scenario som beskriver hur systemet-i-fokus används i en specifik situation för att lösa ett eller flera verksamhetsbehov.
ArkitekturbeskrivningEn beskrivning av ett systems arkitektur.
IntressentförteckningEn förteckning över de intressenter som är relevanta för systemet-i-fokus, inklusive information om de olika intressenternas relation till systemet.
KontextdiagramEn 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.
KravspecifikationEtt eller flera dokument som innehåller ett eller flera krav som har strukturerats för ett särskilt syfte.
PersonaEn verklighetstrogen och levande beskrivning av en fiktiv person.
Kommentarer
  1. En persona kan helt eller delvis vara baserad på en verklig person. I sådana fall är det bra att att inhämta samtycke från personen i fråga. Detta gäller särskilt för eventuella porträtt eller fotografier.
  2. 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.)
  3. 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.
  4. 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 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.
  5. 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.

Roller

I tabellen nedan finns en lista över roller som förekommer inom kravtekniken.

Ambitionen är att endast inkludera roller som är särskilt centrala för kravtekniksprocesserna. Roller som exempelvis är nödvändiga för att få ett projekt att fungera tas därför inte med, även om det är svårt att helt undvika att tangera andra områden inom systems engineering och projektledning. Rollerna är listade i bokstavsordning; ordningen har således inget att göra med hur viktiga de är.

Roll Definition
BeställareEn intressent som anskaffar eller upphandlar en produkt eller en tjänst från en leverantör.(1)
IntressentEn individ eller organisation som påverkas av, eller har inflytande över, ett systems utformning eller existens.
KravägareEn intressent som är ägare till ett eller flera krav.
LeverantörEn organisation eller individ som ingår en överenskommelse med en beställare om att tillhandahålla en produkt eller en tjänst.(1)
(1)  Definitionen har översatts från ISO 15288:2015 av Patrik Sternudd och används med vederbörligt tillstånd från SIS Förlag AB som medlem i ISO. ISO äger upphovsrätten till ISO 15288:2015.