Requirement Engineering – A Roadmap

1. Requirement Engineering – A Roadmap Bashar Nuseibeh Steve Easterbrook Presented By Adnan Choudhary

2. 1. Introduction • Abstract • Success of a software ? • How to know the purpose ? • Identifying stakeholders • Identifying needs of stakeholders • Creating documentation for: • Analysis • Communication • Implementation

3. 1. Introduction (contd.) • Inherent difficulties • Numerous and distributed stakeholders • Vary and conflicting goals • Goals may not be explicit • Difficult to articulate requirements

4. 2. Foundation • Definition of Requirement Engineering “ 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. ”

5. 2. Foundation (contd.) • What's good about the definition ? • Highlights the importance of real-world goals • Precise specification of: • Analyzing – requirements • Validating – what stakeholders need • Defining – what designers have to build • Verifying – they have done so correctly • Evolution – capable to cope with the changes • What's ambiguous in the definition ? • Main focus is on software engineering

6. 2. Foundation (contd.) • The context in which RE takes place is usually human activity system and the problem owner are people. • Techniques for eliciting and modeling, drawn on cognitive and social sciences: • Cognitive Psychology • Anthropology • Sociology • Linguistics

7. 3. Context and Groundwork • RE is often the fore-end activity in the software system development process • RE plays an important role in the management of change in software development • RE processes depend on the type of product • Groundwork mean the assessment of project’s feasibility and associated risks

8. 4. Eliciting Requirements • Requirements to Elicit • Boundaries • Identify the high level boundaries of the system • Stakeholders and Use Cases depend on boundaries • Stakeholders • Customer or Clients • Developers • Users • Goals • Eliciting High level goals early in development • Tasks • When it is difficult to articulate user requirements

9. 4. Eliciting Requirements (contd.) • Elicitation Techniques • Traditional Techniques • Questionnaires and Surveys • Interviews • Analysis of existing documentation • Group Elicitation • Group brainstorming sessions • RAD (Rapid Application Development) • JAD (Joint Application Design) • Prototyping • Where there is great deal of uncertainty • Early feedback from stakeholders is needed

10. 4. Eliciting Requirements (contd.) • Elicitation Techniques • Model-Driven • Goal Based Methods – KAOS & I • Scenario Based Methods - CREWS • Cognitive • Protocol Analysis • Laddering • Card Sorting • Repertory Grids • Contextual • Alternative to Tradition and Cognitive techniques • Ethnographic Technique– Participant Observation

11. 5. Modeling and Analysis Requirements “ The construction of abstract descriptions that are amenable to interpretation ” • Enterprise Modeling • Understanding organization's structure • Business rules • Goals, tasks and responsibilities • Data • Data Modeling • Understand, manipulate and manage large volume of information • How to represent real world phenomenon into system information

12. 5. Modeling and Analysis Requirements (contd.) • Behavioral Modeling • Dynamic or Functional behavior of stakeholders and system, both existing and required • Domain Modeling • Abstract description of the world in which the system will operate • Requirements reuse within a domain • Modeling Non-Functional Requirements • Difficult to express in a measurable way • Difficult to analyze • Properties of a system as a whole

13. 5. Modeling and Analysis Requirements (contd.) • Analyzing Requirements Models • Requirements Animation • Automated Reasoning • Analogical and Case-based Reasoning • Knowledge based Critiquing • Consistency Checking

14. 6. Communicating Requirements • Requirement Management “ The ability, not only to write requirements but also to do so in a form that is readable and traceable by many, in order to manage their evolution over time ” • Requirement Traceability (RT) “ The ability to describe and follow life of a requirement in both forwards and backwards direction ”

15. 7. Agreeing Requirements • Maintaining agreement with the stakeholders can be a problem • Validation “ Validation is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements ” • Validation is difficult for two reasons: • Question of truth and what is knowable • Reaching agreement among different stakeholders

16. 8. Evolving Requirements • Adding requirements • Changing stakeholder needs • Missed in initial analysis • Requirement Scrubbing – Removing requirements • Usually only during development, to forestall cost and schedule overruns • Manage inconsistency in requirements • Managing changing requirements • Continued requirement elicitation • Evaluation of Risk • Evaluation of systems in the environment

17. 8. Evolving Requirements (contd.) • Product Family • Increasingly important form of development activity • Range of software product that share similar requirements and architectural characteristics, yet differ in certain key requirements • Research issue : Identifying the core requirements for the architectures that are: • Stable in the presence of change • Flexible enough to be customized and adapted to changing requirements

18. 9. Integrated Requirements Engineering • Different approaches to manage and integrate RE activities: • Problem Frames • Viewpoints • Automated tools: • DOORS • Requisite Pro • Cradle

19. 10. Requirement Engineering Roadmap • Three radical ideas • Modeling and analysis cannot be performed adequately in isolation from the organizational and social context in which the new system will have to operate • RE should not focus on specifying the functionality of a new system, but instead should concentrate on modeling indicative and optative properties of the environment • Attempt to build consistent and complete requirement models is futile.

20. What's the Future ? • New techniques for formally modeling and analyzing properties of the environment • Richer model for capturing and analyzing non-functional requirements • Bridging the gap between requirements elicitation apporaches. • Better understanding of software architectural choices • Reuse of requirement models • Multidisciplinary training of requirements practitioners