Softwarebehovsanalyse med eksempel
Charles Moore
For eksempel vil det funktionelle krav i forbindelse med bankapplikation være, at når kunden vælger "Se saldo", skal de kunne se deres seneste kontosaldo.
Softwarekrav kan også være et ikke-funktionelt, det kan være et præstationskrav. For eksempel er et ikke-funktionelt krav, hvor hver side i systemet skal være synlig for brugerne inden for 5 sekunder.
Så dybest set softwarekravet er en
- Funktionel eller
- Ikke-funktionel
har brug for som skal implementeres i systemet. Softwarekrav udtrykkes normalt som udsagn.
Typer af krav
- Virksomhedskrav: Det er krav på højt niveau, der er taget fra business casen fra projekterne. For eksempel leverer et mobilbankservicesystem banktjenester til Sydøstasien. Forretningskravet, der er besluttet for Indien, er kontooversigt og pengeoverførsel, mens kontooversigt og fakturabetaling for Kina er besluttet som et forretningskrav
| Land | Virksomhed, der leverer bankfunktioner eller -tjenester |
|---|---|
| Indien | Kontooversigt og pengeoverførsel |
| Kina | Kontooversigt og Bill Betaling |
- Architekniske krav og designkrav: Disse krav er mere detaljerede end forretningskrav. Det bestemmer det overordnede design, der kræves for at implementere forretningskravet. For vores uddannelsesorganisation vil de arkitektoniske og designmæssige anvendelsestilfælde være login, kursusdetaljer osv. Kravet vil være som vist nedenfor.
| Bankbrugscase | Krav |
|---|---|
| Bill Betaling | Denne use case beskriver, hvordan en kunde kan logge ind på netbank og bruge Bill Betalingsfacilitet.
Kunden kan se et dashboard over udestående regninger fra registrerede fakturaudstedere. Han kan tilføje, ændre og slette en fakturaudsteder. Kunden kan konfigurere SMS, e-mail-advarsler for forskellige faktureringshandlinger. Han kan se historien om tidligere betalte regninger. Aktørerne, der starter denne use case, er bankkunder eller supportmedarbejdere. |
- System- og integrationskrav: På det laveste niveau har vi system- og integrationskrav. Det er en detaljeret beskrivelse af hvert eneste krav. Det kan være i form af brugerhistorier, som virkelig beskriver hverdagens forretningssprog. Kravene er i rigelige detaljer, så udviklere kan begynde at kode. Her er et eksempel på Bill Betalingsmodul, hvor krav vil blive nævnt for tilføjelse af en Biller
| Bill Betaling | Krav |
|---|---|
| Tilføj BillERS |
|
Nogle gange modtager du måske ikke nogle krav eller dokumenter til at arbejde med. Men der er stadig andre kilder til krav, som du kan overveje til kravet eller informationen, så du kan basere din software eller testdesign på disse krav. Så de andre kilder til krav, du kan stole på, er
Andre kilder til krav
- Videnoverførsel fra kolleger eller medarbejdere, der allerede arbejder på det pågældende projekt
- Tal om projekt med forretningsanalytiker, produktchef, projektleder og udviklere
- Analyser tidligere systemversion, der allerede er implementeret i systemet
- Analyser projektets ældre kravdokument
- Kig ind i de tidligere fejlrapporter, nogle af fejlrapporterne omdannes til forbedringsanmodninger, som kan implementeres i den nuværende version
- Se i installationsvejledningen, hvis den er tilgængelig for at se, hvad der kræves for installation
- Analyser det domæne- eller branchekendskab, som teamet forsøger at implementere
Uanset hvilken kilde til krav du får, skal du sørge for at dokumentere dem i en eller anden form, få dem gennemgået fra andre erfarne og kyndige teammedlemmer.
Hvordan man analyserer krav
Overvej et eksempel på et pædagogisk softwaresystem, hvor en studerende kan tilmelde sig forskellige kurser.
Lad os studere, hvordan man analyserer kravene. Kravene skal opretholde en standardkvalitet af sit krav, forskellige typer kravkvalitet omfatter
- Atomic
- Unikt identificeret
- Komplet
- Konsekvent og utvetydigt
- sporbar
- prioriteret
- Testbar
Lad os forstå dette med et eksempel, der er tre kolonner i tabellen vist her,
- Den første kolonne angiver- "kravkvalitet"
- Den anden kolonne angiver - "dårligt krav med et eller andet problem"
- Den tredje kolonne er den samme som anden kolonne, men - "konverteret til et godt krav".
| Krav Kvalitet | Eksempel på dårligt krav | Eksempel på godt krav |
|---|---|---|
| Atomic |
|
|
| Unikt identificeret | 1- Studerende vil være i stand til at tilmelde sig bachelorkurser1- Studerende vil være i stand til at tilmelde sig postgraduate kurser |
|
| Komplet | En professorbruger vil logge ind i systemet ved at angive sit brugernavn, adgangskode og andre relevante oplysninger | En professorbruger vil logge ind i systemet ved at angive sit brugernavn, password og afdelingskode |
| Konsekvent og utvetydigt | En studerende vil have enten bachelor- eller postgraduate-kurser, men ikke begge dele. Nogle kurser vil være åbne for både bachelor- og postgraduate | En studerende vil have enten bachelor- eller postgraduate, men ikke begge dele |
| sporbar | Vedligeholde elevinformation kortlagt til BRD req.ID? | Vedligeholdelse af elevoplysninger - Kortlagt til BRD krav ID 4.1 |
| prioriteret | Registreret studerende-Prioritet 1Bevar brugeroplysninger-Prioritet 1Tilmeld kurser-Prioritet 1Se rapportkort-Prioritet 1 | Registrer Studenter-Prioritet 1Bevar brugeroplysninger-Prioritet 2Tilmeld kurser-Prioritet 1Se rapportkort-Prioritet3 |
| Testbar | Hver side i systemet indlæses inden for en acceptabel tidsramme | Tilmeld studerende og tilmeld kurser sider i systemet indlæses inden for 5 sekunder |
Lad os nu forstå hvert af disse krav i detaljer begyndende med Atomic.
Atomic
Så hvert eneste krav, du har, skal være atomare, hvilket betyder, at det skal være på et meget lavt niveau af detaljer, og det burde ikke være muligt at adskille dem i komponenter. Her vil vi se de to eksempler på krav, kl Atomic og unikt identificerede kravniveauer.
Så lad os fortsætte med et eksempel på systemopbygning til uddannelsesdomæne. Her er det dårlige krav "Studenter vil være i stand til at tilmelde sig bachelor- og postgraduate-kurser" . Dette er et dårligt krav, fordi det ikke er atomart, fordi det taler om to forskellige entiteter undergraduates og post-graduates kurser. Så det er selvfølgelig ikke et godt krav, men et dårligt krav, så et godt korrespondancekrav ville være at adskille det i to krav. Så den ene taler om optagelsen til bacheloruddannelserne, mens den anden taler om optagelsen til efteruddannelserne.
Unikt identificeret
På samme måde er den næste kravkvalitet at tjekke for unikt identificeret, her har vi to separate krav, men de har begge samme ID#1. Så hvis vi henviser til vores krav med henvisning til ID#, men det er ikke klart, hvilket præcist krav vi henviser til dokument eller anden del af systemet, da begge har samme ID#1. Så udskilles med unikke id'er, så gode krav vil blive returneret som sektion 1- kursustilmeldinger, og det har to krav 1.1 id er tilmelding til bacheloruddannelser, mens 1.2 id er tilmelding til postgraduate kurser.
Komplet
Desuden skal hvert eneste krav være fuldstændigt. For eksempel siger det dårlige krav her, at en "professorbruger vil logge ind i systemet ved at give sit brugernavn, adgangskode og andre relevante oplysninger". Her er de øvrige relevante oplysninger ikke klare, så de øvrige relevante oplysninger bør udformes i god forskrift for at gøre kravet fuldstændigt.
Konsekvent og utvetydigt
Dernæst skal hvert eneste krav være konsekvente og utvetydige, så her har vi for eksempel krav "En studerende vil have enten bachelor- eller postgraduate-kurser, men ikke begge", dette er et krav, der er et andet krav, der siger "Nogle kurser vil være åben for både bachelor- og postgraduate studerende”.
Problemet med dette krav er, at fra det første krav ser det ud til, at kurserne er opdelt i to kategorier under kandidatkurser og postgraduate kurser, og studerende kan vælge en af to, men ikke begge. Men når du læser andre krav, er det i konflikt med det første krav, og det fortæller, at nogle kurser vil åbne for både post-graduate og under-graduate.
Så det er oplagt at konvertere dette dårlige krav til et godt krav, som er "En studerende vil have enten bachelor- eller postgraduate-kurser, men ikke begge dele". Hvilket betyder, at hvert kursus vil blive markeret enten som bachelor- eller postgraduate-kursus
sporbar
Hvert eneste krav skal kunne spores, fordi der allerede er forskellige krav, vi så allerede, at vi i toppen havde forretningskrav, og så har vi arkitektoniske og designkrav efterfulgt af systemintegrationskrav.
Når vi nu konverterer forretningskrav til arkitektoniske og designkrav, eller vi konverterer arkitektoniske og designkrav til systemintegrationskrav, skal der være sporbarhed. Hvilket betyder, at vi bør være i stand til at tage ethvert forretningskrav og kortlægge det til det tilsvarende en eller flere softwarearkitektoniske og designmæssige krav. Så her er et eksempel på et dårligt krav, der siger "Vedligehold elevoplysninger - kortlagt til BRD req ID?" krav-id er ikke angivet her.
Så konverteres det til et godt krav, siger det det samme, men det er kortlagt med krav-id 4.1. Så kortlægning bør være der for hvert eneste krav. På samme måde som vi har krav om kortlægning på højt niveau og lavt niveau, er kortlægningen også der mellem system- og integrationskrav til den kode, der implementerer dette krav, og der er også en mapping mellem system- og integrationskravet til testcasen, som tester det pågældende krav .
Så denne sporbarhed er på tværs af hele projektet
prioriteret
| prioriteret | Registreret studerende - Prioritet 1 Oprethold brugeroplysninger-prioritet 1 Tilmeld dig kurser - Prioritet 1 Se rapportkort-prioritet 1 |
Tilmeld Student-Prioritet 1 Oprethold brugeroplysninger-prioritet 2 Tilmeld dig kurser - Prioritet 1 Se rapportkort-prioritet3 |
Så skal hvert eneste krav prioriteres, så teamet har en retningslinje, så hvilke krav der kan implementeres først, og hvilke der kan gøres senere. Her kan du se den dårlige prioritet har registreret elev, vedligeholde brugeroplysninger og hvert eneste krav har prioriteret-1. Alt kan ikke have samme prioritet, så krav kan prioriteres. Så eksemplet på et godt krav herovre er, at registrere studerende og tilmelde kurser har højeste prioritet 1, mens vedligeholdelse af brugeroplysninger kommer under ved prioritet 2, og så har vi se rapportkort på prioritet-3
Testbar
| Testbar | Hver side i systemet indlæses inden for en acceptabel tidsramme | Tilmeld studerende og tilmeld kurser sider i systemet indlæses inden for 5 sekunder |
Hvert eneste krav bør være testbart, her er det dårlige krav "hver side i systemet vil indlæses inden for en acceptabel tidsramme". Nu er der to problemer med dette krav først er, at hver side betyder, at der kan være mange sider, som kommer til at sprænge testindsatsen. Det andet problem er, at der står, at siden skal indlæses i en acceptabel tidsramme, hvad er nu en acceptabel tidsramme? Acceptabelt for hvem. Så vi skal konvertere det ikke-testbare argument til et testbart argument, som specifikt fortæller om hvilken side vi taler om "registrer studerende og tilmeld kurser sider", og den acceptable tidsramme er også givet, som er 5 sekunder.
Konklusion
Så det er sådan, vi skal se på hvert eneste krav på passende niveau. For eksempel hvis vi skal bygge en software med hensyn til system- og integrationskrav. Vi er nødt til at se på system- og integrationskravene, der er angivet i softwarekravsspecifikationerne eller brugerhistorierne og anvende på hver eneste kravkvalitet. Kontroller derefter, om hvert eneste krav er atomare, unikt identificeret og fuldstændigt og så videre.
