Paper Presentation

1. Paper Presentation Requirements Engineering: A Road Map Bashar Nuseibeh & Steve Easterbrook Presented By: Bob X. Chen (xiaoboch@usc.edu) Ruchi Gupta (ruchigup@usc.edu) csci599

2. Today’s Discussion • Introduction to RE • Software & System level view • Cognitive and Social Science Techniques • Context & Groundwork • RE core activities • Eliciting requirements • Modeling and Analyzing requirements • Communicating requirements • Agreeing requirements • Evolving requirements • Requirements Engineering a roadmap • Summary csci599

3. Introduction • Requirement Engineering • Process of discovering the purpose • Identifying stakeholders & needs • Documenting needs for analysis, communication & implementation • Challenges • Numerous & distributed stakeholders • Varying & conflicting goals • Difficulties in articulating these goals csci599

4. Relative Costs of Fixing Software Faults 200 30 10 4 3 2 1 Requirements Specification Planning Design Implementation Integration Maintenance csci599

5. Software & System Level View • Zave’s definition of RE “Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.” • Software functions in liaison with the System in which it is Embedded • Software: A formal description • RE must span gap between Informal world of stakeholder needs & formal world of Software • System: Understanding of System theory & practice • Characterizing Systems, identifying their boundaries and managing their development life cycle csci599

6. Cognitive & Social Science techniques • Cognitive psychology • Provides understanding of difficulties people may have in describing their needs. • Anthropology • Observing human activities to understand how computer system may help or hinder those activities. • Sociology • Aims to involve those in RE process, who are most affected by outcomes. • Linguistic • Analyze communication patterns in organization. csci599

7. Context & Groundwork • RE, a Front end activity • Not always true • Requirements evolve while system is in operation • Context & Groundwork • Assessment of Project’s Feasibility & associated Risks • Identification of suitable RE Process • Selection of Methods and Techniques for RE Activities csci599

8. RE Core Activities • Eliciting requirements • Modeling and Analyzing requirements • Communicating requirements • Agreeing requirements • Evolving requirements csci599

9. Eliciting Requirements (1) • Requirements to Elicit • Identifying stakeholders & user classes • Customers or Clients • Developers • Users - novice users, expert users, occasional users, disabled users • Goals & Tasks • Focus on Problem domain • And needs of stakeholders • Scenarios & Use cases csci599

10. Eliciting Requirements (2) • Elicitation Techniques • Traditional techniques • Questionnaires, surveys, interviews, documents • Group elicitation techniques • Prototyping • Model-driven techniques • Cognitive techniques • Contextual techniques • Need for guidance on use of these Techniques csci599

11. Modeling & Analyzing Requirements • Enterprise Modeling • Organizational Structure • Business Rules • Data Modeling • Entity-Relationship-Attribute • Behavioral Modeling • Functional behavior of Stakeholders. • Existing • Required csci599

12. Modeling & Analyzing Requirements (2) • Domain Modeling • Abstract description of the world • Advantage: Requirement reuse within a domain • Advantage: detailed reasoning about the domain • Modeling Non-Functional Requirement • Difficult to measure and test • Analyzing Requirement Models • Requirement animation, automated reasoning • Knowledge based critique, consistency check csci599

13. Communicating Requirements • Effective Communication of Requirements • Requirements Documentation • Specification of languages & notations • Formal, semi-formal & informal language • Requirements Management • Readability & Traceability • Requirement’s origin, development & specification • Documentation Standards • Pro: Guideline for structuring requirement documents • Con: Rigid contractual constraints csci599

14. Agreeing Requirements • Maintain agreement with all stakeholders • Inspection & formal method • Coherence & consistency of the requirements • Requirement Validation (difficult) • Knowable & question of truth, science like • Devise experiments to refute current requirements • conflicting goals among stakeholders • Conflict resolution among stakeholders • Win-win approach, negotiation • Agreement without explicit goals, matrices csci599

15. Evolving Requirements • Manage Change • Changing stakeholders’ needs • Forestall cost & schedule • Techniques and tool for configuration management and version control • Exploiting Traceability • Evaluation of proposed change with existing requirements csci599

16. Integrated Requirements Engineering • Problem Frames • Identify well-understood problem offers well-understood solutions • Multiple perspective of requirements • Facilitate req. partition, modeling, analysis • Automated tools • DOORS, Prequite Pro, Cradle • Document req. manage changes csci599

17. A Requirements Engineering Roadmap • RE became a field of study in early 1990’s • New ideas emerged • Modeling & analysis cannot be isolated from its social & organizational context • RE should focus on modeling the property of the environment, not functionality • Resolve conflicting requirements csci599

18. A Requirements Engineering Roadmap (cont.) • Future Challenges • Techniques for modeling & analyzing properties of the environment instead of the behavior of the software • Fill the gap between requirement elicitation and formal specification • Richer models nonfunctional requirements • Understanding of the impact of Software Architecture • Multidisciplinary training for requirements practitioners csci599

19. Summary • Strengths • Well structured and well organized paper aiding easy understanding. • Discusses each of the RE core activities in detail depicting importance of each of them. • As the title suggests the paper gives an indication where we stand today in terms of RE and what are the future research goals and objectives. • Weaknesses • Paper account well for the RE activities, but fails to explain the RE process. • Relevance to Embedded Systems • Author is of the view that software functions in conjunction with the system in which it is embedded. csci599