Hoorcollege System Development Management 1 Requirement Analyse Mario van Vliet 6 Juni 2006

Cap Gemini Ernst & Young Contents What is requirements analyse? Waarom zo moeilijk? Kritische succesfactoren De fasen De stappen en de op te leveren documenten Oefening Cap Gemini Ernst & Young 2

Cap Gemini Ernst & Young Context “Because software, like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent and incomplete in large measure, software development is a social learning process. The process is a dialogue in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users and designers and evolving tools (technology). It is an iterative process in which the evolving tool itself serves as the medium for communication, with each new round of dialogue eliciting more useful knowledge from the people involved.” Howard Baetjer, jr. Dit zegt ‘t eigenlijk. Als na afloop van de cursus dit idee door jullie aderen stroomt, en deel uitmaakt van je ruggemerg. Dan kan ik als een tevreden mens sterven. Cap Gemini Ernst & Young

Requirements Analyse: Een definitie ‘The process of establishing the services the system should provide and the constraints under which it must operate’ Roger S. Pressman Software Engineering – A practitioner’s Approach European Adaptation, fifth edition ‘the appropriate mechanism for understanding what the customer wants, analysing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system’ Thayer, R.H. and M. Dorfman, Software requirements engineering Cap Gemini Ernst & Young

Waarom is requirements analyse zo moeilijk? Gebruiker/stakeholder Software ontwerper Interactie….match Verwachtingen, uiteindelijk oplossing is moeilijk voor te stellen Begrijpen van wensen Scope Huidig systeem versus toekomstig systeem (‘vastgeroeste’ eisen en wensen) Veranderingen (tijd tussen analyse en uiteindelijke oplossing) (functionele) behoeftes versus (technische) oplossingen Volledigheid (functioneel en technisch) ‘Wicked problems’ – geen eenduidige oplossing Conflicterende eisen bij gebruikers Verschil tussen opdrachtgever en gebruiker (b.v budget) Verschil tussen ‘nice-to-have’ en kritische functionaliteit Proces van ‘onderhandelen’ tussen gebruiker en ontwerper Cap Gemini Ernst & Young

Kritische succesfactoren: uitgangspunten voor requirements analyse Beoordeel de business en technische haalbaarheid van het systeem Identificeer de stakeholder (opdrachtgever, ‘super-users’ en gebruikers) Identificeer de gebruikers die de requirements kunnen vaststellen (‘super-users’) (verschil hierachie versus mandaat en content kennis) Definieer de technische omgeving (architectuur, operating system, communicatie-oimgeving) Identificieer de ‘domain constraints’ die de functionaliteit en performance van het systeem beïnvloeden Definieer de methoden die gebruikt worden om de requirements boven water te krijgen (interviews, workshops, rapid solution workshops) Creëer de identificeer de juiste en meest geschikte omgeving voor het analyseren van de requirements (prototyping, walkthroughs, rapid solution techniques, case tools) Cap Gemini Ernst & Young

De Fasen: waar bevindt requirements analyse zich? ‘Unfreezing’ ‘Freezing’ Analyse Ontwerp Coderen Testen Beheer Fase 1 Ontwikkelen blauwdruk Fase 2 Ontwerpen Informatie- systeem Fase 3 Realiseren Informatie- systeem Fase 4 Invoeren Informatie- systeem Cap Gemini Ernst & Young

Stappen en op te leveren documenten (vereenvoudigd) Fasen Fase 1 Ontwikkelen blauwdruk Fase 2 Ontwerpen Informatie- systeem Fase 3 Realiseren Informatie- systeem Fase 4 Invoeren Informatie- systeem Stappen Vaststellen Systeem Behoeften Definitie studie Haalbaarheids- studie Haalbaarheids Rapport Functioneel Ontwerp Functionele Specificatie Technisch Ontwerp Technische Specificatie Documenten Requirements Analyse Cap Gemini Ernst & Young

Cap Gemini Ernst & Young Functioneel ontwerp Substappen Requirements identificatie en analyse Requirements definitie Requirement specificatie (functionele specificatie) Cap Gemini Ernst & Young

Requirements identificatie en analyse Activiteiten Identificatie van requirements Stakeholders (procesgeoriënteerd) Scope bepaling Systeemomgeving Analyse van requirements Is elke requirement SMART geformuleerd? (Specific, Measurable, Achievable, Realistic, Time-Bound) Zijn alle requirements op het juiste abstractieniveau geformuleerd? ‘Nice-to-have’ versus ‘Must-have’ Is een requirement terug te voeren naar het definitierapport Zijn er conflicterende requirements Kan elke requirement binnen de gekozen technische omgeving worden ingevuld? Kan elke requirement getest worden? Zijn de requirements volledig? Aandachtspunten Begin van afstemming tussen gebruiker/stakeholder en software ontwerper Verschil tussen behoefte en oplossing Cap Gemini Ernst & Young

Requirements definitie Activiteiten Afstemmen van de requirements Afstemming door prototyping/system modelling Alle super-users involved Vastleggen van de requirements ‘natural language’ Bedoeld voor de eindgebruiker Aandachtspunten ‘Levend proces’. Requirements definities kunnen in het verloop toich wijzingen of worden aangepast. Iteratief proces Cap Gemini Ernst & Young

Requirements specificatie Activiteiten Vertalen van gedefinieerde requirements naar functionele specificatie Geschreven document, modellen, prototype, scenario screen downloads Bedoeld voor contract tussen stakeholder en systeem ontwerper Deliverable Functionele specificatie Inhoud Introductie Technische omgeving Systeem model Systeem evolutie Functionele requirements Niet-functionele requirements (hardware sizing en configuratiue, database, performance (response tijden), interactie met andere systemen, interfaces, conversie en migratie, geheugen requirements, te gebruiken standaarden, protocollen en producten) Glossary Cap Gemini Ernst & Young

Requirements Specificatie Aandachtspunten Focus op externe performance van het systeem (naar de gebruiker toe) Het moet de beperkingen in de omgeving goed beschrijven (technisch, omgeving, procesmatig) Makkelijk aan te passen (in verband met iteraties) Referentie voor onderhoud aan het systeem Visie op levenscyclus van het systeem (object-orientatie) Hoe om te gaan met onverwachte gebeurtenissen (fault-proof) – consistentie AO/IC Cap Gemini Ernst & Young