De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

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

Verwante presentaties


Presentatie over: "Hoorcollege System Development Management 1 Requirement Analyse 6 Juni 2006 Mario van Vliet."— Transcript van de presentatie:

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

2 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

3 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.

4 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

5 Cap Gemini Ernst & Young Waarom is requirements analyse zo moeilijk? –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 Gebruiker/stakeholder Software ontwerper Interactie….match

6 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)

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

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

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

10 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

11 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

12 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

13 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


Download ppt "Hoorcollege System Development Management 1 Requirement Analyse 6 Juni 2006 Mario van Vliet."

Verwante presentaties


Ads door Google