1. Requirements Engineering: A Continuous Process ShlomoArgamon, PhD Illinois Institute of Technology Chicago, IL and Center for Advanced Defense Studies Washington, DC 20002 Presented at the Military Operations Research Society 20 September, 2011
2. Requirements Engineering (RE) Requirements Engineering is a subfield of: Software Engineering Systems Engineering Goal: Solve key step in problem solving: Identify the Problem! With complex projects, Requirements Engineering must be dynamic and continuous.
3. Cost of Delay in Fixing Requirements Errors Data: Boehm & Papaccio (1988) IEEE Trans. Software Eng. 20-fold increase during development Nominal unit cost 200-fold increase after delivery
6. IterativeManagement Verification Elicitation: Discover requirements – user interviews, workshops, storyboarding, use cases, prototyping, brainstorming, … Also explore trade space to ensure customer satisfaction. Specification: Define readily understood and complete requirements to ensure design integration. May involve integrating Key Performance Parameters (KPPs). Analysis: Ensure specification is unambiguous, complete, verifiable, consistent, modifiable, traceable, usable , necessary and prioritized. Management: Establish traceability to track changes status, effort and funds expended, and identify the impact of changes with links to design and architecture plans. Verification: Establish methods to ensure that requirements have been met in implementation: observation, testing, prototyping, etc.
7. Tacit Requirements 1985: Matsushita Electric developing a new bread machine, but the crust was overdone, while the inside was raw No progress by usual engineering analyses, including interviewing bakers and x-ray comparisons Finally, one engineer apprenticed with a master baker, discovering need to twist the dough Result: New technical requirements which resulted in a working product with record sales Nonaka 2007; Harvard Business Review
8. Context is King User World Participation Causal effects Interface System World Representation Process Subject World Development World after (Jarke & Pohl 1993)
9. Recursion in Development Traditional Waterfall Engineering (Plan-Driven) Modified Modular, with coordination points Iterative development models (spiral, agile, etc.) are more context-driven… but still maturing for large-scale projects Requirements Design Implementation Verification Maintenance
11. Spiral Strengths & Weaknesses Strengths: Highest risks can be dealt with first, lowering overall costs Each iteration can be tailored for project needs as they evolve Tacit requirements uncovered at each iteration Weaknesses: More complex project organization – issues with scale Requires attentive and expert management General Recommendation: To reduce project risk, when possible: run risk-reduction iterations followed by waterfall or other non-risk-based lifecycle, once things are clear Depends on CONTEXT!!
12. Requirements Management Challenge Requirements Engineering challenges: Scope Understanding Volatility Agility is required to: Adapt to a moving target Enable engineering time to achieve objectives
13. The Bottom Line(s) Requirements are never known up front Requirements engineering should be interleaved in an iterative development process End-users must be involved in the development process
Editor's Notes
Getting this process right is vital. As you can see by this chart from the GA Tech CS department (2002) , poor requirements engineering resulted in a 200 fold increase in costs.
This is one of the more recent models for context-driven requirements elicitation from the Center for Informatics Research (CRI) at the Sorbonne in Paris. There are many others. First, The subject world—our environment has an impact on our requirements. The market and target customer may change because of economics, for example. In the usage world, our usage cases and mis-use cases can gain fidelity or be discovered. In the system world, interfaces may change. In the Design world, we may change approach because of technology maturity. In each case, there is a trade space associated with the requirements choices. The objective is to determine, when the customer cannot explicitly identify all requirements, the nuances in the perceived utility, desirability or necessity of various specifications for the customer. Like military missions, because of the changeable context, we hope to accomplish the customers intent.
The traditional approach is to waterfall activities in a linear approach from specified requirements. Because of the dynamic nature of context, this frequently approximates the customers objectives less and less, the longer it takes to accomplish.So, the modified approach is to create a series of smaller waterfalls by generating specified elicitation points. This also has its failings. The customer’s objectives are continually evolving. Understanding where these objectives come from becomes important when the customer is not present in the engineering process.More recently, software development has examined Agile approaches including Scrum, Extreme Programming, and the Dynamic Systems Development Method, among others. The difficulty with these approaches lies in managing very large projects where teams are distributed. Agile Development requires senior developers and thrives in an environment where requirements change often, there are fewer developers to coordinate, and the culture embraces chaos.
In conclusion, poor requirements engineering is guaranteed to increase time delays and costs. Requirements traceability is not separable from the other requirements processes. There are a wide variety of Requirements approaches and associated tools. The overall objective of any approach should be to ensure continuous recursion and context awareness.
