We hebben eerder de belangrijkste 4 activiteiten van requirements engineering besproken.

Requirements engineering is een proces van het verzamelen en definiëren van de diensten die door het systeem moeten worden geleverd.

Het richt zich op het beoordelen of het systeem nuttig is voor het bedrijf (haalbaarheidsstudie), het ontdekken van eisen (elicitatie en analyse), het omzetten van deze eisen in een of ander standaard formaat (specificatie), en het controleren of de eisen het systeem definiëren dat de klant wil (validatie).

In de praktijk is requirements engineering geen sequentieel proces, maar een iteratief proces waarin activiteiten door elkaar heen lopen.

Zo itereer je bijvoorbeeld eerst op de gebruikerseisen; elicitatie, specificatie en validatie, en herhaal je dezelfde stappen voor de systeemeisen.

In het begin van het proces zal de meeste inspanning worden besteed aan het begrijpen van high-level bedrijfs- en gebruikerseisen. Later in het proces zullen meer inspanningen worden besteed aan de elicitatie en het begrijpen van gedetailleerde systeemvereisten.

Sommigen beschouwen requirements engineering als het proces van het toepassen van gestructureerde analysemethoden, zoals objectgeoriënteerde analyse. Dit omvat het analyseren van het systeem en het ontwikkelen van een set van grafische systeemmodellen, zoals use case modellen, die vervolgens dienen als een systeem specificatie.

Hoewel gestructureerde methoden een rol te spelen in de requirements engineering proces, is er veel meer aan de requirements engineering dan die wordt gedekt door deze methoden.

Object-georiënteerde analyse en ontwerp zal worden besproken in een andere serie tutorials.

User and System Requirements

Typisch, eisen worden gepresenteerd in twee niveaus van detail; gebruiker en systeem eisen, waar de gebruiker behoefte heeft aan een high-level verklaringen van de eisen, terwijl systeemontwikkelaars een meer gedetailleerde systeemspecificatie nodig hebben. Dus, gebruiker en systeem eisen zijn gewoon verwijzen naar verschillende niveau van detail.

Having verschillende niveau van details is nuttig omdat het communiceert informatie over het systeem wordt ontwikkeld voor verschillende soorten lezers.

Dus, eindgebruikers zullen zich niet bezighouden met de details, zij hebben behoefte aan een generieke, geabstraheerde geschreven eis.

De mensen die bij de ontwikkeling betrokken zijn, hebben behoefte aan wat het systeem precies moet doen.

U zult waarschijnlijk op een hoop problemen en misverstanden stuiten als u geen duidelijke scheiding hebt aangebracht tussen de verschillende detailniveaus.

User Requirements

Het beschrijft de diensten die het systeem moet leveren en de randvoorwaarden waaronder het moet werken. We verwachten geen detailniveau te zien, of wat het systeem precies zal doen, het zijn meer generieke eisen.

Het is meestal geschreven in een natuurlijke taal en wordt geleverd door diagrammen.

We zullen later in deze serie verschillende manieren bespreken om de eisen te specificeren.

Systeemeisen

De systeemeisen zijn een meer gedetailleerde beschrijving van de systeemdiensten en de operationele randvoorwaarden, zoals de manier waarop het systeem zal worden gebruikt, en de ontwikkelingsrandvoorwaarden, zoals de programmeertalen.

Dit niveau van detail is nodig voor degenen die betrokken zijn bij de systeemontwikkeling, zoals ingenieurs, systeem architecten, testers, enz.

Functionele & Niet-functionele eisen

De software-eisen worden ingedeeld in functionele eisen en niet-functionele eisen.

Functionele eisen

Het omvat de belangrijkste functies die moeten worden verstrekt door het systeem. Wanneer uitgedrukt als gebruikerseis, worden zij gewoonlijk beschreven op een abstracte manier.

Hoewel, meer specifieke functionele systeemeis de systeemfuncties beschrijft, zijn inputs, verwerking; hoe het gaat reageren op een bepaalde input, en wat de verwachte output is.

Niet-functionele eisen

Dit zijn de beperkingen op de functies die door het systeem worden verstrekt.

De beperkingen, zoals hoeveel processen het systeem aankan (prestaties), wat zijn de (veiligheids)problemen waar het systeem voor moet zorgen, zoals SQL-injecties …

De mate van falen (betrouwbaarheid), welke talen en hulpmiddelen worden gebruikt (ontwikkeling), wat zijn de regels die u moet volgen om ervoor te zorgen dat het systeem binnen de wetten van de organisatie opereert (wetgeving).

Niet-functionele eisen zijn vaak kritischer dan de afzonderlijke functionele eisen. Gebruikers kunnen meestal manieren vinden om een systeemfunctie te omzeilen die niet echt aan hun behoeften voldoet. Het niet voldoen aan een niet-functionele eis kan echter betekenen dat het hele systeem onbruikbaar is.

Bijv. als een vliegtuig niet voldoet aan zijn betrouwbaarheidseisen, zal het niet veilig zijn voor gebruik, of als een ingebed besturingssysteem niet voldoet aan zijn prestatie-eisen, zullen de besturingsfuncties niet correct werken.

Niet-functionele eisen moeten meetbaar zijn

Wanneer mogelijk, moeten we niet-functionele eisen kwantitatief schrijven, zodat ze kunnen worden getest. Je kunt ze meten als het systeem getest wordt om te controleren of het systeem voldoet aan de niet-functionele eisen.

In de praktijk vinden afnemers van een systeem het vaak moeilijk om hun doelen te vertalen in meetbare eisen. Ze begrijpen niet wat een bepaald getal betekent voor de vereiste snelheid of betrouwbaarheid. Voor sommige doelen, zoals onderhoudbaarheid, zijn er geen metrieken die kunnen worden gebruikt.

De kosten van het verifiëren van meetbare niet-functionele eisen kunnen zeer hoog zijn en de afnemers denken misschien niet dat deze kosten gerechtvaardigd zijn.

Niet-functionele en functionele eisen zijn afhankelijk

Niet-functionele eisen conflicteren vaak, interacteren, of genereren zelfs andere functionele of niet-functionele eisen.

Een gebruikerseis die te maken heeft met veiligheid, zoals het beperken van toegang tot geautoriseerde gebruikers, kan andere eisen genereren die functioneel zijn, zoals de noodzaak om authenticatievoorzieningen voor gebruikers in het systeem op te nemen.

Het onderscheid tussen functionele en niet-functionele eisen

In de praktijk is het moeilijk om functionele en niet-functionele eisen te scheiden. Het onderscheid is niet duidelijk zoals hun definities suggereren.

Het onderscheid tussen functionele en niet-functionele eisen

Als de niet-functionele eisen apart van de functionele eisen worden vermeld, kan de relatie tussen hen moeilijk te begrijpen zijn.

Eisen die duidelijk verband houden met emergente systeemeigenschappen, zoals prestatie of betrouwbaarheid, moeten echter expliciet worden vermeld.

Emergente eigenschappen zijn eigenschappen van het systeem als geheel in plaats van eigenschappen die kunnen worden afgeleid uit de eigenschappen van de afzonderlijke systeemcomponenten.