Programvarukravsanalys med exempel
Charles Moore
Till exempel, i samband med bankapplikationer kommer funktionskravet att vara när kunden väljer "Visa saldo" måste de kunna titta på sitt senaste kontosaldo.
Programvarukrav kan också vara ett icke-funktionellt, det kan vara ett prestandakrav. Till exempel är ett icke-funktionellt krav att varje sida i systemet ska vara synlig för användarna inom 5 sekunder.
Så i princip mjukvarukravet är ett
- Funktionell eller
- Icke-funktionell
behöver som måste implementeras i systemet. Programvarukrav uttrycks vanligtvis som ett påstående.
Typer av krav
- Företagskrav: De är krav på hög nivå som är hämtade från affärscase från projekten. Till exempel tillhandahåller ett mobilt banktjänstsystem banktjänster till Sydostasien. Affärskravet som beslutas för Indien är kontosammanfattning och överföring av pengar, medan för Kinas kontosammanfattning och fakturabetalning beslutas som ett affärskrav
| Land | Företag som tillhandahåller bankfunktioner eller tjänster |
|---|---|
| Indien | Kontosammanfattning och överföring av pengar |
| Kina | Kontosammanfattning och Bill Betal-info |
- Architekniska och designkrav: Dessa krav är mer detaljerade än affärskrav. Det bestämmer den övergripande designen som krävs för att implementera affärskravet. För vår utbildningsorganisation skulle arkitektoniska och designmässiga användningsfall vara inloggning, kursdetaljer etc. Kravet skulle vara som visas nedan.
| Användningsfall för banker | Krav |
|---|---|
| Bill Betal-info | Detta användningsfall beskriver hur en kund kan logga in på nätbank och använda Bill Betalningsmöjlighet.
Kunden kommer att kunna se en instrumentpanel med utestående räkningar från registrerade fakturorer. Han kan lägga till, ändra och ta bort en faktureringsdetalj. Kunden kan konfigurera SMS, e-postvarningar för olika faktureringsåtgärder. Han kan se historien om tidigare betalda räkningar. De aktörer som startar detta use case är bankkunder eller supportpersonal. |
- System- och integrationskrav: På den lägsta nivån har vi system- och integrationskrav. Det är en detaljerad beskrivning av varje krav. Det kan vara i form av användarberättelser som verkligen beskriver det dagliga affärsspråket. Kraven finns i rikligt med detaljer så att utvecklare kan börja koda. Här finns ett exempel på Bill Betalningsmodul där krav kommer att nämnas för att lägga till en Biller
| Bill Betal-info | Krav |
|---|---|
| Lägg till BillERS |
|
Ibland för något projekt kanske du inte får några krav eller dokument att arbeta med. Men det finns fortfarande andra källor till krav som du kan överväga för kravet eller informationen, så att du kan basera din programvara eller testdesign på dessa krav. Så de andra källorna för krav du kan lita på är
Andra källor till krav
- Kunskapsöverföring från kollegor eller anställda som redan arbetar med det projektet
- Prata om projekt med affärsanalytiker, produktchef, projektledare och utvecklare
- Analysera tidigare systemversion som redan är implementerad i systemet
- Analysera projektets äldre kravdokument
- Titta på de tidigare felrapporterna, några av felrapporterna omvandlas till förbättringsbegäranden som kan implementeras i nuvarande version
- Titta i installationsguiden om den finns tillgänglig för att se vilken installation som krävs
- Analysera domänen eller branschkunskapen som teamet försöker implementera
Oavsett vilken källa till krav du får, se till att dokumentera dem i någon form, få dem granskade från andra erfarna och kunniga teammedlemmar.
Hur man analyserar krav
Se exempel på ett pedagogiskt programvarusystem där en student kan registrera sig för olika kurser.
Låt oss studera hur man analyserar kraven. Kraven ska hålla en standardkvalitet på sitt krav, olika typer av kravkvalitet inkluderar
- Atomic
- Unikt identifierad
- Komplett
- Konsekvent och entydigt
- spårbar
- Prioriterade
- Testbar
Låt oss förstå detta med ett exempel, det finns tre kolumner i tabellen som visas här,
- Den första kolumnen anger- "kravkvalitet"
- Den andra kolumnen anger- "dåligt krav med något problem"
- Den tredje kolumnen är samma som andra kolumnen men – "omvandlas till ett bra krav".
| Krav Kvalitet | Exempel på dåligt krav | Exempel på bra krav |
|---|---|---|
| Atomic |
|
|
| Unikt identifierad | 1- Studenter kommer att kunna anmäla sig till grundutbildningskurser1- Studenter kommer att kunna anmäla sig till forskarutbildningskurser |
|
| Komplett | En professorsanvändare kommer att logga in i systemet genom att ange sitt användarnamn, lösenord och annan relevant information | En professorsanvändare kommer att logga in i systemet genom att ange sitt användarnamn, lösenord och institutionskod |
| Konsekvent och entydigt | En student kommer att ha antingen grundkurser eller forskarutbildningskurser men inte båda. Vissa kurser kommer att vara öppna för både grund- och forskarutbildning | En student kommer att ha antingen grund- eller efterexamen men inte båda |
| spårbar | Behålla studentinformation mappad till BRD req.ID? | Underhåll studentinformation-Mappad till BRD req ID 4.1 |
| Prioriterade | Registrerad student-Prioritet 1Behåll användarinformation-Prioritet 1Anmäl kurser-Prioritet 1Se rapportkort-Prioritet 1 | Registrera Student-Prioritet 1Upprätthålla användarinformation-Prioritet 2Anmäl kurser-Prioritet 1Se rapportkort-Prioritet3 |
| Testbar | Varje sida i systemet kommer att laddas inom en acceptabel tidsram | Registrera studenter och registrera kurser sidorna i systemet kommer att laddas inom 5 sekunder |
Låt oss nu förstå vart och ett av dessa krav i detaljer från och med Atomic.
Atomic
Så varje krav du har bör vara atomärt, vilket innebär att det ska vara på mycket låg detaljnivå och det ska inte vara möjligt att dela upp i komponenter. Här kommer vi att se de två exemplen på krav, kl Atomic och unikt identifierade kravnivåer.
Så låt oss fortsätta med exempel på systembyggande för utbildningsdomän. Här är det dåliga kravet "Studenter kommer att kunna anmäla sig till grund- och forskarutbildningskurser". Detta är ett dåligt krav eftersom det inte är atomärt eftersom det talar om två olika entiteter grund- och forskarutbildningskurser. Så uppenbarligen är det inte ett bra krav utan dåligt krav, så korrespondens bra krav vore att dela upp det i två krav. Så den ena pratar om inskrivningen till grundkurser medan den andra talar om inskrivningen till forskarutbildningen.
Unikt identifierad
På samma sätt är nästa kravkvalitet att leta efter unikt identifierade, här har vi två separata krav men de har båda samma ID#1. Så, om vi hänvisar vårt krav med hänvisning till ID#, men det är inte klart vilket exakt krav vi hänvisar till dokument eller annan del av systemet eftersom båda har samma ID#1. Så att separera ut med unika id:n, så bra krav kommer att återlämnas som avsnitt 1- kursregistreringar, och det har två krav 1.1 id är anmälan till grundkurser medan 1.2 id är anmälan till forskarutbildningskurser.
Komplett
Dessutom bör varje krav vara komplett. Till exempel, här säger det dåliga kravet att en "professoranvändare kommer att logga in i systemet genom att tillhandahålla sitt användarnamn, lösenord och annan relevant information". Här är den övriga relevanta informationen inte tydlig, så den andra relevanta informationen bör stavas i bra krav för att göra kravet komplett.
Konsekvent och entydig
Därefter bör varje krav vara konsekvent och entydigt, så här har vi till exempel krav "En student kommer att ha antingen grundkurser eller forskarutbildningskurser men inte båda" detta är ett krav, det finns något annat krav som säger "Vissa kurser kommer att vara öppen för både grund- och forskarstuderande”.
Problemet med detta krav är att från det första kravet verkar det som att kurserna är uppdelade i två kategorier under forskarkurser och forskarutbildningar och studenter kan välja endera av två men inte båda. Men när du läser andra krav strider det mot det första kravet och det säger att vissa kurser kommer att öppna för både forskarutbildning och grundutbildning.
Så det är uppenbart att omvandla detta dåliga krav till bra krav som är "En student kommer att ha antingen grundkurser eller forskarutbildningskurser men inte båda". Vilket innebär att varje kurs kommer att markeras antingen som grundkurs eller forskarutbildning
spårbar
Varje krav ska kunna spåras eftersom det redan finns olika nivåer av krav, vi såg redan att på toppen hade vi affärskrav, och sedan har vi krav på arkitektur och design följt av systemintegrationskrav.
När vi nu omvandlar affärskrav till arkitektoniska och designkrav eller vi konverterar arkitektur- och designkrav till systemintegrationskrav måste det finnas spårbarhet. Vilket innebär att vi bör kunna ta varje affärskrav och mappa det till motsvarande ett eller flera programvaruarkitektur och designkrav. Så här är ett exempel på dåliga krav som säger "Underhåll studentinformation - mappad till BRD req ID?" krav-id anges inte här.
Så om man konverterar det till ett bra krav står det samma sak men det mappas med krav-id 4.1. Så kartläggning bör finnas där för varje krav. På samma sätt som vi har mappningskrav på hög och låg nivå, mappningen är också där mellan system- och integrationskrav till koden som implementerar det kravet och det finns också en mappning mellan system- och integrationskravet till testfallet som testar just det kravet .
Så denna spårbarhet är över hela projektet
Prioriterade
| Prioriterade | Registrerad student-Prioritet 1 Behåll användarinformation-prioritet 1 Anmäl kurser-Prioritet 1 Visa rapportkort-prioritet 1 |
Registrera Student-Prioritet 1 Behåll användarinformation-prioritet 2 Anmäl kurser-Prioritet 1 Visa rapportkort-prioritet3 |
Sedan måste varje krav prioriteras, så teamet har riktlinjer så vilka krav som kan implementeras först och vilka som kan göras senare. Här kan du se dålig prioritet har registrerat student, underhålla användarinformation och varje krav har prioriterat-1. Allt kan inte ha samma prioritet, så krav kan prioriteras. Så exemplet på bra krav här är att registrera studenten och anmäla kurser ges högsta prioritet 1, medan underhålla användarinformation kommer under vid prioritet 2 och sedan har vi visa rapportkort vid prioritet-3
Testbar
| Testbar | Varje sida i systemet kommer att laddas inom en acceptabel tidsram | Registrera studenter och registrera kurser sidorna i systemet kommer att laddas inom 5 sekunder |
Varje krav bör vara testbart, här är det dåliga kravet "varje sida i systemet kommer att laddas inom en acceptabel tidsram". Nu finns det två problem med detta krav först är att varje sida innebär att det kan finnas många sidor som kommer att spränga testarbetet. Det andra problemet är att det står att sidan kommer att laddas inom en acceptabel tidsram, vad är nu acceptabel tidsram? Acceptabelt för vem. Så vi måste konvertera det icke-testbara argumentet till ett testbart argument, som specifikt berättar om vilken sida vi talar om "registrera student- och anmäla kurssidor" och den acceptabla tidsramen ges också som är 5 sekunder.
Slutsats
Så det är så vi måste se på varje krav på lämplig nivå. Till exempel om vi ska bygga en mjukvara med avseende på system- och integrationskrav. Vi måste titta i system- och integrationskrav som anges i kravspecifikationerna för programvara eller användarberättelser och tillämpa på varje kravkvalitet. Kontrollera sedan om varje krav är atomärt, unikt identifierat och komplett och så vidare.