Home · Fasen · Rollen · Producten · Best practices · Referenties · Nieuws & release notes · Begrippen

Planning
Bijstellen non-functional requirements

Op basis van nieuwe inzichten uit de bedrijfsstudie of door opgedane kennis van reeds opgeleverde incrementen kunnen nieuwe of gewijzigde randvoorwaarden aan de applicatie worden gesteld. Tevens wordt nagegaan of de reeds gestelde non-functional requirements nog valide en correct zijn.

Doel

Identificeren, kwantificeren, prioriteren van nieuwe non-functional requirements en het herzien van bestaande non-functional requirements.

Stappen

  1. Identificeren nieuwe non-functional requirements
    Organiseer een brown paper sessie. Laat de deelnemers nieuwe non-functional requirements identificeren. Gebruik de huidige non-functional requirements als uitgangspunt. Leg de nieuwe non-functional requirements vast. Formuleer de non-functional requirements helder en eenduidig.

  2. Vaststellen prioriteiten voor iteratie
    Stel tijdens dezelfde sessie opnieuw de prioriteiten van alle non-functional requirements vast, ten aanzien van de huidige iteratie en de use cases die tijdens deze iteratie worden gerealiseerd. Hanteer eventueel de MoSCoW-regels voor het vaststellen van de prioriteiten.

  3. Vaststellen non-functional requirements huidige iteraite
    Stel tijdens de brown paper sessie vast welke non-functional requirements een rol spelen tijdens de huidige iteratie. Bepaal de impact van deze non-functional requirements op de planning van de iteratie. Weeg het handhaven van de non-functional requirements af tegen het beschikbare budget én tegen de planning.

Richtlijnen

Non-functional requirements en projectplan
De non-functional requirements zijn direct van invloed op de kwaliteit van de applicatie en hebben gevolg voor de planning, de resources en het budget. Eventuele consequenties voor planning en budget worden verwerkt in het projectplan.

MoSCoW
Bij het toepassen van MoSCoW krijgen in eerste instantie veel requirements het label must have. Veel meer dan realiseerbaar is. Een strategie hierbij is om de non-functional requirements op volgorde van importantie te plaatsen. Zo wordt alsnog bepaald welke requirements het grootste belang voor de iteratie hebben.

 [TASK036] Versie 2003Q2 Basic - ©1999-2006 Sander Hoogendoorn (aahoogendoorn@gmail.com), 1 juli 2003