• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Kernachtige gedragsverandering
Gepubliceerd in Citaten: verandermanagement
E-mail Afdrukken

citaat

The central issue is never strategy, structure, culture or systems. The core of the matter is always about changing the behavior of people.

John Kotter

Laatst aangepast op woensdag, 30 november 2011 20:53  
'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  
Omdenken (6)
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat

Happiness doesn't depend on any external conditions, it is governed by our mental attitude.

Dale Carnegie

Laatst aangepast op dinsdag, 15 november 2011 20:31  
Heilige doelen
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

Hell, there are no rules here - we're trying to accomplish something.

Thomas Edison

Laatst aangepast op woensdag, 23 maart 2011 18:36  
Duivelse details
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

The difference between the almost right word and the right word is really a large matter.

Mark Twain

Laatst aangepast op zaterdag, 09 april 2011 18:27  
Begin met het einde voor ogen
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

You've got to think about big things while you're doing small things, so that all the small things go in the right direction.

Alvin Toffler


Laatst aangepast op maandag, 18 april 2011 18:30  
Muziek uit het hart
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

I have never thought of writing for reputation and honor. What I have in my heart must come out; that is the reason why I compose.

Ludwig von Beethoven

Laatst aangepast op woensdag, 23 maart 2011 18:35  
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  
Rottende strategie
Gepubliceerd in Citaten: strategie
E-mail Afdrukken

citaat

Once, strategy was about protecting your existing competitive advantage. Today, it is about finding your next advantage. In fact, the day you create a new strategy is the day it starts to decay.

Vijjay Govindarajan

Laatst aangepast op woensdag, 30 november 2011 21:02  
Succesvolle wilskracht
Gepubliceerd in Citaten
E-mail Afdrukken

citaat

The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will.

Vince Lombardi

Laatst aangepast op maandag, 21 maart 2011 20:21  


JPAGE_CURRENT_OF_TOTAL

 

Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them.

Paul Hawken

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 92 gasten online
Artikelen

focus jim collins

Banner
Banner

understandin by design

Understanding by Design
Grant Wiggins & Jay Mctighe

Bij Bol.com




Lean boekentips

Banner