![NEGOTIATING REQUIREMENTS
• The inception, elicitation, and elaboration tasks in an ideal requirements
engineering setting determine customer requirements in sufficient depth to
proceed to later software engineering activities.
• Boehm [Boe98] defines a set of negotiation activities at the beginning of each
software process iteration. Rather than a single customer communication
activity, the following activities are defined:
1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a
set of win-win conditions for all concerned (including the software team).
9](https://image.slidesharecdn.com/topic19-230509111146-d6a088e4/85/Topic-19-User-Requirements-pptx-9-320.jpg)
Topic 19. User Requirements.pptx
- 2. TYPES OF ELEMENTS OF THE REUIREMENTS • The specific elements of the requirements model are dictated by the analysis modeling method that is to be used. However, a set of generic elements is common to most requirements models. Scenario-based elements Class-based elements Behavioral elements Flow-oriented elements Analysis patterns 2
- 3. SCENARIO-BASED ELEMENTS 3 Use Case Diagram for Safe home Activity Diagram for eliciting requirements
- 4. CLASS-BASED ELEMENTS 4 Class Diagram for Sensor
- 6. FLOW – ORIENTED ELEMENTS – Information is transformed as it flows through a computer- based system. – The system accepts input in a variety of forms; applies functions to transform it; and produces output in a variety of forms. 6
- 7. ANALYSIS PATTERNS • Anyone who has done requirements engineering on a number of software projects will note that some issues repeat across all projects within a certain application area. These patterns of analysis provide solutions (e.g., a class, a function, or a behavior) inside the application domain that can be reused when modelling several applications. • By referencing the pattern name, analysis patterns are integrated into the analysis model. They are also stored in a repository so that requirements engineers can find and apply them using search facilities. Information about an analysis pattern (and other sorts of patterns) is contained in a standard template. 7
- 9. NEGOTIATING REQUIREMENTS • The inception, elicitation, and elaboration tasks in an ideal requirements engineering setting determine customer requirements in sufficient depth to proceed to later software engineering activities. • Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration. Rather than a single customer communication activity, the following activities are defined: 1. Identification of the system or subsystem’s key stakeholders. 2. Determination of the stakeholders’ “win conditions.” 3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned (including the software team). 9
- 10. 10 THANK YOU Team – Adaptive Software Engineering