Analyse van softwarevereisten met voorbeeld
Karel Moore
In de context van de banktoepassing is de functionele vereiste bijvoorbeeld dat wanneer de klant 'Bekijk saldo' selecteert, hij of zij het laatste rekeningsaldo moet kunnen bekijken.
Softwarevereiste kan ook een niet-functionele vereiste zijn, het kan een prestatievereiste zijn. Een niet-functionele vereiste is bijvoorbeeld dat elke pagina van het systeem binnen 5 seconden zichtbaar moet zijn voor de gebruikers.
Dus eigenlijk softwarevereiste is een
- Functioneel of
- Niet-functioneel
genoodzaakt bent dat in het systeem moet worden geïmplementeerd. Softwarevereisten worden meestal uitgedrukt als uitspraken.
Soorten vereisten
- Zakelijke vereisten: Het zijn vereisten op hoog niveau die zijn overgenomen uit de businesscase van de projecten. Bijvoorbeeld, een mobiel bankieren servicesysteem biedt bankdiensten aan Zuidoost-Azië. De zakelijke vereiste die voor India is besloten, is een rekeningoverzicht en fondsoverdracht, terwijl voor China een rekeningoverzicht en betaling van rekeningen is besloten als een zakelijke vereiste.
| Land | Bedrijf dat bankfunctionaliteiten of -diensten levert |
|---|---|
| India | Rekeningoverzicht en overboeking |
| China | Rekeningoverzicht en Bill Betalen |
- Architechnische en ontwerpvereisten: Deze vereisten zijn gedetailleerder dan zakelijke vereisten. Het bepaalt het algehele ontwerp dat nodig is om de zakelijke vereiste te implementeren. Voor onze onderwijsorganisatie zouden de architecturale en ontwerp-use cases zijn: inloggen, cursusdetails, enz. De vereiste zou zijn zoals hieronder weergegeven.
| 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 Betalingsfaciliteit.
De klant kan een dashboard zien met openstaande facturen van geregistreerde facturatie-aanbieders. Hij kan een facturatie-detail toevoegen, wijzigen en verwijderen. De klant kan SMS- en e-mailmeldingen configureren voor verschillende factureringsacties. Hij kan de geschiedenis van eerdere betaalde facturen bekijken. De actoren die deze use case starten zijn bankklanten of ondersteunend personeel. |
- Systeem- en integratievereisten: Op het laagste niveau hebben we systeem- en integratievereisten. Het is een gedetailleerde beschrijving van elke vereiste. Het kan in de vorm van gebruikersverhalen zijn, die eigenlijk de dagelijkse zakelijke taal beschrijven. De vereisten zijn in overvloedige details, zodat ontwikkelaars kunnen beginnen met coderen. Hier is een voorbeeld van Bill Betalingsmodule waar de vereiste wordt vermeld voor het toevoegen van een Biller
| Bill Betalen | Voorwaarden |
|---|---|
| Toevoegen Billers |
|
Soms ontvangt u voor een bepaald project geen vereisten of documenten om mee te werken. Maar er zijn nog andere bronnen van eisen die u kunt overwegen voor de eis of informatie, zodat u uw software of testontwerp op deze eisen kunt baseren. Dus de andere bronnen voor vereisten waarop u kunt vertrouwen, zijn dat wel
Andere bronnen van vereisten
- Kennisoverdracht van collega’s of medewerkers die al aan dat project werken
- Over project gesproken met businessanalist, productmanager, projectleider en ontwikkelaars
- Analyseer de vorige systeemversie die al in het systeem is geïmplementeerd
- Analyseer het oudere vereistendocument van het project
- Bekijk de eerdere bugrapporten. Sommige bugrapporten zijn omgezet in een verbeteringsverzoek dat in de huidige versie kan worden geïmplementeerd
- Kijk in de installatiehandleiding als deze beschikbaar is om te zien wat de vereiste installatie is
- Analyseer de domein- of branchekennis die het team probeert te implementeren
Welke bron van vereisten u ook krijgt, zorg ervoor dat u ze in een of andere vorm documenteert en laat ze beoordelen door andere ervaren en deskundige teamleden.
Hoe vereisten te analyseren
Beschouw een voorbeeld van een educatief softwaresysteem waarbij een student zich kan inschrijven voor verschillende cursussen.
Laten we bestuderen hoe we de vereisten kunnen analyseren. De eisen moeten een standaardkwaliteit van de eisen behouden, die verschillende soorten eisen omvatten
- Atomic
- Uniek geïdentificeerd
- Volledige
- Consistent en eenduidig
- Traceable
- met prioriteit
- Testbaar
Laten we dit met een voorbeeld begrijpen. Er zijn drie kolommen in de hier weergegeven tabel:
- De eerste kolom geeft aan: “vereistekwaliteit”
- De tweede kolom geeft aan: “slechte vereiste met een probleem”
- De derde kolom is hetzelfde als de tweede kolom, maar – “omgerekend naar een goede eis”.
| Eis Kwaliteit | Voorbeeld van een slechte vereiste | Voorbeeld van een goede vereiste |
|---|---|---|
| Atomic |
|
|
| Uniek geïdentificeerd | 1- Studenten kunnen zich inschrijven voor niet-gegradueerde cursussen. 1- Studenten kunnen zich inschrijven voor postdoctorale cursussen |
|
| 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 1Gebruikersinformatie onderhouden-Prioriteit 1Cursussen inschrijven-Prioriteit 1Rapport bekijken-Prioriteit 1 | Student registreren - Prioriteit 1 Gebruikersinformatie onderhouden - 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 nu elk van deze vereisten in detail bekijken, te beginnen met Atomic.
Atomic
Dus elke vereiste die u heeft, moet atomisch zijn, wat betekent dat het op een heel laag detailniveau moet zijn, het mag niet mogelijk zijn om het in componenten te scheiden. Hier zien we de twee voorbeelden voor vereisten, op Atomic en uniek geïdentificeerde vereistenniveaus.
Laten we doorgaan met het voorbeeld van een systeem dat is gebouwd voor het onderwijsdomein. Hier is de slechte vereiste "Studenten kunnen zich inschrijven voor bachelor- en masteropleidingen". Dit is een slechte vereiste omdat het niet atomair is, omdat het over twee verschillende entiteiten gaat: bachelor- en masteropleidingen. Het is dus duidelijk geen goede vereiste, maar een slechte vereiste, dus een goede vereiste zou zijn om het in twee vereisten te splitsen. Dus de ene gaat over de inschrijving voor bacheloropleidingen, terwijl de andere gaat over de inschrijving voor masteropleidingen.
Uniek geïdentificeerd
Op dezelfde manier is de volgende vereistekwaliteit het controleren op uniek geïdentificeerde personen. Hier hebben we twee afzonderlijke vereisten, maar ze hebben allebei dezelfde ID#1. Dus als we onze vereiste verwijzen met verwijzing naar ID#, maar het is niet duidelijk welke exacte vereiste we bedoelen naar een document of een ander deel van het systeem, aangezien beide dezelfde ID#1 hebben. Dus gescheiden door unieke id's, dus een goede vereiste zal opnieuw worden geretourneerd als sectie 1-cursusinschrijvingen, en het heeft twee vereisten: 1.1 id is inschrijving voor niet-gegradueerde cursussen, terwijl 1.2 id inschrijving is voor postdoctorale cursussen.
Volledige
Bovendien moet elke vereiste compleet zijn. Hier zegt de slechte vereiste bijvoorbeeld dat een “professorgebruiker zich bij het systeem zal aanmelden door zijn gebruikersnaam, wachtwoord en andere relevante informatie op te geven”. Hier is de andere relevante informatie niet duidelijk, dus de andere relevante informatie moet goed worden omschreven om de vereiste compleet te maken.
Consistent en eenduidig
Vervolgens moet elke vereiste consistent en ondubbelzinnig zijn, dus hier hebben we bijvoorbeeld vereisten: “Een student zal een bacheloropleiding of een postdoctorale opleiding volgen, maar niet beide.” Dit is één vereiste. Er is een andere vereiste die zegt: “Sommige cursussen zullen openstaan voor zowel bachelor- als postdoctorale studenten”.
Het probleem met deze vereiste is dat het op grond van de eerste vereiste lijkt alsof de cursussen in twee categorieën zijn verdeeld onder graduate cursussen en postdoctorale cursussen en dat de student een van de twee kan kiezen, maar niet beide. Maar als u een andere vereiste leest, is deze in strijd met de eerste vereiste en vertelt u dat sommige cursussen openstaan voor zowel postdoctorale als niet-gegradueerde studenten.
Het ligt dus voor de hand om deze slechte vereiste om te zetten in een goede vereiste, namelijk: “Een student zal een bacheloropleiding of een postdoctorale opleiding volgen, maar niet beide”. Dit betekent dat elke cursus wordt gemarkeerd als een bacheloropleiding of een postdoctorale opleiding
Traceable
Aan elke afzonderlijke eis moet worden voldaan tracDat is mogelijk omdat er al verschillende niveaus van eisen zijn. We zagen al dat bovenaan de eisen de bedrijfsvereisten staan, vervolgens de architectuur- en ontwerpeisen en tot slot de systeemintegratie-eisen.
Wanneer we bedrijfsvereisten omzetten in architectuur- en ontwerpvereisten, of in systeemintegratievereisten, dan moet er rekening worden gehouden met het volgende: tracEability. Dit betekent dat we elke bedrijfsvereiste moeten kunnen koppelen aan de bijbehorende architectuur- en ontwerpvereisten voor de software. Een voorbeeld van een slechte vereiste is: "Studentinformatie bijhouden - gekoppeld aan BRD-vereiste-ID?". De vereiste-ID ontbreekt hier.
Als we het omzetten naar een goede vereiste, staat er hetzelfde, maar het is gekoppeld aan vereiste-ID 4.1. Dus koppelenping Er moet voor elke mogelijke behoefte een kaart beschikbaar zijn. Op dezelfde manier hebben we een kaart op hoog en laag niveau.ping vereiste, de kaartping Er is ook een verband tussen het systeem en de integratievereisten enerzijds en de code die deze vereisten implementeert anderzijds, en er is ook een kaart.ping tussen de systeem- en integratievereisten en de testcase die die specifieke vereisten test.
Dus dit tracToegankelijkheid is overal in het hele project aanwezig.
met prioriteit
| met prioriteit | Geregistreerde student-prioriteit 1 Behoud gebruikersinformatie-prioriteit 1 Cursussen inschrijven - Prioriteit 1 Bekijk rapportkaart-prioriteit 1 |
Registreren Student-Prioriteit 1 Behoud gebruikersinformatie-prioriteit 2 Cursussen inschrijven - Prioriteit 1 Rapportkaart-prioriteit bekijken3 |
Dan moet elke vereiste prioriteit krijgen, zodat het team een richtlijn heeft voor welke vereiste als eerste kan worden geïmplementeerd en welke later kan worden uitgevoerd. Hier ziet u dat de slechte prioriteit is om student te registreren, gebruikersinformatie te onderhouden en elke vereiste heeft prioriteit-1 gekregen. Niet alles kan dezelfde prioriteit hebben, dus de vereiste kan worden geprioriteerd. Dus het voorbeeld van een goede vereiste hier is dat de student registreren en cursussen inschrijven de hoogste prioriteit 1 krijgt, terwijl gebruikersinformatie onderhouden hieronder op prioriteit 2 komt en dan hebben we het rapport bekijken op prioriteit-3
Testbaar
| 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 |
Elke vereiste moet testbaar zijn, hier is de slechte vereiste: "elke pagina van het systeem wordt binnen een acceptabel tijdsbestek geladen". Er zijn twee problemen met deze vereiste. Ten eerste: elke pagina betekent dat er veel pagina's kunnen zijn, wat de testinspanningen zal opblazen. Het andere probleem is dat er staat dat de pagina binnen een acceptabel tijdsbestek wordt geladen. Wat is nu een acceptabel tijdsbestek? Aanvaardbaar voor wie. We moeten dus het niet-toetsbare argument omzetten in een toetsbaar argument, dat specifiek vertelt over welke pagina we het hebben over “studenten registreren en cursuspagina's inschrijven” en ook het acceptabele tijdsbestek wordt gegeven, namelijk 5 seconden.
Conclusie
Dus dit is hoe we naar elke vereiste op het juiste niveau moeten kijken. Bijvoorbeeld, als we software gaan bouwen met betrekking tot systeem- en integratievereisten. We moeten kijken naar systeem- en integratievereisten die in de softwarevereistenspecificaties of gebruikersverhalen staan en deze toepassen op elke vereistekwaliteit. Controleer vervolgens of elke vereiste atomisch, uniek geïdentificeerd en compleet is, enzovoort.
