Requirements management, is dat nog wel van toepassing als je websites en intranetten maakt met een standaardproduct als SharePoint? Ja, het blijft belangrijk, maar kies wel een vorm die past bij je project. Het doel van requirements management is immers niet om bureaucratie te genereren, maar om je project in de hand te houden én om te zorgen dat de gebruikers krijgen wat ze nodig hebben. Anders vliegen de enthousiaste teamleden en hun ad hoc oplossingen je om de oren.
Het doel van requirements management is immers niet om bureaucratie te genereren …
Needs, features en requirements
Bij het ontwikkelen van een systeem moet je natuurlijk eerst bepalen wat eigenlijk het doel is. Wie zijn de beoogde gebruikers en waar hebben die behoefte aan: wat zijn hun needs? Vervolgens zoek je uit welke features aan die gebruikersbehoeften kunnen voldoen. En dan werk je in de requirements uit hoe dat moet functioneren.
Wie zijn de gebruikers en andere stakeholders?
Aangezien we een systeem maken voor gebruikers, moet je zo snel mogelijk een duidelijk beeld krijgen van die gebruikers. Wat voor mensen zijn dat, in wat voor situatie zitten ze, wat hebben ze tot hun beschikking en hoe voeren ze hun taken uit? Hoe doen ze b.v. hun werk, als je het hebt over een intranet?
Naast de gebruikers zijn er ook andere stakeholders, zoals aandeelhouders en helpdesk-medewerkers, die niet direct gebruik maken van het systeem, maar die er b.v. wel baat bij hebben als anderen dat goed doen.
Een handig hulpmiddel om grip te krijgen op de gebruikers zijn personas
Een handig hulpmiddel om grip te krijgen op de gebruikers zijn personas: de personificatie van belangrijke gebruikersgroepen. Je baseert die personas op gegevens over doelgroepen en gebruikersstatistieken. En je geeft ze een verhaal, zodat iedereen zich gemakkelijk kan verplaatsen in die persona bij het bedenken en toetsen van slimme oplossingen. Een voorbeeld: Jantien Smit is een ervaren sales-medewerker die veel onderweg is. Dat geeft haar een heel ander perspectief dan Pieter de Vries, die net begonnen is bij HR.
Schrijf dus op wie de stakeholders zijn, en schrijf ze uit als als personas wanneer je aan een systeem werkt waarbij gebruikersvriendelijkheid erg belangrijk is.
Fig.1: Needs, features en requirements
Needs: wat hebben ze nodig?
Wat hebben die gebruikers die je hebt geïdentificeerd nodig? Eeen voorbeeld kan zijn dat “de medewerkers van het bedrijf op de hoogte willen blijven van de laatste ontwikkelingen over de reorganisatie”.
Ik vind het soms best lastig om samen met mijn opdrachtgever te bepalen wat eigenlijk de needs zijn van de gebruikers, omdat iedereen liever in termen van features praat. Je hoort dan “we willen een blog voor de directie op ons intranet”. Maar wie wil dat eigenlijk en waarom? Omdat iemand dat cool en web 2.0 vindt? Of omdat de medewerkers het belangrijk vinden om op de hoogte te blijven en te kunnen reageren, terwijl de directie eigenlijk helemaal geen tijd heeft voor het schrijven van blogs? Of omdat de directeurs het belangrijk vinden om ideeën te delen met de medewerkers en daar ook feedback op te krijgen? En waarom wil de directie dit? Om een gevoel van betrokkenheid te creëren? Om goede ideeën te verzamelen?
Je zit goed als je belandt bij een need die is geënt op een business case, b.v. “die betrokkenheid vermindert het verloop en bespaart zo wervingskosten en inwerktijd, en de feedback vervangt de inhuur van een extern bureau”.
Maak daarom een overzicht van de needs, en vermeld daarbij de gebruiker (of algemener: de stakeholder) die deze need heeft. En dit mag een simpel lijstje zijn …
Features: wat moet het systeem dus bieden?
Als je weet wat de gebruiker nodig heeft, bedenk je welke functionaliteit voldoet aan deze eisen en wensen. Dit is de overstap van het probleemdomein naar het oplossingsdomein. Iedere feature die je bedenkt is een antwoord op een van de geformuleerde needs. Als gebruikers b.v. op de hoogte willen blijven van de nieuwste ontwikkelingen op een bepaald gebied, kun je een pagina maken met een overzicht van de laatste informatie, een nieuwsbrief aanbieden, en notificaties mogelijk maken.
Maak dus een overzicht van de features en zet bij iedere feature bij welke need hij hoort. Je kunt gewoon een lijst maken, maar ook een diagram waarin je onderlinge afhankelijkheden uitdrukt, als die belangrijk zijn. Ik zet ze zelf graag in een lijst op een projectsite in SharePoint.
PS: Ik gebruik de term ‘feature’ hier in de betekening van ‘functionaliteit’, zoals dat ook gebeurt in het Rational Unified Process. Dus niet in de technische zin, als de features die je b.v. in SharePoint kunt definiëren in XML.
Requirements: hoe moet het dan werken?
De globale features werk je uit in gedetailleerde requirements. Een veelgebruikte definitie van requirement is “a software capability needed by the user to solve a problem to achieve an objective” [Leffingwell en Widrig, 2000]. Ze geven als tweede optie dat de software-capability moet voldoen aan een contract, standaard of zo iets formeels, maar ik leg de nadruk liever op de gebruiker.
Als b.v. een nieuwsbrief een van de features is, dan staat in de requirements dat de gebruiker een abonnement op de nieuwsbrief moet kunnen nemen, veranderen en opzeggen, en bovendien dat hij moet inloggen om dat allemaal te doen. Dit zijn functional requirements. Ieder van deze requirements is als het goed is geassocieerd met een feature en daarmee ook met een need, dus je weet waarom je die requirement realiseert: om aan die gebruikerswens te voldoen.
De functional requirements worden ondersteund door non-functional requirements: randvoorwaarden of kwaliteitseisen los van directe gebruikersfunctionaliteit. Voorbeelden zijn performance, veiligheid en gebruiksvriendelijkheid, maar ook zaken als beheerbaarheid en schaalbaarheid.
Maak dus een overzicht van functional requirements, gegroepeerd op de feature waar ze bij horen, en een overzicht van de non-functional requirements.
De requirements beheren
Hoe groter en complexer je project en je systeem, des te belangrijker wordt het dat je de verzamelde requirements actief beheert. Leffingwell en Widrig definiëren requirements management als een systematische aanpak om de requirements van het system te achterhalen, organiseren en documenteren, en een proces om overeenstemming tussen de klant en het projectteam te verkrijgen en behouden over de veranderingen in de requirements van het systeem. [Leffingwell en Widrig, 2000]
“Requirements management gaat niet over het gebruik van geavanceerde tools”
Proces: wie doet wat en hoe?
Requirements management gaat niet over het gebruik van geavanceerde tools. Het gaat erom dat je achterhaalt en bijhoudt welke functionaliteit je moet ontwikkelen en wat de status daarvan is, en dat de opdrachtgever en het team hiervan hetzelfde beeld hebben. In je projectaanpak spreek je af hoe je omgaat met de requirements. Wie doet wat in de levenscyclus van de requirements: hoe leg je ze vast, wie moet ze langs welke weg goedkeuren, enz.
Daarbij kun je natuurlijk allerlei tools gebruiken, vooral als je een langlopend project doet met veel requirements. Een voorbeeld van een tool waarin je je proces kunt beheren is Eclipse. Je definieert alle elementen van je standaardproces en geeft er de benodigde instructies en templates bij. En aan het begin van je project maak je je proces specifiek door b.v. in te vullen wie de gedefinieerde rollen op zich neemt.
Ook als je agile werkt en Scrum kiest als proces, kom je niet om requirements heen, al schrijf je die niet in detail uit. Tijdens een korte sprintje in Scrum zijn die requirements bevroren; aan het einde van dat sprintje kijk je of het toch anders moet.
Fig.2: Het proces vastleggen in Eclipse
Scope en prioriteit: wat doen we nu eerst?
Vanaf het begin stel je met de opdrachtgever vast wat de scope van je project is: welke needs adresseer je wel en welke (nog) niet, welke features ga je daarvoor maken, en welke requirements moet je dus realiseren? Als je bepaalde needs wel besproken hebt, maar ze niet binnen de scope van dit project passen, schrijf dat dan op. En stel vast welke prioriteit de requirements krijgen, zodat je weet welke eventueel kunnen vervallen voor deze versie van het systeem.
Overwegingen bij het bepalen van de scope en de prioriteiten zijn bijvoorbeeld: hoe belangrijk en urgent is de gebruikerswens, zijn andere features afhankelijk van deze, hoe tijdrovend en riskant is de realisatie?
Neem dus in de lijsten van need, features en requirements op of ze in de scope zitten en wat hun prioriteit is.
Neem dus in de lijsten van need, features en requirements op of ze in de scope zitten en wat hun prioriteit is.
Requirements vastleggen: use cases, wireframes en prototype screenshots
In maatwerkprojecten leg ik requirements vaak vast in use cases (Unified Modeling Language). Daarin beschrijf ik per functionele eenheid stap voor stap de specificatie van wat de gebruiker doet, b.v. voor het geval waaarin hij een nieuwsbriefabonnement aanvraagt. Dat kan gewoon in tekst in een gestructureerd Word document, met afbeeldingen van schermen en eventueel diagrammen, als de flow ingewikkeld is. Sinds ik SharePoint projectsites tot mijn beschikking heb, zet ik die documenten in de projectsite, evt. gekoppeld aan een lijst met alle use cases, om documenten over dezelfde requirements bij elkaar te houden. En straks hebben we ook de nieuwe modelleertaal M en de tool Quadrant tot onze beschikking.
Wireframes zijn handig om de requirements vast te leggen voor systemen waarin schermen belangrijker zijn dan functionele eenheden waarin de gebruiker een aantal stappen moet doorlopen. In een wireframe schets je welke elementen waar op de pagina’s moeten staan. Je kunt wireframes overal in tekenen, maar Axure is een tool die het gemakkelijk maakt om ze te maken en beheren. Je hoeft bijvoorbeeld elementen die in verschillende wireframes staan slechts op één plek bij te houden.
De laatste tijd doe ik echter veel projecten waarin we SharePoint configureren, maar niets programmeren. Dan ga ik geen standaard functionaliteit uitschrijven in use cases. In die projecten klik ik meteen een prototype in elkaar. De opdrachtgevers zien in het prototype beter wat ik bedoel dan in een tekstdocument. Om hun beslissingen vast te leggen documenteer ik de functionaliteit en interface van het prototype in screenshots en lijstjes met instellingen. Als een collega op basis hiervan contenttypes en templates in XML-code gaat maken, dan zet ik instellingen in kopieerbare tabellen in Word of Excel. In de echt kleine projecten kan ik zelfs in het prototype de benodigde templates bakken.
Fig. 3: Een wireframe in Axure
Voortgang van de requirements: hoever zijn we?
Vooral als je systeem veel requirements heeft en er veel mensen in het team mee bezig zijn, is het belangrijk om goed bij te houden hoe het ermee staat: is de requirement uitgewerkt en goedgekeurd? Is hij gerealiseerd in het systeem en is dat getest, opgeleverd en geaccepteerd? En wie is er functioneel en technisch verantwoordelijk voor deze requirement?
Dus: hou de status van je requirements bij en geef bij een oplevering aan welke requirements daarin gerealiseerd zijn.
Tijdens het project zullen er altijd requirements veranderen
Veranderingen in requirements: beslissen, vastleggen en communiceren
Tijdens het project zullen er altijd requirements veranderen! De oorzaak kan zo triviaal zijn als een interpretatieverschil dat je strak moet trekken, maar een stakeholder kan voortschrijdend inzicht hebben. Of de omstandigheden veranderen, zoals bij een reorganisatie of een nieuwe wet die extra maatregelen vergt. Veranderingen zijn niet erg, mits je de requirements goed beheert en dus beheerst.
Een wijziging op een goedgekeurde requirement vergt zorgvuldig change management. Wat is de impact van de gewenste wijziging? Hoe belangrijk is zij? Op basis daarvan moet de opdrachtgever beslissen of de wijziging nu echt gewenst is, en kijkt het projectteam of de wijziging nu ook uitgevoerd kan worden. In een complexer project richt je voor deze beslissingen een Change Control Board in. En als de wijziging inderdaad doorgaat, zorg dan ook dat de uitvoerder en de tester weten wat de laatste versie is en wat ze dus precies moeten doen.
Een SharePoint projectsite helpt bij het beheren van de aangevraagde changes, en specificatiedocumenten en hun versies. De versie die daar staat is altijd de laatste. En je kunt een workflow opzetten voor de goedkeuring van de requirements.
Conclusie: bepaal de impact van de wijzigingen, besluit over de uitvoering, documenteer de besluiten en de wijzigingen, en communiceer ze goed naar alle betrokkenen.
Fig. 4: Voorbeeld van een dashboard voor requirements management in een SharePoint team site.
Traceability: iedere requirement heeft een traceerbare herkomst
Een van de kernwoorden het verhaal van requirements management is traceability: je moet de herkomst van iedere requirement kunnen traceren. Welke gebruikersbehoefte moet hij vervullen? Wie heeft dat gezegd en wat waren de overwegingen? Is er iets aan veranderd tijdens het project?
Je bouwt niets waarvoor niet duidelijk waarom het nodig is.
Je bouwt niets waarvoor niet duidelijk waarom het nodig is
Doordat je weet waar de requirement vandaan komt, kun je hem op waarde schatten en prioriteren. Als er iets verandert, weet je waar dat impact op heeft. En wanneer het systeem eenmaal in gebruik genomen is, kun je onderzoek naar het gebruik van het systeem in context plaatsen. Gebruikt niemand de functionaliteit? Dan toch eens kijken wat de onderliggende wens was en wat we nog meer gedaan hebben om aan die wens te voldoen.
Requirements management loopt door na de oplevering
Voor projectleden is de oplevering van een werkende site vaak het einde van hun inspanningen. Maar die site begint zijn leven pas. De gebruikers gaan ermee aan de slag, en die willen dan toch meer of iets anders.
Zolang iemand de site verder ontwikkelt, blijft requirements management nodig. Zelfs als je de vervolgstappen niet projectmatig neemt, en je geen budget hoeft te vragen voor wijzigingen. Wat krijg je anders? Je plaatst op verzoek van de ene gebruiker een knop, en een maand later vraagt een ander weer een andere knop. Je systeem loopt vol met onderdelen die niemand blijkt te gebruiken en waarvan niemand weet waarom ze er op staan. Maar ze zitten gebruikers wel in de weg. En de gebruiker moet steeds weer wennen aan nieuwe functionaliteit.
Dus:
- Kijk of de wijziging past in het interactieconcept, de bestaande structuur, de stijl;
- Bepaal voor iedere wijziging wat de onderliggende wens is en voor welke gebruikersgroepen het van belang is. Wat levert het op?
- Bepaal de impact van de wijziging voor andere gebruikers. Riskeren ze een overload of verwarring, oftewel wat kost het de gebruikers aan extra energie?
- Bepaal wat de impact is op het beheer. Kost het de beheerders extra energie of wordt het systeem instabieler?
- Besluit met de verantwoordelijken of je de wijziging doorvoert, en documenteer dit.
Releases
Wijzigingen die programmeerwerk en dus uitrol vergen, doe je in geplande releases. Wijzigingen die je kunt doorvoeren door de configuratie van een Sharepoint-site aan te passen hoeven niet per se in releases. Maar je kunt het wel zo insteken, als de configuratie-wijzigingen zo belangrijk zijn dat je ze expliciet moet communiceren naar de gebruikers, en dat je duidelijk de oude en de nieuwe versie wilt kunnen onderscheiden.
Governance: plan het intranetbeleid
Requirements management past in het bredere kader van governance. Met name in de context van intranetten krijgt dat onderwerp veel aandacht de laatste tijd. Organisaties hebben goed bestuur nodig, en dat geldt ook voor de intranetten die de organisaties ondersteunen. Niet alleen gedurende het ontwikkeltraject, maar juist ook nadat het live is gegaan. Het intranet is een levend systeem, dat de juiste kant op moet groeien. Dit vergt, zonder in te gaan op de meer technische aspecten, duidelijkheid over bijvoorbeeld:
- De geldende functional en non-functional requirements;
- Templates en richtlijnen voor het beheer van sites en content, in bijvoorbeeld een stijlgids en policies;
- Verantwoordelijkheden: Wie is bijvoorbeeld verantwoordelijk voor de navigatiestructuur, de best bets in de zoekfunctie, en de content op de verschillende plaatsen in de site? En hoe is dat precies geregeld, met stuurgroepen, redactieraden, goedkeuringsworkflows, champions en dergelijke?
- Wijzigingen: Gezien de verantwoordelijkheden, hoe gaan we om met wensen voor wijzigingen? Waar kunnen gebruikers feedback geven, hoe kunnen redacteurs wijzigingen aanvragen, en wie gaat daar op welke manier over besluiten? En wat zeggen de statistieken? Een site owner van een projectsite spreekt zijn gebruikers vaak en hij kan b.v. wijzigingen in zijn locale site-menu zelf doorvoeren, maar alleen het portal team mag een nieuwe knop op de portal-homepage zetten, na goedkeuring van de portal-eigenaar. En als de afdeling Financiën op hun afdelingsite een koppeling wil met een ander systeem, dan moeten ze de ontwikkeling daarvan zelf betalen.
- ‘Life cycle management’ van sites en content: hoe vraag je een nieuwe site aan, en wat gebeurt er met informatie die een jaar lang niet gewijzigd of gelezen is?
- De werking: trainingen, help en communicatie. Wie verzorgt de ondersteuning?
Maak een governance plan, waarin je de verantwoordelijkheden en processen rond wijzigingen vastlegt.
Conclusie
Requirements management is belangrijk tijdens het ontwikkeltraject en zolang je doorwerkt aan het levende systeem. Cruciaal is dat je niet zomaar wat bouwt, maar alleen requirements realiseert die gefundeerd zijn in gebruikerswensen. Daarvoor moet je altijd inzicht hebben in de gebruikers en hun wensen.
Je kunt lichtgewicht requirements management doen in eenvoudige projecten, aan de hand van simpele afspraken en lijstjes in bijvoorbeeld een projectsite, maar maak wel een plan voor de governance na oplevering. Requirements management zorgt dat alle kikkers in de kruiwagen doorrijden in de juiste richting, zelfs wanneer het pad de bocht om gaat vanwege voortschrijdend inzicht.
Referenties