Requirements Engineering: Contextual and Dynamic
1 like515 views
Requirements engineering is a subfield of software and systems engineering that aims to identify problems by discovering requirements through iterative processes like elicitation, specification, analysis, verification and management. It must be a continuous and dynamic process to adapt to changing requirements given the high costs of fixing errors late in development. Tacit and contextual requirements are often uncovered through apprenticeships or risk-reduction iterations in development models like spiral development. Managing requirements is challenging due to their scope, volatility and the need for agility to adapt to a moving target.
Requirements Engineering: Contextual and Dynamic
- 1. Requirements Engineering:A Continuous ProcessShlomoArgamon, PhDIllinois Institute of TechnologyChicago, ILandCenter for Advanced Defense StudiesWashington, DC 20002Presented at the Military Operations Research Society20 September, 2011
- 2. Requirements Engineering (RE)Requirements Engineering is a subfield of:Software Engineering Systems EngineeringGoal: 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 ErrorsData: Boehm & Papaccio (1988)IEEE Trans. Software Eng.20-fold increase during developmentNominalunit cost200-fold increase after delivery
- 4. Components of Requirements EngineeringSpecificationElicitationAnalysisProcesses are: Non-linear
- 5. Dynamic
- 6. IterativeManagementVerificationElicitation: 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 Requirements1985: Matsushita Electric developing a new bread machine, but the crust was overdone, while the inside was rawNo progress by usual engineering analyses, including interviewing bakers and x-ray comparisonsFinally, one engineer apprenticed with a master baker, discovering need to twist the doughResult: New technical requirements which resulted in a working product with record salesNonaka 2007; Harvard Business Review
- 8. Context is KingUserWorldParticipationCausal effectsInterfaceSystemWorldRepresentationProcessSubjectWorldDevelopmentWorldafter (Jarke & Pohl 1993)
- 9. Recursion in DevelopmentTraditional Waterfall Engineering (Plan-Driven)ModifiedModular, with coordination pointsIterative development models (spiral, agile, etc.) are more context-driven… but still maturing for large-scale projectsRequirementsDesignImplementationVerificationMaintenance
- 11. Spiral Strengths & WeaknessesStrengths:Highest risks can be dealt with first, lowering overall costsEach iteration can be tailored for project needs as they evolveTacit requirements uncovered at each iterationWeaknesses:More complex project organization – issues with scaleRequires attentive and expert managementGeneral Recommendation:To reduce project risk, when possible:run risk-reduction iterations followed by waterfall or other non-risk-based lifecycle, once things are clearDepends on CONTEXT!!
- 12. Requirements Management ChallengeRequirements Engineering challenges:ScopeUnderstandingVolatilityAgility is required to:Adapt to a moving targetEnable engineering time to achieve objectives
- 13. The Bottom Line(s)Requirements are never known up frontRequirements engineering should be interleaved in an iterative development processEnd-users must be involved in the development process
Editor's Notes
- #4: 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.
- #7: 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.
- #8: 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.
- #11: 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.