Requirements engineering gaat over het definiëren, documenteren en onderhouden van requirements gedurende de levenscyclus van de ontwikkeling van een informatiesysteem. Requirements engineering is een iteratief proces. Eerst moeten de business requirements worden ontwikkeld en vastgesteld ('gebaselined'), vervoglens vormen de business requirements input voor het ontwikkelen van requirements op gebruikersniveau. Hierbij kan het nodig zijn de business requirements aan te vullen en/of verder te verfijnen.
Requirements engineering wordt onderverdeeld in: (1) requirements development, en (2) requirements management.
Requirements development omvat alle activiteiten voor het identificeren en vastleggen van requirement en het vervolgens bereiken van overeenstemming over de requirements.
Volgens De Swart is het doel van requirements engineering het tot stand brengen en in stand houden van overeenstemming tussen de opdrachtgever, medewerkers en de softwareontwikkelaars over de requirements. Requirements development richt zich op het tot stand brengen van de overeenstemming.
Requirements development omvat alle activiteiten die problemen, kansen en behoeften omzetten naar een overeengekomen set aan requirements, de zgn. baseline. Anders gezegd gaat het om de activiteiten die nodig zijn om nieuwe requirements aan de baseline toe te voegen. Het begint bij het in kaart brengen van globale requirements, waarna de requirements tot op het gewenst detailniveau worden gespecificeerd. De gedetailleerde requirements in de baseline dienen bij een waterval- of iteratief ontwikkeltraject als basis voor de realisatie van het systeem.
Bij het specificeren van requirements dreigt volgens De Swart altijd verlammingsgevaar (analysis paralysis): de specificaties van requirements zijn nooit perfect, het kan altijd beter, completer en duidelijker. Het risico is dus dat je té lang doorgaat met het perfectioneren van beschreven requirements. Requirements development streeft naar requirementsspecificaties die 'goed genoeg' zijn om met een aanvaardbaar risico te starten met het realiseren van het systeem. Het risico bestaat in dit verband uit de kosten voor en het uitvoeren van herstelwerkzaamheden bij fouten in reeds goedgekeurde specificaties. De kwaliteit van de requirementsspecificaties is hoog genoeg, zodra de kosten voor het nog verder verhogen van de kwaliteit van de requirementsspecificaties niet meer opwegen tegen de verwachte herstelkosten later in het traject.
Volgens De Swart zijn 'de requirements in de baseline namelijk niet in beton gegotenen geldt: "Hoewel de requirements in de baseline zijn goedgekeurd en misschien zelfs al zijn geïmplementeerd, zijn wijzigingen daarin onvermiijdelijk. Dit komt omdat de wereld niet stil staat tijdens de ontwikkeling van het systeem." Als gevolg van wijzigingen in de omgeving en voortschrijdend inzicht, zullen namelijk gedurende de gehele cyclus van softwareontwikkeling wijzigingen plaats (moeten) vinden. Requirements management omvat alle activiteiten die nodig zijn om wijzigingen in de specificaties van de requirements in de baseline door te voeren. Doel hiervan is het gecontroleerd laten plaatsvinden van wijzigingen. De activiteiten met betrekking tot het omgaan met wijzigingen op requirements die 'gebaselined' zijn: het doen van wijzigingsverzoeken, het uitvoeren van impactanalyses en de besluitvorming over en invoering van goedgekeurde wijzigingen.
De Swart onderscheid vier processtappen, met daarbinnen specifieke activiteiten
Requirements development
(1) Positioneren van het systeem binnen het businessdomein
- Analyseren van de business
- Zoeken van belanghebbenden en gesprekspartners
(2) Definiëren van de gewenste oplossing
- Vaststellen behoeften en eisen aan geautomatiseerde ondersteuning
- Selecteren belangrijkste kwaliteitseigenschappen
- Identificeren technische beperkingen
- Afbakenen systeem
(3) Detailleren van de requirements
- Vaststellen van door het systeem uit te voeren activiteiten
- Vaststellen van benodigde kwaliteitsniveau van het systeem
Volgens De Swart zijn bij elk van de drie processtappen binnen requirements development vier subgebieden nodig:
[i] Elicitatie (expliciet maken van requirements)
[ii] Analyse (onderzoeken requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid)
[iii] Specificatie (vastleggen van requirements, incl. meta-informatie)
[iv] Validatie (zekerstellen dat gespecificeerde requirements overeenkomen met behoeften van de business)
Requirements managmeent
(4) Beheren van de requirements
Volgens De Swart rust requirements management op vijf pijlers:
[a] Wijzigingsbeheer
[b] Versiebeheer
[c] Traceerbaarheid
[d] Metagegevens
[e] Managementoverzichten (inzicht in stand van de requirements in de baseline)
Bron: Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall), Handboek Requirements (2010), Nicole de Swart
