• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements
Requirements
Het belang van requirements voor succesvolle ICT-projecten
Gepubliceerd in Requirements
E-mail Afdrukken

duivelsdriehoek tijd geld kwaliteit

In hun boek Precies volgens plan!, Succesvolle IT-projecten met heldere requirements gaan Mark Hoogveld, Jan Willem Knop en Marcel Schaar in op de relatie tussen heldere requirements en het succes van een IT-project. Hieronder een samenvatting van het eerste hoofdstuk.

Omdat bij informatie-intensieve organisaties de ict nauw verweven is met de bedrijfsvoering, hebben veranderingen in de ICT rechtstreeks invloed op de bedrijfsvoering van een organisatie. Grote veranderingen vinden veelal plaats middels programma’s en projecten. Een ICT-project is succesvol te noemen als het de informatievoorziening zodanig heeft veranderd dat deze de beoogde bijdrage aan de bedrijfsdoelstellingen levert. Randvoorwaarde is vanzelfsprekend dat deze bijdrage binnen de grenzen van tijd, geld en kwaliteit (inclusief de functionaliteit) gerealiseerd moet worden, de zgn. duivelsdriehoek.

Mark Hoogveld, Jan Willem Knop en Marcel Schaar baseren zich op Aart J. van Dijk, gepromoveerd op een onderzoek naar succes- en faalfactoren bij ict-projecten, die een project als succesvol definieert wanneer geldt dat het doel van de verandering wordt bereikt door (a) realisatie van de afgesproken kwaliteit (inclusief functionaliteit); (b) de geplande doorlooptijd met maximaal 50 procent wordt overschreden, geaccordeerde scopewijzigingen uitgezonderd; en (c) de kosten voor de verandering met maximaal 50 procent worden overschreden, geaccordeerde scopewijzigingen uitgezonderd (‘overrun’).

Volgens Van Dijk zijn er zeven aspecten van IT-projecten die bepalend zijn voor een succesvolle afloop, de zgn. Big Hitters:

  1. Goed projectmanagement

  2. Realistische deadlines

  3. Goede communicatie

  4. Sterk en compleet requirementsdocument

  5. Voldoende betrokkenheid van toekomstige gebruikers

  6. Betrokkenheid en commitment van senior management

  7. Voldoende professionaliteit (professionals)

Van Dijk stelt: “[g]eef aandacht aan deze Big Hitters en je maakt grote kans op een succes, verwaarloos er één van, en de kans dat je project niet succesvol wordt is haast een zekerheid.” Requirements worden niet alleen expliciet genoemd als 4e Big Hitter, maar bovendien geldt dat ze ook een cruciale rol spelen bij alle andere Big Hitters.

Volgens Hoogveld, Knop en Schaar zijn er drie pijlers van belang bij het goed (kunnen) beschrijven van requirements:

  1. Belanghebbenden

  2. Kwaliteit

  3. Context

Pijlers requirements succesvol it-project

Ad (1) Belanghebbenden
Hoogveld, Knop en Schaar definëren requirements als de eisen die belanghebbenden stellen ten aanzien van een product. Dit kan een fysiek product zijn, maar ook een dienst, organisatie, proces, functionaliteit of systeem. Requirements zijn niets anders dan een communicatiemiddel, een gezamenlijk vastgelegd referentiekader. Binnen een project stellen requirements een projectteam in staat om een eindproduct te realiseren dat voldoet aan de eisen van de belanghebbenden. Om aantoonbaar te maken dat het eindproduct voldoet aan de requirements geven de belanghebbenden aan welke requirements zij dermate belangrijk vinden, dat ze in het eindproduct gecontroleerd moeten worden om tot acceptatie over te kunnen gaan. Deze requirements noemen we acceptatiecriteria .

Belanghebbenden zijn in te delen in drie groepen:
• huidige belanghebbenden;
• toekomstige belanghebbenden;
• transitiebelanghebbenden (projectbelanghebbenden).

Ad (2) Kwaliteit (inclusief functionaliteit )
Requirements omschrijven de eisen aan het eindresultaat; wanneer is het product, in de ogen van de belanghebbenden, goed genoeg? Ze definiëren de kwaliteit. De kwaliteitseisen zijn meestal afgeleiden van de algemene kwaliteitseigenschappen die producten kunnen hebben. Zoals bijvoorbeeld functionaliteit, veiligheid, robuustheid, gebruikersvriendelijkheid, et cetera.

Ad (3) Context
De werkelijke invulling van kwaliteitseigenschappen moet samen met belanghebbenden worden gedaan en de kwaliteitseigenschappen krijgen een specifieke betekenis binnen de context van het product. “In de context van het ontwikkelen van een informatiesysteem kan de kwaliteitseigenschap ‘veiligheid’ bijvoorbeeld resulteren in het requirement ‘Onbevoegden
mogen geen toegang hebben tot het informatiesysteem’. Binnen de context van een gastank denken we veel meer aan explosiegevaar.”

Niveaus van requirements
In de praktijk worden requirements vaak verdeeld over vier niveaus:

niveaus requirements business user system

  1. Doelstelling: welke bedrijfsdoelstellingen wil het bedrijf realiseren?

  2. Business requirements: aan welke eisen moeten de organisatie en bedrijfsprocessen voldoen om de bedrijfsdoelstellingen te (kunnen) realiseren?

  3. User requirements: aan welke eisen moet een deelproces voldoen en wat zijn de bijbehorende functionaliteiten, bijvoorbeeld de marketing-, sales- of financiële processen van de organisatie?

  4. System requirements: aan welke eisen moeten de IT-systemen voldoen die de functionaliteiten moeten ondersteunen?

Requirements engeneering
Het voortbrengingsproces van requirements wordt requirements engineering genoemd.
Requirements engineering resulteert in vastgelegde en vastgestelde requirements.

Een van de werkpakketten in een projectplan is is het verzamelen van de wensen en eisen ten aanzien van de oplossing, eerst de user requirements en later de system requirements. Een requirements engineer krijgt als opdracht dit werkpakket uit te voeren. Een belangrijke eerste stap – na afstemming met de opdrachtgever over de opdracht en de scope, is het inventariseren van de belanghebbenden en hun belang, de belanghebbendenanalyse. De fase van het opstellen van requirements resulteert in een eisendocumt (‘programma van eisen’) dat ter goedkeuring wordt voorgelegd aan de belanghebbenden en de opdrachtgever.
De projectmanager neemt het resultaat van het werkpakket in ontvangst en tekent het af.
De goedgekeurde set requirements vormt de basis voor de volgende fasen van het project. Ze zijn het uitgangspunt voor analyses, ontwerpen, de te bouwen oplossing, de acceptatiecriteria ten behoeve van testen, et cetera. Binnen een project blijft de rol van de requirements engineer van belang bij het overdragen van requirements aan diegenen die deze nodig hebben voor het uitvoeren van hun werkpakketten. Verder beheert de requirements engineer de opgeleverde set van requirements om te borgen dat de uiteindelijke oplossing voldoet aan de eisen van de belanghebbenden en het resultaat bijdraagt aan de doelstelling van de opdrachtgever.

Requirements engineering precies volgens plan

Bron: Precies volgens plan!, Succesvolle IT-projecten met heldere requirements Mark Hoogveld, Jan Willem Knop, Marcel Schaar (pdf-versie Hoofdstuk 1: Succesvolle IT-projecten)

Laatst aangepast op zaterdag, 06 januari 2018 08:26  
Opstellen van requirements met de 4 B's
Gepubliceerd in Requirements
E-mail Afdrukken

opstellen requirements 4 B's

Bij het uitleggen van nut en noodzaak van requirements aan collega's ontstonden spontaan de 4 B's voor het opstellen van requirements:

  1. Betrek de belanghebbenden (stakeholders): "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution" (Alan M. Davis)

  2. Begrijp: probleem, behoefte.

  3. Beschrijf het 'WAT' (en dus niet het 'HOE'); oplossingvrij, eenduidg, identifcieerbaar én uniek.

  4. Beslis: valideren, prioriteren en autoriseren tót er een volledige set aan requirements is vastgelegd en vastgesteld.

Laatst aangepast op donderdag, 11 januari 2018 19:25  
Requirements volgens Leo Kouwenhoven en Joke Peek
Gepubliceerd in Requirements
E-mail Afdrukken

Requirements: bezint eer ge begint

Leo Kouwenhouven en Joke Peek beschrijven in het Computable-artikel "Requirements: bezint eer ge begint" de belangrijkste basics van requirements en gaan vooral in op de rol van stakeholder(s). Het artikel blijft wat mij betreft een beetje steken in algemeenheden, maar geeft wel goed inzicht in de complexiteit van het requirementsproces.

Het belang van requirements wordt ondersteund met een verwijzing naar het klassieke Chaos Report van de Standish Group en de stelling dat zonder goede requirements eigenlijk geen goede oplossing mogelijk is.

Requirements worden onderverdeeld in: functionele en niet-functionele requirements: "Functionele requirements zijn de eisen die de business aan de werking van het systeem stelt: wat moet het kunnen? Het gaat hier om functionaliteit die de organisatie in staat stelt haar werk te doen. De non-functional requirements beschrijven hoe het systeem moet werken en aan welke kwaliteitseisen het moet voldoen. Denk hierbij aan zaken zoals veiligheid, betrouwbaarheid, compliancy, compatibiliteit, beheerbaarheid en gebruikersvriendelijkheid."

Binnen het requirementsproces is het volgens Kouwenhoven en Peek belangrijk voldoende aandacht te besteden aan de rol van de stakeholders. De rol van de stakeholders is cruciaal bij het achterhalen en verifiëren van de requirements. Belangrijke aandachtspunten zijn verder dat de relevante stakeholders al vanaf het beginstadium bij een project worden betrokken en zich bewust is van zijn verantwoordelijkheden ('ownership' van de requirements en daarmee verantwoordelijk voor het uiteindelijke eindresultaat!).

Bij het achterhalen van de stakeholders via een zgn. stakeholderanalyse moet ook worden gekeken of de getraceerde stakeholders ook daadwerkelijk een goede vertegenwoordiging zijn van hun achterban (incl. mandaat) en of hij of zij beschikt over de juiste kennis en (communicatie)vaardigheden. "Die analyse moet tijdig uitgevoerd worden. Stel dat het traject onderweg is en je komt erachter dat de stakeholder stelselmatig de verkeerde input op de verkeerde gronden heeft geleverd, of dat hij alleen namens zichzelf spreekt; dan is veel kostbare tijd verloren gegaan en kun je eigenlijk opnieuw beginnen."

Kouwenhoven en Peek stellen dat bij de vaststelling van requirements stakeholders en requirements-engineers goed moeten (kunnen) samenwerken en beide partijen beschikken over de juiste vaardigheden. "En hoe goed de soft skills en hard skills van de requirements-engineers ook zijn, als de stakeholders niet hetzelfde niveau hebben wordt de vaststelling van de requirements een moeilijk verhaal. Dat is dan ook vaak de praktijk: stakeholders moeten meedoen in het requirements-proces, maar weten vaak niet wat er van hen wordt verwacht en wat ze van de requirements-engineers mogen verwachten. Opleiding kan stakeholders helpen hun verantwoordelijkheden duidelijk te maken, hun rol in te vullen en te voldoen aan de verwachtingen."

Volgens Kouwenhoven en Peek spreken requirements-engineers en stakeholders letterlijk een andere taal: "Onder requirements-engineers zelf bestaat vaak al onenigheid over het gebruikte jargon, laat staan dat de stakeholders aan kunnen sluiten op die taal van de requirements-engineers.
Het resultaat: aan de ene kant heb je de requirements-engineers die op technisch niveau precies weten hoe de vork in de steel zit, maar eigenlijk geen idee hebben van wat de stakeholders precies verwachten en willen; aan de andere kant de stakeholders die het ontbreekt aan kennis van het proces waar ze inzitten en die niet in staat zijn hun wensen en eisen op het juiste detailniveau aan de requirements-engineers over te brengen. (..) De requirements-engineer moet in staat zijn de ‘vraag achter de wens' van de stakeholder bloot te leggen, de requirements achter de gevraagde oplossing; de stakeholder moet ervan doordrongen zijn dat ook de niet uitgesproken requirement cruciaal kan zijn."

Kouwenhoven en Peek wijzen ook op het belang van een duidelijke scope van het project: "Wat beoogt de organisatie met de nieuwe oplossing? Aan de hand daarvan kun je bepalen welke requirements nodig zijn om dat doel te bereiken en welke niet. Het kan dan gebeuren dat stakeholders het moeten doen zonder allerlei nice to haves die misschien handig zijn, maar niet essentieel. Die scope ontbreekt vaak, laat staan dat het de stakeholders duidelijk is naar welk einddoel wordt toegewerkt. Stakeholders moeten met andere woorden de randvoorwaarden weten waarbinnen ze hun requirements kunnen formuleren. Dat verhoogt de kans op goede requirements."

Bron: Leo Kouwenhoven/Joke Peek, artikel "Requirements: bezint eer ge begint", Computable 29-07-2011

Laatst aangepast op donderdag, 11 januari 2018 19:32  
Wat maakt een goede business analist?
Gepubliceerd in Requirements
E-mail Afdrukken

Business analist

Volgens Guy Beauchamp is hét kenmerk van een goede business analist dat hij of zij beschikt over een analytische houding (analytical attitude). Deze houding heb je of je hebt het niet en is samen te vatten in: "Trust nothing, believe no-one, prove everything".

  1. Vertrouw niets (trust nothing): dingen zijn niet altijd wat het lijkt. Doe geen aannames, maar onderzoek waar het precies om gaat en of claims worden waargemaakt.

  2. Geloof niemand (believe no-one): het feit dat iets gezegd wordt door iemand met een hoge positie en/of veel materiekennis, maakt iets nog niet waar. Laat dingen bevestigen en valideer het tegen de andere informatie die je al hebt.

  3. Bewijs alles (prove everything): doe je al door niets en niemand bij voorbaat te vertrouwen en alleen conclusies te trekken op basis van feiten.

Bron: http://www.requirementsnetwork.com/node/1361

Laatst aangepast op donderdag, 11 januari 2018 19:33  
Weten wat je wilt
Gepubliceerd in Requirements
E-mail Afdrukken

citaat

I can teach anybody how to get what they want out of life. The problem is that I can't find anybody who can tell me what they want.

Mark Twain

Laatst aangepast op zondag, 28 januari 2018 09:07  
10 Stappen naar beter requirements management
Gepubliceerd in Requirements
E-mail Afdrukken

In de IBM's whitepaper "Ten steps to better requirements management" worden door Dominic Tavassoli de volgende 10 stappen beschreven die een organisatie helpen om beter requirements te definiëren en managen:

  1. Structureer de requirements: structuur werkt begripverhogend en voorkomt dubbelingen en omissies

  2. Manage en verbind requirements met behoeften (customer needs): traceerbaarheid is van belang voor impactbepaling

  3. Manage beperkingen (constraints): de zgn. niet-functionele requirements bepalen in belangrijke de kwaliteit van het systeem

  4. Visualiseer requirements: het visueel modelleren is een belangrijk communicatiemiddel en faciliteert het eliciteren van requirements

  5. Test de requirements: zorg ervoor dat requirements vanaf het begin goed testbaar zijn.

  6. Overbrug de kloof tussen business en ontwikkeling: less is more, focus op de waarde en prioriteit van requirements voor de business.

  7. Beheers de verandering van requirements: requirements zijn aan continue verandering onderhevig, zorg voor wijzigingenbeheer.

  8. Volg de metrieken en trends: zorg dat alle stakeholders voortgang in/rond requirements goed kunnen volgen (bijv. via een dashboard)

  9. Zorg voor voorbeelden van goede requirements: 'best practices' bevorderen de kwaliteit, consistentie en volledigheid van requirements.

  10. Hergebruik requirements: waarbij je in het ideale geval een link legt met het originele requirements

Bron: Ten steps to better requirements management, Requirements Management Whitepaper, Dominic Tavassoli (Juni 2009, IBM)

Laatst aangepast op zondag, 28 januari 2018 09:05  
'Meetbare' requirements
Gepubliceerd in Requirements
E-mail Afdrukken

citaat

Anything can be made measurable in a way that is superior to not measuring it at all.

Tom Gilb

Laatst aangepast op zondag, 28 januari 2018 09:07  
Requirements volgens Mirjam van den Berg
Gepubliceerd in Requirements
E-mail Afdrukken

Requirements heldere eisen en wensen Mirjam van den Berg

Mirjam van den Berg beschrijft in de pocket "Helder wensen en eisen! vijf stappen voor het opstellen van requirements en beschrijft een requirementsmodel bestaande uit vijf soorten requirements (door haar dus 'wensen en eisen' genoemd). Hieronder mijn samenvatting.

Van den Berg begint met het betogen dat in de dagelijkse praktijk de slechte kwaliteit van eisen en wensen resulteert in: (a) projecten die voortijdig stoppen, (b) gebrekkig software, (c) veel herstelwerk en -kosten, en (d) overbodige functionaliteit.

De oorzaak van slechte requirements ligt vaak in de gebrekkige communicatie tussen de belanghebbenden, waarbij het vaak misgaat omdat men aanneemt te begrijpen wat de ander bedoeld. Oftewel typisch een geval van aannames als 'mother of all fuck ups'.

Dat het beter kan en moet is vooral een kwestie van meer aandacht besteden aan het ontwikkelen van requirements. Zich baserend op de Wet van Boehm, benoemt Van de Berg dat de kosten van een ontwikkeltraject exponentieel dalen naarmate meer tijd en aandacht wordt besteed aan het ontwikkelen van eisen en wensen.

De vijf stappen die volgens Van den Berg gevolgd moeten worden (om aannames en miscommunicatie te minmaliseren) zijn:

  1. Maak een indeling in soorten wensen en eisen (vanuit behoeften).

  2. Beschrijf elk soort wens en eis volgens eigen kenmerken: de juiste gegeven opschrijven voor de verschillende soorten wensen en eisen.

  3. Luister actief! Vraag door! (toepassen van communicatietechnieken)

  4. Stel een verklarende woordenlijst op.

  5. Toets de eisen en wensen (fouten, aannames en verwarring zo snel mogelijk via review (informeel) of inspectie (formeel) achterhalen).

Volgens Van den Berg bestaat het proces voor het opstellen van wensen en eisen uit (minimaal) vijf fasen:

  1. Identificeren en analyseren van de belanghebbenden.

  2. Identificeren van wensen en eisen.

  3. Specificeren van wensen en eisen.

  4. Inspecteren van wensen en eisen.

  5. Autoriseren van wensen en eisen (door belanghebbenden).

Van den Berg definieert wensen en eisen als: "heldere en duidelijke beschrijvingen van de verwachtingen van belanghebbenden betrokken bij een project aan het eindresultaat en/of aan het proces om tot het eindresultaat te komen." Een eis heeft hierbij voor een belanghebbende een hogere prioriteit dan een wens. De wensen en eisen geven (alleen) antwoord op de vraag 'Wat' met het te realiseren eindresultaat moet worden bereikt. Het is dus oplossingsvrij. Een oplossing geeft namelijk antwoord op de vraag 'Hoe' dit dan moet gebeuren. In de woorden van Van den Berg:

"Oplossingen zijn dus geen wensen en eisen! Integendeel zelfs. Wensen en eisen vormen de basis voor het in kaart brengen van alle mogelijke oplossingen. Daarna zal de beste oplossing gekozen moeten worden. Bij die keuze die moet een afweging worden gemaakt tussen de mate waarin een oplossing bijdraagt aan het doel dat moet worden bereikt én de kosten om de gewenste oplossing te realiseren."

Dé reden om wensen en eisen ook écht oplossingsvrij te formuleren is dat anders het risico dreigt dat allerlei alternatieven over het hoofd worden gezien. Van den Berg geeft als tip twee controlevragen om te beoordelen of er geen sprake is van een oplossing: (1) Komt het woord 'hebben' voor in de geformuleerde wens of eis?, (2) Stel de vraag: "Kan het ook nog op een andere manier? Als één van beide vragen met ja kan worden beantwoord gaat het vaak om een oplossing en is het nodig de behoefte achter deze oplossing te achterhalen (door de vraag te stellen: "Waarom heb je ... nodig?). Oplossingen kunnen wel als aanbeveling worden meegegeven bij de requirements.

Volgens Van den Berg is geen eenduidige indeling in requirements (bijv. "waarom" (business), "wat" (user) en "hoe" (system), "functioneel" vs. "niet-functioneel") en wordt nog vaak onterecht gedacht dat de business alleen eisen en wensen zou mogen aangeven die gaan over het "Waarom" en de ICT-afdeling alleen mogen aangeven welke wensen en eisen zij stelt aan het systeem. Van den Berg stelt dat de business wel degelijk wensen en eisen kan hebben over de manier waarop het gewenste eindresultaat moet worden gerealiseerd (geformuleerd in termen van randvoorwaarden), terwijl ook ICT wensen en eisen kan hebben ten aanzien van het wat (bijv. keuze nieuw besturingsplatform).

Verwarring over wie welke soorten eisen mag stellen, is - aldus Van den Berg - te voorkomen door de volgende vijf categorieën wensen en eisen te onderscheiden:

  1. Behoeften: wat wil je ermee bereiken? Beantwoorden de vragen wat men wil bereiken en welke behoeften vervuld moeten worden .

  2. Benodigdheden: wat - vaak gaat het om een product - heb je nodig om de behoefte te vervullen?

  3. Functies; wat moet een product kunnen doen.

  4. Kwaliteiten: hoe goed moet een product de functies kunnen uitvoeren? In welke mate moet de functie aanwezig zijn? (bijv. op het gebied van werking, veiligheid, verschijning, bruikbaarheid)

  5. Randvoorwaarden: vooraf gestelde grenzen aan de oplossing(srichting).

Van den Berg visualiseert de vijf categorieën schematisch door middel van een 'piramide aan eisen en wensen', waarbij alle eisen en wensen moeten bijdragen aan het beoogde eindresultaat (de behoefte). De concrete en meetbare resultaten die men wil bereiken staan centraal. Volgens Van den Berg wordt in de prakijk vaak wel aandacht wordt besteed aan de benodigdheden en de functies, maar dat er weinig tot geen aandacht is voor de behoeften (als het eindresultaat dat bereikt moet worden met de onderliggende functies) en de kwaliteiten (hoe goed moeten de functies worden uitgevoerd). Door behoeften en kwaliteiten wél te beschrijven, kun je vooraf al bepalen óf wensen en eisen überhaupt bijdragen aan het eindresultaat en zo ja, is het mogelijk vooraf deze wensen en eisen te prioriteren (naar hun bijdrage aan het eindresultaat). Bijkomend voordeel is dat je ook beschikt over betere acceptatiecriteria.

Ad (2)  Beschrijf elk soort wens en eis volgens eigen kenmerken

Elk soort wens en eis heeft eigen specifieke kenmerken:

Functies

  • Omschrijf elke functie kort en bondig in één zin
  • Gebruik één kernwerkwoord per zin (dat de vraag beantwoord wát het product moet doen!)
  • Beschijf elke functie 'uniek': controleer combinaties van 'verwachtingen' door formulering te screenen op het gebruik van het woord 'en'.
  • Verschaf extra achtergrond (bijv. herkomst)
  • Ken een prioriteit toe aan een functie
  • Definieer de betekenis van in de formulering gebruikte termen en/of afkortingen (bij functie óf in verklarende woordenlijst)

Kwaliteit

  • Gebruik één bijwoord (dat antwoord geeft op de vraag hoe goed de functie moet worden uitgevoerd óf het product moet zijn)
  • Geef expliciet aan bij welk product of functie de kwaliteit hoort
  • Maak de kwaliteit meetbaar (meetschaal, -eenheden en -methode + norm(en))
  • Geef indien nodig en relevant extra achtergrondinformatie

Randvoorwaarden

  • Beschrijf per randvoorwaarde concreet aan welke norm exact moet worden voldaan

Behoeften

  • Maak de behoefte meetbaar (meetschaal/-eenheden en - methode + norm(en))

Ad (3) Luister actief! Vraag door!

Van de Berg stelt dat door gebruik te maken van vijf vraagtechnieken de benodigde informatie van de belanghebbenden kan worden verkregen:

  • Stel open + gesloten vragen: open vragen beginnen met een vraagwoord (wie, wat, hoe, waarom, waar, wanneer, waarmee, enz.)
  • Stell toekomstgerichte vragen (problemen in het heden en verleden => wat wil men niet, toekomst => wat je wél wil)
  • Stel abstraherende + concretisererend vragen (afwisseling in abstractieniveaus; voorkom dat je een oplossing concretiseert)
  • Stell vragen die kaders afbakenen (voorkomen woorden die niet eenduidige zijn: > 1 betekenis, generalisaties ('altijd') of vaag ('modern')
  • Zorg voor afwisseling in de vragen (schakelen tussen vraagtechnieken, abstractieniveaus)

Bron: Heldere wensen en eisen! 5 Stappen om aannames te voorkomen bij Business én ICT (2011), Mirjam van den Berg

 

Laatst aangepast op zaterdag, 06 januari 2018 08:30  
Sterke verhalen: user stories als requirementstechniek
Gepubliceerd in Requirements
E-mail Afdrukken

user stories

Binnen de agile softwareontwikkeling vormen de zgn. user stories de aanbevolen requirementstechniek. User stories staan voor requirements verteld vanuit het gezichtspunt van de gebruikers. Belangrijk hierbij is dat de veranderbehoefte wordt weergegeven in de taal van taal van de business.

Volgens Nicode de Swart voldoen user stories bij voorkeur aan de syntax: "Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>" en geeft hierbij als voorbeeld: "Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald." Het gaat hierbij alleen om de korte omschrijving ter aanduiding van de user story. Het is niet de bedoeling om volledige functionaliteit al tot in detail te beschrijven. Hiervoor is een ander onderdeel de user stories bedoeld: mondelinge communicatie. 'Mondeling' omdat het veel effectiever is om detailinformatie mondeling over te dragen.

Zodra de ontwikkelaar een user story gaat implementeren is detailinformatie nodig over de gewenste werking van de user stories. De korte omschrijving is té globaal, zodat het ontwikkelteam de gebruiker (product owner) vragen moet gaan stellen. De antwoorden op de vragen worden - voor zover nodig voor de correcte werking van de te realiseren software - vastgelegd als acceptatiecriteria. Door de samenwerking tussen het ontwikkelteam en de product owner is dus ook geen analist nodig als brugfunctie tussen business en ICT.

Deze acceptatiecriteria vormen het derde onderdeel van user stories. De acceptatiecriteria hoeven - omdat er intensief wordt samengewerkt bij het implementeren van de user stories - niet volledig te zijn. De kracht van het werken met user stories is volgens De Swart dan ook dat het detailleren van requirements, het ontwikkelen van de software en het testen ervan hand in hand gaan: "De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden. Aangezien een user stories in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren."

Onderdelen user story

  1. Korte beschrijving als aanduiding van de requirement (ivm planning)

  2. Mondelinge communicatie om de details te achterhalen (tijdens de realisatie)

  3. Acceptatiecriteria om juiste werking vast te stellen

De kracht van user stories zit in het feit dat door de intensieve samenwerking tussen het ontwikkelteam en de product owner en de nadruk op mondelinge communicatie drie voordelen optreden:

  1. Eenvoud:"Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want het is onmogelijk om de requirements (in use cases) voor 100% volledig en eenduidig te specificeren".

  2. Flexibiliteit: user stories kunnen beter omgaan met voortschrijdend inzicht: "Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project".

  3. Snelheid: een user story moet in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, moeten worden opgesplitst. Kom daar maar eens om, bij een volledige use case. Het is niet langer een analist gedetailleerd requirements te laten specificeren. Verder gaat ook geen tijd verloren aan het lezen en begrijpen van gedetailleerde requirements door de ontwikkelaars en testers en is het - omdat detaillering van requirements later en mondeling plaatsvindt - niet nodig om wijzigingen door te voeren in de specificaties.

Bron: Nicole de Swart op http://www.reaco.nl/kenniscentrum/userStories.asp

Laatst aangepast op dinsdag, 02 januari 2018 08:29  
'Just-in time' requirements
Gepubliceerd in Requirements
E-mail Afdrukken

Just in time requirements

Op haar website stelt Nicole de Swart dat mooi zou zijn als requirements 'just in time' kunnen worden opgesteld: "Net op tijd om te kunnen plannen en net op tijd om de software te kunnen ontwikkelen. We zouden dan geen last hebben van wijzigende requirements, geen change control board nodig hebben en geen scope creep kennen. Dit scheelt veel tijd, geld en gedoe."

In de goede oude watervaltijdperk was het de gewoonte om alle requirements ver van te voren op te stellen (up front) om vervolgens op basis van de totale set aan requirements een offerte op te stellen, een planning te maken en te kunnen starten met de ontwerp- en bouw-activiteiten. De werkelijkheid blijkt alleen wat minder voorspelbaar dan gehoopt, zodat wijzigingen in de overeengekomen requirements onvermijdelijk zijn (bijv. door veranderingen in de omgeving, voortschrijdend inzicht en/of ontbrekende requirements).

Volgens De Swart laten agile ontwikkelmethoden zien dat 'just in time' requirements mogelijk zijn. Het idee hierbij is het vaststellen (en vooral detailleren) van requirements zo lang mogelijk uit te stellen. In eerste instantie is het alleen nodig een globaal totaalbeeld te hebben dat net genoeg detail geeft om de doorlooptijd van het project in te kunnen schatten. Vervolgens worden alleen de requirements die ook daadwerkelijk moeten worden geïmplementeerd nader uitgewerkt. Ook hier geldt weer dat het detailniveau net genoeg moet zijn om de relatieve ontwikkelinspanning (niet in uren) in te kunnen schatten en een planning op te stellen voor de eerstvolgende iteratie.

"Pas als een ontwikkelaar daadwerkelijk de software voor een bepaalde requirement gaat bouwen, spreekt hij de wensen en de details door met de continue beschikbare (en fysiek aanwezige) vertegenwoordiger van de business. Met deze aanpak zijn de juiste requirements, op het juiste detailniveau, 'just in time' beschikbaar. Omvangrijke producten met uitgebreide specificaties hoeven dan niet opgesteld en niet onderhouden te worden."

Bron: http://www.reaco.nl/kenniscentrum/vanUpFrontNaarJustInTime.asp

Laatst aangepast op zondag, 28 januari 2018 09:06  


JPAGE_CURRENT_OF_TOTAL

Als je geen tijd hebt om iets goed te doen, waar haal je dan de tijd vandaan om je fouten te corrigeren?

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 207 gasten online
Artikelen

masaaki imai kaizen strategy improvement

Banner

passie energie prestaties bevlogenheid wingerden

Passie, energie, prestatie
de kracht van werken met bevlogenheid
Jessica Van Wingerden, Bernadette van de Laak

Bij Bol.com | Managementboek





Lean boekentips

Lean Practitioner & Lean Expert
mindset, skill set & tool set
H.C. Theisens

Bij Bol.com | Managementboek

Banner