Analyse van softwarevereisten met voorbeeld
Karel Moore
⚡ Slimme samenvatting
Softwarevereistenanalyse splitst de behoeften van belanghebbenden op in functionele en niet-functionele eisen, rangschikt deze op bedrijfs-, architectuur- en systeemniveau, en controleert vervolgens elk ervan aan de hand van kwaliteitskenmerken om een testbare oplossing te garanderen. traceable, geprioriteerde specificatie.
Een softwarevereiste is een functionele of niet-functionele behoefte die in het systeem moet worden geïmplementeerd. Functioneel betekent dat er een specifieke dienst aan de gebruiker moet worden geleverd.
In de context van een bankapplicatie is de functionele eis bijvoorbeeld dat wanneer een klant 'Saldo bekijken' selecteert, hij of zij het meest recente rekeningsaldo moet kunnen inzien.
Een softwarevereiste kan ook niet-functioneel zijn, zoals een prestatievereiste. Een niet-functionele vereiste zou bijvoorbeeld kunnen inhouden dat elke pagina van het systeem binnen 5 seconden voor gebruikers moet laden.
Dus eigenlijk softwarevereiste is een
- Functioneel of
- Niet-functioneel
genoodzaakt bent dat in het systeem moet worden geïmplementeerd. Softwarevereisten worden doorgaans in de vorm van verklaringen uitgedrukt.
Soorten vereisten
Zakelijke vereistenDit zijn de belangrijkste eisen die zijn overgenomen uit de businesscase voor het project. Een mobiel banksysteem biedt bijvoorbeeld bankdiensten aan in Zuidoost-Azië. De vastgestelde eisen voor India zijn rekeningoverzichten en geldoverboekingen, terwijl voor China rekeningoverzichten en factuurbetalingen vereist zijn.
| Land | Bedrijf dat bankfunctionaliteiten of -diensten levert |
|---|---|
| India | Rekeningoverzicht en overboeking |
| China | Rekeningoverzicht en Bill Betalen |
Architechnische en ontwerpvereistenDeze eisen zijn gedetailleerder dan de bedrijfseisen en bepalen de architectuur van de oplossing. Ze bepalen het algehele ontwerp dat nodig is om de bedrijfseisen te implementeren. Voor een onderwijsinstelling omvatten typische architectuur- en ontwerpscenario's onder andere inloggen, cursusdetails en inschrijven. De eis zou er als volgt uitzien.
| Gebruiksscenario voor banken | eis |
|---|---|
| Bill Betalen | Deze use case beschrijft hoe een klant kan inloggen op Net Banking en gebruik kan maken van het Bill Betaalfaciliteit. De klant kan een dashboard bekijken met openstaande facturen van geregistreerde factuurverstrekkers. De klant kan factuurgegevens toevoegen, wijzigen en verwijderen. De klant kan sms- en e-mailmeldingen instellen voor verschillende factuuracties. De klant kan een overzicht van eerder betaalde facturen bekijken. De gebruikers die deze use case starten, zijn bankklanten of ondersteunend personeel. |
Systeem- en integratievereistenOp het laagste niveau vinden we systeem- en integratievereisten. Deze bieden een gedetailleerde beschrijving van elke vereiste. Ze kunnen worden vastgelegd als gebruikersverhalen, geschreven in alledaagse zakelijke taal. De vereisten bevatten veel details, zodat ontwikkelaars direct aan de slag kunnen met programmeren. Bill Het onderstaande voorbeeld van de betalingsmodule laat zien hoe je een factuurontvanger kunt toevoegen.
| Bill Betalen | Voorwaarden |
|---|---|
| Toevoegen Billers | Naam energieleverancier, relatie met klantnummer, automatische betalingen – ja/nee, totaalbedrag betalen Bill – Ja/Nee, limiet voor automatische betalingen – Niet betalen indien Bill is boven het opgegeven bedrag |
Soms ontvang je voor een project geen specificaties of documenten om mee te werken. Zelfs dan zijn er andere bronnen met specificaties waarop je kunt vertrouwen om je software- of testontwerp te baseren. Deze andere bronnen staan hieronder vermeld.
Andere bronnen van vereisten
- Kennisoverdracht van collega’s of medewerkers die al aan dat project werken
- Bespreek het project met de businessanalist, productmanager, projectleider en ontwikkelaars.
- Analyseer de eerder geïmplementeerde versie van het systeem.
- Analyseer oudere eisendocumenten van het project.
- RevBekijk eerdere bugrapporten; sommige bugrapporten worden omgezet in verbeteringsverzoeken die mogelijk in de huidige versie worden geïmplementeerd.
- Raadpleeg de installatiehandleiding, indien beschikbaar, om te zien welke installaties vereist zijn.
- Analyseer de domein- of branchekennis die het team probeert toe te passen.
Ongeacht welke bron voor de vereisten u gebruikt, documenteer ze in een gemeenschappelijk formaat en laat ze beoordelen door ervaren teamleden.
Hoe vereisten te analyseren
Neem bijvoorbeeld een educatief softwaresysteem waarmee een student zich kan inschrijven voor verschillende cursussen.
Laten we eens bekijken hoe we de eisen kunnen analyseren. Elke eis moet voldoen aan een reeks standaardkwaliteitskenmerken, waaronder de volgende:
- Atomic
- Uniek geïdentificeerd
- Volledige
- Consistent en eenduidig
- Traceable
- met prioriteit
- Testbaar
De volgende tabel illustreert elk kenmerk met drie kolommen:
- De eerste kolom geeft aan: “vereistekwaliteit”
- De tweede kolom geeft aan: “slechte vereiste met een probleem”
- De derde kolom laat zien dat dezelfde eis “is omgezet in een goede eis”.
| Eis Kwaliteit | Voorbeeld van een slechte vereiste | Voorbeeld van een goede vereiste |
|---|---|---|
| Atomic | Studenten kunnen zich inschrijven voor bachelor- en postdoctorale opleidingen | Studenten kunnen zich inschrijven voor bacheloropleidingen. Studenten kunnen zich inschrijven voor masteropleidingen. |
| Uniek geïdentificeerd | 1. Studenten kunnen zich inschrijven voor bacheloropleidingen. 1. Studenten kunnen zich inschrijven voor masteropleidingen. | Cursusinschrijving. Studenten kunnen zich inschrijven voor bacheloropleidingen. Studenten kunnen zich inschrijven voor masteropleidingen. |
| Volledige | Een professor-gebruiker logt in op het systeem door zijn gebruikersnaam, wachtwoord en andere relevante informatie op te geven | Een hoogleraargebruiker logt in op het systeem met zijn gebruikersnaam, wachtwoord en afdelingscode |
| Consistent en eenduidig | Een student zal een bacheloropleiding of een postdoctorale opleiding volgen, maar niet beide. Sommige cursussen staan open voor zowel bachelor- als postdoctoraalstudenten | Een student heeft een bachelordiploma of een postdoctoraal diploma, maar niet beide |
| Traceable | Studentgegevens bijhouden die zijn toegewezen aan BRD req.ID? | Studentinformatie bijhouden - Toegewezen aan BRD-req ID 4.1 |
| met prioriteit | Geregistreerde student - Prioriteit 1. Gebruikersinformatie beheren - Prioriteit 1. Cursussen inschrijven - Prioriteit 1. Rapportkaart bekijken - Prioriteit 1 | Student registreren - Prioriteit 1. Gebruikersgegevens beheren - Prioriteit 2. Cursussen inschrijven - Prioriteit 1. Rapportkaart bekijken - Prioriteit 3 |
| Testbaar | Elke pagina van het systeem wordt binnen een acceptabel tijdsbestek geladen | De pagina's voor het registreren van studenten en het inschrijven van cursussen van het systeem worden binnen 5 seconden geladen |
Laten we elk van deze eigenschappen eens nader bekijken, te beginnen met Atomic.
Atomic
Elke eis moet atomair zijn, wat betekent dat deze op het laagste detailniveau moet liggen en niet verder kan worden onderverdeeld in componenten. De volgende voorbeelden vergelijken atomaire en niet-atomische eisen.
Om verder te gaan met het voorbeeld van het onderwijssysteem: hier is de slechte eis: "Studenten kunnen zich inschrijven voor bachelor- en masteropleidingen". Dit is een slechte eis omdat deze niet atomair is – er worden twee verschillende entiteiten, bachelor- en masteropleidingen, door elkaar gehaald. De overeenkomstige goede eis splitst dit op in twee eisen. De ene eis heeft betrekking op inschrijving voor bacheloropleidingen en de andere op inschrijving voor masteropleidingen.
Uniek geïdentificeerd
Het volgende kwaliteitskenmerk is unieke identificatie. In het slechte voorbeeld delen twee afzonderlijke vereisten hetzelfde ID#1. Als een team naar een vereiste verwijst met behulp van het ID, wordt het onduidelijk welke van de twee bedoeld wordt. De goede vereisten groeperen ze onder Sectie 1 — Cursusinschrijving, met subvereisten 1.1 (inschrijving voor bacheloropleidingen) en 1.2 (inschrijving voor masteropleidingen).
Volledige
Elke eis moet volledig zijn. Een slechte eis luidt bijvoorbeeld: "Een professor logt in op het systeem door zijn gebruikersnaam, wachtwoord en andere relevante informatie te verstrekken." "Andere relevante informatie" is vaag. Een volledige eis vermeldt de exacte velden, zoals de afdelingscode, die de professor moet invullen.
Consistent en eenduidig
Elke eis moet consistent en ondubbelzinnig zijn. In het slechte voorbeeld staat er in de ene eis: "Een student volgt ofwel bachelorvakken ofwel mastervakken, maar niet beide", terwijl in een andere eis staat: "Sommige vakken zijn toegankelijk voor zowel bachelor- als masterstudenten".
De eerste eis houdt in dat cursussen in twee exclusieve categorieën worden verdeeld, maar de tweede eis spreekt dit tegen door sommige cursussen voor beide groepen open te stellen.
De goede eis lost het conflict op door duidelijk te stellen dat elke cursus is aangemerkt als bachelor- of masteropleiding, en dat een student zich slechts voor cursussen van één categorie kan inschrijven.
Traceable
Aan elke eis moet worden voldaan traceable omdat er eisen bestaan op meerdere niveaus: zakelijk, architectuur en ontwerp, en systeem en integratie.
Wanneer je een bedrijfsvereiste omzet in architectuur- en ontwerpvereisten, of architectuur- en ontwerpvereisten in systeem- en integratievereisten, tracDe toegankelijkheid moet gewaarborgd blijven. Elke bedrijfsvereiste moet gekoppeld zijn aan een of meer architectuur- en ontwerpvereisten. In het slechte voorbeeld "Studentinformatie bijhouden – gekoppeld aan BRD-vereiste-ID?" ontbreekt de vereiste-ID.
De goede eis bevat dezelfde verklaring, maar is expliciet gekoppeld aan BRD-eis-ID 4.1. Elke eis moet een tracinclusiekaartpingSysteem- en integratievereisten moeten ook overeenkomen met de code die ze implementeert en met de testgevallen die ze verifiëren.
TracEability is daarom een integraal onderdeel van het hele project.
met prioriteit
Elke vereiste moet prioriteit krijgen, zodat het team weet wat als eerste moet worden geïmplementeerd en wat kan wachten. In het slechte voorbeeld hebben 'Student registreren', 'Gebruikersgegevens beheren', 'Cursussen inschrijven' en 'Rapportkaart bekijken' allemaal prioriteit 1. Niet alles kan prioriteit 1 zijn, dus de vereisten moeten realistisch worden gerangschikt. In het goede voorbeeld krijgen 'Student registreren' en 'Cursussen inschrijven' de hoogste prioriteit 1, 'Gebruikersgegevens beheren' prioriteit 2 en 'Rapportkaart bekijken' prioriteit 3.
Testbaar
Elke eis moet testbaar zijn. Het slechte voorbeeld, "elke pagina van het systeem laadt binnen een acceptabele tijd", is om twee redenen niet testbaar. Ten eerste kan "elke pagina" tientallen pagina's betekenen, wat de testinspanning enorm verhoogt. Ten tweede is "acceptabele tijd" niet gedefinieerd – acceptabel voor wie, en ten opzichte van welke benchmark? De goede eis lost beide problemen op door de specifieke pagina's te benoemen ("pagina's voor studentenregistratie en cursusinschrijving") en een meetbaar doel van 5 seconden te stellen.
