Programvarebehovsanalyse med eksempel
Charles Moore
⚡ Smart oppsummering
Kravanalyse for programvare deler interessentenes behov inn i funksjonelle og ikke-funksjonelle utsagn, rangerer dem på forretnings-, arkitektur- og systemnivå, og kontrollerer deretter hver enkelt mot kvalitetsattributter for å garantere en testbar, tracmulig, prioritert spesifikasjon.
Et programvarekrav er et funksjonelt eller ikke-funksjonelt behov som må implementeres i systemet. Funksjonelt betyr å tilby en bestemt tjeneste til brukeren.
For eksempel, i forbindelse med en bankapplikasjon, er det funksjonelle kravet at når en kunde velger «Vis saldo», skal de kunne se sin siste kontosaldo.
Et programvarekrav kan også være ikke-funksjonelt, for eksempel et ytelseskrav. For eksempel kan et ikke-funksjonelt krav angi at hver side i systemet skal lastes inn for brukere innen 5 sekunder.
Så i bunn og grunn programvarekravet er en
- Funksjonell eller
- Ikke-funksjonell
trenge som må implementeres i systemet. Programvarekrav uttrykkes vanligvis som utsagn.
Typer krav
ForretningskravDette er overordnede krav hentet fra forretningsplanen for prosjektet. For eksempel tilbyr et mobilbanksystem banktjenester til Sørøst-Asia. Forretningskravet som er bestemt for India er kontooppsummering og pengeoverføring, mens det for Kina er kontooppsummering og betaling av regninger.
| Land | Selskap som tilbyr bankfunksjoner eller -tjenester |
|---|---|
| India | Kontosammendrag og pengeoverføring |
| Kina | Kontosammendrag og Bill Betaling |
Architekniske krav og designkravDisse kravene er mer detaljerte enn forretningskrav og driver løsningsarkitekturen. De bestemmer den overordnede designen som kreves for å implementere forretningskravet. For en utdanningsorganisasjon inkluderer typiske arkitektur- og designbrukstilfeller innlogging, kursdetaljer og påmelding. Kravet vil være som vist nedenfor.
| Bankbrukssak | Krav |
|---|---|
| Bill Betaling | Denne brukssaken beskriver hvordan en kunde kan logge seg på nettbank og bruke Bill Betalingsfasilitet. Kunden kan se et dashbord over utestående regninger for registrerte fakturautstedere. Kunden kan legge til, endre og slette en fakturautstederdetalj. Kunden kan konfigurere SMS- og e-postvarsler for ulike faktureringshandlinger. Kunden kan se en historikk over tidligere betalte regninger. Aktørene som starter denne bruksscenariet er bankkunder eller supportpersonell. |
System- og integrasjonskravPå det laveste nivået har vi system- og integrasjonskrav. Det gir en detaljert beskrivelse av hvert krav. Det kan fanges opp som brukerhistorier skrevet i et vanlig forretningsspråk. Kravene inneholder rikelig med detaljer slik at utviklere kan begynne å kode. Bill Eksempelet på betalingsmodulen nedenfor viser kravet for å legge til en fakturautsteder.
| Bill Betaling | Krav |
|---|---|
| Legg til BillERS | Navn på strømleverandør, kundenummer, automatiske betalinger – Ja/Nei, betal hele beløpet Bill – Ja/Nei, automatisk betalingsgrense – Ikke betal hvis Bill er over spesifisert beløp |
Noen ganger kan det hende at du ikke mottar noen krav eller dokumenter å jobbe med for et prosjekt. Selv da finnes det andre kilder til kravinformasjon som du kan stole på for å basere programvaren eller testdesignet ditt. De andre kildene til krav du kan stole på er listet opp nedenfor.
Andre kilder til krav
- Kunnskapsoverføring fra kolleger eller ansatte som allerede jobber med det prosjektet
- Diskuter prosjektet med forretningsanalytikeren, produktsjefen, prosjektlederen og utviklerne
- Analyser den forrige versjonen av systemet som allerede er implementert
- Analyser eldre kravdokumenter fra prosjektet
- Revse tidligere feilrapporter; noen feilrapporter konverteres til forbedringsforespørsler som kan implementeres i gjeldende versjon
- Sjekk installasjonsveiledningen, hvis tilgjengelig, for å se hvilke installasjoner som kreves
- Analyser domene- eller bransjekunnskapen teamet prøver å implementere
Uansett hvilken kilde du bruker til krav, dokumenter dem i et delt format og få dem gjennomgått av erfarne teammedlemmer.
Hvordan analysere krav
Tenk på et eksempel på et pedagogisk programvaresystem der en student kan registrere seg for forskjellige kurs.
La oss studere hvordan vi analyserer kravene. Hvert krav må opprettholde et sett med standardkvalitetsattributter, som inkluderer følgende:
- Atomic
- Unikt identifisert
- Komplett
- Konsekvent og entydig
- Tracmulig
- Prioritert
- Testbar
Tabellen nedenfor illustrerer hvert attributt med tre kolonner:
- Den første kolonnen indikerer- "kravkvalitet"
- Den andre kolonnen indikerer- "dårlig krav med et eller annet problem"
- Den tredje kolonnen viser det samme kravet «konvertert til et godt krav».
| Krav Kvalitet | Eksempel på dårlig krav | Eksempel på godt krav |
|---|---|---|
| Atomic | Studentene vil kunne melde seg på grunn- og etterutdanningskurs | Studenter vil kunne melde seg på bachelorkurs. Studenter vil kunne melde seg på høyere utdanning. |
| Unikt identifisert | 1- Studenter vil kunne melde seg på bachelorkurs. 1- Studenter vil kunne melde seg på høyere utdanning. | Kurspåmelding. Studenter vil kunne melde seg på bachelorkurs. Studenter vil kunne melde seg på høyere utdanning. |
| Komplett | En professorbruker vil logge på systemet ved å oppgi brukernavn, passord og annen relevant informasjon | En professorbruker vil logge inn i systemet ved å oppgi brukernavn, passord og avdelingskode |
| Konsekvent og entydig | En student vil ha enten bachelor- eller postgraduate-kurs, men ikke begge deler. Noen kurs vil være åpne for både undergraduate og post-graduate | En student vil ha enten under- eller postgraduate, men ikke begge deler |
| Tracmulig | Vedlikeholde studentinformasjon kartlagt til BRD req.ID? | Oppretthold studentinformasjon-tilordnet BRD krav ID 4.1 |
| Prioritert | Registrert student – prioritet 1. Vedlikehold av brukerinformasjon – prioritet 1. Meld på kurs – prioritet 1. Visning av karakterutskrift – prioritet 1 | Registrer student – prioritet 1. Vedlikehold brukerinformasjon – prioritet 2. Meld på kurs – prioritet 1. Vis rapportkort – prioritet 3 |
| Testbar | Hver side i systemet vil lastes inn i en akseptabel tidsramme | Sidene for registrering av studenter og påmelding til kurs vil lastes inn innen 5 sekunder |
La oss forstå hver av disse egenskapene mer detaljert, og starte med Atomic.
Atomic
Alle krav bør være atomære, noe som betyr at de må være på laveste detaljnivå og ikke kan deles ytterligere ned i komponenter. Følgende eksempler sammenligner atomære og ikke-atomære krav.
Fortsetter med eksemplet med utdanningssystemet: Her er det dårlige kravet «Studentene vil kunne melde seg på bachelor- og masterkurs». Dette er et dårlig krav fordi det ikke er atomært – det blander to forskjellige enheter, bachelor- og masterkurs. Det tilsvarende gode kravet deler det inn i to krav. Det ene kravet dekker opptak til bachelorkurs, og det andre dekker opptak til masterkurs.
Unikt identifisert
Den neste kvalitetsattributten er unik identifikasjon. I det dårlige eksemplet deler to separate krav samme ID#1. Hvis et team refererer til et krav med sin ID, blir det uklart hvilket av de to som menes. Det gode kravet omgrupperer dem under Seksjon 1 – Kurspåmelding, med delkrav 1.1 (påmelding til bachelorkurs) og 1.2 (påmelding til høyere utdanning).
Komplett
Alle krav må være fullstendige. For eksempel sier det ugyldige kravet her at en «professorbruker vil logge seg inn i systemet ved å oppgi brukernavn, passord og annen relevant informasjon». «Annen relevant informasjon» er vagt. Et fullstendig krav viser de nøyaktige feltene, for eksempel avdelingskode, som professoren må oppgi.
Konsekvent og entydig
Alle krav bør være konsistente og utvetydige. I det dårlige eksemplet sier ett krav «En student vil ha enten bachelor- eller masterkurs, men ikke begge deler», mens et annet sier «Noen kurs vil være åpne for både bachelor- og masterstudenter».
Det første kravet innebærer at kurs er delt inn i to eksklusive kategorier, men det andre kravet motsier det ved å åpne noen kurs for begge gruppene.
Kravet om godhet løser konflikten ved å tydelig si at alle emner er merket enten som bachelor eller master, og en student kan bare melde seg på emner i én kategori.
Tracmulig
Hvert krav må være tracmulig fordi krav finnes på flere nivåer: forretnings-, arkitektur- og designnivå, og system- og integrasjonsnivå.
Når du konverterer et forretningskrav til arkitektur- og designkrav, eller arkitektur- og designkrav til system- og integrasjonskrav, tracBærekraften må bevares. Alle forretningskrav bør tilordnes ett eller flere arkitektoniske og designmessige krav. I det dårlige eksemplet «Vedlikehold studentinformasjon – tilordnet BRD-krav-ID?» mangler krav-ID-en.
Det gode kravet registrerer den samme setningen, men er eksplisitt knyttet til BRD-krav-ID 4.1. Hvert krav må ha en tracmulighetskartpingSystem- og integrasjonskrav bør også være knyttet til koden som implementerer dem og til testtilfellene som verifiserer dem.
Traceffektivitet går derfor ende til ende på tvers av prosjektet.
Prioritert
Alle krav må prioriteres slik at teamet vet hva som skal implementeres først og hva som kan vente. I det dårlige eksemplet er Registrer student, Vedlikehold brukerinformasjon, Meld på kurs og Vis rapportkort satt til prioritet 1. Alt kan ikke ha prioritet 1, så kravene må rangeres realistisk. Det gode eksemplet gir Registrer student og Meld på kurs høyest prioritet 1, Vedlikehold brukerinformasjon prioritet 2 og Vis rapportkort prioritet 3.
Testbar
Alle krav bør kunne testes. Det dårlige eksemplet, «hver side i systemet lastes inn innen en akseptabel tidsramme», er ikke testbart av to grunner. For det første kan «hver side» bety dusinvis av sider, noe som forringer testarbeidet. For det andre er «akseptabel tidsramme» udefinert – akseptabelt for hvem, og mot hvilken målestokk? Det gode kravet løser begge problemene ved å navngi de spesifikke sidene («registrer student og meld inn kurs») og sette et målbart mål på 5 sekunder.
