Mastering the Requirements Process (Second Edition)
Suzanne Robertson, James Robertson
Addison-Wesley Professional, 2006
ISBN: 978-0-321-41949-1
592 pagina's
In de loop van een project blijkt vaak dat nog niet helemaal duidelijk is wat nou precies de eisen zijn voor het eindproduct. We willen een systeem voor X, maar waar moet dat systeem precies aan voldoen? Wie moet het gebruiken? Wat moeten ze er mee kunnen doen? Wat zijn de randvoorwaarden?
Daarmee loop je het risico dat het eindproduct toch niet is wat de opdrachtgever er van verwachtte. Of dat de gebruikers er niet beter of sneller mee kunnen werken dan met wat er al was.
Uiteraard zijn er methodes ontwikkeld om die eisen (oftewel de requirements) vooraf zo goed mogelijk boven tafel te krijgen.
Eén zo'n methode wordt beschreven in het onderhavige boek.
In 15 hoofdstukken, plus 4 uitgebreide appendices, komen het hele proces aan de orde; van de "project blastoff" tot en met het moment dat de requirements voldoende compleet zijn om aan de ontwikkelaars te geven.
Een korte samenvatting:
Hoofdstuk 1. What are requirements?
Inleiding en het een en ander over het "Volere Requirements Process" (waar dit boek op gebaseerd is)
Hoofdstuk 2. The requirements process
Een overzicht van het proces.
Daarbij worden drie soorten projecten onderscheiden, gebaseerd op de mate van formaliteit.
Hoofdstuk 3. Project blastoff
Aan het begin van het project wil je een ruw beeld hebben van wat het eindproduct moet gaan doen en wie de "stakeholders" zijn.
Daarbij is het ook van belang te weten wat er wel en niet bij hoort. Bijvoorbeeld:
als je eindproduct gebruik gaat maken van een bestaand systeem, vallen eventuele wijzigingen of uitbreidingen van dat systeem ook bij je project?
Overigens kan dit ook in de voorfase van het project al gebeuren, als je eerst wil weten of een project wel uitvoerbaar is.
Hoofdstuk 4. Event-driven use cases
Hierin wordt het schrijven van use cases behandeld. "Event driven" wil zeggen: er komt een signaal bij je product
(dat kan een handeling van een gebruiker zijn of een automatisch signaal) en je product reageert daarop.
Hoofdstuk 5. Trawling for requirements
Het is lang niet altijd voldoende om mensen alleen te vragen wat ze willen.
Je mist dan bijvoorbeeld dingen die zij vanzelfsprekend vinden, maar anderen niet.
Daarom worden in dit hoofdstuk diverse technieken besproken om requirements te ontdekken.
Hoofdstuk 6. Scenarios and requirements
Scenarios zijn ook een methode om requirements te ontdekken. Het zijn gedetailleerde uitwerkingen van use cases: wat moet er precies gebeuren? Wat zijn de voorwaarden vooraf? Wat is het eindresultaat van deze use case? Daarbij kan ook naar boven komen dat een use case bestaat uit een stukje "te maken product" en een stukje "bestaat al".
Lang niet alles wat in zo'n scenario staat hoeft dus terug te komen in je eindproduct.
Hoofdstuk 7. Functional requirements
In de "functional requirements" beschrijf je wat je product moet doen om een scenario uit te voeren. Deze requirements kun je vastleggen in data- of domeinmodellen.
NB: in deze fase kijk je nog niet naar de techniek. Je modellen zullen dus niet één-op-één vertaald kunnen worden naar een programmeertaal.
Hoofdstuk 8. Nonfunctional requirements
De "niet-funtionele" requirements beschrijven niet wat je product moet doen, maar hoe goed. Denk aan dingen als: het moet er begrijpelijk uitzien; het moet snel zijn; het moet werken op een standaard computer binnen deze organisatie.
Hoofdstuk 9: Fit criteria
Je hebt nu een heel stel eisen, maar die zijn lang niet altijd SMART geformuleerd. Zie het voorbeeld hierboven: het moet er begrijpelijk uitzien, maar hoe meet je dat?
De belangrijkste les uit dit hoofdstuk is: elk requirement is meetbaar te maken. Zo kun je voor "er begrijpelijk uitzien" stellen "bij een gebruikersonderzoek geeft 90% van de gebruikers aan dat het er begrijpelijk uit ziet".
Vergeet ook niet om hierbij collega's te betrekken die ervaring hebben met testen en gebruikersonderzoeken.
Hoofdstuk 10. Writing the requirements
Hoe schrijf je je requirements zodanig op dat je er ook echt wat aan hebt?
De stakeholders moeten het er mee eens zijn, de ontwikkelaars moeten ze begrijpen en je wilt ook graag een manier om straks bij te houden hoe het staat met de implementatie.
In bijlage B van het boek staat een "requirements specification template" om je op weg te helpen.
Hoofdstuk 11. The quality gateway
Het is een goed idee om de requirements nog eens kritisch te laten bekijken voordat je verder gaat. De kwaliteitscontroleur kijkt naar dingen als "zijn de requirements compleet", "zijn ze onderling consistent", "is dit uitvoerbaar". Ook is het belangrijk om te controleren dat het echt requirements zijn en niet al oplossingen. Een requirement mag wel zijn "het moet werken op mobiele apparaten", maar niet "we gaan een iPhone app maken".
En de kwaliteitscontroleur kijkt of er geen requirements zijn ingeslopen die buiten de scope vallen van wat er in het begin van het project is afgesproken.
Hoofdstuk 12. Prototyping the requirements
Je maakt een prototype op basis van de requirements die je hebt en laat stakeholders daar naar kijken. De kans is groot dat je daarmee nog meer requirements ontdekt. Bijvoorbeeld "je moet hier ook kunnen zoeken" of "je doet hier alsof X altijd voor Y komt, maar in praktijk komt Y ook vaak voor X".
Het moge duidelijk zijn dat dat weer leidt tot aanpassingen van je requirements documenten.
Hoofdstuk 13. Reusing requirements
Veel requirements komen steeds weer terug en zijn dus herbruikbaar. Als je bijvoorbeeld vaak back-office systemen maakt, dan weet je al voor wat voor welke gebruikers het is en wat de technische grenzen zijn ("moet kunnen werken op onze bestaande computers").
Hoofdstuk 14. Reviewing the specification
Op een gegeven moment heb je een stel requirements waar je wat mee kunt. De kwaliteitscontroleur heeft ze goedgekeurd en de ontwikkelaars willen er mee aan de gang. Dat is het moment om prioriteiten te gaan stellen. Welke requirements moeten
als eerste geïmplementeerd worden? Zijn er geen requirements die elkaar in de weg gaan zitten?
De projectleider zal ook willen weten hoeveel tijd en geld het zal gaan kosten om het product te maken en wat ongeveer de planning zal worden.
Bij sommige requirements zul je risico's ontdekt hebben. De stakeholders willen iets heel graag, maar het is nog niet duidelijk of het mogelijk is. Ook die wil de projectleider dan graag weten.
De risico's, kosten en urenschatting kunnen weer aanleiding zijn om de requirements nog aan te passen.
En in het uiterste geval kan op dit punt nog worden besloten om het project toch maar niet voort te zetten, omdat het niet mogelijk zal zijn om iets te maken wat aan de eisen voldoet.
Hoofdstuk 15. Whither requirements
De auteurs beseffen dat het opstellen van goede requirements niet een kwestie is van simpelweg alle stappen uitvoeren die in de voorgaande hoofdstukken zijn beschreven. In dit laatste hoofdstuk geven ze tips over hoe je het proces kunt aanpassen aan je eigen project, wat voor tools je kunt gebruiken en hoe je om kunt gaan met de onvermijdelijk veranderingen in de requirements.
In de bijlagen vind je tenslotte:
Volere Requirements Process Model
Volere Requirements Specification Template (handig als checklist)
Function Point Counting (een manier om urenschattingen te maken)
Project Sociology Analysis Templates (hoe weet ik wie de stakeholders zijn?)
Na lezing van dit boek hebben we een aardig idee van hoe onze projecten nog beter kunnen worden. Het is dan wel van belang dat er in het project ook tijd gereserveerd wordt voor het ontdekken en uitwerken van de requirements.
Geen opmerkingen:
Een reactie posten