Veel bedrijven hebben een misplaatst geloof in planning, onvoldoende begrip voor de onsystematische aard van het innovatieproces, een overdreven vertrouwen in grootschaligheid en een volledig gebrek aan inzicht in de werking van georganiseerde chaos en de cumulatieve waarde van veel kleine successen.

Tom Peters, Robert H. Waterman (In Search of Excellence)

In het boek Grip op requirements onderkennen Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis twee indelingen van requirements. De eerste onderverdeling die vaak wordt gebruikt voor requirements is de splitsing in functionele requirements en niet-functionele requirements. De tweede indeling van requirements is het onderkennen van business requirements, gebruikers requirements en systeem- of softwarerequirements.

Functionele requirements vs. niet-functionele requirements

1. Functionele requirements: requirement die het door een systeemfunctie gewenste gedrag beschrijft.

2. Niet-functionele requirements: requirement die niet het gedrag van het systeem beschrijft maar andere systeemeisen definieert (kwaliteitseisen en/of beperkingen waaraan het systeem moet voldoen)

Functionaliteit definiëren Cannegieter, De Swart en Zandhuis als de mogelijkheden die het systeem moet bieden zoals gesteld in functionele requirements.

Kwaliteitsrequirements geven aan hoe goed het beoogde systeem haar functionaliteit moet aanbieden; het gaat om een kwaliteitseigenschap die niet door een functioneel requirement wordt afgedekt. Een beperking is een requirement dat de oplossingsruimte beperkt in aanvulling op de functionele en kwaliteitsrequirements. In tegenstelling tot functionele en kwaliteitsrequirements kun je een beperking niet implementeren; het gaat om eisen die de oplossingsruimte of het ontwikkelproces limiteren. Bijvoorbeeld, 'het systeem moet gebruik maken van een Oracle-database' en 'het systeem moet voor het eind van het jaar operationeel zijn'.

Business requirements, gebruikersrequirements & systeem- of softwarerequirements

1. Business requirements: requirements die beschrijven wat de met het systeem te realiseren doelen zijn (welke toegevoegde waarde heeft het systeem voor de organisatie?).

2. Gebruikersrequirements: requirements die de activiteiten, processen of taken beschrijven die een gebruiker met het systeem wil uitvoeren (op welke manier ga je de business requirements halen?).

3. Systeem- of softwarerequirements: requirements die het gewenste gedrag of de gewenste kwaliteit van het systeem beschrijven (aan welke eisen moet het systeem voldoen?).

Business requirements zijn geformuleerd vanuit het perspectief van bedrijfsdoelstellingen. Gebruikersrequirements vanuit het perspectief van de bedrijfsvoering en de gebruikers. Systeemrequirements worden beschreven vanuit het perspectief van het systeem.

Bron: Grip op requirements, Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis

There are no rules of architecture for a castle in the clouds.

G. K. Chesterton

En doet het zeer?
7 prachtverhalen over krachtig leiderschap
Eveline Jansen

Bij: Managementboek

The original purpose of a hierarchy is always to help its originating subsystems do their jobs better.

Donella H. Meadows

Organizational models tend to focus only on snapshots of a complex, evolutionary process

Claudio Ciborra

My definition of an expert in any field is a person who knows enough about what’s really going on to be scared.

P. J. Plauger

If people are good only because they fear punishment, and hope for reward, then we are a sorry lot indeed.

Albert Einstein

The secret of change is to focus all of your energy, not on fighting the old but on building the new.

Socrates

Nieuwe Powerpoint-presentatie toegevoegd aan mijn Slideshare-verzameling met een afbeelding van een Ordnung muss sein bordje.