SISp 2.3 Activiteiten vaststellen requirements

Iedere fase binnen de SISP methode bestaat uit een aantal activiteiten. De fase ‘Vaststellen requirements’  bevat de volgende activiteiten.

Activiteiten:

1. Verzamel bestaande informatie.
2. Breng structuur aan.
3. Verzamel nieuwe informatie & leg vast.
4. Check op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid
5. Evalueer & maak definitief

 Activiteit 1: Verzamel bestaande informatie

Een deel van de informatie die we nodig hebben is aanwezig in het projectplan:
* Lijst met projectaannames
* Doelstelling en resultaat
* Afbakening / scope in het projectplan
* Communicatieplan
Haal één of meerdere business requirements uit bovenstaande informatie.  Verifieer deze nogmaals bij opdrachtgever en management. Vul deze aan of deel op in meerdere business requirements als dat mogelijk is.
In de loop van deze fase is het mogelijk dat er user requirements worden neergelegd die niet naar een business requirement zijn te herleiden. Dan is het wenselijk om te bespreken of er business requirements moeten worden aangevuld.

Activiteit 2: Breng structuur aan

Om straks een helder overzicht te hebben en te houden van de verzamelde requirements is het van belang goed te documenteren. Zorg ervoor dat de eisen van de business, user en system gescheiden worden opgeslagen.
Leg minimaal onderstaande gegevens vast;
– Volgnummer
– Soort requirement (business, user, software)
– Categorie (functioneel – niet functioneel)
– Datum, versie, auteur
– Bron (dit kunnen meerdere belanghebbende betreffen)
– Fase (fase waarin de eis is geformuleerd)
– Beschrijving eis
– Prioriteit (eis, wens)
– Verwijzing naar volgnummer betrokken business requirement?
–  Verwijzing naar volgnummer betrokken user requirement?
De belanghebbende van dit project zijn gedefinieerd in het communicatieplan. Maak daar gebruik van. Verzamel deze groep en documenteer ze apart in een document ‘Stakeholders’ waarbij de volgende rubrieken minimaal worden opgenomen;
– Naam, afdeling, telefoonnummer
– Soort belanghebbende (gebruiker, super gebruikers, beheerder, beslisser, materiedeskundige)

Activiteit 3: Verzamel nieuwe informatie & leg vast

De informatie die in het project plan is opgenomen is voldoende om een begin te maken aan de business requirements, dit is vaak niet specifiek genoeg, vul deze als mogelijk verder aan.
Dan zijn de user & software requirements aan de beurt. Deels kunnen deze uit de lijst met projectaannames gehaald worden, maar verdere specificering is in deze fase heel belangrijk.
Hoe ga je te werk?
Er zijn afhankelijk van de project grootte een aantal methode om deze informatie boven tafel te krijgen.
* Analyseer het proces dat met het software pakket moet worden ondersteund.
* Wat doet het huidige software pakket? Het pakket dat moet worden vervangen.
* Interview de gebruikers, beheerders (zowel functioneel als technisch) en de systeem/proces eigenaar.
* Interview de overige belanghebbende.
* Gebruik mail om bepaalde vragen breed uit te zetten.
* Organiseer een workshop.
* Informeer en ga langs bij zuster organisaties die voor hetzelfde doel een oplossing/systeem hebben draaien.
Voor elke eis moet zeker zijn dat deze specifiek, meetbaar en ondubbelzinnig is. Denk aan de condities die vervuld moeten zijn om aan te tonen dat de eis is gehaald. Zorg dat je de eisen zo beschrijft dat iedereen er dezelfde betekenis aan geeft. Voor elke eis moet je weten welke waarde de klant/business er aan toekent om vast te stellen waar hij zonder kan en welke absoluut noodzakelijk zijn.
Use cases.
Soms kan het verhelderend zijn om requirements schematisch weer te geven. Hiervoor kan gebruik worden gemaakt van use cases. Het is ook een manier om het overzicht te bewaren. Een voorbeeld van een use case voor de hoofdfunctionaliteiten van een webshop:

Activiteit 4: Check op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid

Valideer je verzamelde eisen regelmatig. Daarbij kunnen de volgende vragen gesteld worden.
=> Is deze eis te herleiden naar een business requirement? Zo nee, dan is dit geen eis, of moet er een business eis worden toegevoegd.
=> Is de eis (of zijn de eisen) juist en volledig? Dit kan worden onderzocht door andere belanghebbende te bevragen over dit onderwerp.
=> Wat is de prioriteit van deze eis? Is het een harde eis of een wens?
=> Is de eis haalbaar. Dit kan zowel vanuit een technisch- of financieel oogpunt worden benaderd.
Afhankelijk van de uitkomst kan het zijn dat er sommige eisen vervallen of worden aangepast.
Er bestaan checklists die je kan gebruiken voor specifieke requirements. Zie hiervoor de volgende links:

Activiteit 5: Evalueer

In het projectplan staat wie zijn aangesteld om de requirements te beoordelen. Verspreid de concept documenten onder de reviewers en iedereen die betrokken is geweest bij het verzamelen van de requirements . Geef ze ruim de tijd voor de beoordeling en verzamel de opmerkingen en vragen. Zorg dat deze allemaal zorgvuldig worden bekeken en voer eventuele wijzigingen door. Communiceer de aanpassing en maak de documenten definitief.

Boeken over dit onderwerp

Handboek requirements

Auteur: Nicole de Swart
Iedereen die te maken heeft met softwareontwikkeling kent het spanningsveld tussen business en ICT. Requirements zijn daarbij een kritieke succesfactor. Hoe krijgt u de juiste requirements boven water? Hoe managed u de verwachtingen van de business? Hoe legt u de requirements eenduidig vast? Hoe voorkomt u scope creep? Deze en andere vragen staan in het ‘Handboek Requirements’ centraal.
Europrijs: 42,95
Bestellen

Requirements Engineering Fundamentals

Auteur: Klaus Pohl
The 2nd edition has been thoroughly revised and is aligned with the curriculum Version 2.2 of the IREB. In addition, some minor corrections to the 1st edition have been included.

Europrijs: 26,5
Bestellen

Meer boeken over informatie analyse vinden.


-- Printbare PDF-versie --


Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten: Geen
Sidebar