Requirements engineer
De Requirements engineer haalt op wat het systeem moet doen en legt dat vast als een samenhangende set use cases en aanvullende specificaties waarover opdrachtgever, gebruikers en realisatieteam het eens zijn.
Beschrijving
De Requirements engineer is verantwoordelijk voor de volledigheid, samenhang en toetsbaarheid van de eisen aan het systeem. De rol bedenkt die eisen niet zelf, maar haalt ze op bij de stakeholders, ordent ze rond het gebruik van het systeem en legt ze zo vast dat er later niet over te twisten valt wat er bedoeld werd.
Het zwaartepunt van de rol ligt bij het gesprek, niet bij het document. Stakeholders spreken in oplossingen, in gewoontes en in aannames die zij zelf niet meer als aanname herkennen. De Requirements engineer werkt daar doorheen naar het onderliggende resultaat dat zij willen bereiken, maakt tegenstrijdigheden tussen stakeholders zichtbaar in plaats van ze glad te strijken, en legt de afweging terug bij degenen die haar mogen maken.
Daarbij bewaakt de rol voortdurend de omvang van het werk: het use-casemodel is niet alleen een overzicht van wat het systeem doet, maar ook de begrenzing van wat het niet doet. En de rol bewaakt het detailniveau — er wordt uitgeschreven zolang dat onzekerheid wegneemt en niet langer, zodat de specificaties niet dichtgroeien met werk dat niemand leest.
De Requirements engineer werkt nauw samen met de architectuureigenaar, die uit de use cases en de aanvullende specificaties de architectuurbepalende eisen selecteert, en met het realisatieteam en de testers, die op de specificaties verder bouwen.
Competenties
Wie deze competentie heeft, haalt de behoeften van andere stakeholders op, brengt ze onder woorden, weegt ze tegen elkaar af, en vertegenwoordigt hun standpunten getrouw.
Analyse omvat het doorgronden van de uitdaging en de stakeholderbehoeften die daarbij horen, en het omzetten daarvan in een consistente requirementset waarover overeenstemming bestaat. Wie deze competentie beheerst, levert bovendien input voor ontwerpbeslissingen tijdens het bouwen van het systeem.
Bij Development gaat het om het ontwerpen en realiseren van systemen die goed werken, en dat binnen de kaders van de standaarden en normen die het team samen heeft afgesproken.
Testen is het vermogen om een systeem te beproeven: zowel valideren — voldoet het aan wat gebruikers nodig hebben — als verifiëren — voldoet het aan de vastgelegde requirements.
Leiderschap is het vermogen om een team zodanig te inspireren en te motiveren dat het zijn werk succesvol afrondt en de gestelde doelen haalt.
Management draait om het plannen, coördineren en volgen van het werk dat een team verzet.
Activiteiten
Identificeer actoren en use cases
Brengt in kaart wie het systeem gebruikt en welk waardevol resultaat zij ermee willen bereiken, en legt daarmee de systeemgrens en de omvang van het werk vast.
Specificeer use cases
Werkt de use cases die ertoe doen uit tot een specificatie met het hoofdscenario en de afwijkingen daarop, en legt de eisen die niet aan één use case toebehoren vast in de aanvullende specificaties.
Verantwoordelijk voor
Aanvullende specificaties
De eisen die niet aan één use case zijn toe te wijzen: kwaliteitseisen, wettelijke verplichtingen en ontwerpbeperkingen die voor het systeem als geheel gelden.
Use-casemodel
Het overzicht van alle actoren en use cases van het systeem, met per use case alleen een naam en het beoogde resultaat — het werkproduct dat de systeemgrens en de omvang van het werk begrenst.
Use-casespecificatie
De uitwerking van één use case: het hoofdscenario van interactie tussen actor en systeem, de afwijkingen daarop, en de voorwaarden en regels die daarbij gelden.