Softwarebehovsanalyse med eksempel
Charles Moore
⚡ Smart opsummering
Analyse af softwarekrav opdeler interessenternes behov i funktionelle og ikke-funktionelle udsagn, rangerer dem på forretnings-, arkitektur- og systemniveau og kontrollerer derefter hver enkelt mod kvalitetsegenskaber for at garantere en testbar, tracmulig, prioriteret specifikation.
Et softwarekrav er et funktionelt eller ikke-funktionelt behov, der skal implementeres i systemet. Funktionelt betyder at levere en bestemt service til brugeren.
For eksempel, i forbindelse med en bankapplikation, er det funktionelle krav, at når en kunde vælger "Vis saldo", skal de kunne se deres seneste kontosaldo.
Et softwarekrav kan også være ikke-funktionelt, såsom et ydelseskrav. For eksempel kan et ikke-funktionelt krav angive, at hver side i systemet skal indlæses 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
VirksomhedskravDette er overordnede krav taget fra projektets business case. For eksempel leverer et mobilbanksystem banktjenester til Sydøstasien. Forretningskravet for Indien er kontooversigt og pengeoverførsel, mens det for Kina er kontooversigt og betaling af regninger.
| Land | Virksomhed, der leverer bankfunktioner eller -tjenester |
|---|---|
| Indien | Kontooversigt og pengeoverførsel |
| Kina | Kontooversigt og Bill Betaling |
Architekniske krav og designkravDisse krav er mere detaljerede end forretningskrav og driver løsningsarkitekturen. De bestemmer det overordnede design, der kræves for at implementere forretningskravet. For en uddannelsesorganisation omfatter typiske arkitektur- og designmæssige anvendelsesscenarier login, kursusdetaljer og tilmelding. Kravet ville 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 for registrerede fakturaudstedere. Kunden kan tilføje, ændre og slette en fakturaudstederoplysning. Kunden kan konfigurere SMS- og e-mail-advarsler for forskellige faktureringshandlinger. Kunden kan se en historik over tidligere betalte regninger. Aktørerne, der starter denne use case, er bankkunder eller supportpersonale. |
System- og integrationskravPå det laveste niveau har vi system- og integrationskrav. Det giver en detaljeret beskrivelse af hvert krav. Det kan opfattes som brugerhistorier skrevet i almindeligt forretningssprog. Kravene indeholder rigelige detaljer, så udviklere kan begynde at kode. Bill Eksempel på betalingsmodul nedenfor viser kravet om at tilføje en fakturaudsteder.
| Bill Betaling | Krav |
|---|---|
| Tilføj BillERS | Navn på forsyningsudbyder, kundenummer, automatiske betalinger – Ja/Nej, betal hele beløbet Bill – Ja/Nej, Automatisk Betalingsgrænse – Betal ikke hvis Bill er over det angivne beløb |
Nogle gange modtager du muligvis ikke nogen krav eller dokumenter til et projekt at arbejde med. Selv da er der andre kilder til kravinformation, som du kan stole på som base for din software eller dit testdesign. De andre kilder til krav, du kan stole på, er anført nedenfor.
Andre kilder til krav
- Videnoverførsel fra kolleger eller medarbejdere, der allerede arbejder på det pågældende projekt
- Diskuter projektet med forretningsanalytikeren, produktchefen, projektlederen og udviklerne
- Analyser den tidligere version af systemet, der allerede er implementeret
- Analyser ældre kravdokumenter fra projektet
- Revse tidligere fejlrapporter; nogle fejlrapporter konverteres til forbedringsanmodninger, der kan implementeres i den nuværende version
- Tjek installationsvejledningen, hvis tilgængelig, for at se, hvilke installationer der kræves
- Analyser den domæne- eller brancheviden, som teamet forsøger at implementere
Uanset hvilken kilde til krav du bruger, skal du dokumentere dem i et fælles format og få dem gennemgået af erfarne teammedlemmer.
Hvordan man analyserer krav
Overvej eksemplet med et uddannelsesmæssigt softwaresystem, hvor en studerende kan tilmelde sig forskellige kurser.
Lad os undersøge, hvordan man analyserer kravene. Hvert krav skal overholde et sæt standardkvalitetsegenskaber, som omfatter følgende:
- Atomic
- Unikt identificeret
- Komplet
- Konsekvent og utvetydigt
- Tracegnet
- prioriteret
- Testbar
Følgende tabel illustrerer hver attribut med tre kolonner:
- Den første kolonne angiver- "kravkvalitet"
- Den anden kolonne angiver - "dårligt krav med et eller andet problem"
- Den tredje kolonne viser det samme krav "konverteret til et godt krav".
| Krav Kvalitet | Eksempel på dårligt krav | Eksempel på godt krav |
|---|---|---|
| Atomic | Studerende vil være i stand til at tilmelde sig bachelor- og postgraduate-kurser | Studerende vil kunne tilmelde sig bacheloruddannelser. Studerende vil kunne tilmelde sig kandidatuddannelser. |
| Unikt identificeret | 1- Studerende vil kunne tilmelde sig bacheloruddannelser. 1- Studerende vil kunne tilmelde sig kandidatuddannelser. | Kursustilmelding. Studerende vil kunne tilmelde sig bachelorkurser. Studerende vil kunne tilmelde sig kandidatkurser. |
| 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 |
| Tracegnet | Vedligeholde elevinformation kortlagt til BRD req.ID? | Vedligeholdelse af elevoplysninger - Kortlagt til BRD krav ID 4.1 |
| prioriteret | Registreret studerende - Prioritet 1. Vedligehold brugeroplysninger - Prioritet 1. Tilmelding til kurser - Prioritet 1. Se karakterbog - Prioritet 1 | Registrer elev - Prioritet 1. Vedligehold brugeroplysninger - Prioritet 2. Tilmeld kurser - Prioritet 1. Se karakterbog - Prioritet 3 |
| 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 forstå hver af disse egenskaber mere detaljeret, startende med Atomic.
Atomic
Hvert krav skal være atomært, hvilket betyder, at det skal være på det laveste detaljeringsniveau og ikke kan opdeles yderligere i komponenter. Følgende eksempler sammenligner atomære og ikke-atomære krav.
Fortsætter vi med eksemplet med uddannelsessystemet: Her er det dårlige krav "Studerende vil kunne tilmelde sig bachelor- og kandidatuddannelser". Dette er et dårligt krav, fordi det ikke er atomært - det blander to forskellige enheder, bachelor- og kandidatuddannelser. Det tilsvarende gode krav opdeler det i to krav. Det ene krav dækker tilmelding til bacheloruddannelser, og det andet dækker tilmelding til kandidatuddannelser.
Unikt identificeret
Den næste kvalitetsattribut er unik identifikation. I det dårlige eksempel deler to separate krav det samme ID#1. Hvis et team refererer til et krav med dets ID, bliver det uklart, hvilket af de to der menes. Det gode krav omgrupperer dem under Afsnit 1 — Kursustilmelding, med underkrav 1.1 (tilmelding til bachelorkurser) og 1.2 (tilmelding til kandidatkurser).
Komplet
Alle krav skal være opfyldt. For eksempel siger det ukorrekte krav her, at en "professorbruger logger ind på systemet ved at angive sit brugernavn, adgangskode og andre relevante oplysninger". "Andre relevante oplysninger" er vagt. Et komplet krav angiver de nøjagtige felter, såsom afdelingskode, som professoren skal angive.
Konsekvent og utvetydigt
Alle krav bør være ensartede og utvetydige. I det dårlige eksempel angiver ét krav: "En studerende skal enten have bachelorkurser eller kandidatkurser, men ikke begge dele", mens et andet angiver: "Nogle kurser vil være åbne for både bachelor- og kandidatstuderende".
Det første krav indebærer, at kurser er opdelt i to eksklusive kategorier, men det andet krav modsiger det ved at åbne nogle kurser for begge grupper.
Kravet om godkendelse løser konflikten ved tydeligt at angive, at alle kurser er markeret som enten bachelor- eller kandidatkurser, og at en studerende kun kan tilmelde sig kurser i én kategori.
Tracegnet
Ethvert krav skal være tracmulig, fordi krav findes på flere niveauer: forretnings-, arkitektur- og designniveau samt system- og integrationsniveau.
Når du konverterer et forretningskrav til arkitektoniske og designmæssige krav, eller arkitektoniske og designmæssige krav til system- og integrationskrav, tracFunktionaliteten skal bevares. Alle forretningskrav skal knyttes til et eller flere arkitektoniske og designmæssige krav. I det dårlige eksempel "Vedligehold elevoplysninger – knyttet til BRD-krav-ID?" mangler krav-ID'et.
Det gode krav registrerer den samme sætning, men knytter eksplicit til BRD-krav-ID 4.1. Hvert krav skal indeholde en tractilgængelighedskortpingSystem- og integrationskrav bør også knyttes til den kode, der implementerer dem, og til de testcases, der verificerer dem.
TracEffektiviteten løber derfor fra ende til anden på tværs af projektet.
prioriteret
Alle krav skal prioriteres, så teamet ved, hvad der skal implementeres først, og hvad der kan vente. I det dårlige eksempel er Registrer elev, Vedligehold brugeroplysninger, Tilmeld kurser og Vis rapport alle indstillet til prioritet 1. Alt kan ikke have prioritet 1, så kravene skal rangeres realistisk. Det gode eksempel giver Registrer elev og Tilmeld kurser den højeste prioritet 1, Vedligehold brugeroplysninger prioritet 2 og Vis rapport prioritet 3.
Testbar
Alle krav bør kunne testes. Det dårlige eksempel, "hver side i systemet indlæses inden for en acceptabel tidsramme", kan ikke testes af to grunde. For det første kan "hver side" betyde snesevis af sider, hvilket forpurrer testindsatsen. For det andet er "acceptabel tidsramme" udefineret - acceptabel for hvem, og i forhold til hvilket benchmark? Det gode krav løser begge problemer ved at navngive de specifikke sider ("sider til registrering af studerende og tilmelding af kurser") og sætte et målbart mål på 5 sekunder.
