1. Introduction to Requirements Engineering
“The hardest single part of building a software system is deciding precisely what to build”-F.Brooks

2. Overview Picture What is Requirements Engineering about? What is RE?
Notion of a requirement
The requirements engineering process
Why Requirements Engineering is needed?
When to Engineer Requirements?
Approaches to Requirements Engineering

3. What is RE about? The WHY question
Why the system needs to be developed?
The WHAT question
What the system shall do?
« Requirements definition must say
– why a system is needed, based on current or foreseen conditions,
– what system features will satisfy this context,
……………….» (Ross77)
IEEE Computer 85, IEEE SE 91-92, Bubenko94, Mylopoulos92,
Dardenne93, Loucopoulos95, Rolland98 etc..

4. What is RE about? Tentative Definition WHY
Requirements Engineering is the activity which transforms a fuzzy idea into a precise specification of stakeholders’ needs that shape the system to be built and therefore, defines the intended link between a system and its environment
WHAT

5. What is RE about? WHY ? WHAT ? Mission statement, goals
The Requirements
Engineering process
Requirements
Specification
WHAT ?

6. What is a Requirement? “Something that the product must do or
a quality that the product must have” (Robertson99)
“A description of how the system shall behave, an information
about the application domain, constraints on operations,
a system property etc.” (Kotonya98)
“A requirement specifies how a goal should be accomplished by a
proposed system” (Anton96)

7. What is a Requirement? Examples
a constraint : the system shall include a spelling checker
a required function : the system shall identify “old customers”
a required quality : the print out for old customers shall be in colour

8. What is a Requirement? Requirements taxonomy
Functional (1) versus non functional (2)
(1) Things the system must do
(2) Qualities that the product must have
Ex : Send Christmas cards to old customers(1)
print them in colour (2)

9. A complex process with intertwined activities and multiple actors
What is Engineering Requirements?
A complex process with intertwined activities and multiple actors
User
Client
Requirements
Engineer
Elicitation
Validation
Project
manager
facilitator
Specification
Documentation
Negotiation
Domain
expert
System
Analyst

10. What is Engineering Requirements ?
Modelling as a core activity
The existing system (As-Is) has to be modelled
The alternative hypothetical systems (To-Be) have to be modelled
Models serve as a basic common interface to the RE activities
(previous slide)
Models provide the basis for documentation and evolution
What aspects to model in the Why-What range?
How to model such aspects?
How to define the model precisely?
How to reason about the model?
Questions

11. Why is RE Needed ?
" Inadequate, Inconsistent, Incomplete or ambiguous requirements
are numerous and have a critical impact on the quality
of the resulting software" (Bell&Tayer76)
"Late correction of requirements errors
cost up to 200 times as much as during such
requirements engineering" (Boehm81)
"The primary cause of safety-related faults was errors in functional
interface requirements " NASA's Voyager and Galileo programs,
(Brooks87)

12. Why is RE Needed ?
Poor requirements are major source of failures (Standish95)
8000 projects, 350 US companies :
1/3 of projects never completed & 50% succeeded only partially
Most perceived problems are related to requirements specification
( >50%) - (ESI96)
3800 organisations in 17 European countries

13. When to Model Requirements ?
Traditionally : the early phase of the software development cycle
RUP,
(Jacobson98)
Inception
Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
Tests
Life Cycle
Objectives
Life Cycle
Architecture
Initial Operational
Capability
Product
Release

14. Decide what is to be the contents of a student registration system for
Exercise
Decide what is to be the contents of a student registration system for
your University

15. is essential to meet users'
RE Framework
2 sources of
requirements
Understanding the
Usage Fit
Relationship
is essential to meet users'
expectations
The individual,
pragmatic
perspective
SUBJECT
WORLD
System
Environment
Scenario Driven
Approaches
USAGE
WORLD
Usage Fit
relationship
SYSTEM
WORLD

16. The “User” point of view
Scenario Based RE
The “User” point of view
Requirements
Collection
Actor C
Actor A
Actor B
Every Actor has his/her view on how to use the system
Scenario 1
System
Actor A
Actor B
Scenario
Every Actor describes the way he/she would like to interact with the system

17. Example : The Meeting Scheduler
Temporal sequence of interactions between the system-to-be & its environment
Example : The Meeting Scheduler
(Potts94)

18. It is necessary to improve the maturity level of development teams
The RE process
The development world is concerned with methods, models and tools to support the RE process
Maturity levels
• INITIAL
• REPEATABLE
• DEFINED
• MANAGED
• OPTIMISED
(80%)
It is necessary to improve the
maturity level of development teams
Including RE teams
(Humphrey89)

19. How to improve the current practice?
The RE process
How to improve the current practice?
Improving methods : the methodological impact
From handicraft to industrial performance:
formalisation of the RE process (definition of process models)
and tool driven guidance
Improving RE process management : the managerial
impact
Continuous improvement cycle
and mechanisms for capitalising from experience

20. Tracing the RE Process

21. 1. Introduction Requirement Engineering – A Roadmap Abstract
Success of a software ?
How to know the purpose ?
Identifying stakeholders
Identifying needs of stakeholders
Creating documentation for:
Analysis
Communication
Implementation

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

23. 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. ”

24. 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

25. 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

26. 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

27. 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

28. 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

29. 5. 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 ”

30. 6. 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

31. 7. 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

32. 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

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

34. 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.

35. 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 approaches.
Better understanding of software architectural choices
Reuse of requirement models
Multidisciplinary training of requirements practitioners