Programvarukravsanalys med exempel

Ett programvarukrav är ett funktionellt eller icke-funktionellt behov som måste implementeras i systemet. Funktionellt innebär att tillhandahålla en viss tjänst till användaren.

Till exempel, i samband med en bankapplikation, är det funktionella kravet att när en kund väljer "Visa saldo" ska de kunna se sitt senaste kontosaldo.

Ett programvarukrav kan också vara icke-funktionellt, såsom ett prestandakrav. Till exempel kan ett icke-funktionellt krav ange att varje sida i systemet ska laddas för användare 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 påståenden.

Typer av krav

FöretagskravDessa är övergripande krav hämtade från projektets affärsmodell. Till exempel tillhandahåller ett mobilt banksystem banktjänster till Sydostasien. Affärskravet som beslutats för Indien är kontosammanfattning och överföring av medel, medan det för Kina är kontosammanfattning och fakturabetalning.

Land	Företag som tillhandahåller bankfunktioner eller tjänster
Indien	Kontosammanfattning och överföring av pengar
Kina	Kontosammanfattning och Bill Betalning

Architekniska och designkravDessa krav är mer detaljerade än affärskraven och driver lösningsarkitekturen. De avgör den övergripande designen som krävs för att implementera affärskravet. För en utbildningsorganisation inkluderar typiska arkitektur- och designanvändningsfall inloggning, kursinformation och registrering. Kravet skulle se ut som nedan.

Användningsfall för banker

Krav

Bill Betalning

Detta användningsfall beskriver hur en kund kan logga in på nätbank och använda Bill Betalningsmöjlighet. Kunden kan se en översikt över utestående fakturor för registrerade fakturautställare. Kunden kan lägga till, ändra och ta bort en fakturautställaruppgift. Kunden kan konfigurera SMS- och e-postaviseringar för olika faktureringsåtgärder. Kunden kan se en historik över tidigare betalda räkningar. De aktörer som startar detta användningsfall är bankkunder eller supportpersonal.

System- och integrationskravPå den lägsta nivån har vi system- och integrationskrav. Det ger en detaljerad beskrivning av varje krav. Det kan beskrivas som användarberättelser skrivna i vardagligt affärsspråk. Kraven innehåller rikliga detaljer så att utvecklare kan börja koda. Bill Exempel på betalningsmodul nedan visar kravet för att lägga till en fakturautställare.

Bill Betalning	Krav
Lägg till BillERS	Namn på leverantör av el, kundnummer, automatiska betalningar – Ja/Nej, betala hela Bill – Ja/Nej, Automatisk betalningsgräns – Betala inte om Bill är över angivet belopp

Ibland får man inga krav eller dokument att arbeta med i ett projekt. Även då finns det andra källor till kravinformation som man kan förlita sig på för att basera sin programvara eller testdesign. De andra kravkällorna som man kan förlita sig på listas nedan.

Andra källor till krav

• Kunskapsöverföring från kollegor eller anställda som redan arbetar med det projektet
• Diskutera projektet med affärsanalytikern, produktchefen, projektledaren och utvecklarna
• Analysera den tidigare versionen av systemet som redan implementerats
• Analysera äldre kravdokument från projektet
• Revvisa tidigare felrapporter; vissa felrapporter konverteras till förbättringsförfrågningar som kan implementeras i den aktuella versionen
• Kontrollera installationsguiden, om sådan finns, för att se vilka installationer som krävs
• Analysera den domän- eller branschkunskap som teamet försöker implementera

Oavsett vilken källa du använder för krav, dokumentera dem i ett gemensamt format och låt erfarna teammedlemmar granska dem.

Hur man analyserar krav

Ta exemplet med ett utbildningsprogram där en student kan registrera sig för olika kurser.

Låt oss studera hur man analyserar kraven. Varje krav måste upprätthålla en uppsättning standardkvalitetsattribut, vilka inkluderar följande:

• Atomic
• Unikt identifierad
• Komplett
• Konsekvent och entydigt
• Tractillgänglig
• Prioriterade
• Testbar

Följande tabell illustrerar varje attribut med tre kolumner:

1. Den första kolumnen anger- "kravkvalitet"
2. Den andra kolumnen anger- "dåligt krav med något problem"
3. Den tredje kolumnen visar samma krav ”omvandlat till ett bra krav”.

Krav Kvalitet	Exempel på dåligt krav	Exempel på bra krav
Atomic	Studenter kommer att kunna anmäla sig till grund- och forskarutbildningskurser	Studenter kommer att kunna anmäla sig till kurser på grundnivå. Studenter kommer att kunna anmäla sig till kurser på forskarnivå.
Unikt identifierad	1- Studenter kommer att kunna anmäla sig till kurser på grundnivå. 1- Studenter kommer att kunna anmäla sig till kurser på forskarnivå.	Kursregistrering. Studenter kommer att kunna registrera sig för kurser på grundnivå. Studenter kommer att kunna registrera sig för kurser på forskarnivå.
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
Tractillgänglig	Behålla studentinformation mappad till BRD req.ID?	Underhåll studentinformation-Mappad till BRD req ID 4.1
Prioriterade	Registrerad student - Prioritet 1. Underhåll användarinformation - Prioritet 1. Registrera kurser - Prioritet 1. Visa rapportkort - Prioritet 1	Registrera student - Prioritet 1. Underhåll användarinformation - Prioritet 2. Registrera kurser - Prioritet 1. Visa rapportkort - Prioritet 3
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 förstå vart och ett av dessa attribut mer i detalj, med början med Atomic.

Atomic

Varje krav ska vara atomärt, vilket innebär att det måste vara på lägsta detaljnivå och inte kan delas upp ytterligare i komponenter. Följande exempel jämför atomära och icke-atomära krav.

För att fortsätta med exemplet med utbildningssystemet: Här är det dåliga kravet "Studenter kommer att kunna anmäla sig till grundutbildning och forskarutbildning". Detta är ett dåligt krav eftersom det inte är atomärt – det blandar två olika enheter, grundutbildning och forskarutbildning. Motsvarande bra krav delar upp det i två krav. Det ena kravet täcker anmälan till grundutbildning och det andra täcker anmälan till forskarutbildning.

Unikt identifierad

Nästa kvalitetsattribut är unik identifiering. I det dåliga exemplet delar två separata krav samma ID#1. Om ett team refererar till ett krav med sitt ID blir det oklart vilket av de två som avses. Det goda kravet grupperar om dem under Avsnitt 1 — Kursregistrering, med delkrav 1.1 (registrering till grundutbildningskurser) och 1.2 (registrering till forskarutbildningskurser).

Komplett

Varje krav ska vara komplett. Till exempel, här säger det felaktiga kravet att en "professoranvändare loggar in i systemet genom att ange sitt användarnamn, lösenord och annan relevant information". "Övrig relevant information" är vagt. Ett komplett krav listar de exakta fälten, såsom institutionskod, som professorn måste ange.

Konsekvent och entydig

Varje krav bör vara konsekvent och otvetydigt. I det dåliga exemplet anger ett krav "En student ska ha antingen grundutbildningskurser eller forskarutbildningskurser men inte båda", medan ett annat anger "Vissa kurser kommer att vara öppna för både grundutbildnings- och forskarutbildningsstudenter".

Det första kravet innebär att kurser är uppdelade i två exklusiva kategorier, men det andra kravet motsäger det genom att öppna vissa kurser för båda grupperna.

Kravet om att vara bra löser konflikten genom att tydligt ange att varje kurs är markerad antingen som grundutbildning eller forskarutbildning, och en student kan bara registrera sig i kurser i en kategori.

Tractillgänglig

Varje krav måste vara tracmöjlig eftersom krav finns på flera nivåer: affärs-, arkitektur- och designnivåer, samt system- och integrationsnivåer.

När du omvandlar ett affärskrav till arkitektur- och designkrav, eller arkitektur- och designkrav till system- och integrationskrav, tracFunktionaliteten måste bevaras. Varje affärskrav bör mappas till ett eller flera arkitektur- och designkrav. I det dåliga exemplet "Underhåll studentinformation – mappad till BRD-krav-ID?" saknas krav-ID:t.

Det godkända kravet registrerar samma påstående men mappas explicit till BRD-krav-ID 4.1. Varje krav måste ha en tracförmåga kartapingSystem- och integrationskrav bör också mappas till koden som implementerar dem och till de testfall som verifierar dem.

Traceffektiviteten löper därför från början till slut genom hela projektet.

Prioriterade

Varje krav måste prioriteras så att teamet vet vad som ska implementeras först och vad som kan vänta. I det dåliga exemplet är Registrera student, Underhåll användarinformation, Registrera kurser och Visa rapportkort alla inställda på prioritet 1. Allt kan inte ha prioritet 1, så kraven måste rangordnas realistiskt. Det goda exemplet ger Registrera student och Registrera kurser högsta prioritet 1, Underhåll användarinformation prioritet 2 och Visa rapportkort prioritet 3.

Testbar

Varje krav bör vara testbart. Det dåliga exemplet, ”varje sida i systemet laddas inom en acceptabel tidsram”, är inte testbart av två skäl. För det första kan ”varje sida” betyda dussintals sidor, vilket tar bort testarbetet. För det andra är ”acceptabel tidsram” odefinierad – acceptabel för vem, och mot vilket riktmärke? Det bra kravet åtgärdar båda problemen genom att namnge de specifika sidorna (”registrera student och anmäla kurser”) och sätta ett mätbart mål på 5 sekunder.

Vanliga frågor