Fråga:

När det gäller krav bör man hela tiden hålla koll på hur de befintliga kraven förändras och ny krav till. Motivera varför ska man göra detta? Det finns även fem steg när ett krav kommer till, vilka är dessa och vad betyder de? Ge exempel på hur man kan göra för att hålla reda på ändringar av olika slag.

Lösningsförslag:

Krav ändras och kommer till under hela processen och inte bara under eliciteringen. Därför behövs något sätt att hålla reda på vilka krav som har kommit till och vilka krav som ändrats. Detta måste även göras för att spårbarheten i kraven och produkten ska fungera. Det är lika bra att redan från början, använda en procedur för ändringar och nya krav. Det borde göras redan under eliciteringen. Även de kraven som inte kommer med i själva kravspecifikationen bör vara med i hanteringen. På så sätt har man även dessa krav dokumenterade och man kan gå tillbaka om det skulle uppkomma problem eller funderingar. Hanteringen av kraven fortsätter även efter det att produkten är levererad. Efter leverans är hanteringen en del av felhantering och buggfix. När en process är framtagen för att hantera hur kraven ska tas om hand gör detta att alla vet hur det ska gå till och det sparas tid, eftersom var och en inte måste hålla reda på nya krav eller ändringar i befintliga. Alla aktörer som berörs av ändringarna i specifikationen måste inte vara med i alla stegen. Detta gör att man endast måste fokusera på rapporteringen under korta stunder.

De fem stegen för att ta reda på om ett krav ska tas med i kravspecifikationen eller inte är:

1. Rapportering: Rapporter om fel och önskade ändringar kommer oftast in efter en leverans eller en prototyp. Personerna som använder systemet rapporterar in vad som inte fungerar som önskat eller vad som är fel.
2. Analys: Rapporterna som kommer in tas om hand och analyseras. Är det ett nytt krav, en ändring till ett redan befintligt eller endast ett missförstånd? Är det något som flera behöver eller är det endast en användare?
3. Beslut: Ska kravet vara med eller inte? Vilken prioritet ska det ha?
4. Svar: Personen som har rapporterat felet och andra personer som berörs av beslutet får ta del av det. Till exempel utvecklare som ska implementera ändringarna.
5. Utför beslutet: Uppdatering av specifikationen, prata med leverantörer och lägg upp planen för att ändringen ska genomföras.

Exempel på hur man kan hålla reda på ändringar i kravhanteringen:

Vilket alternativ som ska användas är beroende på vilken storlek det är på projekten, vem kunden är samt vilken kultur som gäller på företaget.

Skriv alltid ner vad som beslutats. På så sätt finns det dokumenterat ifall det skulle bli problem vid senare tillfälle.

Uppdatera kravspecifikationen och sätt nytt versionsnummer på den. Då finns även de gamla versionerna kvar och man kan gå tillbaka för att se hur ett krav har utvecklats. Problemet är att man måste distribuera ändringarna till många olika personer. Det kan bli svårt att hålla reda på vilka ändringar som gjorts var.

För en lista över ändringarna. Det är lätt att hålla reda på men kraven kommer ur sitt sammanhang vilket kan göra dem svåra att förstå.

Ha kraven i en databas. En databas är lätt att hålla ordning på och alla kan komma åt kraven och dess historia. Problemet med databaser är att man inte kan få en riktig överblick på skärmen.

Bedömningsmall:

En utförlig förklaring till varför man bör ha en process för att ta hand om ger 4p. Stegen för hantering av krav och ändringar med förklaring ger 1p/steg och exempel på hur man kan hålla reda på kraven ger 1p, de är med för att visa olika möjligheter och för att man ska fundera ytterligare ett steg.