Requirements Engineering and Agile Methodology R. Kuehl/J. Scott Hawker p. 1
Requirements Engineering and Agile Processes (You may be thinking) Requirements engineering model as presented is not very agile Writing a SRS, etc. sounds like a classic heavy weight process It is! But, two points to consider as good software engineers: 1. Fit the software methodology and process to the problem 2. Agile processes do equivalent requirement engineering activities still need requirements validated by stakeholders for success R. Kuehl/J. Scott Hawker p. 2
Requirements and Agile Traditional approach the requirements document Agile argument against tradition Communication gaps between authors and readers Change cycle is too long Challenging to capture the complete problem and system context Brain s capacity to retain information Agile answer: Continuous collaboration with stakeholders Workshops, conversation Stories (index cards) record conversations Are they requirements? No! R. Kuehl/J. Scott Hawker p. 3
Requirements Engineering in Agile Processes Where is the Knowledge? Requirements Eng. 1. Elicitation 2. Analysis 3. Specification 4. Validation 5. Management Agile Methodology 1. Stories 2. Iteration design, customer collaboration 3. Stories, code, acceptance tests, unit tests 4. Customer collaboration, acceptance tests 5. Planning cycle, frequent iterations R. Kuehl/J. Scott Hawker p. 4
A Picture Worth a 1000 Words Requirements Waterfall Incremental Evolutionary Classic or agile style Design The Requirements Engineering Model Always maps Construction (coding & testing) Deployment The General Software Engineering Framework R. Kuehl/J. Scott Hawker p. 5
R. Kuehl/J. Scott Hawker p. 6
Requirements Envisioning: An Agile Best Practice Perform some high-level requirements envisioning early in the project Gain a common understanding of the scope of the problem Business goals Identify initial requirements quickly days not weeks Iteration 0 of an agile project (inception phase) Also do initial architectural envisioning Get a feel about what the project is all about Scott Ambler: http://www.agilemodeling.com/essays/initialrequirementsmodeling.htm R. Kuehl/J. Scott Hawker p. 7
Agile Requirements Envisioning Why do it? Answer basic business questions Reduce business risk everyone agrees on the problem and solution scope up front Establishes a knowledge framework to move ahead on architecture and project planning What modeling techniques? Usage use cases, scenarios Use case diagram for context Business domain model process flow, key data entities, business rules User experience story boards, prototypes R. Kuehl/J. Scott Hawker p. 8
How Much Detail? Initial project vision Overview diagrams Just enough requirements to start the first iteration R. Kuehl/J. Scott Hawker p. 9
How Much Detail? (cont) When is more upfront detail recommended? The domain and problem space are unknown and/or complex A commercial product limited contact with stakeholders (market driven requirements) Serial project milestone governance framework System engineering involving new hardware Contractual obligations Organizational culture is traditionalist R. Kuehl/J. Scott Hawker p. 10
References Cockburn, Alistair, Agile Software Development, Addison-Wesley, 2002 Paetsch, Eberlein, Maurer, Requirements Engineering and Agile Software Development Kroll and Lyons, Eclipse Process Framework Presentation, Open Unified Process Distilled, 2006 Scott Ambler, http://www.agilemodeling.com/essays/initialrequirementsm odeling.htm R. Kuehl/J. Scott Hawker p. 11