Introduction to Requirements Engineering

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

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion

3
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? Approa
ches to Requirements Engineering
4
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..
5
What is RE about?
Tentative Definition
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
6
What is RE about?
Mission statement, goals
WHY ?
The Requirements Engineering process
Requirements Specification
WHAT ?
7
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)
8
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

9
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)
10
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
11
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
12
Why is RE Needed ?
" Inadequate, Inconsistent, Incomplete or
ambiguous requirements are numerous and have a
critical impact on the quality of the resulting
software" (BellTayer76)
"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)
13
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
• ( gt50) - (ESI96)
• 3800 organisations in 17 European countries

14
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
15
Exercise
Decide what is to be the contents of a student
registration system for your University
16
Outline

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion

17
The Conventional View Point
"Abstracting from the users wishes, constraints,
needs.. the conceptual specification of the
system to build the acquisition, modelling,
validation cycle
Acquisition of domain knowledge and IS
specification
Validation
CONCEPTUAL SCHEMA
WHAT
Requirements Engineering
Design
Correction
Requirements specification conceptual
specification
INTERNAL SCHEMA
HOW
System Engineering
18
Modelling Perspectives
Three perspectives Data, Function, Behaviour
Data
Data Driven Approaches
E/R
CIAM
NIAM
SHM
REMORA
ERAE
MERISE
Behavioural Temporal Approaches
Function
SADT
IE
Structured Analysis Design Approaches
(Rolland01)
SART
Behaviour
19
Modelling Perspectives
Data
Function
Behaviour
20
Modelling Perspectives
Data
Function
Behaviour
21
Modelling Perspectives
Data
Request Arrival
Create
Update
Wait List
Room Availability
Reservation
Request
Increased availability
Function
Create
Update
Behaviour
22
Integrating Perspectives
23
Integrating Perspectives
Data
Function
Behaviour
24
Exercise
Place the method that you are most familiar
within the framework
Place OMT in the framework
25
Limits Assumptions of Conventional Approaches

• Requirements are supposed to be stable and
  known
• Users just need to be questioned about their
  needs
• RE is too much centred on the technical
  solution
• Notations are far too abstract
• RE is driven by computer engineers

26
Revisiting Conventional Approaches
Embed schema production in organisational
context modelling
WHY
WHAT
HOW
27
New RE perspectives

• Enlarge modelling scope from E/R to EM
• (from modelling system functions to modelling the
  organisational context of the system to be built)
• Consider requirements as a lifecycle 'product'
• Rethink the RE process
• requirements need to be elicited, discovered,
  grown!
• Intensify participation of various stakeholders
  engineering requirements must be a co-operative
  activity involving domain experts, engineers,
  business executives etc..

28
RE in a ChangePerspective
Elaborate the change vision in its
organisational context (Jarke93)
New model (To-Be)
Initial model (As-Is)
Change definition
Change implementation
Reverse analysis
Legacy integration
New system
Existing system
29
Outline

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• Bibliography
• Conclusion

30
RE Framework
Structuring the context The worlds of
Requirements Engineering
How does IS represent information about the
Subject World
SUBJECT
How is Information about Subject World used in
the IS environment

WORLD
Intentional relationship
SYSTEM WORLD
Usage fit relationship
DEVELOPMENT
Design
Justification of
decisions
WORLD
development goals
(Jarke92, Jarke93)
31
RE Framework
2 sources of requirements
Understanding the Intentional Relationship is
essential to comprehend the system rationale
The social perspective
SUBJECT
WORLD
System Environment
USAGE
Goal driven approaches
WORLD
Intentional Relationship
SYSTEM
WORLD
32
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
33
RE Framework
Understanding the Domain Genericity Relationship
helps eliciting generic requirements
2 sources of requirements
SUBJECT
WORLD
System Environment
Domain Genericity relationship
USAGE
WORLD
Usage Fit relationship
SYSTEM
Intentional relationship
WORLD
34
Outline

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion

35
Usage World and IS Rationale
The usage world is the social and organisational
environment in which the system is intended to
function Goal driven analysis is an approach to
link the various parts the usage world among them
and with the system.
Modelling this link allows to understand WHY a
new system has to be developed or a legacy system
has to be revised
36
The EKD Approach
Modelling organisational objectives to derive
functional and non-functional system
requirements, (Bubenko94)
37
Example Car Repair Shop
38
Example Car Repair Shop
39
Example Car Repair Shop
40
Example Car Repair Shop
41
Exercise
Write one path from a high level objective to
requirements in the student registration system
42
Scenario Based RE
The User point of view
43
Example The Meeting Scheduler
Temporal sequence of interactions between the
system-to-be its environment
(Potts94)
44
Scenario Based RE
Scenarios are important artefacts used for a
variety of purposes - elicitation of
requirements (Potts94, Rolland98) - identify
exceptional cases (Potts95) - to populate
abstract models (Rumbaugh91, Rubin92) - to
validate requirements in conjunction with
prototyping (Sutcliffe98), animation
(Dubois93), or plan generation tools (Fickas92)
and generate acceptance tests (Hsia94)
The use of scenarios raise problems coverage,
combinatorial explosion, procedural nature,
leave intended system properties implicit,
force to premature choices
45
Outline

• Overview Picture
• Conventional Approaches
• RE Framework
• Recent Approaches
• About the RE process
• Bibliography
• Conclusion

46
The RE process
The development world is concerned with methods,
models and tools to support the RE process
It is necessary to improve the maturity level of
development teams Including RE teams
(Humphrey89)
47
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

48
Pohls View
Understanding the process
(Pohl94)
49
Pohls view of the RE process

• Elicitation/specification (representation axis)
• Requirements shall be discovered and specified
• according to some representation system
• Negotiation (agreement axis)
• Requirements might be conflicting with one
  another and
• must be negotiated depending on their costs and
  priority
• Compliance to standards (specification axis)
• Requirements must comply with quality standards

50
Pottss ViewInquiry Cycle Model
Expression - requirements documents - goals -
scenarios Discussion - questions - answers - open
questions Commitment - change requests
(Potts94)
51
Tracing the RE Process
Example of trace model IBIS
Argument
Position
Pro ()
Con (-)
Is a response to
is suggested by
Issue
52
Tracing the RE ProcessPottss example
53
Guiding the RE ProcessNATURE example
(a) Guidance is based on situated knowldge
cardinality 0
o.n
SITUATION
Car
owns
(b) Guidance suggests improvements decision to
partition ET
DECISION
"Partition" the ET Person
(c) If guidance is embedded in a CASE tool the
decision is applied automatically
Person
ACTION
is.a
is.a
1.n
Car owner
Car
Non car owner
owns
(Rolland96)
ARGUMENT to remove Null values
54
Process centred environment framework
Process Model Domain
Real World Development Domain
Agents,
Activities
Process models Methods
Enactment
Guidance
Control
Enactment Domain
Process Tracing gt Trace Model Process
Guidance gt Guidance Model
55
Process Management Aspects

• CMM Adaptation to RE processes
• (Ian Sommerville Peter Sawyer
• Requirements Engineering A Good practice Guide,
  
• Wiley 1997)
• IEE standard
• IEEE/ANSI 830-1993
• IEEE/ANSI 830-1998
• Standards, Guidelines and Examples on System and
  Software
• RE, M.Dorfman, R.H.Tayer, IEEE Computer Society
  Press, 19931998
• CASE tools for requirements management
• DOORS , Quality Software Software
• RequisitePro 4.0, Rational Software

56
Sommervilles Adaptation of the CMM
The first three levels are reconsidered
Initial ad-hoc process definition leaving many
problems in the performance of RE processes
Repeatable definition of a list of activity
types and of a standard for documentation. Leads
to a better mastering of projects of the same
nature. Defined Guided process through
patterns of good practice. Mechanisms for process
improvement are installed.
57
Sommervilles Adaptation of the CMM
Team evaluation and process improvement are based
on guidelines classified as Basic guidelines,
Intermediate guidelines advanced guidelines
Ex the  top ten  Define a standard document
structure Make the document easy to
change Uniquely identify each requirement Define
policies for requirements management Define
standard templates for requirements
description Use language simply, consistently and
concisely Organise formal requirements
inspections Define validation checklist Use
checklist for requirements analysis Plan for
conflicts and conflict resolution
58
IEEE standard 830-1993
1 Introduction Purpose of the requirements
document Scope of the product Definitions,
acronyms and abbreviations References Overview
of the remainder of the document 2 General
description Product perspective Product
functions User characteristics General
constraints Assumptions and dependencies 3
Specific requirements, functional,
non-functional, and interface requirements.
59
Bibliography
Software requirements Objects, Functions and
States A.Davis, Prentice Hall, 1993  software
and structured analysis oriented   System
Requirements Engineering P. Loucopoulos, V.
Karakostas, Mcgraw-Hill, 1995  overview  Explor
ing Requirements Quality Before Design D.C
Gause, G.M. Weinberg, Dorset House, 1989  if you
like stories  Software Requirements and
Specifications A Lexicon of Practise,
Principles and Prejudices M. Jackson, Addison
Wesley, 1995  good 
60
Bibliography
Requirements Engineering A Good Practice
Guide Ian Sommerville Pete Sawyer, John Wiley,
1998  a  cookbook  CMM  like Mastering the
Requirements Process S. Robertson, J. Roberston,
Addison Wesley, 1999   the GUILDE view point
the Amazon's must in 2002 Non-Functional
Requirements in Software Engineering L. Chung,
B.A. Nixon, E. Yu, J. Mylopoulos, Kluwer,
2000  THE book on NFR!  System and Software
Requirements Engineering R.H. Thayer, M. Dorfman,
2nd ed 1999, IEEE Computer Press  selected
papers on RE 
61
Conclusion

• Abandon the 'system' centred approach
• Favour the 'usage' view point
• Forget about system analyst prominence
• Prefer a 'facilitator' to conduct co operative
  work
• with all concerned stakeholders
• Define the RE process, trace and guide it

62
Readings
1- From Conceptual Modelling to Requirements
Engineering C. Rolland, N. Prakash Special
issues of Annals of Software Engineering on
Comparative Studies of Engineering Approaches,
2001
2- The Three Dimensions of Requirements
Engineering a framework and its application K.
Pohl Information Systems Vol 19, N 3, pp
243-258, 1994