EQUA Moeten we requirements serieus nemen?

Traditioneel Iteratief Agile Open Source Frank Peeters Petra Heck

Traditioneel & Iteratief

Principes Requirements Design Bridge Design Bridge Software  De klant is de koning  De klant is de keurmeester  Wij zijn aansprakelijk 4

Kwaliteit Software m.socrative.com Niet te veel en niet te weinig 1.Mijn ontwikkelteam garandeert dat de software matcht met de requirements. In verband met onderhoud: 2.Mijn ontwikkelteam garandeert dat de software matcht met het design.

Symbiosis methodologie 1. garandeert een match tussen requirements en design. 2. garandeert een match tussen design en software.

Symbiosis: Aanpak + Tool Requirements Design Bridge Design Bridge Software  Tool stelt realisatie van requirement vast  Validatie + Realisatie = KLAAR  Requirements   Design  Geen verspilde aandacht voor documentatie

Programmeren Requirements Design Bridge Design Bridge Software  Geen Boilerplate Broncode Domeinlaag  Geschikte operaties, Juiste parameters, Implementatie operaties, Afstemming tussen klassen, …  Rules m.b.t. Afleidbaarheid  Rules m.b.t. Automatische Toestandsovergang  Domain Class Library wordt gegenereerd  Na Use Case Modelling wordt UseCase Class Library gegenereerd 8

Agile & Open Source Petra Heck

Kwaliteit van requirements A. Davis et al., Identifying and measuring quality in a software requirements specification, 1993 Hoe vertalen we dit naar agile?

STELLING De kwaliteit van agile user stories is minder belangrijk dan bij traditionele requirementsdocumenten.

VRAAG 1 “With user stories … we just need to understand each other enough to know when we have struck a proper bargain” (Leffingwell 2011, Agile Software Requirements) In welke vorm leggen jullie agile requirements vast? 1) Helemaal niet (alleen mondeling) 2) Alleen kort statement wat gebruiker wil 3) Een use-case achtige omschrijving (scenario met stappen) 4) Meer detail in vorm van attachments, modellen, algoritmes

VRAAG 2 “user stories need little or no maintenance and can be safely discarded after implementation” (Leffingwell 2011, Agile Software Requirements) Bewaren jullie de agile requirements? 1) Nee 2) Ja, op papier 3) Ja, digitaal als naslag 4) Ja, digitaal voor hergebruik

Conclusie De kwaliteit van agile user stories is net zo belangrijk als bij traditionele requirementsdocumenten.

Heeft u agile requirements die we kunnen analyseren?

Neem requirements serieus!