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