Transcript Kursplan
Kursplan REQB® Certifierad Kravhanterare Grundnivå
Ver 1.0 ––––––––––––––––––––––––––––––––––––––––––––––––
Software Quality Engineering Board (SQEB)
––––––––––––––––––––––––––––––––––––––––––––––––
Tillkännagivanden
Det engelska originalet (Syllabus, Certified Professional for Requirements Engineering) till denna kursplan har producerats av Requirements Engineering Qualifications Board Working Party Foundation Level (Edition 2011): (Karolina Zmitrowicz (chair), Alain Betro, Dorothée Blocks, Jérôme Khoualed, Eric Riou Du Cosquer, Chris Hofstetter, Michał Figarski, Francine Lafontaine, Beata Karpioska, Folke Nilsson, Ingvar Nordström, Alain Ribault, Radosław Smilgin) Bidragande till den svenska översättningen har varit Cecilia Sigrand, Ingvar Nordström, Beata Karpinska och Tanja Souza. Dessutom vill vi tacka Ingvar Nordström, Beata Karpinska, Daniel Säther och Chris Hofstetter för terminologiöversättningen som fungerat som bas för denna översättning.
Huvudtanke
Grundtanken med denna kursplan är att programvarukomplexiteten och vårt beroende av programvara fortsätter att öka. Resultatet gör att vi kräver att programvaran har en hög nivå av felfrihet. The Requirements Engineering Qualifications Board (REQB) har därför beslutat att skapa en enhetlig internationell standard inom området kravhantering (requirements engineering). Standarder är som språk – det är bara när du väl förstår dem som du kan arbeta effektivt. För att kunna skapa ett sådant enhetligt språk i detta viktiga område som kravhantering är, så har förlagan till denna kursplan skapats av internationella experter under samordning av REQB.
Denna kursplan
Detta dokument baseras på REQB Certified Professional for Requirements Engineering utgivet av Requirements Engineering Qualifications Board, REQB i samarbete med Global Association for Software Quality, och har översatts till svenska av Software Quality Engineering Board, SQEB. SQEB och REQB har kommit överens att följande villkor skall gälla: 1) Individer och kursarrangörer får använda denna kursplan som bas för kurser om referenser ges till REQB och SQEB som copyright-ägare av dokumentet och att all annonsering av kurser först kan omnämna kursplanen efter det att en officiell ackreditering av kursmaterialet har gjorts av SQEB (SQEB är av REQB erkänt som nationellt organ i Sverige). 2) Varje individ eller grupp av individer får använda denna kursplan som bas för artiklar, böcker eller andra skrifter om REQB och SQEB är nämnda som källan och copyright-ägare av kursplanen Copyright © SQEB 2011 Ver 1.0 © SQEB – Software Quality Engineering Board
2 (97)
Innehåll
Ver 1.0 © SQEB – Software Quality Engineering Board
3 (97)
Ver 1.0 © SQEB – Software Quality Engineering Board
4 (97)
Ver 1.0 © SQEB – Software Quality Engineering Board
5 (97)
Ver 1.0 © SQEB – Software Quality Engineering Board
6 (97)
Inledning
Syftet med kursplanen
Denna kursplan definierar grundnivån i det program som syftar till att bli certifierad kravhanterare (REQB Certified Professional for Requirements Engineering, CPRE). Den är utvecklad av REQB i samarbete med Global Association for Software Quality och sedan översatt till svenska. Alla typer av IT-relaterade produkter, där en produkt kan bestå av HW, service och SW med sina utfästelser till krav, men också affärskrav med tillhörande dokumentation. Kursplanen fungerar som en bas för kurshållare som ansöker om ackreditering som lärare. Alla avsnitt i kurplanen måste på motsvarande sätt ingå i kursmaterialet. Kursplanen kan också fungera som förberedelse för studenter inför en tentamen. Alla områden är därför föremål för en tentamen som kan tas antingen efter en genomgången kurs eller oberoende av kurs. Kursplanen innehåller också rekommenderade tider för varje avsnitt
Certifierad kravhanterare på grundnivå i kravhantering
Målgruppen för certifiering på grundnivån är den som är på något sätt involverad i programvaru utveckling och kravhantering. Certifiering på grundnivå är också användbar för de som vill ha en grundläggande baskunskap om kravhantering, t.ex. projektledare, kvalitetsansvariga, system ansvariga, utvecklingsansvariga, IT-chefer, produkt och marknadsanalytiker och chefskonsulter. Att vara certifierad kravhanterare på grundnivå i programvarutestning innebär också att man kan fortsätta till högre certifieringsnivåer inom kravhantering
Examinering
Examinering för att bli certifierad kravhanterare på grundnivå (Foundation Level) är baserat på denna kursplan med stöd av den engelska syllabus och ordlistan. Alla delar av kursplanen/syllabus är därför med i examen. Examensfrågorna är inte nödvändigtvis knutna till enbart ett kapitel utan kan spänna över flera. Frågorna är av typen flerval (Multiple Choice) Examinering (tenta) kan göras efter deltagande i en ackrediterad kurs eller i en öppen examinering (utan tidigare kurs) eller som deltagare i en examen som hållits efter en kurs.
Ackreditering
Kurshållare för kurs för REQB Certifierad Kravhanterare måste vara ackrediterad av Global Association for Software Quality eller SQEB. När det gäller kurs på svenska ger detta genom SQEBs försorg. Ackrediterade kurshållare kan kännas igen genom det officiella REQB Accredited Training Provider Logo.
Inlärningsmål/kognitiv kunskapsnivå
Inlärningsmålen i denna kursplan har delats in i kognitiva nivåer (K-nivåer), vilket gör det möjligt för eleven att hitta ”kompetensnivån” för varje punkt. De kognitiva nivåerna är angivna i varje kapitel i kursplanen och klassificeras enligt följande: K1: komma ihåg Ver 1.0 © SQEB – Software Quality Engineering Board
7 (97)
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 om de inte tydligt uttrycks i inlärningsmålen.
Detaljnivå
Detaljnivån i denna kursplan tillåter internationell jämförbar undervisning och examination. För att uppnå detta mål, omfattar kursplanen följande: Generella undervisningsmål som beskriver avsikten med grundnivån En lista med information som skall läras ut och som innehåller beskrivningar och referenser till extra material och källor. Inlärningsmål för varje kunskapsområde som beskriver de kognitiva kunskapsmålen och vad man avser med denna kunskap. En lista av begrepp som studenterna måste kunna komma ihåg och förstå. En beskrivning av nyckelområden att lära ut, vilket också inbegriper erkända källor och standarder. Kursplanens innehåll är inte en beskrivning av hela kunskapsområdet programvarutestning, utan speglar den kunskapsnivå som måste täckas in av kursen för grundnivån.
Hur kursplanen är organiserad
Kursplanen innehåller 10 kapitel. Översta rubriken för varje område visar vilka inlärningsmål som täcks av kapitlet och specificerar också tiden för varje kapitel. T.ex.: 3. Projekt- och riskhantering (K2) 60 minuter Rubriken visar att kapitel 3 har inlärningsmål för K1 och K2 (men inte K3). K1 förutsätts gälla därför att kapitlet riktar sig mot 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 som också har inlärningsmål och ungefärlig tidsomfattning beskriven. De underavsnitt som inte har tidsangivelser specifikt utskrivna inkluderas i tiden för överordnat avsnitt.
Versionshistorik
Version
1.0
Datum
2011-11-24
Kommentarer
Första utgåva Ver 1.0 © SQEB – Software Quality Engineering Board
8 (97)
1 Grunderna (K2) 40 minuter
Inlärningsmål för Kravhantering, grundnivån
Målen visar vad du kommer att kunna göra efter att ha genomfört respektive avsnitt
1.1 Krav (K2)
LO-1.1.1 LO-1.1.2 LO-1.1.3 Komma ihåg definitionen på krav) Förklara skälen för och syftet med krav (K2) Förklara hur krav kan klassificeras (K2) LO-1.1.4 LO-1.1.5 LO-1.1.6 LO-1.1.7 Beskriva de olika typerna av krav (K2) Förklara vilka problem som finns när det gäller krav (K2) Beskriva vilka begrepp som är viktiga i samband med krav (K2) Förklara skillnaden mellan RM (Requirements Management) och RE (Requirements Engineering) (K2)
1.2 Standarder och normer (K1)
LO-1.2.1 Komma ihåg viktiga normer och standarder för Kravhantering (K1) LO-1.2.2 Förklara varför Kravhantering är viktigt (K2) Ver 1.0 © SQEB – Software Quality Engineering Board
9 (97)
1.1
Kravspecifikation (K2) 20 minuter
Termer
Åtagande, kritikalitet, funktionella krav, icke-funktionella krav, krav, kravhantering, kravledning, processkrav, produktkrav, prioritet, lösning, validering, verifiering
1.1.1
Definition och klassificering (K2)
Definition av vad som menas med ett ”krav” (K1): Krav [IEEE 610.12]: Ett villkor eller en egenskap som användaren behöver för att lösa ett problem eller uppnå ett mål. Ett villkor eller en egenskap som systemet eller systemkomponenterna måste inneha eller uppfylla för att tillgodose vad som finns i kontrakt, standarder, specifikation och andra dokument. En dokumentation av varje villkor eller egenskap som beskrivs i (1) eller (2). Meningen med och skälen för krav (K2): Grunden för att kunna bedöma, planera, genomföra och följa ett projekt. Kundens förväntningar En del i överenskommelser, beställningar, projektplaner etc. Gränssättning, leveranstidsramar, kontraktstjänster Klassificering av krav [Ebert05] (K2) Krav består av: Processkrav Produktkrav Processkrav är sådana krav som relaterar till utvecklings- och leveransprocesser. Exempel är kostnader, marknadsföring, tidsåtgång, försäljning och distribution, organisation och dokumentation. Ver 1.0 © SQEB – Software Quality Engineering Board
10 (97)
Produktkrav kan vara funktionella och icke-funktionella. Båda kan ses såväl från användarens och kundens synpunkt (externa) som från utvecklingsteamets synpunkt (interna). Det är viktigt att komma ihåg att användare och kund inte alltid är samma sak. Funktionella krav beskriver hur systemet fungerar (beter sig). Icke-funktionella krav ”kvalitetsegenskaper.” beskriver systemets kvalitetsegenskaper. De kallas Skillnaden mellan funktionella och icke-funktionella krav kan uttryckas på följande sätt: ofta Funktionella krav beskriver
vad
systemet gör. Icke-funktionella krav beskriver
hur
systemet gör det. Exempel: Funktionella produktkrav från användarens och kundens synpunkt: gränssnitt, applikationer, tjänster. Funktionella produktkrav från utvecklingsteamets synpunkt: arkitektur, strömförbrukning, lastfördelning. Icke-funktionella krav från användarens och kundens synpunkt: tillförlitlighet, prestanda, användbarhet. Icke-funktionella produktkrav från utvecklingsteamets synpunkt: testbarhet och ändringsbarhet, verktyg. Grundtyper av krav (K1): Kundens krav o Kundens önskningar, behov och förväntningar, verksamhetskrav på hög nivå o Verksamhetsbegränsningar Lösning/systemkrav o Specifikation av kundens behov (detaljerad specificering av verksamhetskrav på hög nivå). Produkt/komponentkrav o Funktioner och egenskaper hos lösningen. o Bas för detaljerad analys och design (exempel: systemanvändningsfall) Ver 1.0 © SQEB – Software Quality Engineering Board
11 (97)
1.1.2
Problem med krav (K1)
De vanligaste problemen med krav är: Oklara mål Kommunikationssvårigheter Språkbarriärer Kunskapsbarriärer Oklara formuleringar Alltför formella formuleringar Instabila krav Dålig kvalitet på kraven (inklusive tvetydiga, överspecificerade, oklara, omöjliga och motstridiga krav) Förgyllning (Gold Plating, alltför mycket beskrivning av ett krav vilket gör att själva kravet döljs av onödig information) Otillräckligt användarengagemang Förbisedda användarkategorier (följden av att en del intressenter saknas) Dålig eller otillrä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: Korrekt – kravet måste exakt beskriva den funktionalitet som ska tillhandahållas. Utgångspunkten för att bedöma (utvärdera) funktionaliteten är källan till kravet (till exempel kunder eller systemkrav på hög nivå). Genomförbart – kravet måste kunna implementeras inom de kända möjligheter och/eller begränsningar som finns i själva systemet och i omgivningen. Nödvändigt – kravet ska svara mot vad kunden (eller andra intressenter) verkligen behöver och vad som behövs för att möta ett externt krav, gränssnitt eller specifika standarder. Prioriterat – kravet ska ges en prioritet som visar hur viktigt det är för en bestämd produktrelease. Entydigt – kravet ska bara kunna tolkas på ett sätt. Olika läsare ska tolka och förstå kravet på samma sätt. Verifierbart – det ska gå att verifiera om kravet implementerats på ett korrekt sätt. Unikt – innehåller inte flera krav; är tillräckligt detaljerat för att specificera ett enskilt krav Oberoende av design – beskriver “vad” inte “hur” Ver 1.0 © SQEB – Software Quality Engineering Board
12 (97)
2.
Kravspecifikationen måste vara: Fullständig – inga krav eller nödvändig information får saknas i kravspecifikationen. Fullständighet bör också gälla enskilda krav och detaljeringsgrad. Konsekvent – kraven får inte strida mot andra programvarukrav eller högnivåkrav (system eller verksamhet) Modifierbar – kravspecifikationen måste tillåta förändringar i kraven. En löpande dokumentation av ändringar bör göras för varje krav. Spårbar – varje krav ska kunna kopplas till dess källa (till exempel ett systemkrav på hög nivå eller ett användningsfall eller en kundrapport) och relaterade implementerings artefakter (till exempel designelement, källkod och testfall).
1.1.4
Lösning (K1)
Lösning (K1) En lösning är implementeringen av kraven. Lösningen kan vara ett programvarusystem, processförbättring etc.
1.1.5
Åtagande (K1)
Åtagande (K1) Åtagande är graden av skyldighet att möta kravet. Åtagandet definieras genom nyckelord som tilldelas övergripande krav: Systemet ska… Nyckelorden inkluderar: “måste”, “kommer att”, ”ska”, “bör”, “kan”. Nyckelorden “måste”, “ska”, “bör”, “kan” relateras till företags- och användarkrav före en överenskommelse. När man kommit överens och dragit upp riktlinjerna för kraven bör dessa ord definiera graden av åtagande på ett mer exakt sätt: Systemet kommer att... Nivån på åtagandet kan uttryckas genom att använda MoSCoW notation (Must have, Should have, Could have, Would have). När kunden och den som tillhandahåller lösningen har nått en överenskommelse så har man ett gemensamt åtagande av kraven från deltagarna i projektet. Kraven kan utvecklas under hela projektet. När kraven ändras garanterar åtagandet att deltagarna i projektet accepterar de aktuella, överenskomna kraven och ändringar i projektplaner, aktiviteter och arbetsprodukter detta kan resultera i. Ver 1.0 © SQEB – Software Quality Engineering Board
13 (97)
1.1.6
Juridiskt ansvar och fel (K1)
Juridiskt ansvar (K1) Det finns ett juridiskt ansvar kopplat till programvarans kvalitet. Det juridiska ansvaret är ofta kopplat till specifika juridiska krav (till exempel miljökrav för ett kärnkraftverk eller ett flygplan) som måste uppfyllas för den levererade produkten. Det juridiska ansvaret kan också gälla fel (defekter) på produkten. Det juridiska ansvaret bör klargöras i kontraktet mellan säljare och kund. Vissa företag kan också vara ålagda att möta kontraktskrav liksom juridiska krav eller industrispecifika standarder. Fel (defekt) (K1) Ett fel är en brist i en komponent eller ett system som gör att komponenten eller systemet inte fungerar som de ska, till exempel en felaktig rapport eller datadefinition. En defekt, som inträffar under exekvering, kan göra att en komponent eller ett system inte fungerar. [ISTQB].
1.1.7
Prioritering och kritikalitet (K1)
Prioritering av krav (K1) Prioritering är en utvärdering av hur viktigt/angeläget ett krav är. Enligt [SWEBOK], gäller oftast att ju högre prioritet desto viktigare är kravet för att uppfylla de övergripande målen för programvaran. Ofta klassificeras de i en fast skala som till exempel obligatoriska, mycket önskvärda, önskvärda eller valbara, och måste balanseras mot kostnaden för utveckling och implementering. Exempel på kravprioriteringar: Hög Medium Låg Kravkritikalitet (K1) Utvärdering av risk genom att uppskatta den skada som skulle uppstå om kravet inte uppfylls. Kritikaliteten uttrycks i nivåer: ju högre nivå desto allvarligare konsekvenser vid funktionella felsymptom.
1.1.8
Validering och verifiering (K1)
Validering är en process för att försäkra sig om att specifikationerna av en fas eller hela systemet uppfyller kundens krav. Valideringen utförs vanligen tillsammans med kunden och syftet är att bekräfta att kraven eller kravspecifikationen beskriver det som kunden behöver. Enligt CMMI visar valideringsarbetet att en produkt eller produktkomponent fungerar som avsett när den placeras på avsedd plats. Det vill säga att man vet att ”man byggt rätt sak”. Kunder tar ofta Ver 1.0 © SQEB – Software Quality Engineering Board
14 (97)
fram produktbeskrivningar eller krav på ett vagt sätt och valideringen är en hjälp att förstå vad som behövs (genom att använda verktyg som scenarier, användningsfall, prototyper etc.) Verifiering är en jämförelse mellan en arbetsprodukt och specifikationerna för den. Då kan man avgöra om programvaran har utvecklats korrekt och om de specifikationer som beslutades under den föregående fasen har uppfyllts. Enligt CMMI, tillhandahåller verifieringen kontrollstationer, där utvalda leveranser eller arbetsprodukter verifieras för att bekräfta att de uppfyller kraven som ställts på dem. Verifikationsarbetet fokuserar på stegvist säkerställande av kravimplementeringen; det möjliggör tidig och fortlöpande bekräftelse på att produkterna byggs på rätt sätt. De vanligaste teknikerna för verifiering och validering är granskning, revision, checklistor och testning. Skillnaden mellan validering och verifiering kan beskrivas på följande sätt: Verifiering – skapade vi produkten på rätt sätt? Validering – skapade vi den rätta produkten?
1.1.9
Kravhantering, kravledning och kravutveckling (K2)
Skillnaden mellan Kravhantering, kravledning och kravutveckling (K2) Den engelska förlagan har definierat tre begrepp, Requirements Engineering (RE), Requirements Management (RM) och Requirements Development (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 beroende på sammanhanget. Requirements Development (RD), kravutveckling
Kravhantering, Requirements Engineering, RE
Kravhantering på högsta nivå (Requirements Engineering, RE) är en underdisciplin till programvaruutveckling (Software Engineering), som fokuserar på att bestämma och hantera kraven på hårdvaru- och programvarusystem. Kravhanteringen här omfattar kravhantering på lägre nivå, kravledning, och kravutveckling. Kravhanteringen har följande delprocesser: framtagning av krav, analys och bearbetning (inklusive kravprioritering), specificering, systemmodellering, kravvalidering. Dessa underprocesser kan överlappa varandra, t.ex. kan systemmodellering vara en del av både analys och 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 funktionell ram i hela disciplinen och har beröringspunkter med andra processer som projektledning, konfigurationshantering och kvalitetsstyrning. Syftet med kravhantering RM, Requirements Management, är att hantera kraven på projektets produkter och komponenter, att säkerställa överensstämmelse mellan dessa krav, projektplanerna Ver 1.0 © SQEB – Software Quality Engineering Board
15 (97)
och arbetsmaterial under hela livscykeln för projektets produkter (utveckling och underhåll). Den inkluderar processer för den övergripande styrningen av krav. Det är en kontinuerlig process som innebär dokumentation, analys, spårning, prioritering, kommunikation, överenskommelse om krav liksom att hantera kravförändringar.
Kravutveckling, Requirements Development, RD
Kravutveckling (Requirements Development (RD), är en samling av aktiviteter, uppgifter, tekniker och verktyg för att identifiera, analysera och validera krav. Här ingår processen att omvandla behov till krav. Syftet med kravutveckling är att samla in, analysera, etablera och validera kundkrav, produktkrav och komponentkrav. Ver 1.0 © SQEB – Software Quality Engineering Board
16 (97)
1.2
Standarder och normer (K1) 60 minuter
För att klara examinationen är det inte nödvändigt att kunna innehållet i alla normer. Det är dock viktigt (K1) att känna till vilka normer som är viktiga för Kravhanteringen.
1.2.1
Standarder (K1)
ISO 9000: Krav på ett kvalitetsstyrningssystem: Definierade begrepp och grunder för en QMS Domän- och industrineutralt ISO 9126 (ersatt av ISO/IEC 25000): Definierar en kvalitetsmodell med sex kategorier: funktionalitet, tillförlitlighet, användbarhet, effektivitet, underhållbarhet, portabilitet IEEE 610: Standardordlista för programvaruutveckling IEEE 830: Rekommenderad tillämpning av kravspecifikationer för programvara IEEE 1233: Handledning för utveckling av systemkravspecifikationer IEEE 1362: Handledning för systemdefinitioner för informationsteknik SWEBOK - The Guide to the Software Engineering Body of Knowledge (känd som ISO Technical Report 19759): SWEBOK beskriver allmänt vedertagen kunskap när det gäller programvaruhantering. Dess 10 kunskapsområden summerar grundläggande begrepp och innehåller även en referenslista som visar var man kan hitta detaljerad information. Ver 1.0 © SQEB – Software Quality Engineering Board
17 (97)
1.2.2
Processnormer (K1)
ISO 12207: Standard för programvarors livscykelprocess ISO 15288: Livscykelprocess hos system ISO 15504: Software Process Improvement and Capability Determination (SPICE), förbättring av och förmåga hos programvara Ver 1.0 © SQEB – Software Quality Engineering Board
18 (97)
1.2.3
Skälen till att kravhanteringen försummas (K2)
Kravhanteringen är av avgörande betydelse men ändå glöms den bort gång på gång. Skälen till att kravhanteringen försummas kan vara följande (K2): Stor tidspress En enda inriktning mot snabba resultat En ensidig fokusering på kostnader Hänsyn tas endast till funktionella krav Feltolkningar (mycket tas för givet) och brist på förståelse om kravhanteringens betydelse för ett lyckat projekt Möjliga konsekvenser av kravhanteringen försummas (K2) Kraven blir inte exakta Kraven är tvetydiga Kraven är motsägande Kraven ändras ofta under programvaruutvecklingen Krav som inte uppfyller kriterier Krav som kan tolkas olika Saknade krav Ver 1.0 © SQEB – Software Quality Engineering Board
19 (97)
2 Processmodeller och kravhanteringsprocessen (K2) 60 minuter
Inlärningsmål för grundnivån för kravhantering
Målen talar om vad du kommer att kunna göra efter att ha slutfört respektive avsnitt.
2.1 Processmodell (K2)
LO-2.1.1 LO-2.1.2 Beskriva de olika processmodellerna (K2) Förklara hur de olika processmodellerna skiljer sig åt (K2)
2.2 Kravhanteringsprocessen (K2)
LO-2.2.1 Beskriva de utmärkande dragen i kravhanteringsprocessen (K2) LO-2.2.2 Förklara de olika faserna i kravhanteringsprocessen (K2) Ver 1.0 © SQEB – Software Quality Engineering Board
20 (97)
2.1
Processmodeller (K2) 30 minuter
Terms
Extrem programming, processmodeller, produktlivscykel, Rational Unified Process, V-modellen
2.1.1
Processmodeller (K2)
Processmodeller är metodoberoende beskrivningar av utvecklingsprocesser. Här vägs även roller, aktiviteter, faser och dokument in. En programvaruprocessmodell ger ett standardformat för att planera, organisera och driva ett programvaruprojekt. Product life cycle (PLC) (K2) Definierar olika faser i produktutvecklingen. Grundläggande faser: 1.
Planering 2.
Utveckling 3.
Underhåll 4.
Utfasning (End of life) Planeringsfasen omfattar: vision, strategi, affärsplan och lönsamhetsanalys. Utvecklingsfasen omfattar: specificering, förslag och implementering. Utvecklingsfasen delas i sin tur ofta upp i fyra faser: Analys Design Implementering Testning Ver 1.0 © SQEB – Software Quality Engineering Board
21 (97)
2.1.2
Generell V-modell (K2)
Utvecklingssteg: Definition av krav, fastställande av krav (specificering av högnivåkrav) Utkast till funktionssystemering, systemanalys (funktionsspecifikationer) Utkast till teknisk systemering, och arkitektur (programvarudesign) Komponentspecifikation Implementering Modellen är v-formad och till varje nivå hör en testnivå: Kravdefinitioner och analys Funktionell systemdesign Teknisk design → → → Användaracceptanstestning Systemtestning Integreringstestning Komponent(modul)design → Implementering Enhetstestning
För utbildningsföretag Grafisk återgivning av den grundläggande v-modellen; fördjupad beskrivning av den grundläggande v-modellen.
2.1.3
Rational Unified Process (RUP©) (K2)
Rational Unified Process är en processmodell som tagits fram av IBM Rational © Det är en iterativ modell (d.v.s. processen upprepas tills alla scenarier, risker och ändringar har behandlats). Den består av 9 områden (6 hanteringsdiscipliner och 3 stödjande discipliner) inklusive en disciplin som rör krav. Varje disciplin täcks av 4 på varandra följande livscykelfaser för projekt: förberedelse (inception), etablering (elaboration), konstruktion (construction) och överlämning (transition).
För utbildningsföretag: Fördjupning av RUP© med grafisk presentation, fördjupad studie av kravdisciplinen
2.1.4
Agila tillvägagångssätt
Kravledning (Requirements Management) I en agil miljö, spåras och kommuniceras krav genom till exempel produktbackloggar, ”story cards” och skärmmodeller (mock-ups). Kravåtagande görs antingen av teamet kollektivt eller av en ansvarig teamledare. Arbetsplaner modifieras regelbundet (t.ex. dagligen eller varje vecka) baserat på vilka framsteg som gjorts och allteftersom förståelsen för krav och lösning utvecklas. Kontroll av spårbarhet och överensstämmelse med krav och arbetsmaterial görs med de tekniker som redan nämnts, liksom vid början av start- och slutaktiviteter som återblick (retrospective) och demostrationsdagar. Kravutveckling I agila miljöer blir kundens behov och idéer iterativt insamlade, genomarbetade, analyserade och validerade. Kraven dokumenteras i form av till exempel användarberättelser (user stories), scenarier, användningsfall och produkt-backloggar liksom resultatet av de olika iterationerna Ver 1.0 © SQEB – Software Quality Engineering Board
22 (97)
(fungerande kod när det gäller programvara). Vilka krav som ska tas upp i en viss iteration beror på den bedömning som görs av riskerna och på de prioriteter som hör ihop med det som återstår i backloggen. Vilka enskilda krav (och andra artefakter) som ska dokumenteras beror på vilket behov som finns av samordning (mellan teammedlemmar, team och senare iterationer) och risken för att förlora det man lärt. Även om kunden är med i teamet kan det finnas ett behov av att separera kund- och produktdokumentation för att ge utrymme för att undersöka olika lösningar. När lösningen börjar klarna övergår ansvaret för de utvecklade kraven till det team som är bäst lämpat.
2.1.5
Extreme Programming (K2)
Extreme Programming, är en metod av Kent Beck m.fl. som agerar på förändrade kundkrav. Projektledningen (t ex Scrum, paragraf 2.1.6) definierar hur och när kundens kravändringar ska implementeras i programvarulösningen (t.ex. i vilken Sprint). Metoden förespråkar att kunden får täta programvaruleveranser i korta utvecklingsfaser (timeboxing) med syfte att förbättra produktivitet och tillhandahålla kontrollpunkter där nya krav kan föras in. Några kännetecken för extreme programming är: Parprogrammering Omfattande kodgranskning Enhetstestning av koden Undvika implementering av features förrän de verkligen behövs Platt ledningsstruktur (ingen komplex hierarki i teamet). Detta kan bäst ses i Scrumteam – Scrumteamet är “självstyrande”, det finns inga roller som t ex ledare, projektledare etc.) Enkel och tydlig kod Beredskap för ändringar av kundens krav allteftersom tiden går och förståelsen för problemet ökar Tät kommunikation med kunden och mellan programmerarna Fullständig avsaknad av kravbegränsning (ingen separat “kravfas” innan utvecklingen inleds; kravutveckling, förädling och
upptäckt
är en del av den verkliga programvaruutvecklingen (programmeringen).
2.1.6
Scrum (K2)
Scrum är ett agilt ramverk. Scrum formaliserades ursprungligen för programvaruutvecklingsprojekt och innehåller uppsättningar med tillämpningar och förbestämda roller. Huvudrollerna inom Scrum är: Scrum Master (ansvarig för att underhålla och driva processerna) Produktägare (representerar intressenter och verksamheten) Team (en tvärfunktionell grupp som utför de verkliga analyserna, design, implementering, testning etc.) Ett av de viktigaste kännetecken för Scrum är att utvecklingen delas in i “Sprint” (vanligt är en två- eller fyraveckorsperiod). Under varje Sprint, skapar teamet så kallade potentiellt levererbara produkttillägg (inkrement). Scrum tillåter hantering av krav via backloggar. Det finns två typer av backloggar: Ver 1.0 © SQEB – Software Quality Engineering Board
23 (97)
Scrums arbetssätt karaktäriseras i första hand av: I slutet av varje Sprint bör fungerande programvara levereras – i praktiken börjar teamen arbeta med kravanalysen och fortsätter med det under den faktiska Sprinten. När man bryter ned uppgifterna så klargörs kraven. Produktbackloggar – en högnivålista som behålls under hela projektet. Den förenar krav i form av breda beskrivningar av alla potentiella features, prioriterade i förhållande till affärsnytta eller verksamhetsnytta. Produkt-backloggar ägs av produktägaren. Sprint-backlogg – en arbetslista för teamet under nästa Sprint. Features bryts ned till aktiviteter som bör motsvara mellan fyra och sexton timmars arbete. Sprint-backloggen ägs av teamet. Teammedlemmar förväntas samarbeta och fortlöpande kundengagemang är en nyckelförutsättning i agil utveckling. Feedback till kunden kan ges genom att programversionen demonstreras vid möten mot slutet av en Sprint eller genom att användaren gör acceptanstester Kraven utvecklas genom feedback från kunden – att se programvaran i bruk hjälper kunderna att förtydliga sina krav. Kraven är inte helt specificerade innan utvecklingsarbetet börjar, men de features (finesser) som väljs för en Sprint specificeras i början av denna Sprint. Prioriteringsordningen för varje feature kan förväntas ändras när projektet avancerar. Scrums huvudsakliga betydelse för kravhanteringen är att kravspecifikationer inte är kompletta eller validerade innan projektet startar. Projektägaren och teamet kommer överens om vilka features från produkt-backloggen som ska inkluderas i kommande Sprint, baserat på affärsprioritering och vilka arbetsinsatser som fordras. Användarkraven formuleras av produktägaren i form av användarberättelser (user stories) som innehåller information om “vem, vad och varför” men inte “hur” för kravet. I början av en aktuellt Sprint bryts utvalda features ner till uppgifter i Sprint-backloggen och utvecklas sedan. Att engagera produktägarna, t.ex. genom att presentera funktioner som implementerats i programvaran för dem, hjälper till att tydliggöra kraven både för teamet och för produktägarna själva.
För utbildningsföretag: Ge exempel på användarberättelser och motsvarande produkt och Sprint backlogg. För utbildningsföretag: Förklara också åtminstone två ytterligare agila modeller, inklusive Crystal.
2.1.7
Mognadsmodell (K2)
Mognadsnivåer hjälper till att identifiera och förbättra processmognaden (processbedömning och processförbättring). ISO/IEC 15504 (SPICE – Software Process Improvement and Capability Determination) (K1) ISO/IEC 15504 (SPICE – Software Process Improvement and Capability Determination), är en uppsättning tekniska standarder för programvaruutvecklingsprocessen och tillhörande verksamhetsledningsfunktioner. Ver 1.0 © SQEB – Software Quality Engineering Board
24 (97)
ISO/IEC 15504 kan användas som ett medel för processförbättringar och/eller utvärdering (till exempel en värdering av säljarens processförmåga) SPICE definierar processer indelade fem processkategorier: Customer - supplier Engineering Support Management Organization För var och en av ovanstående, ISO/IEC 15504, definieras en kapabilitetsnivå: 0.
Ofullständig process 1.
Genomförd process 2.
Förvaltad process 3.
Etablerad process 4.
Förutsägbar process 5.
Optimal process Capability Maturity Model Integrated (CMMI) Definierar fem mognadsnivåer för utveckling, av hela systemet: 1.
Begynnande, initial (kaotisk, ad hoc, ensamspelare) – startpunkten för användningen av en ny process. 2.
Hanterad – processen hanteras enligt överenskomna mätetal. 3.
Definierad – processen definieras/bekräftas som en standaraffärsprocess och bryts ned till nivåerna 0, 1 och 2. 4.
Kvantitativt hanterad 5.
Optimerad – processhanteringen inkluderar noga övervägd processoptimering/förbättring.
För utbildningsföretag: Fördjupning av ISO 15504/SPICE och CMMI med en beskrivning av de typiska kraven för Requirements Engineering
Ver 1.0 © SQEB – Software Quality Engineering Board
25 (97)
2.2
Kravhanteringsprocessen (K2) 30 minuter
Termer
Kundorienterad process, perspektiv, kravhantering
2.2.1
Definition av kravhanteringsprocessen (K2)
Kravhantering är en disciplin som omfattar processer vilka behövs för att identifiera, strukturera och hantera krav. Kravhantering består av följande underprocesser: Identifiering av krav Analys av krav Specificering av krav Överenskommelse om krav Kravändringar Validering och kvalitetssäkring
2.2.2
Påverkan på kravhanteringen
Det finns faktorer som kan påverka kravhanteringen negativt: Internt (i programvaruleverantörens organisation): o Bristande kunskap om användarens domän o Ineffektivt sätt att angripa och metodiskt arbeta med kravhantering o Otillräcklig erfarenhet eller skicklighet hos personalen Externt (utanför programvaruleverantörens organisation): o Brist på kommunikation o Oklara och/eller skiftande affärs- eller verksamhetsmål som resulterar i ostabila krav o Avsaknad av kunskap om processen för programvaruutveckling o Inget deltagande från användare och/eller affärsintressenter Det finns olika intressenter med olika syn på kravhanteringsprocessen. Vanligen kan processen betraktas både ur kundens och ur leverantörens (säljarens) synvinkel. Ver 1.0 © SQEB – Software Quality Engineering Board
26 (97)
Exempel: För kunden kan de viktigaste delarna i kravhanteringen vara: användargränssnitt, tillämpningar och tjänster. För leverantören är andra synpunkter att beakta: arkitektur, lastfördelning etc. Metoder i kravhanteringsprocessen som har kunden i fokus: Kundorienterad analys och design Hur man lägger upp prototyparbetet Använda demonstrationer som ett medel att validera systemets tillväxt Ver 1.0 © SQEB – Software Quality Engineering Board
27 (97)
3 Projekt- och riskhantering (K2)
Inlärningsmål för Kravhantering, grundnivå
Målen visar vad du kommer att kunna göra efter att ha fullföljt respektive avsnitt
3.1 Projekthantering (K2)
LO-3.1.1 LO-3.1.2 Förklara varför Kravhantering är viktigt i projekt (K2) Komma ihåg vilka fel som kan uppstå i Kravhantering(K1)
3.2 Riskhantering (K3)
LO-3.2.1 Känna igen risker relaterade till Kravhantering(K1)
60 minuter
Ver 1.0 © SQEB – Software Quality Engineering Board
28 (97)
3.1
Projekthantering (K2) 30 minuter
Termer
Projektstart, avtalsförhandlingar, projektdefinition, projektgenomförande(exekvering)
3.1.1
Nödvändigheten av Kravhantering i projekt (K2)
Några huvudorsaker till att projekt misslyckas hänger samma med krav.
Att försumma kravhanteringen kan resultera i att kraven är oprecisa eller motsägande, eller att de inte uppfyller kriterierna och inte tillgodoser intressenternas behov. Därför är en omsorgsfull och strukturerad kravhantering en nödvändig del av varje projekt. Kravhanteringen bör bidra inom följande områden (K1): Projektstart o Identifiering av kundens behov och förväntningar när det gäller lösning av uppgiften o Etablering av högnivåkrav Avtalsförhandlingar o Utvärdering av kundens krav o Beslut om den inledande omfattningen av projektet och de resurser som behövs o Beslut om utvecklingskostnaderna (implementering av kraven) o Överenskommelse om hur kraven ska prioriteras Projektdefinitioner o Bestämning av roller, uppgifter, aktiviteter och tilläggsprocesser (t.ex. ändringshantering) o Detaljerad verksamhetsdesign av lösningen o Bidrag till den arkitektuella designen o Bidrag till testprocessleveranser Projektgenomförande o Tillhandahållande av en bas för kravutveckling, kravverifiering och validering (testning) o Pådriva granskning av planer och anpassa dem till den aktuella lösningsomfatt ningen, om kraven ändras. Ver 1.0 © SQEB – Software Quality Engineering Board
29 (97)
3.1.2
Vilka fel kan uppstå i kravhanteringen? (K2)
De vanligaste felen är följande: Oklara krav Ändrade krav (om ändringarna är resultatet av oklara projektmål och brist på kunskap om kundens verksamhetsområde; kravändringar uppfattas inte som ett fel i agila och iterativa tillvägagångssätt) Instabil produkt- och designbas för underbeställningar Oklar ansvarsfördelning (på såväl kundens som leverantörens håll) Gap mellan kundens förväntningar och projektets innehåll Otillräckligt kundengagemang Projektdefinition med milstolpar som inte kan uppnås Oprecis kostnadsuppskattning Oprecis (inexakt) uppskattning av hur kravändringar påverkar andra områden inom produktutvecklingen Brist på spårbarhet Ver 1.0 © SQEB – Software Quality Engineering Board
30 (97)
3.2
Riskhantering (K2) 30 minuter
Terms
Failure Mode and Effect Analysis, produktrisk, projektrisk, riskhantering, riskhanteringsplan
3.2.1
Nödvändigheten av riskhantering (K2)
Effektiv riskhantering är en nyckel till att minska projekt- och produktriskerna. Identifiering, rätt analys och planering av adekvata reaktioner på risker minimerar chanserna för att risker ska uppstå och för konsekvenser om en risk skulle inträffa.
3.2.2
Risker (K2)
Risk (K1) En risk definieras som effekten av osäkerhet när det gäller målen och kan vara positiv eller negativ. [ISO 31000]. En annan definition beskriver en risk som chansen att en händelse, slump, hot eller annan situation inträffar som resulterar i oönskade konsekvenser eller ett potentiellt problem. Risknivån bestäms av sannolikheten för en skadlig händelseutveckling och den följd detta får [ISTQB]. Risktyper (K2) Det finns två typer av risk: Projektrisk Produktrisk Projektrisker (K2) Projektrisker är risker som handlar om projektets förmåga att nå sina mål, t.ex: Organisatoriska faktorer: o Skicklighet, utbildning, personalbrist o o o Personalfrågor Policyfrågor som: Problem att få intressenter att kommunicera sina behov och förväntningar Misslyckande med att följa upp den information som kommer fram vid granskning (t.ex. inte förbättra dokumenthanteringen av krav) Felaktig inställning till eller felaktiga förväntningar på kravhanteringen Teknikrelaterade frågor: o Problem med att definiera rätt krav o Till vilken utsträckning kraven inte kan uppfyllas med de begränsningar som finns Ver 1.0 © SQEB – Software Quality Engineering Board
31 (97)
o o Utvecklings- eller testmiljön inte färdig i tid Dålig kvalitet på design, kod, konfigurationsdata, testdata och tester Leverantörsrelaterade frågor: o Misslyckande från en tredje part (t.ex. att komponenterna inte levererats i tid) o Avtalsfrågor Produktrisker(K2) Potentiella felområden (negativa framtida händelser eller osäkerheter) i programvaran eller systemet kallas produktrisker, eftersom de riskerar produktens kvalitet. De omfattar: Ökad risk för att den levererade programvaran inte fungerar (att programvaran eller systemet inte kan utföra sin avsedda uppgift inom givna ramar) Dålig kvalitet på programvarudokumentationen (inkomplett, inkonsekvent, svår att underhålla) Faran att programvara/hårdvara kan orsaka skada för en enskild person eller ett företag Dåliga programvaruegenskaper (t.ex. funktionalitet, pålitlighet, användbarhet eller prestation) Låg dataintegritet och –kvalitet (t.ex. frågor som rör datamigration, dataomvandlings problem, datatransportproblem, brott mot datastandarder) Programvaran utför inte dess avsedda funktioner och tillgodoser inte intressenternas behov Verksamhetsrisker på grund av dålig kvalitet
3.2.3
Riskhantering (K2)
Riskhantering är processen att identifiera, uppskatta och prioritera risker, planera sättet att reagera på risker, och att lösa och övervaka risker. Det gör att man kan identifiera faktorer som kan ha en negativ effekt på genomförandet av ett projekt och ta fram ändamålsenliga åtgärder att handskas med en risk, om den uppstår Olika risker kan komma från olika intressentgrupper, t.ex. kommer utvecklingsteamet att se andra risker än företagsintressenter eller slutanvändare. Riskhantering består av följande åtgärder [ISTQB]: Riskidentifiering Riskanalys Riskminskning Potentiella sätt att hantera risker Tekniker att hantera risker kan delas in i fyra huvudkategorier: Undvika Reducera Dela Bevara Ver 1.0 © SQEB – Software Quality Engineering Board
32 (97)
Plan för riskhantering En plan för riskhantering bör skapas före och efter (regelbundet uppdaterad) framtagandet av projektplanen. Riskhanteringsplanen bör tillhandahålla effektiv säkerhetskontroll för hantering av risker och innehålla en tidsplan för att styra införandet liksom ansvariga personer för dessa. kontroller. Planen för riskhanteringen omfattar: Lista på risker Sannolikhet för att riskerna ska inträffa och/eller prioritet Allvaret i varje risks påverkan (inklusive kostnader om det är aktuellt) Strategier för att minimera varje risk (inklusive de personer/grupper som är ansvariga att agera) Matriser för riskuppskattning
3.2.4
Failure Mode and Effects Analysis (K2)
En vanlig teknik för riskhantering (identifiering, analys och planering av angreppssätt) är Failure Mode and Effects Analysis (FMEA). FMEA möjliggör prioritering av potentiella fel i förhållande till hur allvarliga konsekvenserna blir, hur frekvent de inträffar och hur lätt de kan hittas. FMEA dokumenterar också aktuell kunskap och metoder som rör felrisker för att använda i ett kontinuerligt förbättringsarbete. I de flesta fall används FMEA under designstadiet i projektet och dess huvudsakliga uppgift är att undvika framtida fel. I senare faser kan tekniken användas för processkontroll. FMEA bör inledas i projektets allra tidigaste faser och fortsätta genom hela l livscykeln. Idealet är att FMEA planeras in så snart preliminär information är tillgänglig. Resultatet av en FMEA är åtgärder som hinder eller minskar allvaret i eller sannolikheten för fel. FMEAs implementeringssteg FMEA görs i tre steg: Steg 1: Graden av allvar (identifiering hur allvarligt ett potentiellt fel skulle vara) Steg 2: Frekvens (identifiering av hur ofta ett potentiellt fel kan väntas inträffa) Steg 3: Spårning (identifiering av teknik för felupptäckt) Ver 1.0 © SQEB – Software Quality Engineering Board
33 (97)
4 Ansvar och roller (K2) 50 minuter
Inlärningsmål för Kravhantering, grundnivå
Målen visar vad du kommer att kunna göra efter att ha fullföljt respektive avsnitt.
4.1 Grundläggande roller (K1)
LO-4.1.1 LO-4.1.2 Komma ihåg de grundläggande roller som finns i Kravhantering(K1) Beskriva en intressents uppgift och roll (K2)
4.2 Uppgifter för Kravhantering (Requirements Engineering) (K2)
LO-4.2.1 LO-4.2.2 Beskriva uppgifterna för Kravhantering(K2) Känna till de utmärkande dragen hos en professionell utövare av Kravhantering(K1) Ver 1.0 © SQEB – Software Quality Engineering Board
34 (97)
4.1
Grundläggande roller (K1) 20 minuter
Termer
Klient, kund, entreprenör, intressent
4.1.1
Grundläggande roller(K2)
Roller som påverkar eller påverkas av Kravhantering
Klient (kund) En person, grupp eller organisation som efterfrågar lösningen. Entreprenör (leverantör) En person, grupp eller organisation som tillhandahåller lösningen. Klienter formulerar sina behov och tillhandahåller en första beskrivning av verksamhetsbehov och förväntningar. Vanligen tillhandahålls detta tillsammans med offertförfrågan. Det är leverantörens ansvar att utforska dessa behov och formulera kraven utifrån detta. Entreprenören (leverantören) levererar lösningar baserad på klientens behov.
Roller i kravhanteringen
Kravledare En Requirements Manager, är en person som ansvarar för dokumentation, analys, spårning, prioritering och överenskommelse om krav och som sedan kontrollerar ändringar och kommunicerar med relevanta intressenter. Kravutvecklare En kravutvecklare är en tekniskt orienterad person som huvudsakligen är engagerad i insamling, analys och prioritering av krav.
4.1.2
Intressenter (K2)
Intressenter är en grupp eller enskilda personer som berörs av eller på något sätt kan ha ansvar för slutresultatet av ett åtagande. Projektintressenter är enskilda personer eller organisationer som är aktivt engagerade i projektet eller som har intressen som kan påverkas av att projektet bedrivs och/ eller slutförs. Intressenter kan vara antingen människor, juridiska personer eller teoretiska personer. Det finns ofta motstridiga intressen bland intressenterna. Detta resulterar inte sällan i motstridiga krav. Problemet med motstridiga krav måste hanteras under kravanalysfasen. Det kan finnas manga olika kategorier av intressenter, t.ex.: Kunder Slutanvändare Ver 1.0 © SQEB – Software Quality Engineering Board
35 (97)
Chefer Personer som är engagerade i (arbetar med) organisationsprocesser Ingenjörer ansvariga för systemutveckling och underhåll Kunder i den organisation som ska använda systemet Externa organisationer (regulatorer) Domänexperter Typiska intressenter är: Kund Slutanvändare Projektledare Produktledare Systemanalytiker Verksamhetsanalytiker Företagsrepresentanter Marknadsförings- och försäljningspersonal Programvaruutvecklare Kvalitetssäkringspersonal Tekniska experter (arkitekter, databasingenjörer) Ändringshanterare Projektets kärnteam Ledningsteam Att identifiera alla intressenter är nödvändigt för att kunna ta adekvat hänsyn till allas synpunkter när man planerar lösningen.
For utbildningsföretag: Beskrivning av en typisk intressent (t ex. vd, projektledare, klient)
Ver 1.0 © SQEB – Software Quality Engineering Board
36 (97)
4.2
Uppgifter för Kravhantering (K2) 30 minuter
4.2.1
Uppgifter för Kravhantering (K2)
Huvuduppgifterna för kravhantering är följande: Analysera verksamhetsprocesser inom en organisation Identifiera och analysera krav Strukturera och modellera krav Kvalitetssäkra krav och specifikationer Skapa kravspecifikationer Göra riskanalys (rörande kraven) Hantera kravändringar Nå samförstånd med intressenterna om kraven
4.2.2
Kunskaper hos en professionell utövare av kravhantering (K1)
Vid sidan av teknisk skicklighet ska en professionell utövare av kravhantering ha r följande ”mjuka” färdigheter: Förmågan att jämka Självförtroende Förmåga att övertyga Språkkunskaper Förmåga att kommunicera Precision Analytisk, klar tankeförmåga Förmåga att handla strukturerat Metodisk kompetens Stresstålighet Ver 1.0 © SQEB – Software Quality Engineering Board
37 (97)
5 Identifiering av krav (K2) 150 minuter
Inlärningsmål för Kravhantering, grundnivå
Målen visar vad du kommer att kunna göra efter att ha fullföljt respektive avsnitt.
5.1 Kund (K1)
LO-5.1.1 LO-5.1.2 Komma ihåg innehållet i ett avtal (K1) Identifiera vad som ska beaktas när man utvärderar krav (K2)
5.2 Visioner och mål för projekt (K2)
LO-5.2.1 Förklara egenskaperna hos en typisk projektvision (K2)
5.3 Identifiering av intressenter (K2)
LO-5.3.1 LO-5.3.2 Förklara hur intressenter kan identifieras (K2) Identifiera intressenter för ett specifikt projekt (K3)
5.4 Tekniker för att identifiera krav (K2)
LO-5.4.1 LO-5.4.2 Identifiera målen för kravidentifiering (K2) Använda olika tekniker för kravidentifiering (K3)
5.5 Funktionella och icke-funktionella krav (K2)
LO-5.5.1 LO-5.5.2 Beskriva egenskaperna hos funktionella och icke-funktionella krav (K2) Jämföra skillnaderna mellan funktionella och icke-funktionella krav (K2)
5.6 Kravbeskrivning (K2)
LO-5.6.1 LO-5.6.2 Beskriva innehållet i ett standardkravdokument. (K2) Beskriva vad som är utmärkande för ett bra krav (K2) LO-5.6.3 Konstruera ett krav (K3) Ver 1.0 © SQEB – Software Quality Engineering Board
38 (97)
5.1
Kund (K1) 20 minuter
Termer
Klient, kund, avtal
5.1.1
Kund (K1)
Kund är den organisation eller person som köper programvaran och är en av nyckelintressenterna i projektet. Kundens behov måste tillgodoses. Kunden måste alltid engageras i projektet. Målet är att förstå kunden och utveckla en ömsesidig förståelse för varandra. Entreprenören (säljaren) ska i detta sammanhang alltid kunna se saken ur kundens synvinkel. När man utvärderar kraven för projektplaneringen (vilket är en av frågorna som ska besvaras av projektet) måste man betrakta dem från olika synpunkter eftersom ett specifikt krav kan ha olika prioritet och vara olika viktigt för olika intressenter.
5.1.2
Avtal (K2)
Överenskommelsen (avtalet) ska formaliserat specificera och beskriva vad kunden önskar. Det måste garanteras att kundens intressen kommer i står i centrum (till exempel ska inte säljaren genomdriva den lösning han föredrar utan analysera kundens behov och rekommendera en lösning som tillfredsställer dessa behov på bästa möjliga sätt). Överenskommelsen: Måste överensstämma med de tillgängliga resurserna för att implementera lösningen Baseras på: uppskattningar, deadlines, priser och projektplaner Kravhantering tillhandahåller indata för sådana uppskattningar. Avtalet bör innehålla: En kort beskrivning av den planerade lösningen Listan med prioriterade högnivåkrav Acceptanskriterierna för varje krav Listan på produkter (dokumentation, kod, fungerande programvara) Deadlines för utveckling och leverans av produkten Andra behov och förväntningar, som att en viss teknik föredras, resurskrav etc. Ver 1.0 © SQEB – Software Quality Engineering Board
39 (97)
5.2
Visioner och mål för projekt (K2)
Termer
Mål, vision
5.2.1
Vision (K2)
Att ta fram projektvisioner är det första steget i kravhanteringen. En vision bör: Definiera kunder, marknad och konkurrenter Definiera de mål som ska uppnås Kunna accepteras av alla intressenter Det är avgörande att det finns en tydlig definition av projektvisionerna.
För utbildningsföretag: Presentation av typiska projektvisioner
Viktiga frågor när det gäller projektvisioner (K2): Vad kommer projektet att förändra? Varför är projektet nödvändigt? Vad händer när projektet har avslutats? Vem/vilka kommer att dra nytta av projektet? Vilka kostnader kan vi acceptera? Vilka risker är vi villiga att anta? För varje projekt måste visionen tas fram på nytt.
20 minuter
Ver 1.0 © SQEB – Software Quality Engineering Board
40 (97)
Faktorer som påverkar projektvisionen (K1) Följande faktorer kan påverka visionen: Kunder o Kundens mål o Kundens preferenser Strategi o En organisations strategi o Marknadspositionering o Direktiv som måste följas Konkurrens o Konkurrensdata o Marknadsutveckling Produkter o Innovationsnivå o Målgrupp Teknologi o Nya verktyg o Nya standarder Tillgängliga resurser o Tid, medarbetare, förmåga Ver 1.0 © SQEB – Software Quality Engineering Board
41 (97)
5.3
Identifiering av intressenter(K2) 20 minuter
Termer
Intressent
5.3.1
Identifiering av intressenter (K2)
Alla intressenter på kund- och leverantörssidan måste identifieras. Varje intressant eller varje grupp av intressenter kan bidra med nya krav och påverka designen på den planerade lösningen. Om inte alla intressenter identifieras är risken att något viktigt krav eller begränsning förblir obekant och inte tas i beaktande i designen. Saknade intressenter kan resultera i att komplexa ändringar i programvaran begärs i ett sent stadium av projektet eller efter att systemet levererats för produktion. Några intressenter kan skapa intressegrupper (t.ex. alla företagsintressenter). Intressegrupper bör sammanföras för att deras krav hanteras på så effektivt som möjligt.
5.3.2
Att identifiera och utvärdera intressenter (K2)
Tillvägagångssättet att identifiera och utvärdera intressenter omfattar följande åtgärder: Identifiering av intressenter (analys av verksamhetsprocesser, bestämma ägarna till processer och produkter, analys av organisationsstruktur och marknad) Gruppering av intressenter (om möjligt) Bedömning av samband Identifiering av potentiella motsättningar Analys av motsättningar, källorna till dessa och identifiering av win-win möjligheter Identifiering av hur man kan minimera risker genom att i större utsträckning engagera intressenterna i projektaktiviteterna Identifiering av intressenternas perspektiv
För utbildningsföretag: Förklara identifiering och evaluering av intressenter
Ver 1.0 © SQEB – Software Quality Engineering Board
42 (97)
5.4
Tekniker för kravidentifiering (K2) 40 minuter
Termer
Kundlärande, brainstorming, kundrepresentanter, fältstudier, intervjuer, frågeformulär, återbruk, självregistrering, workshop
5.4.1
Syftet med kravidentifiering (K2)
Huvudskälen för kravidentifikation är följande: Identifiering av alla önskvärda funktioner, egenskaper, begränsningar och förväntningar Orientering av kraven mot projektvisionen Nedbrytning av högnivåkrav och tydlig beskrivning av funktioner och tjänster Uteslutning av funktioner och features som kunden inte vill ha
5.4.2
Tekniker (K1)
De vanligaste teknikerna för kravidentifiering är: Frågeformulär Intervjuer Självregistrering Kundrepresentanter på plats Identifiering grundad på befintliga dokument Återanvändning (återanvändningen av specifikationen från ett visst projekt) Brainstorming Fältstudier Kundlärande Workshops Ver 1.0 © SQEB – Software Quality Engineering Board
43 (97)
5.4.2.1
Frågeformulär
Ett frågeformulär kan bestå av öppna frågor eller flervalsfrågor. En öppen fråga innebär att den svarande själv formulerar sitt svar. När det rör sig om flervalsfrågor ombeds den svarande att välja ett svar utifrån ett antal alternativ. Dessa alternativ bör inte vara utbytbara. Fördelar: Låg kostnad Kan riktas till en större krets Nackdelar: Kan inte användas för att samla in outtalad kunskap Låg svarsfrekvens och inget deltagarengagemang Frågeformulär kan ofta vara styrande vilket hindrar identifieringen av de verkliga användarbehoven
5.4.2.2
Intervju
Intervjun är en konversationsteknik, där den som intervjuar ställer frågor för att skaffa sig information om ett särskilt ämne. Denna teknik är i hög grad interaktiv och gör det möjligt att modifiera ordningen med förberedda frågor beroende på vilka svar man får och själva situationen. Bra intervjuer är svårare att genomföra än man kan tro, på grund av normalt konversationsbeteende (t.ex. att man avslutar meningar åt den man talar med). Detta kan leda till att tolkningar kommer med i underlaget. Intervjuaren bör ställa öppna frågor för att få information och använda flervalsfrågor enbart för att bekräfta ett förhållande (t.ex. redan identifierade krav). Fördelar: Intervjun kan anpassas efter den specifika intervjupersonen Nackdelar: Tidskrävande Otillräcklig återupprepning av resultat (svårigheter att få samma svar när en intervju upprepas)
5.4.2.3
Självregistrering
I denna teknik dokumenterar intressenten (t.ex. en slutanvändare) sina aktiviteter för att slutföra en speciell uppgift. Förutom dokumentation av aktiviteterna ”i befintligt skick” beskriver användaren också ändringar, önskningar och behov. Tekniker associerade med detta tillvägagångssätt är demonstrationer eller dokumentgranskning. Fördelar: Liten tidsåtgång och arbetsinsats för programvaruleverantörens kravhanterare. Ver 1.0 © SQEB – Software Quality Engineering Board
44 (97)
Nackdelar: Tar inte hänsyn till “automatiska” aktiviteter (som utskrifter och mottagande av det utskrivna exemplaret) I hög grad beroende av användarens motivation och erfarenhet.
5.4.2.4
Kundrepresentanter på plats
Det här tillvägagångssättet är en av de effektivaste metoderna för kravidentifiering (och validering) eftersom det gör det möjligt för kundrepresentanten att systematiskt övervaka utvecklingen, bekräfta att designen är korrekt och lämna feedback och tilläggsinformation närhelst detta behövs. Att ha kundrepresentanter på plats är en av huvudreglerna i agila metoder. Fördelar: Snabb feedback Tillhandahåller användarorienterade krav som lätt accepteras Nackdelar: Dyrt för kunden Anpassningskostnader
5.4.2.5
Kravidentifiering baserad på befintliga dokument
Denna teknik kan användas när det redan existerar dokumentation som kan hjälpa till att identifiera kraven inom en organisation. Sådan dokumentation kan vara: Processmodeller- och kartor Processbeskrivningar Organisationsbeskrivningar Produktspecificering (i betydelsen resultatet av en specifik process) Färdiga procedurer (t.ex. arbetsprocedurer) Standarder och instruktioner De identifierade kraven är basen för fortsatt kravanalys och behöver brytas ned och förlängas mot andra relaterade eller länkade krav. Fördelar: Ingen funktion blir förbisedd Nackdelar: Dyrt Kan inte användas när det finns bara grundläggande dokument eller inga dokument alls i organisationen Kan inte användas när dokumentationen inte underhålls på rätt sätt (inte hålls uppdaterad) Ver 1.0 © SQEB – Software Quality Engineering Board
45 (97)
5.4.2.6
Återanvändning (återanvändning av specifikationen från ett visst projekt)
Återanvändning av specifikationen från ett visst projekt kan ske när en organisation redan har fullföljt ett eller flera projekt som liknar det aktuella. Kravspecificering som gjorts för tidigare projekt (ett eller flera) kan användas i ett annat projekt för att förkorta tidsåtgången för kravanalys och dokumentation, och därmed göra att implementeringen kan starta tidigare. I de flesta fal kan bara visa delar av den existerande specifikationen användas i ett nytt projekt. Dokumentationen som återanvänds måste alltid kontrolleras, för att se hur den uppfyller nuvarande behov och krav, och justeras på lämpligt sätt. Fördelar: Kostnadsbesparande Nackdelar: Hög kostnad för det första projektet Att återanvända krav kan innebära att ändringshanteringen blir omfattande och kostnadskrävande om den inte skötts på ett korrekt sätt i tidigare projekt.
5.4.2.7
Brainstorming
Brainstorming är en teknik som ofta används för att få fram krav som hör ihop med mindre kända eller nya områden inom en organisations verksamhet eller en planerad systemfunktionalitet. Den gör det möjligt att samla in många idéer från olika intressenter på kort tid till låg kostnad. Under en brainstormingsession presenterar deltagarna idéer som gäller ett givet problem. Fördelar: Låg kostnad En möjlighet att samla in många värdefulla idéer på kort tid. Nackdelar: Svårt om deltagarna är omotiverade Svårt använda i team som är utspridda på flera håll
5.4.2.8
Fältstudier
En fältstudie gör det möjligt att se användarnas aktiviteter och processer utföras och utifrån detta identifiera systemkrav. Att genomföra observationer på plats innebär att se hur användaren arbetar och dokumentera processen, uppgifterna och resultaten. I vissa fall kompletteras observation med intervjuer med användarna om deras jobb och på vilket sätt de genomför sina uppgifter. Fördelar: Möjlighet att observera användare i arbete och identifiera faktiska krav Nyttigt när intressenterna har svårt att formulera sina behov Nackdelar: Speciella fall) som inträffar mycket sällan kan blir förbisedda Inte användbart i vissa situationer (t.ex. på grund av säkerhetsskäl eller juridiska skäl) Ver 1.0 © SQEB – Software Quality Engineering Board
46 (97)
5.4.2.9
Kundlärande
Syftet med kundlärande är att samla in krav från en kund, särskilt i fall där processer och aktiviteter, som utförs av kundens personal, är svåra att beskriva med andra tekniker som intervjuer, eller där kunden har problem med att formulera sina krav på den planerade programvaran. Kundlärande är en process att genom kunden lära känna dennes jobb. Kunden, som bäst vet hur man utför ett specifikt jobb, lär kravhanteraren – som mästare och lärling. Fördelar: En hjälp av komma över de svårigheter en kunds medarbetare kan ha att tänka abstrakt och uttrycka sina uppgifter i ord Nackdelar: Dyrt och tidskrävande Går inte att använda i farliga miljöer
5.4.2.10
Workshops
Workshop är en typ av möte som fokuserar på ett speciellt ämne (i förväg definierat och delgivet deltagarna) och omfattar vanligen intressenter som representerar olika områden/domäner under en kort, intensiv period. Workshops kan ha varierande mål: Identifiera krav (t.ex. för att bestämma vilken omfattning en lösning ska ha) Hitta gömda krav (t.ex. krav som inte uttryckts direkt eller som intressenterna inte ens haft klart för sig, men som behövs för att täcka delar av deras behov eller högnivåkrav) Utveckla (bryta ned) krav inom ett nyligen identifierat område Prioritera krav Nå konsensus om krav när det är dags för kravöverenskommelse (sign off) Granska resultaten från en specifik process eller aktivitet (t.ex. funktionell kravspecifikation) och lösa de problem som kan ha visat sig Fördelar: Gör det möjligt att snabbt upptäcka och lösa potentiella motsättningar mellan intressenters krav Nackdelar: Svårt om teamen finns på olika håll Tillgänglighet (alla som behövs har kanske inte möjlighet att delta i denna workshop) Engagerar personer med olika utgångspunkter när det gäller ett givet problem Gör det möjligt att bestämma och beskriva krav som har olika infallsvinklar Konsensus kan vara svårt att nå under en workshop och diskussionen kan fastna i (mindre) problem, vilket gör processen utdragen och att deltagarna tappar motivation. Ver 1.0 © SQEB – Software Quality Engineering Board
47 (97)
5.5
Funktionella och icke-funktionella krav (K2) 20 minuter
Termer
Funktionella krav, icke-funktionella krav För att klara examineringen ska eleverna kunna ge exempel på funktionella och icke-funktionella krav och i detalj redogöra för respektive kvalitetsegenskaper.
5.5.1
Funktionella krav (K2)
Funktionella krav specificerar vad systemet gör. De specificerar de funktioner i systemet som slutanvändaren uppfattar dem Funktionella krav beskriver också triggrar i processen (användaragerande, in/ut-data som sätter i gång verksamhetsprocessen). Funktionella krav bör beskrivas med nedanstående kvalitetsegenskaper [ISO/IEC 25000] (K1): Ändamålsenlighet Exakthet Interoperabilitet Funktionalitet Typgodkännande Säkerhet
5.5.2
Icke-funktionella krav (K2)
Icke-funktionella krav specificerar hur systemet fungerar, vad det gör; de beskriver kvalitetsegenskaperna hos hela systemet eller dess specifika komponenter eller funktioner. De begränsar lösningen till exempel genom att kräva särskilda effektivitetsparametrar. Icke-funktionella krav är svåra att beskriva, därför utrycks de ofta vagt eller dokumenteras inte alls. Det gör dem svåra att testa. Icke-funktionella krav ska därför noga uppmärksammas i alla stadier av kravprocessen. På grund av att svårigheten att formulera icke-funktionella krav kan de vara svåra att testa. Icke funktionella krav ska därför formuleras klart och vara mätbara. Icke-funktionella krav är [ISO/IEC 25000] (K1): Tillförlitlighet Användbarhet Effektivitet Underhållbarhet Portabilitet Ver 1.0 © SQEB – Software Quality Engineering Board
48 (97)
Icke-funktionella krav specificerar kriterier som kan användas för att bedöma hur systemet fungerar och påverkar därför i hög grad hur nöjd kunden blir när programvaran används. Funktionella krav ska tillhandahålla funktioner; icke-funktionella krav avgör hur enkelt och effektivt dessa funktioner kan användas. Ver 1.0 © SQEB – Software Quality Engineering Board
49 (97)
5.6
Kravbeskrivning (K2) 30 minuter
5.6.1
Kravbeskrivning (K2)
Krav måste specificeras tydligt och korrekt. De bör vara mätbara för att säkra att de är testbara och att implementeringen kontrolleras på ett korrekt sätt. Det är viktigt att komma ihåg att normalt språkbruk har vissa begränsningar och nackdelar. Det kan resultera i att kravbeskrivningen inte blir klar och entydig. Därför bör lämpliga standarder och mallar användas när det är möjligt. Standarder bidrar till gemensam förståelse och ”best practice” för specifikationen, och mallar begränsar vokabulären som används. Utöver standarder och mallar är ordval ett viktigt verktyg för att underlätta kommunikationen mellan olika intressenter och för att skapa en viss kontroll av vardagsspråkets oklarheter. Beskrivningen av ett krav måste uppfylla olika kriterier (t.ex. klart, korrekt, entydigt, mätbart, utan onödiga ord etc.)
5.6.2
Tillvägagångssätt vid kravkonstruktion (K3)
Konstruktion av ett krav görs i följande steg: 1.
Beslut om den berörda processen 2.
Fokus ligger på funktionalitet In- och utdata beslutas Klassificering av vad systemet ska göra 3.
4.
5.
Identifiering av oberoende systemaktivitet Identifiering av samspelet (interaktionen) med användaren Identifiering av gränssnittskrav Beslut om juridiska åtaganden Klarläggande av juridiska åtaganden genom nyckelord (bör, måste etc.) Förfining av processbeskrivningen Detaljerad beskrivning av mål och integrationspunkter Begränsningar när det gäller logik och tid Etablering av gränsdragningsvillkor Ver 1.0 © SQEB – Software Quality Engineering Board
50 (97)
Exempel: Ett krav som hör ihop med framtagandet av en faktura, där data tas från externa system. Tillvägagångssättet steg för steg 1.
Beslut om processen: En systemprocess för att ta fram en faktura Output – en kravbeskrivning Systemet genererar en faktura 2.
Klassificering av systemets aktivitet Genera en faktura användarens kommando på Efter att systemet användarna lämnat en fakturaförfrågan genererar systemet en faktura som använder data från det externa 3.
4.
5.
Ett gränssnitt sätts med (mot?) ett externt system Beslut om juridiskt åtagande Systemet måste generera en faktura med korrekta data från det externa systemet Förfining av processbeskrivningen Etablering av det externa ekonomiska systemets namn Begränsningar av logik och tid Beslut om tidsbegränsning – maximitid för förloppet 30 sekunder Efter att användarna lämnat en fakturaförfrågan ska systemet generera en faktura som använder data som tas från det externa systemet Efter att användarna lämnat en fakturaförfrågan ska systemet generera en faktura som använder data som tas från SAP Finance System Efter att användarna en fakturaförfrågan ska systemet generera en faktura genom att använda data från SAP Finance System inom 30 sekunder
För utbildningsföretag: Beskrivning av de olika stegen i konstruktionen av ett krav
lämnat Ver 1.0 © SQEB – Software Quality Engineering Board
51 (97)
5.6.3
Kravdokument (K2)
Standardinnehåll i kravdokumentet är [IEEE 830]: Innehållsförteckning 1. Inledning 1.1 Syfte 1.2 Omfattning 1.3 Definitioner och förkortningar 1.4 Referenser 1.5 Översikt 2. Övergripande beskrivning 2.1 Produktperspektiv 2.2 Produktfunktioner 2.3 Användaregenskaper 2.4 Begränsningar 2.5 Antaganden och beroenden 3. Specifika krav 3.1 Externt gränssnitt 3.2 Funktioner 3.3 Prestandakrav 3.4 Logiska databaskrav 3.5 Designbegränsningar 3.5.1 Standarduppfyllelse 3.6 Programvaruattribut 3.6.1 Tillförlitlighet 3.6.2 Tillgänglighet 3.6.3 Säkerhet Bilagor Register (Index) 3.6.4 Underhållbarhet 3.6.5 Portabilitet Ver 1.0 © SQEB – Software Quality Engineering Board
52 (97)
6 Kravspecifikation (K2) 100 minuter
Kunskapsmål för Kravhantering, grundnivån
Målen talar om vad du kommer att kunna göra när du fullföljt respektive avsnitt.
6.1 Specificering (K2)
LO-6.1.1 LO-6.1.2 LO-6.1.3 LO-6.1.4 LO-6.1.5 LO-6.1.6 Beskriva syftet med och innehållet i en kravspecifikation (K2) Beskriva egenskaperna hos (det som utmärker) en kravspecifikation (K2) Beskriva syftet med och innehållet i en lösningsspecifikation (K2) Beskriva egenskaperna hos en lösningsspecifikation (K2) Komma ihåg standarder som är viktiga för kravspecificering och specificering av en lösning. (K1) Förklara vad en användarberättelse är (K2)
6.2 Tillvägagångssätt (K3)
LO-6.2.1 Använda ett typiskt tillvägagångssätt för specificering av krav (K3)
6.3 Formalisering (K2)
LO-6.3.1 LO-6.3.2 Förklara de olika nivåer av formalisering som finns för specificering av krav (K2) Använda en specifik formaliseringsnivå vid ett givet scenario (K3)
6.4 Kvalitet för krav (Kravkvalitet) (K2)
LO-6.4.1 LO-6.4.2 Känna till vilka konsekvenser det blir av felaktigheter i kraven (K1) Beskriva vilka möjligheter som finns för att undvika felaktigheter i kraven (K2) Ver 1.0 © SQEB – Software Quality Engineering Board
53 (97)
6.1
Specificering (K2) 30 minuter
Termer
IEEE 830, Kravspecificering, Lösningsspecificering
6.1.1
Specifikation (K1)
En specifikation är en bestämd uppsättning krav som ska tillgodoses genom ett material, en produkt eller en tjänst. Specifikationen används för att spåra och hantera krav. Här specificeras kraven på ett strukturerat sätt och modelleras vart och ett för sig (kraven modelleras ”oberoende” när högnivåkrav bryts ned till en nivå där varje enskilt krav utgör en ”oberoende” enhet som kan vidareutvecklas och spåras). Specifikationen är en formell överenskommelse om vilka krav som ska implementeras i det planerade programvarusystemet (eller i andra former av lösningar). Termen “specifikation” kan användas i sammanhang som rör krav och lösning.
6.1.2
Kravspecifikationer (K2)
Kravspecificering beskriver problemområdet (det område som är intressant, som t.ex. lösningen på ett affärsproblem, en ny feature etc.) och innehåller åtminstone följande information: Kundens krav Begränsningar Acceptanskriterier Att skapa kundens kravspecifikation bör vara en uppgift för kunden. I vissa fall kan dock leverantören hjälpa till med att ta fram kravspecifikationer. Att skapa andra typer av specifikationer – systemkrav, SW-krav, säkerhetskrav, informations säkerhetskrav, miljökrav, juridiska krav etc. - är uppgifter för andra roller.
6.1.3
Användarberättelser (K2)
Användarberättelser används i agila metoder för programvaruutveckling. Användarberättelser är ett snabbt sätt att hantera kundens/användarens krav. Avsikten med användarberättelsen är att kunna svara snabbare och till lägre kostnad på snabbt växlande verklighetsbaserade krav. Användarberättelser beskriver funktionalitet som kommer att bli värdefull. De är uppbyggda av tre delar: En nedtecknad beskrivning av berättelsen som används för planering och som påminnelse Samtal om berättelsen som hjälper till att bygga upp berättelsens detaljer Tester som förmedlar och dokumenterar detaljer och som används för att bestämma när berättelsen är komplett [Mike Cohn: User Stories applied. 2009] Ver 1.0 © SQEB – Software Quality Engineering Board
54 (97)
6.1.4
Lösningsspecifikationer (K2)
Lösningsspecifikationer kallas också funktionella specifikationer, systemkravspecifikationer eller programvaruspecifikationer och beskriver området för lösningen. En funktionell specifikation är ett dokument som tydligt beskriver de tekniska kraven för en lösning. Funktionell specificering är basen för ytterligare systemutveckling och måste därför tillhandahålla precis information om alla funktionella aspekter som ska implementeras i programvaran. Baserat på detta kan konstruktörer och utvecklare designa den tekniska delen av systemet på ett effektivt sätt. Funktionell specificering ger testarna vägledning när det gäller verifiering av varje enskilt funktionskrav (t.ex. är en specifikation en del av testbasen) Funktionell specificering beskriver inte hur systemfunktionerna kommer att implementeras och vilken teknik som ska användas. Den fokuserar på funktionalitet, eller på samspelet mellan användare och programvara. Syftet med funktionell specificering kan vara: Tillhandahålla en bas för samförstånd kring ramen och funktionaliteten hos den lösning som ska implementeras Säkerställa konsensus i teamet om vad systemet ska uppnå innan man börjar skriva källkod, manualer och förbereda data och testning Ge utvecklingsteamet en detaljerad beskrivning av vilken funktionalitet som behövs i termer av samspel mellan användare och programvara Tillhandahålla en bas för testorakel för testteamet
6.1.5
Viktiga standarder (K1)
Följande standarder kan användas för att skapa specifikationer: IEEE 1362 (System Performance Specifications) IEEE 830 (Software Requirements Specification) IEEE 1233 (System Functional Specifications) Ver 1.0 © SQEB – Software Quality Engineering Board
55 (97)
6.2
Procedur (K3) 30 minuter
6.2.1
Procedur för lösningsspecifikation (K3)
Specificering är en aktivitet som formaliserar resultaten av kravanalysen (K2). Arbetet med identifiering, analys och specificering leder fram till en kravöverenskommelse (jämför med Komma överens om krav (K2)). Kraven ska, när de väl är identifierade, analyserade och modellerade, dokumenteras på ett tydligt, entydigt sätt. Ett tillvägagångssätt (En metod) för lösningsspecificering omfattar följande aktiviteter: 1.
Identifiering av intressenter 2.
Bestämning av vision och mål 3.
Kravbeslut 4.
Strukturerad kravspecifikation 5.
Beskrivning av systemmiljön 6.
Beslut om lösning (bestämning av system och omfattning med relevanta aspekter, vilka ligger utanför men influerar omfattningen, t.ex. gränssnitt i förhållande till externa system) 7.
Kravanalys 8.
Modellering av problemet 9.
Modellering av lösningen Proceduren formaliserar resultaten av kravanalysprocessen. Lösningsmodellen utgör basen för design och implementering. Proceduren involverar en rad intressenter som stöder specifikationsarbetet inom olika områden. Resultatet av proceduren, lösningsspecifikationen, fungerar som utgångspunkt för design av programvara, hårdvara och databas. Det beskriver systemets funktion (funktionella och icke funktionella specifikationer, systemets prestanda och begräsningar när det gäller drift och användargränssnitt.) Ver 1.0 © SQEB – Software Quality Engineering Board
56 (97)
6.3
Formalisering (K2) 20 minuter
Termer
Formell nivå, informell nivå, halvformell nivå
6.3.1
Grader av formalisering (K2)
En kravspecifikation kan skapas i olika grader av formalisering Informell Halvformell Formell
6.3.1.1
Informell nivå
Ett informellt sätt att skriva en specifikation innebär att dokumentet skrivs på vardagsspråk utan några formella notationer. Detta tillvägagångssätt kan användas när läsaren saknar erfarenhet av mer formaliserat och tekniskt fackspråk och skulle ha svårt att förstå innehållet i ett sådant dokument. Den största svagheten med ett sådant tillvägagångssätt är att det inte blir entydigt och kan leda till missförstånd och övertolkning. Dessutom är inte informella specifikationer någon bra bas för implementering och testning, eftersom de inte är tillräckligt tydliga och precisa.
6.3.1.2
Halvformell nivå
Halvformella specifikationer innehåller en del formella notationer och är väl strukturerade. Vanligtvis baseras sådana specifikationer på specifika mallar (ofta hämtade från relevanta standarder). Halvformella specifikationer kan uttrycka kraven i form av modeller och använder ett formaliserat vardagsspråk. Till de vanligaste notationerna som används för halvformell dokumentation hör UML och SysML
6.3.1.3
Formell nivå
Formella specifikationer är en matematisk beskrivning av programvaran som kan användas för att utveckla en implementering. En formell specifikation beskriver vad systemet ska göra, men beskriver vanligtvis inte hur det ska göras. Eftersom det baseras på matematiska formler och är svårare att lära sig används formella specifikationer ganska sällan och kräver matematiskt kunskap. Ver 1.0 © SQEB – Software Quality Engineering Board
57 (97)
6.4
Kravkvalitet (K2) 20 minuter
Termer
Checklista, kvalitetsegenskaper, granskning, validering, verifiering, spårbarhet
6.4.1
Bakgrund
Kravfel som en orsak till höga kostnader (K2) Eftersom kraven är grunden för systemutveckling kommer varje fel eller saknat krav att sprida sig till projektets övriga utvecklingsprocesser. Det är viktigt att observera att fel som beror på krav med låg kvalitet är dyrare att åtgärda längre fram i projektet än andra typer av fel. Dessutom, ju senare fel hittas desto högre är kostnaden för att åtgärda dem. Därför är användningen av verifiering (skapar vi produkten på ett korrekt sätt?) och validering (skapar vi rätt produkt?) av kraven nödvändig. Kraven bör dokumenteras och sedan testas mot kvalitetskriterier (jämför kapitel 1.1 Krav (K2)).
6.4.2
Mått på kvalitetsförbättring och kvalitetssäkring av krav (K2)
Följande verktyg och tekniker kan användas för kvalitetsförbättring och kvalitetssäkring av krav: Standarder och mallar Granskningar och inspektioner Spårbarhet Prototyper Iakttagande av kvalitetskriterier (kvalitetskriterier kan vara: fullständighet, korrekthet, överensstämmelse mellan kravspecifikationen och korrekta standarder) Kravspecifikationens kvalitet kan förbättras genom att följande beståndsdelar tas med: • Beskrivning av syftet med dokumentet, ram, definitioner och ordlista • • • • Beskrivning av målen på olika nivåer (t.ex. har högnivå-kravspecifikationer andra mål än detaljerade funktionsspecifikationer) Bestämning (precisering) av begränsningar för design och implementering Gradera/prioritera kraven Tydligt redovisa vad ett system bör göra snarare än hur det ska göra det • • • Dokumentation av lagstiftning, antaganden, affärsregler och beroenden Undvika tilläggsbeskrivningar till diagram som redan är tydliga och kan stå för sig själva (ersätt svåra, abstrakta texter med diagram om möjligt) Skapa en tydligt specificerad kundkatalog och tillståndsscheman (användarnas rättigheter och förmåner) Ver 1.0 © SQEB – Software Quality Engineering Board
58 (97)
• • Använda en strukturerad presentation Använda enkelt, tydlig, precist och otvetydigt (entydigt) språk. Ver 1.0 © SQEB – Software Quality Engineering Board
59 (97)
7 Kravanalys (K2) 140 minuter
Inlärningsmål för Kravhantering, grundnivån
Målen identifierar vad du ska kunna göra efter att ha fullföljt respektive modul.
7.1 Krav och lösningar (K1)
LO-7.1.1 LO-7.1.2 LO-7.1.3 Komma ihåg målet för kravanalys (K1) Beskriva tillvägagångssättet vid kravanalys (K2) Förklara begreppet strukturella skillnaden mellan krav och lösningar (K2)
7.2 Metoder och tekniker (K2)
LO-7.2.1 LO-7.2.2 Komma ihåg de olika modellerna för kravanalys (K1) Använda olika analysmetoder för specifika modelltyper (K3)
7.3 Objektorienterad analys (K2)
LO-7.3.1 Beskriva vad som kännetecknar UML (K2) LO-7.3.2 Beskriva vad som kännetecknar SysML (K2)
7.4 Kostnadsuppskattning (K2)
LO-7.4.1 LO-7.4.2 Komma ihåg skälen för kostnadsuppskattningar (K1) Känna igen viktiga faktorer för kostnadsuppskattningar (K1)
7.5 Prioritering (K2)
LO-7.5.1 Använda procedurer för att prioritera i ett givet scenario (K3)
7.6 Kravöverenskommelse (K2)
LO-7.6.1 Identifiera vad som ska finnas med när en kravöverenskommelse görs. (K2) Ver 1.0 © SQEB – Software Quality Engineering Board
60 (97)
7.1
Krav och lösningar (K1) 20 minuter
7.1.1
Mål för kravanalysen (K2)
Målet för kravanalys är att skapa en lösning för implementering av kraven. Kravanalysen tar upp de olika intressenterna och eventuella motstridiga krav, analyserar samband och beroenden mellan kraven etc.
7.1.2
Tillvägagångssätt vid kravanalys (K2)
Tillvägagångssättet vid en kravanalys innehåller följande steg: 1.
Behovsanalys 2.
Beskrivning av lösningen 3.
Kostnadsuppskattning och prioritering
7.1.3
Strukturell skillnad mellan krav och lösningar (K2)
Den strukturella skillnaden mellan krav och lösningar är att en lösning är en implementering av ett krav. Kravmodeller kan betraktas som affärs- eller verksamhetsmodeller som presenterar det affärs- eller verksamhetsproblem som ska lösas av lösningsmodellen. En lösningsmodell är mer detaljerad och omfattar tekniska specifikationer för kraven; den är en bas för utveckling och testning. Det finns tre basnivåer för modeller: Kravmodell o Ofta en ickeformell specifikation o Affärsmodellnotationer (BPMN – Business Process Modeling Notation) Lösningsmodell o Funktionell struktur (algoritmer, tillvägagångssätt, arbetsflöden) Konceptuell modell o Tekniska programvaru/hårdvaruspecifikationer Det bör finnas spårbarhet mellan modellerna. Ver 1.0 © SQEB – Software Quality Engineering Board
61 (97)
7.2
Metoder och tekniker (K2) 20 minuter
Terms
Kontextmodell, dataflödesmodell, enhetssambandsmodell, funktionell nedbrytning, konceptuella modeller, kravmodeller, lösningsmodeller, stadieövergångsmodell. l
7.2.1
Modeller och metoder för analys
Olika aspekter på ett system representeras genom olika synpunkter/infallsvinklar Modeller utvecklas genom lämpliga analysmetoder.
Analysmetod
Kontextanalys Arkitektonisk analys Dataflödesanalys Villkorsanalys Beslutsanalys Dataanalys
Analysmodell
Kontextmodell Funktionell nedbrytning Dataflödesmodell Villkorsmodell Beslutstabell Semantisk datamodell Enhetssambandsmodell Datalexikon Ver 1.0 © SQEB – Software Quality Engineering Board
62 (97)
7.2.2
Modelltyper (K2)
Det finns tre bastyper av modeller: Kravmodell o o o o o Beskriver problemområdet Designas i ett tidigt stadium av projektet Används vid kravanalys och kostnadsuppskattning Tillhandahåller en bas för lösningsmodellen Exempel: Affärsanvändarfall, affärsklassmodell, affärsprocessmodell Lösningsmodell o Beskriver lösningens område från olika synpunkter på systemet o Designas samtidigt med kravmodellen o Bestämmer formen för implementation av funktionella och icke-funktionella krav o Tillhandahåller en bas för systemdesignen o Exempel: Användarfallsmodeller, sekvensdiagram, aktivitetsdiagram, tillståndsövergångsdiagram Konceptuell modell o Tekniska specifikationer av programvara/hårdvara (moduler, hårdvaru komponenter, PC-egenskaper)
7.2.3
Olika perspektiv på systemet (K2)
Några vyer som relaterar till systemet är följande: Logisk vy o Funktionella krav Processvy o Kommunikation o Interaktion o Icke-funktionella krav Implementeringsvy o Komponenter (moduler) Installationsvy o Integration o Systemarkitektur Ver 1.0 © SQEB – Software Quality Engineering Board
63 (97)
7.2.4
Olika modeller (K1)
Följande modeller kan användas: Kontextmodell o o Statisk beskrivning av systemet Uttrycker basarkitekturen Funktionell nedbrytning o Statisk beskrivning av systemet o Uttrycker successiv nedbrytning av systemet) Dataflödesmodell o Dynamisk beskrivning av systemet o Grafisk återgivning av dataflödet genom systemet o Tillhandahåller ingen information om tidsaspekter för processerna och om de fungerar i sekvenser eller parallellt Tillståndsövergångsmodell o Dynamisk beskrivning av systemet o Visar hur systemet beter sig vid en serie av händelser, som kan inträffa i ett eller flera möjliga tillstånd Enhetssambandsmodell o Abstrakt och konceptuell återgivning av data o Innehåller byggelement: begrepp, samband och attribut När bör en specifik modell användas? Olika modeller svarar på olika typer av frågor som rör lösningen. Kontextmodellen VAD (visar huvudströmmarna mellan systemet och omvärlden/världen utanför) Funktionell nedbrytning VILKA (vilka funktioner och features finns inom ramen för systemet) Dataflödesmodell VILKA (flöden mellan affärsprocess/funktion/aktiviteter) Enhetssambandsmodell VILKA (vilka samband finns mellan specifika enheter i systemet) Tillståndsövergångsmodell VARFÖR (orsak och verkan) Ver 1.0 © SQEB – Software Quality Engineering Board
64 (97)
7.3
Objektsorienterad analys (K2) 30 minuter
Terms
Aktivitetsdiagram, beteendediagram, klassdiagram, kommunikationsdiagram, komponentdiagram, sammansättnings-/strukturdiagram, driftsättningsdiagramsdiagram, interaktionsöversiktsdiagram, objektdiagram, objektorienterade diagram, paketdiagram, kravdiagram, sekvensdiagram, tillståndsmaskindiagram, strukturella diagram , SysML, timingdiagram, UML, användningsfallsdiagram
7.3.1
UML (K1)
UML, Unified Modeling Language, är en standardiserad modell för analys och design av system. Den innehåller olika diagramtyper för olika sätt att se på systemet (strukturella diagram eller beteendediagram).
7.3.1.1
Beteendediagram (K2)
Beteendediagram visar beteende hos ett system eller en affärs-/verksamhetsprocess. Dessa diagram omfattar följande diagramtyper: Aktivitetsdiagram o Visar hur ett system beter sig, arbetsflödet, och på vilket sätt dessa aktiviteter relaterar till hela systemets arbetsflöde Användningsfallsdiagram o Fångar upp användningsfall och förhållandet mellan aktörer och systemet o Beskriver systemets funktionella krav, på vilket sätt externa aktörer interagerar vid systemgränsen och responsen från systemet. Tillståndsmaskindiagram o Visar hur ett element kan förflytta sig mellan olika tillstånd, klassificerar dess beteende i förhållande till övergångstriggrar och restriktioner Timingdiagram o Definierar olika objekts beteende över tiden o Ger en visuell representation av objekt som byter stadium och interagerar över tid. Sekvensdiagram o En strukturerad bild av beteende som en serie sekventiella steg över tiden o Används för att avbilda arbetsflöden, meddelandeflöden ( kommunikation hur olika element i allmänhet samverkar över tid för att uppnå ett resultat ), och Ver 1.0 Kommunikationsdiagram o Visar interaktion mellan element under löptiden, visualiserar samband mellan olika objekt © SQEB – Software Quality Engineering Board
65 (97)
Interaktionsöversiktsdiagram o Visualiserar samverkan mellan andra interaktionsdiagram för att illustrera ett kontrollflöde som har ett övergripande syfte
7.3.1.2
Strukturella diagram (K2)
Strukturella diagram avbildar de strukturella element som tillsammans utgör ett system eller en funktion. Dessa diagram återspeglar de statiska sambanden i en struktur, t.ex. klassdiagram eller paketdiagram, eller löptidskonstruktioner som objekt- eller sammansättnings- strukturdiagram. Strukturdiagram består av följande diagramtyper: Klassdiagram o Fångar upp den logiska strukturen i systemet, de klasser och objekt som skapar modellen, beskriver vad som finns och vilka attribut och beteenden systemet har Sammansättnings- strukturdiagram. o Återspeglar det interna samarbetet mellan klasser, gränssnitt och komponenter (och deras egenskaper) för att beskriva en funktionalitet Komponentdiagram o Presenterar de delar i en programvara som skapar ett system liksom hur de är organiserade och beroenden dem emellan Driftsättningsdiagram o Beskriver den exekverande arkitekturen i systemet Objektdiagram o Visar objektinstanser hos klasser och deras relation vid en viss tidpunkt Paketdiagram o Visar hur modellelementen organiseras i paket och deras inbördes beroenden.
7.3.2
SysML (K2)
SysML, System Modeling Language, är ett modelleringsspråk för kravhantering. Det är en utvidgning av UML 2.1. SysML erbjuder en del förbättringar jämfört med UML. Dessa förbättringar är följande: Flexiblare och uttrycksfullare semantik o o Reducerar UML's programvarucentrerade begränsningar och lägger till två nya diagramtyper, kravdiagram och parametriska diagram Tillåter modellering av en stor spännvidd av system, omfattande hårdvara, programvara, information, processer, personal och hjälpmedel Lätt att lära och använda o Mindre än UML (utnyttjar inte många av UML's programvarucentrerade konstruktioner) Stödjer modeller och vyer Ver 1.0 © SQEB – Software Quality Engineering Board
66 (97)
o Modeller och vyer är arkitektoniskt i linje med IEEE-Std-1471-2000 Återanvänder sju UML-diagram och tillhandahåller två nya diagram (kravdiagram och parametriska diagram) som ger totalt nio diagramtyper o Kravdiagram för att fånga upp funktionella krav, prestandakrav och gränssnittskrav o Parametriska diagram för att definiera prestanda och kvantitativa begränsningar Ver 1.0 © SQEB – Software Quality Engineering Board
67 (97)
7.4
Kostnadsuppskattningar (K2) 20 minuter
Bakgrund
Kostnadsuppskattningar kopplar ihop kravhantering med projektledningen.
7.4.1
Typer av beräkningar (K2)
Vanligast är att man gör beräkningar för: Kostnader Tidsåtgång Krav Kostnadsuppskattningar är en hjälp att känna igen bli medveten om kostnaderna för utveckling, ändringar etc.
7.4.2
Påverkan på utvecklingskostnaderna (K2)
Projektkostnaden beror på olika faktorer: Projekttyp Processmognad Metoder och verktyg för design och testning Teknologi Den planerade lösningens komplexitet Kvalitetsmål (t.ex. önskad kvalitetsnivå på programvaran) Teamets förutsättningar (hur kvalificerat teamet är) Fördelningen inom teamet Erfarenhet Hur exakt kostnadsberäkningen blir beror på hur projektet framskrider och hur moget det är.
7.4.3
Olika sätt att göra kostnadsuppskattningar
Kostnadsberäkning kan göra genom att använda: Slutledning genom analogi Algoritmiskt tillvägagångssätt Ver 1.0 © SQEB – Software Quality Engineering Board
68 (97)
7.4.3.1
Slutledning genom analogi (K2)
En kostnadsberäkning baserad på jämförelse med kostnaderna för liknande projekt. Den grundas på erfarenhet snarare än matematiska formler. Det är en teknik där det aktuella projektet jämförs med tidigare projekt. Jämförelsen kan innehålla: Antalet krav Omfattningen av lösningen Vilken teknik som används Medarbetarnas egenskaper (skicklighet, erfarenheter) Baserat på resultatet från jämförelsen kan en beräkning göras. Beräkningsarbetet baseras alltid på historiska data och ramvillkor. Delfimetoden Detta är en strukturerad kommunikationsteknik som används för att styra interaktivt prognosarbete. Den involverar en expertpanel. [Linstone75]. Experterna ombeds besvara enkäter i ett antal omgångar. Efter varje omgång görs en anonym sammanfattning av experternas prognoser tillsammans med skälen för dessa ställningstaganden. Experterna reviderar sina tidigare svar när de väger in svaren från andra deltagare i panelen. Antagandet är att spridningen i svar kommer att minska under denna process och gruppen konvergera mot ett “korrekt” svar. Processens stoppas vid ett förbestämt stoppkriterium. Genomsnittspoängen i de sista omgångarna bestämmer slutresultatet. Agil uppskattning I agila projekt, ofta hanterade med Scrum, finns en beräkningsmetod som kallas Planning Game eller Playing Poker. Denna metod används för att uppnå konsensus i teamet. Teamets förmåga mäts sedan genom vad man kallar Burn Down Rate, och förbättras genom återblickande möten som genomförs efter varje Sprint, där planeringssiffror jämförs med de verkliga siffrorna. Detta gör att teamets förmåga att göra beräkningar förbättras.
7.4.3.2
Algoritmiskt tillvägagångssätt (K2)
Här kalkyleras kostnaderna baserat på parametrar. Parametrarna kan beskriva produkten (volym, livslängd), gränssättande förhållanden (effektivitet) etc. Följande metoder kan användas: Putnamformeln (ekvation) Function points Konstruktiv kostnadsmodell (CoCoMo) Ver 1.0 © SQEB – Software Quality Engineering Board
69 (97)
Putnamekvationen [Putnam91] Insats = [Storlek/Produktivitet * Tid 4/3 ] 3 *B Där: Storlek – produktstorleken (uppskattad genom någon av det storleksuppskattningar som används av organisationen). Putnam använder ESLOC (Effective Source Lines of Code) B – en skalningsfaktor, är en funktion av produktstorleken Produktivitet – processproduktiviteten, förmågan hos en viss programvaruorganisation att producera programvara av en given storlek med en viss felfrekvens. Tid – projektets totala tidsplan räknat i år Insats – den totala insatsen i projektet räknat i manår Function Points En funktionspoäng är en mätenhet som uttrycker hur stor affärsfunktionalitet ett informationssystem ger användaren. Kostnaden för en enstaka funktionspoäng beräknas med utgångspunkt från tidigare projekt. Det finns fem ”standardfunktioner” som räknas som funktionspoäng. Datafunktioner: 1.
Interna logiska filer o Tabeller i en relationsdatabas o Kontrollinformation för applikationer 2.
Externa gränssnittsfiler o Tabeller i en relationsdatabas, kontrollinformation för applikationer som inte tillhandahålls i den applikation som övervägs. Transaktionella funktioner: 1.
Extern input o Datainmatning som görs av användarna o Data- eller filmatningar som görs av externa applikationer 2.
Extern output o Rapporter skapade av applikationen inklusive härledda data 3.
Externa förfrågningar o Rapporter skapade av den applikation som avses där rapporten inte omfattar några härledda data Identifierade funktioner viktas I tre komplexitetsnivåer; antalet punkter som tilldelas varje nivå skiljer beroende på typen av funktionspoäng. Ett exempel: Komplexitet Låg Poäng 7 Medel Hög 10 15 Ver 1.0 © SQEB – Software Quality Engineering Board
70 (97)
CoCoMo Konstruktiv kostnadsmodell, CoCoMo, gör det möjligt att databehandla arbetsmängd och kostnad för programvaruutveckling som en funktion av programstorleken. Programvarans storlek uttrycks i EKLOC (estimated thousands of lines of code; beräknat tusental kodsträngar). CoCoMo används i tre typer av programvaruprojekt: Organiska projekt Halvinbäddade projekt Inbäddade projekt Grundläggande CoCoMo-ekvationer: Använd arbetsmängd (E) = a b (KLOC) b b [manmånader] Utvecklingstid (D) = c b (Använd insats) d b [månader] Personalåtgång (P) = Använd arbetsmängd / Utvecklingstid
[antal]
KLOC – Det beräknade antalet levererade kodrader (uttryckt i tusental) i projektet
a b
,
b b
,
c b
and
d b
: Programvaruprojekt
a b b b c b d b
Organiskt Halvinbäddat Inbäddat 2.4 3.0 3.6 1.05 1.12 1.20 2.5 2.5 2.5 0.38 0.35 0.32 Ver 1.0 © SQEB – Software Quality Engineering Board
71 (97)
7.5
Prioritering (K2) 20 minuter
Termer
Skala, trenivåskala
7.5.1
Prioritering (K2)
Prioritering gör det möjligt att fastställa ett kravs relativa betydelse och när det ska implementeras för att kunna färdigställa det mest kritikaska kraven först. Prioritering stödjer inkrementell utveckling eftersom det möjliggör gruppering av krav och att sätta prioriteringar för implementering.
7.5.2
Tillvägagångssätt vid prioritering (K2)
Upprättandet av kravprioriteringar omfattar följande åtgärder: 1.
2.
3.
4.
Kravgruppering Identifiering av krav som påverkar varandra och är beroende av varandra (t.ex. krav som skapar en komplex funktionalitet) Kravanalys En analys som görs av alla involverade intressenter för att enas om hur viktigt kravet är Påverkansanalys som ett medel att stödja kravanalysen Upprättande av kravprioriteringar Skapande av en kravprojektplan Upprättande av en plan där krav med hög prioritet ska utvecklas först Ansvarsfördelning (vem/vilka som ska implementera kraven) Planering av testning av systemtillväxt Design av testfall för att testa varje systemtillväxt (upprättas med kravprioriteringen som bas)
7.5.3
Prioriteringsskala (K2)
Ett vanligt sätt att prioritera är att gruppera kraven i prioritetskategorier. Vanligen används en trenivåskala (exempel: Hög, medium och låg). Eftersom sådana skalor är subjektiva och oprecisa måste alla involverade intressenter vara överens om vad varje nivå de använder står för. Prioritetsdefinitionen bör vara tydligt uttalad och bör vara ett nyckelattribut till vart och ett av kraven. Ver 1.0 © SQEB – Software Quality Engineering Board
72 (97)
Exempel på trenivåskalor: Namn Beskrivning Hög Medium Låg Ett avgörande krav, som krävs för den första programvarureleasen Stödjer nödvändiga systemverksamheter, men kan vänta till senare om det behövs En förbättring, funktionell eller kvalitativ, så kallad “vore trevligt att ha” Namn Nödvändig Villkorad Valfri Beskrivning Produkten godkänns inte om inte dessa krav uppfylls Skulle förbättra produkten, men produkten kan acceptera sutan den Funktioner som kan vara eller inte vara värda besväret Ver 1.0 © SQEB – Software Quality Engineering Board
73 (97)
7.6
Överenskommelse om krav (K2) 20 minuter
Termer
Signoff (överenskommelse)
7.6.1
Överenskommelse (K2)
Att komma överens om kraven, ofta kallat krav-signoff, är en formell överenskommelse om att kravens innehåll och omfattning är exakt och komplett. Den formella överenskommelsen är en bas för projektet. Högnivåkrav (verksamhetskrav) bör man vara överens om innan projektet startar. Detaljerade krav (funktionella och icke-funktionella krav) bör vara överenskomna och ha fått klartecken (signoff) före implementeringsfasen. Att utverka krav-signoff är en typisk avslutande uppgift för kravanalys och – design. Överenskommelsen bör göras av projektets intressenter och omfatta: Projektledare på såväl kundens som leverantörens sida Kundens affärsrepresentant Verksamhets- och systemanalytiker Kravhanterarna Representanterna för kvalitetssäkring liksom testnings- och utvecklingsteam. Kravlistan ska vara bindande från både kundens och leverantörens sida. Ett av syftena med krav-signoff är att säkerställa att kraven är stabila och att varje ändring ska hanteras via en formell ändringsförfrågan. En formell överenskommelse minskar risken för att nya krav tas in under den följande implementeringen. En överenskommelse om kraven anses komplett när berörda projektintressenter har gett klartecken (signoff) för kravdokumentet Slutförandet av en krav-signoff bör delges projektteamet och är vanligen en milstolpe i projektet. Fördelar med kravöverenskommelser (K1) Överenskommelsen säkerställer att rätt produkt utvecklas (arbetet baseras på en överenskommen kravlista och omfattar bara vad som behövs för att nå ökat värde för intressenterna) Risken för missförstånd mellan kund och säljare, när det gäller projektets ram, minimeras Utgör en bas för fortsatt designarbete Ver 1.0 © SQEB – Software Quality Engineering Board
74 (97)
8 Kravspårning (K2)
Inlärningsmål för Kravhantering, grundnivån
Målen identifierar vad du ska kunna göra efter att ha fullföljt respektive modul.
8.1 Spårning inom projektet (K2)
LO-8.1.1 LO-8.1.2 LO-8.1.3 LO-8.1.4 Komma ihåg vad spårbarhet innebär (K1) Komma ihåg typiska skäl för kravändringar (K1) Beskriva syftet med spårbarhet (K2) Känna igen olika typer av spårbarhet (K1)
8.2 Ändringshantering (K2)
LO-8.2.1 LO-8.2.2 Beskriva vad som är kännetecknande för ändringshantering (K2) Komma ihåg ändringshanteringsrådets sammansättning (K1)
60 minuter
Ver 1.0 © SQEB – Software Quality Engineering Board
75 (97)
8.1
Spårning inom projektet (K2) 20 minuter
Termer
Horisontell och vertikal spårning
8.1.1
Kravens utveckling (K1)
Krav är inte stabila utan fortsätter att utvecklas under projektets livscykel. Skäl för fortsatt utveckling och förslag till ändringar kan vara följande: Nya insikter Nya kundbehov (som ett resultat av ny lagstiftning, ändringar I verksamheten, nya produkter etc.) Fortsatt arbete (t.ex. nästa projektfas, förbättring och optimering av redan implementerade features etc.) Nya samband inom projektet (t.ex. integrering med nya system, nya accesskanaler som internet eller mobila kanaler etc.)
8.1.2
Spårbarhet (K2)
Spårbarhet tillhandahåller en lösning för att hantera utvecklingen av krav och andra artefakter som hör ihop med dessa krav. Spårbarhet tillhandahåller en kontroll på att alla viktiga steg i utvecklingsprocessen har genomförts och bör implementeras dubbelriktat för alla artefakter (t.ex. från krav till design av artefakter och från design av artefakter till krav). Spårbarhet är också viktigt när det gäller testning, verifiering och validering. Mål för spårbarhet: Påverkansanalys Täckningsanalys Bevis på genomförd implementering Användning av kraven (kravspårning som ett bevis på att kraven används och hur de används) För att säkerställa god spårbarhet är det viktigt att kraven etiketteras på ett unikt sätt).
8.1.3
Typer av spårbarhet (K2)
Horisontell spårning o Visar bindningar mellan krav på samma nivå (samband mellan olika typer av krav) Vertikal spårning Ver 1.0 © SQEB – Software Quality Engineering Board
76 (97)
o Visar bindningar mellan olika artefakter (krav-, lösnings- och prestanda specfikationer, testfall, kod, moduler, planer etc.) Ver 1.0 © SQEB – Software Quality Engineering Board
77 (97)
8.2
Ändringshantering (K2) 20 minuter
Termer
Ändringar, ändringshanteringsråd, ändringshantering, ändringsbegäran
8.2.1
Kravändringar (K1)
Kravändringar kan efterfrågas när som helst under genomförandet av projektet och efter releasen av den slutliga programvaran till produktionsmiljön. Ändringar kommer alltid att inträffa och det är viktigt att planera ändringarna i termer av process och tid. Orsaken till en ändring kan vara följande: Utökning av den befintliga funktionaliteten Fel som hittats i programvaran/dokumentationen Andra saker som upptäckts t.ex. i samband med testning, som dåliga prestanda etc. Begäran om ny funktionalitet eller en modifiering av befintlig funktionalitet Ändringar som beror på externa faktorer (organisationsförändringar, regeländringar)
8.2.2
Ändringshantering (K2)
Ändringshanteringsprocessen är en process om innebär begäran, beslut om vad som ska uppnås, planering, implementering och utvärdering av ändringar i ett programvarusystem, dokument eller andra produkter i projektet. Syftet med ändringshantering är att tillåta och stödja ändringsprocessen och säkerställa spårbarhet i de ändringar som görs. Ändringshanteringsprocessen omfattar följande aktiviteter: 1.
Identifiering av potentiella ändringar 2.
Förfrågan om ny funktionalitet 3.
Analys av ändringsbegäran 4.
Utvärdering av ändringen 5.
Planering av ändringen 6.
Implementering av ändringen 7.
Granskning och avslut av ändringen 8.
Utrullning av ändringen Beroende på dess komplexitet och inverkan kan en ändring påverka systemet på olika sätt. Små ändringar kan innebära bara mindre modifieringar, medan komplexa ändringar kan radikalt ändra logiken i hela systemet. Varje ändring bör analyseras noggrant för att fastställa relaterade risker och bedöma värdet av modifieringen i förhållande till förutsebara risker. Ver 1.0 © SQEB – Software Quality Engineering Board
78 (97)
8.2.3
Ändringsbegäran (K2)
En ändring bör lämnas som ett formellt dokument med ändringsbegäran (kallas Request For Change (RFC)). Vanligen beskriver sådana dokument skälet för ändringen, prioritet och efterfrågad lösning tillsammans med ytterligare detaljer som: Namnet på personen/avdelningen eller annan enhet som begär ändringen Datum för begäran Planerat datum för implementering av ändringen (om aktuellt) Kostnad för ändringen
8.2.4
Ändringshanteringsråd (K1)
Ändringar kontrolleras och beslutas av ett Change Control Board (CCB), ändringshanteringsråd. Att införa ett sådant råd är ett stöd för att på ett kontrollerat sätt kunna implementera en ändring, eller en föreslagen ändring, i en produkt eller tjänst. Ändringshanteringsrådet kan innehålla följande roller: Projektledning Utvecklingsledning Kravingenjörer Kvalitetssäkring (kvalitetsledning, testledning) Verksamhetsstyrning, om tillämpbart Kund, om tillämpbart Ver 1.0 © SQEB – Software Quality Engineering Board
79 (97)
8.2.5
Kravens livscykel (K2)
Beroende på graden av kravanalys och/eller implementering kommer olika status att tilldelas kraven. Livscykeln för ett krav kan uttryckas med följande exempel på status: Nytt (föreslaget) För granskning Godkänt Motstridigt Implementerat Modifierat Borttaget Testat Utgivet (deployed) Olika tillvägagångssätt och olika organisationer kan komma att använda olika livscykler för krav (och olika status). I många fall är livscykeln för krav, ändringskrav och fel mycket lika och hanteras av samma verktyg.
8.2.6
Skillnaden mellan felhantering och ändringshantering (K2)
Det är viktigt att skilja mellan en ändring och ett fel. Ett fel definieras som en brist i en komponent eller ett system som kan orsaka att komponenten eller systemet inte kan utföra den uppgift som krävs. Det är en avvikelse från den efterfrågade systemstatusen. En ändring är en modifiering av existerande features, krav eller funktioner eller nya sådana.
8.2.7
En ändrings påverkan på projektet (K2)
Kravändringar kan påverka projektet på olika sätt. Vanligast är: Ändring av tidsplan, budget, resurser Arbete som resultat av ändringen (beroende på i vilken fas projektet är): o Uppdatering av analys och design av artefakter (t.ex. specifikationer) o Uppdatering av teknisk dokumentation och användardokumentation o Förändringar i teststrategin och testningen o Uppdatering av testplanen o Uppdatering av utbildningsbehov/plan o Utvidgning/minskning av ramen för programmeringsarbetet o Ändring av omfattningen för testförberedelser och genomförande Ver 1.0 © SQEB – Software Quality Engineering Board
80 (97)
9 Kvalitetssäkring (K2)
Inlärningsmål för Kravhantering, grundnivån
Målen identifierar vad du ska kunna göra efter att ha fullföljt respektive modul.
9.1 Påverkande faktorer (K1)
LO-9.1.1 Komma ihåg vilka faktorer som påverkar kravhantering (K1)
9.3 Kvalitetssäkring genom testbarhet (K2)
LO-9.3.1 LO-9.3.2 LO-9.3.3 Förklara hur kravhanteringsprodukter stöder testning (K2) Beskriva användningen av acceptanskriterier (K2) Beskriva hur Kravhantering kan bidra till testningen (K2)
9.4 Mätetal (K2)
LO-9.4.1 LO-9.4.2 Komma ihåg definitionen på mätetal (K1) Beskriva vilka mätetal som kan användas för kravhantering (K2)
30 minuter
Ver 1.0 © SQEB – Software Quality Engineering Board
81 (97)
9.1
Påverkande faktorer (K1) 10 minuter
9.1.1
Påverkan på Kravhantering (K1)
Kvaliteten på Kravhanteringsprodukterna beror på följande faktorer: Produkten som ska produceras Miljön i vilken produkten produceras Domän (hur komplex verksamhetsdomänen är, graden av innovation, hur ofta det är ändringar i verksamheten etc.) Juridiska, säkerhetsmässiga och miljömässiga faktorer Tids- och kostnadstryck (tids- och kostnadsbegränsningar kan minska förmågan att driva kravhanteringsprocesser) Kulturella faktorer (språk, utbildning etc.) Begränsningar som rör teknik och design Det här är faktorer som måste tas med i beräkningen när man planerar kvalitetssäkringsåtgärder. Ver 1.0 © SQEB – Software Quality Engineering Board
82 (97)
9.2
Verifiering av krav i kravinsamlingsstadiet (K2) 20 minuter
Verifiering måste ske kontinuerligt under utvecklingen av en lösning. För att verifiera krav I insamlingsstadiet kan några av följande tekniker användas: Granskningstekniker Simuleringar Presentationer Demonstrationer Demos Det är viktigt att verifieringen är inplanerad när projektet börjar. Ver 1.0 © SQEB – Software Quality Engineering Board
83 (97)
9.3
Kvalitetssäkring genom testbarhet (K2) 20 minuter
Termer
Acceptanskriterier, testbarhet
9.3.1
Kravhantering och testning (K2)
Kravhantering är nära förbundet med testning. Bra testfall kräver bra krav som kan testas. Att involvera testare för specificeringen är därför mycket viktigt.
9.3.2
Acceptanskriterier (K2)
Enligt Prince2™-nomenklaturen är acceptanskriterier, som också kallas framgångskriterier, de standarder som behövs för att tillfredsställa kundens kvalitetsförväntningar och få kundens acceptans för den slutliga produkten. Med andra ord är de kriterier för en specificerad funktion, komponent, annan del i programvaruprodukten eller andra resultat av projektet som måste uppfyllas för att tillfredsställa kunden och få hans acceptans för produkten. Båda sidorna – leverantör och kund – bör vara överens om acceptanskriterierna innan projektet startar (de bör vara en del av avtalsdokumentet) och kommer att vara basen för projektkvalitetsplanen. Varje högnivåkrav måste ha åtminstone ett acceptanskriterium. Sådana kriterier är grunden för acceptanstestning. Vart och ett av kriterierna måste vara mätbart och sättet att mäta kriterier måste vara realistiskt och överenskommet. Ett exempel på acceptanskriterier är: “Applikationen måste svara inom mindre än en sekund och annars visa ett vänligen vänta meddelande”
9.3.3
Testmetoder (K2)
Kravhanteringsprodukter stödjer testning genom att tillhandahålla så kallad testbas. Krav och deras specifikationer kan utgöra testbas. Kravhanteringsprodukter kan stödja testning genom att: Möjliggöra funktionell täckning (täcker alla funktionella krav genom testfall; testfall skrivs för att täcka alla funktionella krav) Funktionell täckning = ∑ krav testade genom att använda testfall / ∑ krav Tillhandahålla en pålitlig testbas för "black-box", eller “specifikationsbaserade” tester som: o Gränsvärden för indata-kategorier o Applikationstillstånd o Logiska begränsningar och verksamhetsbegränsningar etc. Möjliggöra testtekniker som: ekvivalensuppdelning, gränsvärdesanalys, beslutstabeller, tillståndsövergångar, användningsfall Ver 1.0 © SQEB – Software Quality Engineering Board
84 (97)
Exempel: ekvivalensuppdelning är en testteknik som delar ingångsdata, som används i en speciell programvarumodul, i datadelar varifrån testfall kan inhämtas. Testfallen designas för att täcka varje del åtminstone en gång. Exempel på ekvivalensuppdelning: 1.
Det giltiga intervallet för användarnas ålder är 1 till 99. Det giltiga intervallet kallas en giltig delning. Det finns två ytterligare delar med ogiltigt intervall. Den första ogiltiga delen skulle vara ≤ 0 och den andra ogiltiga delen ≥ 100. 2.
Det giltiga intervallet för svar i ett frågeformulär innehåller bokstäverna A, B, C, D. Den ogiltiga delen innehåller alla andra bokstäver, inklusive specialtecken. Testfall bör ta hänsyn både till giltig delning och ogiltiga delar. Det finns andra testtekniker som också kan användas, t.ex. gränsvärdesanalys, beslutstabellsanalys, stadieövergångstester, användningsfallstester etc. De bör användas efter att en testanalys av kraven gjorts och appliceras utifrån vad kravet innehåller.
9.3.4
Krav och testprocesser (K2)
Krav är den grundläggande input-information i processen att utveckla och testa system. Väldefinierade krav minskar risken för ett misslyckat projekt (eller, ännu värre, en misslyckad produkt) eftersom de möjliggör testning med bra kvalitet. Stabila krav gör det möjligt att klara deadlines för den speciella uppgiften. Det är viktigt att komma ihåg att kraven bör valideras genom statiska tester (vilket kan involvera många testare) och godkännas av testledaren (liksom att det i visa fall kan visa sig att kraven inte är testbara). Testarna hjälper till att förbättra kravkvaliteten genom att peka på svaga punkter och möjliga fel. Testarna bör också delta i kravgranskningen för att säkerställa kravens testbarhet. Ver 1.0 © SQEB – Software Quality Engineering Board
85 (97)
9.4
Mätetal (K2) 20 minuter
Termer
Mätetal
9.4.1
Mätetal (K1)
Mätetal är en mätskala och en metod som används för mätning. [ISO 14598]. Mätetal gör att man kan göra kvantifierade uttalanden om projektets status och kvalitet. Det är viktigt att komma ihåg att mätresultat (siffror insamlade under mätningen) alltid ska jämföras med referensdata (relevanta mätetal).
9.4.2
Mätetal för krav (K1)
Följande mätetal kan användas för krav: Projektkostnader o Antal krav Projektspårning o Antal krav som spårats till andra artefakter Projektstabilitet o Antal ändringsbara krav Processförbättring o Skäl för kravändringar (fel, förbättringar) Specifikationskvalitet o Kravtäckning genom modeller Antal fel o Typ av fel o Antal kravfel inklusive olika typer (logik, hållbarhet, datafel etc.)
9.4.3
Mätning av kravkvalitet (K2)
Vissa frågor möjliggör evaluering av kravkvaliteten: Är kraven korrekta? Är kraven begripliga? Är kraven genomförbara? Är kraven spårbara? Är kraven identifierbara? Ver 1.0 © SQEB – Software Quality Engineering Board
86 (97)
Är kraven testbara? En formel som kan användas för att mäta kravkvalitet: Tydlighet = ∑ Krav utan rapporterade fel och ärenden / ∑ Krav Ändringsfrekvensen kan också vara ett mått på kravkvaliteten (detta gäller inte agila projekt). Ju högre ändringsfrekvens i hela kravuppsättningen (som kan orsakas av insatser för att tydliggöra svårförståeliga krav och/eller ofullständig eller motstridig kravbeskrivning) desto större risk för projektet. Ändringsfrekvensen bör därför mätas så att riskerna inom ett projekt kan hanteras. Ver 1.0 © SQEB – Software Quality Engineering Board
87 (97)
10 Verktyg (K2) 40 minuter
Inlärningsmål för Kravhantering, grundnivån
Målen identifierar vad du ska kunna göra efter att ha fullföljt respektive modul.
10.1 Fördelar med verktyg (K2)
LO-10.1.1 LO-10.1.2 Förklara syftet med verktygsstöd för kravhantering (K2) Beskriva vilka åtgärder som kan stödjas av verktyg inom Kravhantering (K2)
10.2 Verktygskategorier (K2)
LO-10.2.1 LO-10.2.2 Förklara vilka krav det finns på verktyg inom kravhanteringsområdet (K2) Förklara vad som måste övervägas när det gäller kostnader för verktyg (K2) Ver 1.0 © SQEB – Software Quality Engineering Board
88 (97)
10.1
Fördelar med verktyg (K2) 20 minuter
Termer
Kravhanteringsverktyg
10.1.1
Användning av verktyg inom kravhantering (K2)
Verktyg för lagring och administration av krav underlättar kravhanteringen. De kan ta över upprepade mekaniska åtgärder eller säkerställa att man har översikt. Därigenom är det möjligt att hålla svåra dokument konsekventa och up-to-date . Valet av verktyg måste göras innan produkten utvecklas. Annars kan sådant förorsaka påtagliga problem. Verktyg kan stödja följande åtgärder i kravhanteringen: Kravidentifiering och lagring Kravmodellering (inklusive prototyper) Kravdokumentation (skapande av kravspecifikationer) Bestämning och hantering av kravspårbarhet
10.1.2
Fördelarna med att använda verktyg (K2)
Säkerställer att alla krav lagras på ett ställe och är tillgängliga för alla inblandade intressenter Stödjer kravspårbarhet (i testfall etc.) och gör det möjligt att verifiera att man har relevant kravtäckning Gör det möjligt att hantera kravändringar på ett lätt sätt Förbättrar kvaliteten på kravspecifikationer genom att kräva användning av definierade malldokument och modellsystem Sparar tid genom att automatisera visa åtgärder (som att generera kompletta specifikationer via verktyget) Ver 1.0 © SQEB – Software Quality Engineering Board
89 (97)
10.2
Verktygskategorier (K2) 20 minuter
Termer
Verktygskategorier
10.2.1
Verktygskategorier (K2)
Verktyg för kravidentifiering o Mindmapping Modelleringsverktyg o UML-verktyg o SysML-verktyg Prototypverktyg Kravhanteringsverktyg Felhanteringsverktyg Ändringshanteringsverktyg Projektstyrningsverktyg Kostnaden för inköp av verktyg varierar mycket. Kommersiella verktyg kan vara mycket dyra medan open source-verktyg är gratis. Valet av verktyg måste därför göras noggrant. Innan ett verktygs väljs bör det göras en analys. Analysen bör ta följande med i beräkningarna: Vilka modellnotationer används inom organisationen och bör stödjas av verktyget? Planerar organisationen att använda andra modellnotationer i framtiden (i så fall kan det vara förnuftigt att köpa ett verktyg som stödjer den planerade notationen tillsammans med dem som redan används organisationen)? En organisations krav på önskad funktionalitet hos verktyget (vanligen tillhandhåller kommersiella verktyg mer komplexa funktioner än open source-verktyg) Kostnaden för verktyget mot bakgrund av om verktyget bara ska användas för ett specifikt projekt eller i alla/de flesta projekt Kan verktyget integreras med andra nödvändiga verktyg (som felhanteringsverktyg, projektstyrningsverktyg eller annat – beroende på organisationers behov)? Kan verktyget utbyta information med ett verktyg som kundens organisation använder (i visa fall gör kunden en egen kravanalys; produkter från leverantörens detaljerade kravanalys bör i sådana falla migreras till kundens miljö) Hur lätt är verktyget är att använda och lära sig (potentiell kostnad för utbildningar), tillgängligheten för on line-support, manualer, handledning och övrig support? Ett förhastat val kan resultera i höga kostnader (K2): Ver 1.0 © SQEB – Software Quality Engineering Board
90 (97)
Kostnad för att köpa in verktyg som inte svarar mot användarens krav och inte fyller sin uppgift Kostnad för inköp av ett dyrt verktyg som bara används i ett projekt eller inköp av ett dyrt verktyg när det finns open source-verktyg med liknande funktionalitet Kostnad för utbildning om man köper ett verktyg utan tillräckligt supportsystem (gäller särskilt när bara basfunktionalitet krävs av verktyget) Kostnad för att utöka det inköpta verktyget med ytterligare tillbehör, som krävs för att användarens funktioner ska stödjas av verktyget (medan det kan finnas andra verktyg med sådan funktionalitet) Kostnad för att integrera verktyget med andra verktyg i organisationen Ver 1.0 © SQEB – Software Quality Engineering Board
91 (97)
11 Litteratur
Beck, K.:
Extreme Programming
. Munich 2003 Beck, K.:
Extreme Programming Explained: Embrace Change
. Boston 2000 Beck, K.:
Test Driven Development. By Example
. Amsterdam 2002 Beck, K.:
Refactorin
g:
Improving the Design of Existing Code
. Addison-Wesley Longman 1999 Boehm, B.:
Software Engineering Economics
. Englewoods Cliffs, NJ 1981 Bohner, S.A. and R.S. Arnold, Eds.
Software Change Impact Analysis
. Los Alamitos, California, USA, IEEE Computer Society Press 1996. Bundschuh, M.; Fabry, A.:
Aufwandschätzung von IT-Projekten
. Bonn 2004 Cockburn, A.: Agile
Software Development
. Addison Wesley 2002 Cockburn, A.:
Writing Effective Use Cases
. Amsterdam 2000 Cohn M.:
Estimating With Use Case Points
, Fall 2005 issue of Methods & Tools Cotterell, M. and Hughes, B.:
Software Project Management
, International Thomson Publishing 1995 Newman, W.M. and Lamming, M.G.:
Interactive System Design
, Harlow: Addison-Wesley 1995 Davis A. M.:
Operational Prototyping: A new Development Approach
. IEEE Software, September 1992. Page 71 Davis, A. M.: Ju
st Enough Requirements Management. Where Software Development Meets Marketing
, Dorset House, 2005, ISBN 0932633641 DeMarco, T. et al.:
Adrenalin-Junkies und Formular-Zombies – Typisches Verhalten in Projekten
. Munich 2007 DeMarco, T.:
Controlling Software Projects: Management, Measurement and Estimates
. Prentice Hall 1986 DeMarco, Tom:
The Deadline: A Novel About Project Management
. New York 1997 Dorfman, M. S.:
Introduction to Risk Management and Insurance (9 ed
.). Englewood Cliffs, N.J: Prentice Hall 2007. ISBN 0-13-224227-3. Dynamic Systems Development Method Consortium. See: http://na.dsdm.org
Ebert, Ch.:
Systematisches Requirements Management. Anforderungen ermitteln, spezifizieren, analysieren und verfolgen
. Heidelberg 2005 Evans, E. J.:
Domain-Driven Design
:
Tackling Complexity in the Heart of Software
. Amsterdam 2003 Graham, D. et al:
Foundations of Software Testing
. London 2007 Gilb, T.; Graham, D.:
Software Inspection
. Reading, MA 1993 Gilb, T.:
What's Wrong with Requirements Specification.
See: www.gilb.com
Heumann, J.:
The Five Levels
Maturity_TheRationalEdge_Feb2003.pdf
of Requirements Management Maturity,
see: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/feb03/Management Ver 1.0 © SQEB – Software Quality Engineering Board
92 (97)
Linstone H. A., Turoff M.:
The Delphi Method: Techniques and Applications, Reading
, Mass.: Adison-Wesley, ISBN 9780201042948, 1975 Hull, E. et. All:
Requirements Engineering
. Oxford 2005 IEEE Standard 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology IEEE Standard 829-1998 IEEE Standard for Software Test Documentation IEEE Standard 830-1998 IEEE Recommended Practice for Software Requirements Specifications IEEE Standard 1012-2004: IEEE Standard for Software Verification and Validation IEEE Standard 1059-1993: IEEE guide for software verification and validation plans IEEE Standard 1220-1998: IEEE Standard for Application and Management of Systems Engineering Process IEEE Standard 1233-1998 IEEE Guide for Developing System Requirements Specifications IEEE Standard 1362-1998 IEEE Guide for Information Technology-System Definition – Concept of Operations (ConOps) Document ISO 9000 ISO/EIC 25000 ISO 12207 ISO 15288 ISO 15504 ISO 31000: Risk Management - Principles and Guidelines on Implementation IEC 31010: Risk Management - Risk Assessment Techniques ISO/IEC 73: Risk Management – Vocabulary ISTQB: ISTQB Glossary of Testing Terms 2 1 ISTQB: Certified Tester, Foundation Level Syllabus, version 2011 Jacobsen, I. et al.:
The Unified Software Development Process
. Reading 1999 Jacobson, I.et al.:
Object-Oriented Software Engineering. A Use Case Driven Approach
. Addison Wesley 1993 Kilpinen, M.S.:
The Emergence of Change at the Systems Engineering and Software Design Interface: An Investigation of Impact Analysis. PhD Thesis
. University of Cambridge. Cambridge, UK 2008. Lauesen, S.:
Software Requirements: Styles and Techniques
. London 2002 Mangold, P.: IT-
Projektmanagement kompakt
. Munich 2004 McConnell, S.:
Aufwandschätzung für Softwareprojekte
. Unterschleißheim 2006 McConnell, S.:
Rapid Development: Taming Wild Software Schedules (1st ed
.). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5, 1996 Paulk, M., et al:
The Capability Maturity Model: Guidelines for Improving the Software Process
. Reading, MA 1995 Pfleeger, S. L.:
Software Engineering: Theory and Practice, 2nd edition
. Englewood Cliffs, NJ 2001 Ver 1.0 © SQEB – Software Quality Engineering Board
93 (97)
Pfleeger, S.L. and J.M. Atlee:
Software Engineering: Theory and Practice.
Upper Saddle River, New Jersey, USA, Prentice Hall 2006. Pohl, K.:
Requirements Engineering. Grundlagen, Prinzipien, Techniken
. Heidelberg 2007 Project Management Institute:
A Guide to the Project Management Body of Knowledge
(PMBOK ® Guide). PMI 2004 Putnam, L.e H.; Ware M.
Measures for excellence: reliable software On time, within budget
. Yourdon Press. ISBN 0-135676-94-0, 1991 Robertson, S.; Robertson, J.:
Mastering the Requirements Process
, Harlow 1999 Rupp, C.:
Requirements-Engineering und Anforderungsanalyse in der Praxis
. Munich 2007
Management. Professionelle, Iterative
Sharp H., Finkelstein A. and Galal G.:
Stakeholder Identification in the Requirements Engineering Process
, 1999 Sommerville, I.:
Requirements Engineering
. West Sussex 2004 Sommerville, I.:
Software Engineering 8
. Harlow 2007 Sommerville, I.; Sawyer, P.:
Requirements Engineering: A Good Practice Guide
. Chichester 1997 Sommerville, I.; Kotonya, G.: 1998
Requirements Engineering: Processes and Techniques
. Chichester Spillner, A. et all:
Software Testing Foundations
. Santa Barbara, CA 2007 SWEBOK - The Guide to the Software http://www.computer.org/portal/web/swebok/home Engineering Body of Knowledge : Thayer, R. H.; Dorfman, M.:
Software Requirements Engineering, 2nd edition
. Los Alamitos, CA 1997 V-Modell® XT: http://www.vmodellxt.de/ Wiegers, K.E.: 1999
First Things First: Prioritizing Requirements.
Software Development, September Wiegers, K. E.:
Software Requirements
. Redmond 2005 Wiegers, K. E.:
More About Software Requirements: Thorny Issues and Practical Advice
. Redmond, Washington 2006 Young, R. R.:
Effective Requirements Practices
. Addison-Wesley 2001 Ver 1.0 © SQEB – Software Quality Engineering Board
94 (97)
12 Index
acceptanskriterier , 81, 84 affärsprocess , 64 aktivitetsdiagram , 63 ändringsbegäran , 78, 79 ändringshantering , 29, 75, 78, 80 användare , 11, 26, 46, 55 användbarhet , 11, 17, 32 användningsfall , 13, 15, 22, 65, 84 användningsfallsdiagram , 65 åtagande , 13, 35, 51 attribut , 64, 66 behov , 11, 16, 22, 29, 31, 32, 35, 39, 44, 46, 47, 90 beroende , 2, 15, 44, 45, 70, 72, 80, 90 beteendediagram , 65 BPMN , 61 Business Analysis, 2 Change Request, 79 Cost Estimates, 68 Customer, 38, 39 Driftsättningsdiagram , 66 effektivitet , 17, 69 enhet , 54, 79 Failure Mode and Effects Analysis, 33 feature , 24, 54 fel , 14, 28, 30, 33, 58, 80, 85, 86, 87 felhantering , 80 felhanteringsverktyg , 90 felsymptom , 14 FMEA, 33 Formalization, 53, 57 Function point , 69 Function Points, 69 Ver 1.0 © SQEB – Software Quality Engineering Board Functional and Requirements, 48 Non-functional funktion , 45, 56, 64, 66, 70, 71, 84 funktionalitet , 12, 17, 32, 50, 54, 55, 66, 72, 78, 90, 91 granskning , 15, 29, 31, 58, 80 högnivå , 58 Identifying Requirements, 43 IEC 31010, 93 Impact Analysis, 92, 93 insamling , 15, 35 Interaktionsöversiktsdiagram , 66 intervju , 44 intressent , 35, 36 ISO 12207, 93 ISO 15288, 93 ISO 15504, 93 ISO 31000, 31, 93 ISO 9000, 93 ISO/EIC 25000, 93 ISO/IEC 73, 93 klassdiagram , 65, 66 klient , 36 kommunikationsdiagram , 65 komplexitet , 68, 78 komponent , 14, 80, 84 komponentdiagram , 65 kravanalys , 45, 46, 60, 61, 63, 74, 80, 90 kravhantering , 2, 7, 10, 15, 20, 26, 29, 37, 66, 68, 81, 88, 89 kravidentifiering , 38, 43, 45, 90 kravspårbarhet , 89 kravspecifikation , 47, 53, 54, 56, 57 kravutveckling , 15, 16, 23, 29 kritikalitet , 10, 14
95 (97)
kund , 11, 14, 23, 35, 39, 42, 47, 74, 84 kundlärande , 47 kvalitet , 12, 14, 32, 58, 84, 85, 86 kvalitetssäkring , 26, 58, 74 kvalitetsstyrning , 15 leverans , 39 leverantör , 35, 84 Lösning , 11, 13 Lösningsmodell , 61, 63 mål , 8, 10, 12, 31, 38, 40, 41, 47, 50, 56, 58 mätetal , 25, 81, 86 mätning , 86 mått , 87 milstolpe , 74 modell , 22, 61, 63, 64, 65 modul , 22, 60, 75, 81, 88 nytta , 40 Object-oriented Analysis, 60 objektdiagram , 65 omfattning , 47, 56, 74 överenskommelse , 13, 16, 35, 54, 74 överenskommelse om krav , 16, 35, 74 överensstämmelse , 15, 22, 58 paketdiagram , 65, 66 påverkan , 33, 80 portabilitet , 17 prestanda , 11, 56, 67, 77, 78 prioritering , 16, 33, 35, 61, 72 prioritet , 10, 12, 14, 33, 39, 72, 79 Prioritization, 60 process , 14, 16, 25, 26, 45, 47, 69, 78 Process Models, 21 processförbättring , 13, 24 processkrav , 10 processmodell , 22 Ver 1.0 © SQEB – Software Quality Engineering Board produkt , 7, 14, 22, 24, 30, 54, 58, 74, 79, 85 produktkrav , 10, 11, 16 Project Management, 92, 94 Project risk, 31 projekt , 10, 19, 22, 28, 29, 31, 32, 38, 40, 43, 46, 69, 70, 71, 85, 87, 90, 91 projektrisk , 31 Rational Unified Process , 21, 22 RD , 15, 16 RE , 9, 15 requirement, 10 Requirement document, 52 Requirement Manager, 35 Requirements Engineering, 2, 7, 9, 20, 28, 31, 34, 38, 53, 60, 75, 81, 88, 89, 93, 94 revision , 15 risk , 14, 31, 32, 33, 87 Risk, 28, 31, 32, 92, 93 Risk Assessment, 93 Risk Management, 28, 31, 92, 93 riskanalys , 37 riskhantering , 8, 28, 31, 33 RUP , 22 scenario , 53, 60 sekvensdiagram , 63, 65 slutanvändare , 32, 44 Software Requirements Specifications, 93 spårbarhet , 22, 30, 58, 61, 75, 76, 78 Specification, 53, 54 specifikation , 10, 54, 55, 57, 61 standard , 2 Structural Diagram, 65 strukturdiagram , 65, 66 synpunkt , 11 SysML , 57, 60, 65, 66, 90
96 (97)
system , 13, 14, 18, 51, 56, 58, 62, 65, 66, 76, 80, 85 systemanalys , 22 systemanalytiker , 74 testbarhet , 11, 81, 84, 85 Three-Level Scale, 72 tillförlitlighet , 11, 17 tillståndsmaskindiagram , 65 timingdiagram , 65 Tools, 88, 90 UML , 57, 60, 65, 66, 67, 90 underhåll , 16, 36 underhållbarhet , 17 Unified Modeling Language , 65 uppskattning , 30, 69 Use Case Diagram, 65 utvärdering , 14, 25, 78 validering , 10, 15, 29, 45, 58, 76 värde , 74 Verification and Validation, 93 verifiering , 10, 14, 15, 55, 58, 76 version , 93 vision , 21, 40, 56 V-modell , 21, 22 workshop , 43, 47 Ver 1.0 © SQEB – Software Quality Engineering Board
97 (97)