Omfattande och robust kravspecifikationsprocess
Comprehensive & Robust Requirements Specification Process), eller CRRSP (uttalas skarp ), är en metod för att samla in, definiera och validera programvarukrav . CRRSP är inte en steg-för-steg-restriktiv process, utan ett anpassningsbart ramverk, avsett att anpassas av Business Analysis-teamen som väljer de delar av processen som är lämpliga för deras behov.
Historia
CRRSP utvecklades 2008 av en senior affärsanalytiker vid namn Barbara Davis efter år av forskning och förfining genom praktiska erfarenheter som senior affärsanalytiker och affärsanalytiker Center of Excellence Practice Director med organisationer som UST Global och Safeway .
Förhållande till andra metoder
CRRSP:s syn på mjukvarukrav möjliggör applikationer med de flesta typer av projektmetodik och en flexibel och anpassningsbar utgångspunkt där man kan tillämpa metoden. CRRSP skiljer sig från andra metoder som Waterfall , RAD , Agile och RUP eftersom det specifikt är en metod för att definiera och validera kraven inom ramen för den större projektlivscykeln, medan andra är projektmetodik som definierar själva projektets övergripande livscykel. .
En av de primära faktorerna i CRRSP är att det utvecklar krav genom krav på hög, medel och låg nivå via en allt djupare dykning av kravsäkerheten.
Etapper
De viktigaste stegen i CRRSP-kravmetoden är forskning och framkallande, analys, utarbetande och specifikation samt validering. Den kännetecknas av detaljerade valideringssteg, verktyg och tekniker samt unika analysleveranser och spårbarhetsprodukter.
Forskning och framkallande
Målet med forsknings- och framkallningsstadiet är att förstå och undersöka affärsdrivkrafterna, målen och målen, projektartefakter som skapats hittills och skapa arbetsflöden för att hjälpa till att illustrera det nuvarande tillståndet och det önskade framtida tillståndet. Det definierar i slutändan projektets krav på mellannivå.
Analys
Vid analys av kraven på mellannivå använder analytikern gapbedömning, en mer detaljerad form av gapanalys, och orsak och verkan eller beslutstabeller för att skissera scenarier, och vidareutveckla högnivåkraven till krav på medelnivå.
Utarbetning och specifikation
Utarbetning och specifikation är stadiet för att konsekvent dokumentera och skriva kravdokumentet till ett format som i slutändan kommer att skickas vidare till design-, utvecklings- och testteamen som ska användas i skapandet av deras produkter och leveranser. Det genererar förfinade affärsregler, förfinade arbetsflödesscheman och lågnivåkraven.
Namn- och numreringskonvention
CRRSP-metoden dikterar en strikt namn- och numreringskonvention för krav inom ett projekt och produkter i allmänhet. Det följer liknande logik och logik bakom namngivning av orkaner och tornados genom att ett krav tilldelas ett exklusivt nummer som förblir sitt eget även om artikeln skrotas. Detta säkerställer korrekt spårbarhet över flera versioner av dokumentationen och omfattningsändringar.
Numren tilldelas ett slutgiltigt utkast innan de släpps till design-, utvecklings- och testteamen för tvetydighetsgranskningsprocessen. Detta säkerställer att det inte uppstår någon förvirring bland BA-teamet när kraven dokumenteras. Nummer tilldelas endast de höga kraven; delnummer tilldelas mellan- och lågnivåkraven eftersom de är förlängningar av högnivåkraven.
Till exempel, om kraven för en webbshoppingvagn anger att applikationen måste kunna beräkna skatten för onlinekundens specifika stat och/eller provins, skulle kravet skrivas som:
1.1 Kunder måste kunna välja sin delstat OCH/ELLER provins från en väljare.
Kravet omformuleras dock senare för att ange att ansökan måste kunna beräkna skatten för onlinekundens specifika stat och/eller provins, då skulle kravet skrivas om till:
1.1 Krav borttaget. 1.2 Staten eller provinsen från kundens profil kommer att användas för att beräkna skatterna på köpet.
Godkännande
Validering använder en kombination av tvetydighetstekniker härledda från kravbaserad testning och logisk modellering. Dessa tekniker inkluderar en tvetydighetslogg, en tvetydighetsgranskning och tvetydighetsgenomgångar som involverar design-, utvecklings- och testteam för att fastställa klarhet och fullständighet av kraven. Granskningarna och genomgångarna använder en tydlig uppsättning kriterier för granskarna för att säkerställa att informationen är fullständig, konsekvent, korrekt och skriven på ett språk som tydligt anger och definierar den avsedda funktionen hos den nya programvaran.
Benchmarking
Förespråkare av denna metod kan tillämpa en specialiserad formel för att bestämma effektiviteten av kravens aktiviteter genom benchmarking och mätning mot det etablerade riktmärket. Genom att benchmarka kravaktiviteter över ett projekt kan BA-teamet bättre förstå var tid spenderas, hur man kan förbättra och att kunna öka uppgiftens effektivitet och effektivitet som ett sätt att förbättra projektet. Detta har visat sig vara den mest effektiva tekniken för att snabbt anpassa ett flaggningsprojekt på grund av den insikt det ger teamet under processen.
Genom att benchmarka kravaktiviteter generellt över flera projekt kan organisationer få en mer detaljerad bild av kravens aktiviteter och var de kan förbättras. Detta kan indikera möjligheter till utbildning bland affärsanalysteamet, behov av mer resurser eller mer chefsstöd, men kan också indikera om problemet ligger i utvecklings- eller testteamen. Det kan också ge tillräckligt med bevis för att stödja förändringar av de övergripande livscykelprocesserna.
Affärsregler
Affärsregler separeras vanligtvis i ett separat dokument med referenser inom själva kraven. Namn- och numreringskonventionerna är desamma som för kraven men anges som regler med ett 'B' före numret.
Till exempel, om affärsregeln B36 för samma kundvagn anger att skatter ska beräknas på det totala köpbeloppet enligt en skattesats på 12 % i British Columbia, skulle affärsregeln skrivas som:
B36.1 British Columbia skattesats 12 %
Om krav 1.1 hänvisar till denna affärsregel, skulle den skrivas som:
1.1 Kunden måste kunna välja sin delstat OCH/ELLER provins från en väljare. Tillämpliga affärsregler: B36
Användningsfall
Use Cases kan startas när som helst under kravprocessen och poleras när kraven är klara. Deras värde är att lägga till ett lager av validering för kraven för att stödja en granskning för fullständighet. Dessa kan presenteras för användarna i en genomgång för att hjälpa till att validera den steg-för-steg-process genom vilken användaren och systemet kommer att utföra specifika transaktioner. Både litterära (beskrivande) och diagram (som UML , Activity eller Swim Lane ) användningsfall är lämpliga för detta på grund av värdet var och en av dessa kan ge slutanvändarna.
externa länkar
- [4] Tillgång till officiell CRRSP-information (inklusive certifiering och nedladdningar) på Requirements Networking Group
- [5] Bender RBT webbplats