Programvarebehovsanalyse med eksempel
Charles Moore
For eksempel, i sammenheng med bankapplikasjoner vil funksjonskravet være når kunden velger "Se saldo", må de kunne se på sin siste kontosaldo.
Programvarekrav kan også være et ikke-funksjonelt, det kan være et ytelseskrav. For eksempel er et ikke-funksjonelt krav at hver side i systemet skal være synlig for brukerne 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 uttalelser.
Typer krav
- Forretningskrav: De er krav på høyt nivå som er hentet fra business casen fra prosjektene. For eksempel gir et mobilbanktjenestesystem banktjenester til Sørøst-Asia. Forretningskravet som er bestemt for India er kontosammendrag og pengeoverføring, mens for Kina er kontosammendrag og fakturabetaling bestemt som et forretningskrav
| Land | Selskap som tilbyr bankfunksjoner eller -tjenester |
|---|---|
| India | Kontosammendrag og pengeoverføring |
| Kina | Kontosammendrag og Bill Betaling |
- Architekniske krav og designkrav: Disse kravene er mer detaljerte enn forretningskravene. Det bestemmer det overordnede designet som kreves for å implementere forretningskravet. For vår utdanningsorganisasjon vil de arkitektoniske og designmessige brukstilfellene være pålogging, kursdetaljer osv. 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 Betalingsanlegg.
Kunden vil se et dashbord med utestående regninger fra registrerte fakturautstedere. Han kan legge til, endre og slette en fakturadetalj. Kunden kan konfigurere SMS, e-postvarsler for ulike faktureringshandlinger. Han kan se historien om tidligere betalte regninger. Aktørene som starter denne brukssaken er bankkunder eller støttepersonell. |
- System- og integrasjonskrav: På laveste nivå har vi system- og integrasjonskrav. Det er en detaljert beskrivelse av hvert eneste krav. Det kan være i form av brukerhistorier som virkelig beskriver det daglige forretningsspråket. Kravene er i rikelig med detaljer slik at utviklere kan begynne å kode. Her er et eksempel på Bill Betalingsmodul hvor krav vil bli nevnt for å legge til en Biller
| Bill Betaling | Krav |
|---|---|
| Legg til BillERS |
|
Noen ganger for et prosjekt kan det hende du ikke mottar noen krav eller dokumenter å jobbe med. Men fortsatt er det andre kilder til krav som du kan vurdere for kravet eller informasjonen, slik at du kan basere programvaren eller testdesignen på disse kravene. Så de andre kildene for krav du kan stole på er
Andre kilder til krav
- Kunnskapsoverføring fra kolleger eller ansatte som allerede jobber med det prosjektet
- Snakk om prosjekt med forretningsanalytiker, produktsjef, prosjektleder og utviklere
- Analyser tidligere systemversjon som allerede er implementert i systemet
- Analyser det eldre kravdokumentet til prosjektet
- Se på tidligere feilrapporter, noen av feilrapportene blir omgjort til forbedringsforespørsel som kan implementeres i gjeldende versjon
- Se på installasjonsveiledningen hvis den er tilgjengelig for å se hva som kreves for installasjon
- Analyser domenet eller bransjekunnskapen som teamet prøver å implementere
Uansett hvilken kilde til krav du får, sørg for å dokumentere dem i en eller annen form, få dem vurdert fra andre erfarne og kunnskapsrike 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 du analyserer kravene. Kravene skal holde en standard kvalitet på sitt krav, ulike typer kravkvalitet inkluderer
- Atomic
- Unikt identifisert
- Komplett
- Konsekvent og entydig
- Tracmulig
- Prioritert
- Testbar
La oss forstå dette med et eksempel, det er tre kolonner i tabellen vist her,
- Den første kolonnen indikerer- "kravkvalitet"
- Den andre kolonnen indikerer- "dårlig krav med et eller annet problem"
- Den tredje kolonnen er den samme som den andre kolonnen, men - "konvertert til et godt krav".
| Krav Kvalitet | Eksempel på dårlig krav | Eksempel på godt krav |
|---|---|---|
| Atomic |
|
|
| Unikt identifisert | 1- Studenter vil kunne melde seg på grunnkurs1- Studenter vil kunne melde seg på postgraduate-kurs |
|
| 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 1Vedlikeholde brukerinformasjon-Prioritet 1Registrere kurs-Prioritet 1Se rapportkort-Prioritet 1 | Registrer Student-Prioritet 1Vedlikeholde brukerinformasjon-Prioritet 2Registrere kurs-Prioritet 1Se rapportkort-Prioritet3 |
| 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 nå forstå hvert av disse kravene i detaljer fra og med Atomic.
Atomic
Så hvert eneste krav du har bør være atomært, noe som betyr at det skal være på svært lavt detaljnivå, det skal ikke være mulig å skille ut i komponenter. Her vil vi se de to eksemplene for krav, kl Atomic og unikt identifiserte kravnivåer.
Så la oss fortsette med eksempel på systembygging for utdanningsdomene. Her er det dårlige kravet "Studenter vil kunne melde seg på bachelor- og postgraduate-kurs" . Dette er et dårlig krav fordi det ikke er atomisk fordi det snakker om to forskjellige enheter undergraduate og post-graduates kurs. Så åpenbart er det ikke et godt krav, men dårlig krav, så korrespondanse godt krav ville være å skille det ut i to krav. Så den ene snakker om påmeldingen til grunnfag, mens den andre snakker om påmeldingen til postgraduate-kursene.
Unikt identifisert
På samme måte er neste kravkvalitet å se etter unikt identifisert, her har vi to separate krav, men de har begge samme ID#1. Så hvis vi refererer kravet vårt med referanse til ID#, men det er ikke klart hvilket eksakt krav vi refererer til dokumentet eller annen del av systemet, da begge har samme ID#1. Så skilles ut med unike id-er, så gode krav vil bli returnert som seksjon 1- kurs påmeldinger, og den har to krav 1.1 id er påmelding til grunnfag mens 1.2 id er påmelding til postgraduate kurs.
Komplett
Dessuten bør hvert eneste krav være komplett. For eksempel, her sier det dårlige kravet at en "professorbruker vil logge på systemet ved å oppgi brukernavn, passord og annen relevant informasjon". Her er den øvrige relevante informasjonen ikke klar, så den andre relevante informasjonen bør staves i god forskrift for å gjøre kravet komplett.
Konsekvent og entydig
Deretter skal hvert eneste krav være konsistente og entydige, så her har vi for eksempel krav "En student vil ha enten grunnkurs eller postgraduate-kurs, men ikke begge" dette er ett krav det er et annet krav som sier "Noen kurs vil være åpen for både undergraduate og post-graduate studenter».
Problemet med dette kravet er at fra det første kravet ser det ut til at kursene er delt inn i to kategorier under hovedfagskurs og etterutdanningskurs, og studenten kan velge ett av to, men ikke begge. Men når du leser andre krav, er det i konflikt med det første kravet, og det forteller at noen kurs vil åpne for både postgraduate og under-graduate.
Så det er åpenbart å konvertere dette dårlige kravet til et godt krav som er "En student vil ha enten under-graduate-kurs eller post-graduate-kurs, men ikke begge deler". Noe som betyr at hvert emne vil bli merket enten som et hovedfag eller et hovedfag
Tracmulig
Hvert eneste krav bør være tracmulig fordi det allerede finnes forskjellige nivåer av krav, vi så allerede at vi på toppen hadde forretningskrav, og så har vi arkitektur- og designkrav etterfulgt av krav til systemintegrasjon.
Når vi konverterer forretningskrav til arkitektoniske og designmessige krav, eller konverterer arkitektoniske og designmessige krav til systemintegrasjonskrav, må det være traceability. Som betyr at vi skal kunne ta hvert eneste forretningskrav og tilordne det til det tilsvarende ett eller flere krav til programvarearkitektur og design. Så her er et eksempel på et dårlig krav som sier «Vedlikehold studentinformasjon – tilordnet til BRD-krav-ID?» Krav-ID-en er ikke oppgitt her.
Så når man konverterer det til et godt krav, står det det samme, men det er kartlagt med krav-ID 4.1. Så kartleggping bør være der for hvert eneste krav. På samme måte som vi har kart på høyt og lavt nivåping kravet, kartetping er det også mellom system- og integrasjonskravet til koden som implementerer det kravet, og det er også et kartping mellom system- og integrasjonskravet til testtilfellet som tester det spesifikke kravet.
Så dette traceffektivitet er på tvers av hele prosjektet
Prioritert
| Prioritert | Registrert student-Prioritet 1 Oppretthold brukerinformasjon-prioritet 1 Meld deg på kurs – prioritet 1 Vis rapportkort-prioritet 1 |
Registrer studentprioritet 1 Oppretthold brukerinformasjon-prioritet 2 Meld deg på kurs – prioritet 1 Se rapportkort-prioritet3 |
Deretter må hvert eneste krav prioriteres, slik at teamet har retningslinjer for hvilke krav som kan implementeres først og hvilke som kan gjøres senere. Her kan du se dårlig prioritet har registrert student, vedlikeholde brukerinformasjon og hvert eneste krav har gitt prioritet-1. Alt kan ikke ha samme prioritet, så krav kan prioriteres. Så eksempelet på gode krav her er registrer studenten og påmeldingskurs er gitt høyeste prioritet 1, mens vedlikehold av brukerinformasjon kommer under ved prioritet 2 og så har vi se rapportkort på prioritet-3
Testbar
| 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 |
Hvert eneste krav skal være testbart, her er det dårlige kravet "hver side i systemet vil lastes i en akseptabel tidsramme". Nå er det to problemer med dette kravet først er at hver side betyr at det kan være mange sider som kommer til å sprenge testarbeidet. Det andre problemet er at det står at siden skal lastes i en akseptabel tidsramme, hva er nå en akseptabel tidsramme? Akseptabelt for hvem. Så vi må konvertere det ikke-testbare argumentet til et testbart argument, som spesifikt forteller om hvilken side vi snakker om "registrer student- og registrer kurssider", og den akseptable tidsrammen er også gitt som er 5 sekunder.
Konklusjon
Så dette er hvordan vi må se på hvert eneste krav på passende nivå. For eksempel hvis vi skal bygge en programvare med tanke på system- og integrasjonskrav. Vi må se på system- og integrasjonskrav gitt i programvarekravspesifikasjonene eller brukerhistoriene og gjelde for hver eneste kravkvalitet. Sjekk deretter om hvert eneste krav er atomært, unikt identifisert og komplett og så videre.
