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.
Requirements Engineering: Contextual and Dynamic
Requirements Engineering:<br />A Continuous Process<br />ShlomoArgamon, PhD<br />Illinois Institute of Technology<br />Chicago, IL<br />and<br />Center for Advanced Defense Studies<br />Washington, DC 20002<br />Presented at the Military Operations Research Society<br />20 September, 2011<br />
Requirements Engineering (RE)<br />Requirements Engineering is a subfield of:<br />Software Engineering <br />Systems Engineering<br />Goal: Solve key step in problem solving:<br />Identify the Problem!<br />With complex projects, Requirements Engineering must be dynamic and continuous.<br />
Cost of Delay in Fixing Requirements Errors<br />Data: Boehm & Papaccio (1988)<br />IEEE Trans. Software Eng.<br />20-fold increase during development<br />Nominal<br />unit cost<br />200-fold increase after delivery<br />
Iterative</li></ul>Management<br />Verification<br />Elicitation: Discover requirements – user interviews, workshops, storyboarding, use cases, prototyping, brainstorming, … Also explore trade space to ensure customer satisfaction.<br />Specification: Define readily understood and complete requirements to ensure design integration. May involve integrating Key Performance Parameters (KPPs).<br />Analysis: Ensure specification is unambiguous, complete, verifiable, consistent, modifiable, traceable, usable , necessary and prioritized.<br />Management: Establish traceability to track changes status, effort and funds expended, and identify the impact of changes with links to design and architecture plans.<br />Verification: Establish methods to ensure that requirements have been met in implementation: observation, testing, prototyping, etc. <br />
Tacit Requirements<br />1985: Matsushita Electric developing a new bread machine, but the crust was overdone, while the inside was raw<br />No progress by usual engineering analyses, including interviewing bakers and x-ray comparisons<br />Finally, one engineer apprenticed with a master baker, discovering need to twist the dough<br />Result: New technical requirements which resulted in a working product with record sales<br />Nonaka 2007; Harvard Business Review<br />
Recursion in Development<br />Traditional Waterfall Engineering (Plan-Driven)<br />Modified<br />Modular, with coordination points<br />Iterative development models (spiral, agile, etc.) are more context-driven… but still maturing for large-scale projects<br />Requirements<br />Design<br />Implementation<br />Verification<br />Maintenance<br />
Spiral Strengths & Weaknesses<br />Strengths:<br />Highest risks can be dealt with first, lowering overall costs<br />Each iteration can be tailored for project needs as they evolve<br />Tacit requirements uncovered at each iteration<br />Weaknesses:<br />More complex project organization – issues with scale<br />Requires attentive and expert management<br />General Recommendation:<br />To reduce project risk, when possible:<br />run risk-reduction iterations followed by <br />waterfall or other non-risk-based lifecycle, once things are clear<br />Depends on CONTEXT!!<br />
Requirements Management Challenge<br />Requirements Engineering challenges:<br />Scope<br />Understanding<br />Volatility<br />Agility is required to:<br />Adapt to a moving target<br />Enable engineering time to achieve objectives<br />
The Bottom Line(s)<br />Requirements are never known up front<br />Requirements engineering should be interleaved in an iterative development process<br />End-users must be involved in the development process<br />