Kursplan REQB Certifierad Kravhanterare Grundnivå

Kursplan REQB Certifierad Kravhanterare Grundnivå Ver 1.0 Sftware Quality Engineering Bard (SQEB)

Tillkännagivanden Det engelska riginalet (Syllabus, Certified Prfessinal fr Requirements Engineering) till denna kursplan har prducerats av Requirements Engineering Qualificatins Bard Wrking Party Fundatin Level (Editin 2011): (Karlina Zmitrwicz (chair), Alain Betr, Drthée Blcks, Jérôme Khualed, Eric Riu Du Csquer, Chris Hfstetter, Michał Figarski, Francine Lafntaine, Beata Karpiska, Flke Nilssn, Ingvar Nrdström, Alain Ribault, Radsław Smilgin) Bidragande till den svenska översättningen har varit Cecilia Sigrand, Ingvar Nrdström, Beata Karpinska ch Tanja Suza. Dessutm vill vi tacka Ingvar Nrdström, Beata Karpinska, Daniel Säther ch Chris Hfstetter för terminlgiöversättningen sm fungerat sm bas för denna översättning. Huvudtanke Grundtanken med denna kursplan är att prgramvarukmplexiteten ch vårt berende av prgramvara frtsätter att öka. Resultatet gör att vi kräver att prgramvaran har en hög nivå av felfrihet. The Requirements Engineering Qualificatins Bard (REQB) har därför beslutat att skapa en enhetlig internatinell standard inm mrådet kravhantering (requirements engineering). Standarder är sm språk det är bara när du väl förstår dem sm du kan arbeta effektivt. För att kunna skapa ett sådant enhetligt språk i detta viktiga mråde sm kravhantering är, så har förlagan till denna kursplan skapats av internatinella experter under samrdning av REQB. Denna kursplan Detta dkument baseras på REQB Certified Prfessinal fr Requirements Engineering utgivet av Requirements Engineering Qualificatins Bard, REQB i samarbete med Glbal Assciatin fr Sftware Quality, ch har översatts till svenska av Sftware Quality Engineering Bard, SQEB. SQEB ch REQB har kmmit överens att följande villkr skall gälla: 1) Individer ch kursarrangörer får använda denna kursplan sm bas för kurser m referenser ges till REQB ch SQEB sm cpyright-ägare av dkumentet ch att all annnsering av kurser först kan mnämna kursplanen efter det att en fficiell ackreditering av kursmaterialet har gjrts av SQEB (SQEB är av REQB erkänt sm natinellt rgan i Sverige). 2) Varje individ eller grupp av individer får använda denna kursplan sm bas för artiklar, böcker eller andra skrifter m REQB ch SQEB är nämnda sm källan ch cpyright-ägare av kursplanen Cpyright SQEB 2011 Ver 1.0 2 (97) SQEB Sftware Quality Engineering Bard

Innehåll Innehåll... 3 Inledning... 7 Versinshistrik... 8 1 Grunderna (K2)... 9 1.1 Kravspecifikatin (K2)... 10 1.1.1 Definitin ch klassificering (K2)... 10 1.1.2 Prblem med krav (K1)... 12 1.1.3 Kvalitetskriterier för krav (K2)... 12 1.1.4 Lösning (K1)... 13 1.1.5 Åtagande (K1)... 13 1.1.6 Juridiskt ansvar ch fel (K1)... 14 1.1.7 Priritering ch kritikalitet (K1)... 14 1.1.8 Validering ch verifiering (K1)... 14 1.1.9 Kravhantering, kravledning ch kravutveckling (K2)... 15 1.2 Standarder ch nrmer (K1)... 17 1.2.1 Standarder (K1)... 17 1.2.2 Prcessnrmer (K1)... 18 1.2.3 Skälen till att kravhanteringen försummas (K2)... 19 2 Prcessmdeller ch kravhanteringsprcessen (K2)... 20 2.1 Prcessmdeller (K2)... 21 2.1.1 Prcessmdeller (K2)... 21 2.1.2 Generell V-mdell (K2)... 22 2.1.3 Ratinal Unified Prcess (RUP ) (K2)... 22 2.1.4 Agila tillvägagångssätt... 22 2.1.5 Extreme Prgramming (K2)... 23 2.1.6 Scrum (K2)... 23 2.1.7 Mgnadsmdell (K2)... 24 2.2 Kravhanteringsprcessen (K2)... 26 2.2.1 Definitin av kravhanteringsprcessen (K2)... 26 2.2.2 Påverkan på kravhanteringen... 26 3 Prjekt- ch riskhantering (K2)... 28 3.1 Prjekthantering (K2)... 29 3.1.1 Nödvändigheten av Kravhantering i prjekt (K2)... 29 Ver 1.0 3 (97) SQEB Sftware Quality Engineering Bard

3.1.2 Vilka fel kan uppstå i kravhanteringen? (K2)... 30 3.2 Riskhantering (K2)... 31 3.2.1 Nödvändigheten av riskhantering (K2)... 31 3.2.2 Risker (K2)... 31 3.2.3 Riskhantering (K2)... 32 3.2.4 Failure Mde and Effects Analysis (K2)... 33 4 Ansvar ch rller (K2)... 34 4.1 Grundläggande rller (K1)... 35 4.1.1 Grundläggande rller(k2)... 35 4.1.2 Intressenter (K2)... 35 4.2 Uppgifter för Kravhantering (K2)... 37 4.2.1 Uppgifter för Kravhantering (K2)... 37 4.2.2 Kunskaper hs en prfessinell utövare av kravhantering (K1)... 37 5 Identifiering av krav (K2)... 38 5.1 Kund (K1)... 39 5.1.1 Kund (K1)... 39 5.1.2 Avtal (K2)... 39 5.2 Visiner ch mål för prjekt (K2)... 40 5.2.1 Visin (K2)... 40 5.3 Identifiering av intressenter(k2)... 42 5.3.1 Identifiering av intressenter (K2)... 42 5.3.2 Att identifiera ch utvärdera intressenter (K2)... 42 5.4 Tekniker för kravidentifiering (K2)... 43 5.4.1 Syftet med kravidentifiering (K2)... 43 5.4.2 Tekniker (K1)... 43 5.5 Funktinella ch icke-funktinella krav (K2)... 48 5.5.1 Funktinella krav (K2)... 48 5.5.2 Icke-funktinella krav (K2)... 48 5.6 Kravbeskrivning (K2)... 50 5.6.1 Kravbeskrivning (K2)... 50 5.6.2 Tillvägagångssätt vid kravknstruktin (K3)... 50 5.6.3 Kravdkument (K2)... 52 6 Kravspecifikatin (K2)... 53 6.1 Specificering (K2)... 54 6.1.1 Specifikatin (K1)... 54 6.1.2 Kravspecifikatiner (K2)... 54 Ver 1.0 4 (97) SQEB Sftware Quality Engineering Bard

6.1.3 Användarberättelser (K2)... 54 6.1.4 Lösningsspecifikatiner (K2)... 55 6.1.5 Viktiga standarder (K1)... 55 6.2 Prcedur (K3)... 56 6.2.1 Prcedur för lösningsspecifikatin (K3)... 56 6.3 Frmalisering (K2)... 57 6.3.1 Grader av frmalisering (K2)... 57 6.4 Kravkvalitet (K2)... 58 6.4.1 Bakgrund... 58 6.4.2 Mått på kvalitetsförbättring ch kvalitetssäkring av krav (K2)... 58 7 Kravanalys (K2)... 60 7.1 Krav ch lösningar (K1)... 61 7.1.1 Mål för kravanalysen (K2)... 61 7.1.2 Tillvägagångssätt vid kravanalys (K2)... 61 7.1.3 Strukturell skillnad mellan krav ch lösningar (K2)... 61 7.2 Metder ch tekniker (K2)... 62 7.2.1 Mdeller ch metder för analys... 62 7.2.2 Mdelltyper (K2)... 63 7.2.3 Olika perspektiv på systemet (K2)... 63 7.2.4 Olika mdeller (K1)... 64 7.3 Objektsrienterad analys (K2)... 65 7.3.1 UML (K1)... 65 7.3.2 SysML (K2)... 66 7.4 Kstnadsuppskattningar (K2)... 68 7.4.1 Typer av beräkningar (K2)... 68 7.4.2 Påverkan på utvecklingskstnaderna (K2)... 68 7.4.3 Olika sätt att göra kstnadsuppskattningar... 68 7.5 Priritering (K2)... 72 7.5.1 Priritering (K2)... 72 7.5.2 Tillvägagångssätt vid priritering (K2)... 72 7.5.3 Pririteringsskala (K2)... 72 7.6 Överenskmmelse m krav (K2)... 74 7.6.1 Överenskmmelse (K2)... 74 8 Kravspårning (K2)... 75 8.1 Spårning inm prjektet (K2)... 76 8.1.1 Kravens utveckling (K1)... 76 Ver 1.0 5 (97) SQEB Sftware Quality Engineering Bard

8.1.2 Spårbarhet (K2)... 76 8.1.3 Typer av spårbarhet (K2)... 76 8.2 Ändringshantering (K2)... 78 8.2.1 Kravändringar (K1)... 78 8.2.2 Ändringshantering (K2)... 78 8.2.3 Ändringsbegäran (K2)... 79 8.2.4 Ändringshanteringsråd (K1)... 79 8.2.5 Kravens livscykel (K2)... 80 8.2.6 Skillnaden mellan felhantering ch ändringshantering (K2)... 80 8.2.7 En ändrings påverkan på prjektet (K2)... 80 9 Kvalitetssäkring (K2)... 81 9.1 Påverkande faktrer (K1)... 82 9.1.1 Påverkan på Kravhantering (K1)... 82 9.2 Verifiering av krav i kravinsamlingsstadiet (K2)... 83 9.3 Kvalitetssäkring genm testbarhet (K2)... 84 9.3.1 Kravhantering ch testning (K2)... 84 9.3.2 Acceptanskriterier (K2)... 84 9.3.3 Testmetder (K2)... 84 9.3.4 Krav ch testprcesser (K2)... 85 9.4 Mätetal (K2)... 86 9.4.1 Mätetal (K1)... 86 9.4.2 Mätetal för krav (K1)... 86 9.4.3 Mätning av kravkvalitet (K2)... 86 10 Verktyg (K2)... 88 10.1 Fördelar med verktyg (K2)... 89 10.1.1 Användning av verktyg inm kravhantering (K2)... 89 10.1.2 Fördelarna med att använda verktyg (K2)... 89 10.2 Verktygskategrier (K2)... 90 10.2.1 Verktygskategrier (K2)... 90 11 Litteratur... 92 12 Index... 95 Ver 1.0 6 (97) SQEB Sftware Quality Engineering Bard

Inledning Syftet med kursplanen Denna kursplan definierar grundnivån i det prgram sm syftar till att bli certifierad kravhanterare (REQB Certified Prfessinal fr Requirements Engineering, CPRE). Den är utvecklad av REQB i samarbete med Glbal Assciatin fr Sftware Quality ch sedan översatt till svenska. Alla typer av IT-relaterade prdukter, där en prdukt kan bestå av HW, service ch SW med sina utfästelser till krav, men ckså affärskrav med tillhörande dkumentatin. Kursplanen fungerar sm en bas för kurshållare sm ansöker m ackreditering sm lärare. Alla avsnitt i kurplanen måste på mtsvarande sätt ingå i kursmaterialet. Kursplanen kan ckså fungera sm förberedelse för studenter inför en tentamen. Alla mråden är därför föremål för en tentamen sm kan tas antingen efter en genmgången kurs eller berende av kurs. Kursplanen innehåller ckså rekmmenderade tider för varje avsnitt Certifierad kravhanterare på grundnivå i kravhantering Målgruppen för certifiering på grundnivån är den sm är på någt sätt invlverad i prgramvaruutveckling ch kravhantering. Certifiering på grundnivå är ckså användbar för de sm vill ha en grundläggande baskunskap m kravhantering, t.ex. prjektledare, kvalitetsansvariga, systemansvariga, utvecklingsansvariga, IT-chefer, prdukt ch marknadsanalytiker ch chefsknsulter. Att vara certifierad kravhanterare på grundnivå i prgramvarutestning innebär ckså att man kan frtsätta till högre certifieringsnivåer inm kravhantering Examinering Examinering för att bli certifierad kravhanterare på grundnivå (Fundatin Level) är baserat på denna kursplan med stöd av den engelska syllabus ch rdlistan. Alla delar av kursplanen/syllabus är därför med i examen. Examensfrågrna är inte nödvändigtvis knutna till enbart ett kapitel utan kan spänna över flera. Frågrna är av typen flerval (Multiple Chice) Examinering (tenta) kan göras efter deltagande i en ackrediterad kurs eller i en öppen examinering (utan tidigare kurs) eller sm deltagare i en examen sm hållits efter en kurs. Ackreditering Kurshållare för kurs för REQB Certifierad Kravhanterare måste vara ackrediterad av Glbal Assciatin fr Sftware Quality eller SQEB. När det gäller kurs på svenska ger detta genm SQEBs försrg. Ackrediterade kurshållare kan kännas igen genm det fficiella REQB Accredited Training Prvider Lg. Inlärningsmål/kgnitiv kunskapsnivå Inlärningsmålen i denna kursplan har delats in i kgnitiva nivåer (K-nivåer), vilket gör det möjligt för eleven att hitta kmpetensnivån för varje punkt. De kgnitiva nivåerna är angivna i varje kapitel i kursplanen ch klassificeras enligt följande: K1: kmma ihåg Ver 1.0 7 (97) SQEB Sftware Quality Engineering Bard

K2: förstå, förklara K3: använda, tillämpa Alla begrepp listade under Begrepp precis under varje kapitelrubrik skall kännas igen (K1) även m de inte tydligt uttrycks i inlärningsmålen. Detaljnivå Detaljnivån i denna kursplan tillåter internatinell jämförbar undervisning ch examinatin. För att uppnå detta mål, mfattar kursplanen följande: Generella undervisningsmål sm beskriver avsikten med grundnivån En lista med infrmatin sm skall läras ut ch sm innehåller beskrivningar ch referenser till extra material ch källr. Inlärningsmål för varje kunskapsmråde sm beskriver de kgnitiva kunskapsmålen ch vad man avser med denna kunskap. En lista av begrepp sm studenterna måste kunna kmma ihåg ch förstå. En beskrivning av nyckelmråden att lära ut, vilket ckså inbegriper erkända källr ch standarder. Kursplanens innehåll är inte en beskrivning av hela kunskapsmrådet prgramvarutestning, utan speglar den kunskapsnivå sm måste täckas in av kursen för grundnivån. Hur kursplanen är rganiserad Kursplanen innehåller 10 kapitel. Översta rubriken för varje mråde visar vilka inlärningsmål sm täcks av kapitlet ch specificerar ckså tiden för varje kapitel. T.ex.: 3. Prjekt- ch riskhantering (K2) 60 minuter Rubriken visar att kapitel 3 har inlärningsmål för K1 ch K2 (men inte K3). K1 förutsätts gälla därför att kapitlet riktar sig mt en högre nivå. Avsikten är att det tar ungefär 60 minuter att undervisa materialet i kapitlet. Varje kapitel innehåller ett antal avsnitt sm ckså har inlärningsmål ch ungefärlig tidsmfattning beskriven. De underavsnitt sm inte har tidsangivelser specifikt utskrivna inkluderas i tiden för överrdnat avsnitt. Versinshistrik Versin Datum Kmmentarer 1.0 2011-11-24 Första utgåva Ver 1.0 8 (97) SQEB Sftware Quality Engineering Bard

1 Grunderna (K2) 40 minuter Inlärningsmål för Kravhantering, grundnivån Målen visar vad du kmmer att kunna göra efter att ha genmfört respektive avsnitt 1.1 Krav (K2) LO-1.1.1 LO-1.1.2 LO-1.1.3 LO-1.1.4 LO-1.1.5 LO-1.1.6 LO-1.1.7 Kmma ihåg definitinen på krav) Förklara skälen för ch syftet med krav (K2) Förklara hur krav kan klassificeras (K2) Beskriva de lika typerna av krav (K2) Förklara vilka prblem sm finns när det gäller krav (K2) Beskriva vilka begrepp sm är viktiga i samband med krav (K2) Förklara skillnaden mellan RM (Requirements Management) ch RE (Requirements Engineering) (K2) 1.2 Standarder ch nrmer (K1) LO-1.2.1 Kmma ihåg viktiga nrmer ch standarder för Kravhantering (K1) LO-1.2.2 Förklara varför Kravhantering är viktigt (K2) Ver 1.0 9 (97) SQEB Sftware Quality Engineering Bard

1.1 Kravspecifikatin (K2) 20 minuter Termer Åtagande, kritikalitet, funktinella krav, icke-funktinella krav, krav, kravhantering, kravledning, prcesskrav, prduktkrav, priritet, lösning, validering, verifiering 1.1.1 Definitin ch klassificering (K2) Definitin av vad sm menas med ett krav (K1): Krav [IEEE 610.12]: Ett villkr eller en egenskap sm användaren behöver för att lösa ett prblem eller uppnå ett mål. Ett villkr eller en egenskap sm systemet eller systemkmpnenterna måste inneha eller uppfylla för att tillgdse vad sm finns i kntrakt, standarder, specifikatin ch andra dkument. En dkumentatin av varje villkr eller egenskap sm beskrivs i (1) eller (2). Meningen med ch skälen för krav (K2): Grunden för att kunna bedöma, planera, genmföra ch följa ett prjekt. Kundens förväntningar En del i överenskmmelser, beställningar, prjektplaner etc. Gränssättning, leveranstidsramar, kntraktstjänster Klassificering av krav [Ebert05] (K2) Krav består av: Prcesskrav Prduktkrav Prcesskrav är sådana krav sm relaterar till utvecklings- ch leveransprcesser. Exempel är kstnader, marknadsföring, tidsåtgång, försäljning ch distributin, rganisatin ch dkumentatin. Ver 1.0 10 (97) SQEB Sftware Quality Engineering Bard

Prduktkrav kan vara funktinella ch icke-funktinella. Båda kan ses såväl från användarens ch kundens synpunkt (externa) sm från utvecklingsteamets synpunkt (interna). Det är viktigt att kmma ihåg att användare ch kund inte alltid är samma sak. Funktinella krav beskriver hur systemet fungerar (beter sig). Icke-funktinella krav beskriver systemets kvalitetsegenskaper. De kallas fta kvalitetsegenskaper. Skillnaden mellan funktinella ch icke-funktinella krav kan uttryckas på följande sätt: Funktinella krav beskriver vad systemet gör. Icke-funktinella krav beskriver hur systemet gör det. Exempel: Funktinella prduktkrav från användarens ch kundens synpunkt: gränssnitt, applikatiner, tjänster. Funktinella prduktkrav från utvecklingsteamets synpunkt: arkitektur, strömförbrukning, lastfördelning. Icke-funktinella krav från användarens ch kundens synpunkt: tillförlitlighet, prestanda, användbarhet. Icke-funktinella prduktkrav från utvecklingsteamets synpunkt: testbarhet ch ändringsbarhet, verktyg. Grundtyper av krav (K1): Kundens krav Kundens önskningar, behv ch förväntningar, verksamhetskrav på hög nivå Verksamhetsbegränsningar Lösning/systemkrav Specifikatin av kundens behv (detaljerad specificering av verksamhetskrav på hög nivå). Prdukt/kmpnentkrav Funktiner ch egenskaper hs lösningen. Bas för detaljerad analys ch design (exempel: systemanvändningsfall) Ver 1.0 11 (97) SQEB Sftware Quality Engineering Bard

1.1.2 Prblem med krav (K1) De vanligaste prblemen med krav är: Oklara mål Kmmunikatinssvårigheter Språkbarriärer Kunskapsbarriärer Oklara frmuleringar Alltför frmella frmuleringar Instabila krav Dålig kvalitet på kraven (inklusive tvetydiga, överspecificerade, klara, möjliga ch mtstridiga krav) Förgyllning (Gld Plating, alltför mycket beskrivning av ett krav vilket gör att själva kravet döljs av nödig infrmatin) Otillräckligt användarengagemang Förbisedda användarkategrier (följden av att en del intressenter saknas) Dålig eller tillräcklig planering Minimal specificering 1.1.3 Kvalitetskriterier för krav (K2) Kvalitetskriterier för krav [Wiegers05] är nedanstående (K2): 1. Varje krav måste vara: Krrekt kravet måste exakt beskriva den funktinalitet sm ska tillhandahållas. Utgångspunkten för att bedöma (utvärdera) funktinaliteten är källan till kravet (till exempel kunder eller systemkrav på hög nivå). Genmförbart kravet måste kunna implementeras inm de kända möjligheter ch/eller begränsningar sm finns i själva systemet ch i mgivningen. Nödvändigt kravet ska svara mt vad kunden (eller andra intressenter) verkligen behöver ch vad sm behövs för att möta ett externt krav, gränssnitt eller specifika standarder. Pririterat kravet ska ges en priritet sm visar hur viktigt det är för en bestämd prduktrelease. Entydigt kravet ska bara kunna tlkas på ett sätt. Olika läsare ska tlka ch förstå kravet på samma sätt. Verifierbart det ska gå att verifiera m kravet implementerats på ett krrekt sätt. Unikt innehåller inte flera krav; är tillräckligt detaljerat för att specificera ett enskilt krav Oberende av design beskriver vad inte hur Ver 1.0 12 (97) SQEB Sftware Quality Engineering Bard

2. Kravspecifikatinen måste vara: Fullständig inga krav eller nödvändig infrmatin får saknas i kravspecifikatinen. Fullständighet bör ckså gälla enskilda krav ch detaljeringsgrad. Knsekvent kraven får inte strida mt andra prgramvarukrav eller högnivåkrav (system eller verksamhet) Mdifierbar kravspecifikatinen måste tillåta förändringar i kraven. En löpande dkumentatin av ändringar bör göras för varje krav. Spårbar varje krav ska kunna kpplas till dess källa (till exempel ett systemkrav på hög nivå eller ett användningsfall eller en kundrapprt) ch relaterade implementeringsartefakter (till exempel designelement, källkd ch testfall). 1.1.4 Lösning (K1) Lösning (K1) En lösning är implementeringen av kraven. Lösningen kan vara ett prgramvarusystem, prcessförbättring etc. 1.1.5 Åtagande (K1) Åtagande (K1) Åtagande är graden av skyldighet att möta kravet. Åtagandet definieras genm nyckelrd sm tilldelas övergripande krav: Systemet ska Nyckelrden inkluderar: måste, kmmer att, ska, bör, kan. Nyckelrden måste, ska, bör, kan relateras till företags- ch användarkrav före en överenskmmelse. När man kmmit överens ch dragit upp riktlinjerna för kraven bör dessa rd definiera graden av åtagande på ett mer exakt sätt: Systemet kmmer att... Nivån på åtagandet kan uttryckas genm att använda MSCW ntatin (Must have, Shuld have, Culd have, Wuld have). När kunden ch den sm tillhandahåller lösningen har nått en överenskmmelse så har man ett gemensamt åtagande av kraven från deltagarna i prjektet. Kraven kan utvecklas under hela prjektet. När kraven ändras garanterar åtagandet att deltagarna i prjektet accepterar de aktuella, överenskmna kraven ch ändringar i prjektplaner, aktiviteter ch arbetsprdukter detta kan resultera i. Ver 1.0 13 (97) SQEB Sftware Quality Engineering Bard

1.1.6 Juridiskt ansvar ch fel (K1) Juridiskt ansvar (K1) Det finns ett juridiskt ansvar kpplat till prgramvarans kvalitet. Det juridiska ansvaret är fta kpplat till specifika juridiska krav (till exempel miljökrav för ett kärnkraftverk eller ett flygplan) sm måste uppfyllas för den levererade prdukten. Det juridiska ansvaret kan ckså gälla fel (defekter) på prdukten. Det juridiska ansvaret bör klargöras i kntraktet mellan säljare ch kund. Vissa företag kan ckså vara ålagda att möta kntraktskrav liksm juridiska krav eller industrispecifika standarder. Fel (defekt) (K1) Ett fel är en brist i en kmpnent eller ett system sm gör att kmpnenten eller systemet inte fungerar sm de ska, till exempel en felaktig rapprt eller datadefinitin. En defekt, sm inträffar under exekvering, kan göra att en kmpnent eller ett system inte fungerar. [ISTQB]. 1.1.7 Priritering ch kritikalitet (K1) Priritering av krav (K1) Priritering är en utvärdering av hur viktigt/angeläget ett krav är. Enligt [SWEBOK], gäller ftast att ju högre priritet dest viktigare är kravet för att uppfylla de övergripande målen för prgramvaran. Ofta klassificeras de i en fast skala sm till exempel bligatriska, mycket önskvärda, önskvärda eller valbara, ch måste balanseras mt kstnaden för utveckling ch implementering. Exempel på kravpririteringar: Hög Medium Låg Kravkritikalitet (K1) Utvärdering av risk genm att uppskatta den skada sm skulle uppstå m kravet inte uppfylls. Kritikaliteten uttrycks i nivåer: ju högre nivå dest allvarligare knsekvenser vid funktinella felsymptm. 1.1.8 Validering ch verifiering (K1) Validering är en prcess för att försäkra sig m att specifikatinerna av en fas eller hela systemet uppfyller kundens krav. Valideringen utförs vanligen tillsammans med kunden ch syftet är att bekräfta att kraven eller kravspecifikatinen beskriver det sm kunden behöver. Enligt CMMI visar valideringsarbetet att en prdukt eller prduktkmpnent fungerar sm avsett när den placeras på avsedd plats. Det vill säga att man vet att man byggt rätt sak. Kunder tar fta Ver 1.0 14 (97) SQEB Sftware Quality Engineering Bard

fram prduktbeskrivningar eller krav på ett vagt sätt ch valideringen är en hjälp att förstå vad sm behövs (genm att använda verktyg sm scenarier, användningsfall, prttyper etc.) Verifiering är en jämförelse mellan en arbetsprdukt ch specifikatinerna för den. Då kan man avgöra m prgramvaran har utvecklats krrekt ch m de specifikatiner sm beslutades under den föregående fasen har uppfyllts. Enligt CMMI, tillhandahåller verifieringen kntrllstatiner, där utvalda leveranser eller arbetsprdukter verifieras för att bekräfta att de uppfyller kraven sm ställts på dem. Verifikatinsarbetet fkuserar på stegvist säkerställande av kravimplementeringen; det möjliggör tidig ch frtlöpande bekräftelse på att prdukterna byggs på rätt sätt. De vanligaste teknikerna för verifiering ch validering är granskning, revisin, checklistr ch testning. Skillnaden mellan validering ch verifiering kan beskrivas på följande sätt: Verifiering skapade vi prdukten på rätt sätt? Validering skapade vi den rätta prdukten? 1.1.9 Kravhantering, kravledning ch kravutveckling (K2) Skillnaden mellan Kravhantering, kravledning ch kravutveckling (K2) Den engelska förlagan har definierat tre begrepp, Requirements Engineering (RE), Requirements Management (RM) ch Requirements Develpment (RD). I den svenska översättningen har följande valts Requirements Engineering (RE), kravhantering. Ett samlingsnamn för kravdisciplinen på högsta nivå Requirements Management (RM), kravhantering, men även kravledning eller kravförvaltning berende på sammanhanget. Requirements Develpment (RD), kravutveckling Kravhantering, Requirements Engineering, RE Kravhantering på högsta nivå (Requirements Engineering, RE) är en underdisciplin till prgramvaruutveckling (Sftware Engineering), sm fkuserar på att bestämma ch hantera kraven på hårdvaru- ch prgramvarusystem. Kravhanteringen här mfattar kravhantering på lägre nivå, kravledning, ch kravutveckling. Kravhanteringen har följande delprcesser: framtagning av krav, analys ch bearbetning (inklusive kravpriritering), specificering, systemmdellering, kravvalidering. Dessa underprcesser kan överlappa varandra, t.ex. kan systemmdellering vara en del av både analys ch specificering, i visa fall även när det gäller insamling av krav. Kravhantering, Requirements Management, RM Kravhantering på lägre nivå (Requirements Management, RM), kravledning, kravförvaltning, utgör en funktinell ram i hela disciplinen ch har beröringspunkter med andra prcesser sm prjektledning, knfiguratinshantering ch kvalitetsstyrning. Syftet med kravhantering RM, Requirements Management, är att hantera kraven på prjektets prdukter ch kmpnenter, att säkerställa överensstämmelse mellan dessa krav, prjektplanerna Ver 1.0 15 (97) SQEB Sftware Quality Engineering Bard

ch arbetsmaterial under hela livscykeln för prjektets prdukter (utveckling ch underhåll). Den inkluderar prcesser för den övergripande styrningen av krav. Det är en kntinuerlig prcess sm innebär dkumentatin, analys, spårning, priritering, kmmunikatin, överenskmmelse m krav liksm att hantera kravförändringar. Kravutveckling, Requirements Develpment, RD Kravutveckling (Requirements Develpment (RD), är en samling av aktiviteter, uppgifter, tekniker ch verktyg för att identifiera, analysera ch validera krav. Här ingår prcessen att mvandla behv till krav. Syftet med kravutveckling är att samla in, analysera, etablera ch validera kundkrav, prduktkrav ch kmpnentkrav. Ver 1.0 16 (97) SQEB Sftware Quality Engineering Bard

1.2 Standarder ch nrmer (K1) 60 minuter För att klara examinatinen är det inte nödvändigt att kunna innehållet i alla nrmer. Det är dck viktigt (K1) att känna till vilka nrmer sm är viktiga för Kravhanteringen. 1.2.1 Standarder (K1) ISO 9000: Krav på ett kvalitetsstyrningssystem: Definierade begrepp ch grunder för en QMS Dmän- ch industrineutralt ISO 9126 (ersatt av ISO/IEC 25000): Definierar en kvalitetsmdell med sex kategrier: funktinalitet, tillförlitlighet, användbarhet, effektivitet, underhållbarhet, prtabilitet IEEE 610: Standardrdlista för prgramvaruutveckling IEEE 830: Rekmmenderad tillämpning av kravspecifikatiner för prgramvara IEEE 1233: Handledning för utveckling av systemkravspecifikatiner IEEE 1362: Handledning för systemdefinitiner för infrmatinsteknik SWEBOK - The Guide t the Sftware Engineering Bdy f Knwledge (känd sm ISO Technical Reprt 19759): SWEBOK beskriver allmänt vedertagen kunskap när det gäller prgramvaruhantering. Dess 10 kunskapsmråden summerar grundläggande begrepp ch innehåller även en referenslista sm visar var man kan hitta detaljerad infrmatin. Ver 1.0 17 (97) SQEB Sftware Quality Engineering Bard

1.2.2 Prcessnrmer (K1) ISO 12207: Standard för prgramvarrs livscykelprcess ISO 15288: Livscykelprcess hs system ISO 15504: Sftware Prcess Imprvement and Capability Determinatin (SPICE), förbättring av ch förmåga hs prgramvara Ver 1.0 18 (97) SQEB Sftware Quality Engineering Bard

1.2.3 Skälen till att kravhanteringen försummas (K2) Kravhanteringen är av avgörande betydelse men ändå glöms den brt gång på gång. Skälen till att kravhanteringen försummas kan vara följande (K2): Str tidspress En enda inriktning mt snabba resultat En ensidig fkusering på kstnader Hänsyn tas endast till funktinella krav Feltlkningar (mycket tas för givet) ch brist på förståelse m kravhanteringens betydelse för ett lyckat prjekt Möjliga knsekvenser av kravhanteringen försummas (K2) Kraven blir inte exakta Kraven är tvetydiga Kraven är mtsägande Kraven ändras fta under prgramvaruutvecklingen Krav sm inte uppfyller kriterier Krav sm kan tlkas lika Saknade krav Ver 1.0 19 (97) SQEB Sftware Quality Engineering Bard

2 Prcessmdeller ch kravhanteringsprcessen (K2) 60 minuter Inlärningsmål för grundnivån för kravhantering Målen talar m vad du kmmer att kunna göra efter att ha slutfört respektive avsnitt. 2.1 Prcessmdell (K2) LO-2.1.1 Beskriva de lika prcessmdellerna (K2) LO-2.1.2 Förklara hur de lika prcessmdellerna skiljer sig åt (K2) 2.2 Kravhanteringsprcessen (K2) LO-2.2.1 Beskriva de utmärkande dragen i kravhanteringsprcessen (K2) LO-2.2.2 Förklara de lika faserna i kravhanteringsprcessen (K2) Ver 1.0 20 (97) SQEB Sftware Quality Engineering Bard

2.1 Prcessmdeller (K2) 30 minuter Terms Extrem prgramming, prcessmdeller, prduktlivscykel, Ratinal Unified Prcess, V-mdellen 2.1.1 Prcessmdeller (K2) Prcessmdeller är metdberende beskrivningar av utvecklingsprcesser. Här vägs även rller, aktiviteter, faser ch dkument in. En prgramvaruprcessmdell ger ett standardfrmat för att planera, rganisera ch driva ett prgramvaruprjekt. Prduct life cycle (PLC) (K2) Definierar lika faser i prduktutvecklingen. Grundläggande faser: 1. Planering 2. Utveckling 3. Underhåll 4. Utfasning (End f life) Planeringsfasen mfattar: visin, strategi, affärsplan ch lönsamhetsanalys. Utvecklingsfasen mfattar: specificering, förslag ch implementering. Utvecklingsfasen delas i sin tur fta upp i fyra faser: Analys Design Implementering Testning Ver 1.0 21 (97) SQEB Sftware Quality Engineering Bard

2.1.2 Generell V-mdell (K2) Utvecklingssteg: Definitin av krav, fastställande av krav (specificering av högnivåkrav) Utkast till funktinssystemering, systemanalys (funktinsspecifikatiner) Utkast till teknisk systemering, ch arkitektur (prgramvarudesign) Kmpnentspecifikatin Implementering Mdellen är v-frmad ch till varje nivå hör en testnivå: Kravdefinitiner ch analys Användaracceptanstestning Funktinell systemdesign Systemtestning Teknisk design Integreringstestning Kmpnent(mdul)design Enhetstestning Implementering För utbildningsföretag Grafisk återgivning av den grundläggande v-mdellen; fördjupad beskrivning av den grundläggande v-mdellen. 2.1.3 Ratinal Unified Prcess (RUP ) (K2) Ratinal Unified Prcess är en prcessmdell sm tagits fram av IBM Ratinal Det är en iterativ mdell (d.v.s. prcessen upprepas tills alla scenarier, risker ch ändringar har behandlats). Den består av 9 mråden (6 hanteringsdiscipliner ch 3 stödjande discipliner) inklusive en disciplin sm rör krav. Varje disciplin täcks av 4 på varandra följande livscykelfaser för prjekt: förberedelse (inceptin), etablering (elabratin), knstruktin (cnstructin) ch överlämning (transitin). För utbildningsföretag: Fördjupning av RUP med grafisk presentatin, fördjupad studie av kravdisciplinen 2.1.4 Agila tillvägagångssätt Kravledning (Requirements Management) I en agil miljö, spåras ch kmmuniceras krav genm till exempel prduktbacklggar, stry cards ch skärmmdeller (mck-ups). Kravåtagande görs antingen av teamet kllektivt eller av en ansvarig teamledare. Arbetsplaner mdifieras regelbundet (t.ex. dagligen eller varje vecka) baserat på vilka framsteg sm gjrts ch allteftersm förståelsen för krav ch lösning utvecklas. Kntrll av spårbarhet ch överensstämmelse med krav ch arbetsmaterial görs med de tekniker sm redan nämnts, liksm vid början av start- ch slutaktiviteter sm återblick (retrspective) ch demstratinsdagar. Kravutveckling I agila miljöer blir kundens behv ch idéer iterativt insamlade, genmarbetade, analyserade ch validerade. Kraven dkumenteras i frm av till exempel användarberättelser (user stries), scenarier, användningsfall ch prdukt-backlggar liksm resultatet av de lika iteratinerna Ver 1.0 22 (97) SQEB Sftware Quality Engineering Bard