• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements Requirements volgens Aydinli, Hendriks & Zandvliet
Requirements volgens Aydinli, Hendriks & Zandvliet

SMART requirements softwareontwikkeling

 

In het boek SMART Requirements 2.0 beschrijven Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks hun visie waarmee ze vanuit hun SMART requirements-methode kijken naar softwareontwikkeling. :

De lussen in de bovenstaande afbeelding representeren de verschillende ontwikkelcycli van de softwareontwikeling. Volgens Aydinli, Hendriks & Zandvliet is het type softwareontwikkeling (waterval,iteratief, agile, enz.) is bepalend voor het aantal lussen dat doorlopen wordt en de 'omvang' van de lus(sen). De individuele stappen binnen de lussen zijn altijd hetzelfde, onafhankelijk van de gehanteerde aanpak. Hierbij kan de diepgang van de verschillende stapjes overigens wel variëren.

  1. Wens en elicitatie: softwareontwikkeling begint met de wens van de business. Je wilt software ontwikkelen die één op één overeenkomt met de wens van de business. Vaak is deze wens nog weinig concreet en zal deze tijdens 'elicitatie' tastbaar moeten worden gemaakt.

  2. Requirements: Aydinli, Hendriks & Zandvliet definiëren requirements als de eisen, wensen en voorwaarden waaraan een product of dienst (resultaat) of een proces of het te gebruiken systeem moeten voldoen. De requirements geven in de eerste plaats aan aan welke voorwaarden het te ontwikkelen resultaat moet voldoen. Naast de requirements voor het resultaat zijn er nog twee andere vormen van requirements: (i) requirements voor de manier waarop het proces om het resultaat te realiseren moet worden uitgevoerd, en (ii) requirements voor de (ICT-)systemen die gebruikt moeten worden.

  3. Specificaties: requirements worden verder gedetailleerd in specificaties. Deze beschrijven de manier waarop de requirements moeten worden vormgegeven en hoe zij worden doorgevoerd binnen de resultaten, processen en systemen.

  4. Proces: nadat de requirements helder zijn, is het zaak een proces te ontwerpen om het gewenste resultaat te bereiken. Dit proces is gebaseerd op zowel de specifaties van het resultaat als de aanvullende requirements die gaan over de manier waarop het proces moet worden uitgevoerd.

  5. Bouw/Test: wanneer de requirements en specificaties eenduidig zijn beschik je over alle benodigde informatie om aan de slag te gaan met het ontwikkelen en testen van de benodigde ICT-middelen.

  6. Acceptatie: de requirements zijn geëvalueerd en geaccordeerd door de business en vormen daarmee het 'contrat' op basis waarvan de oplossingen voor de business worden ontwikkeld. Acceptatie vindt plaats op basis van de door de business geaccordeerde requirements. Op deze manier fungeren de requirements als acceptatiecriteria.

  7. Software: na acceptatie van het resultaat, beschikt de business over software die gebruikt kan worden in de dagelijkse praktijk.

Bron: SMART Requirements 2.0, Jasper Zandvliet, Ömer Aydinli en Edwin Hendriks

Laatst aangepast op zondag, 28 januari 2018 09:08  

The problem with quick and dirty, as some people have said, is that the dirty remains long after the quick has been forgotten.

Steve McConnell

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 168 gasten online
Artikelen

a3 problem solver john shook

Banner

kunst van het heldere denken rolf dobelli

De kunst van het heldere denken
52 denkfouten die je beter aan anderen kunt overlaten
Rolf Dobelli

Bij Managementboek.nl | Bol.com

Lean boekentips

Dagstarts en Hoshin Kanri
Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri
Bert Teeuwen

Bij Bol.com | Managementboek

Banner