LECTURE 4

REQUIREMENTS ENGINEERING PROCESSES

CSE 2142 Software Engineering

 Objectives
2

 To describe the principal requirements engineering

activities and their relationships
 To introduce techniques for requirements elicitation
and analysis
 To describe requirements validation and the role of
requirements reviews
 To discuss the role of requirements management in
support of other requirements engineering
processes
 Challenges faced by Software Engineers
3
 Need for Requirements Engineering
4

 Understanding the requirements of a problem is among

the most difficult tasks faced by a software engineer.
 Just imagine a customer walking in your office and
saying “I know you think you understand what I said, but
what you don’t understand is what I said is not what I
mean”
 Unfortunately these nightmares are very common in the
software industry and prove to be very costly as well.
 Requirements Engineering provides a solid approach
for addressing these challenges
 Requirements Engineering
5

 Requirements Engineering is a process that involves all the

activities required to create and maintain a system requirements
document.
 RE provides the appropriate mechanism for
 understanding what the customer wants,
 analyzing need,
 assessing feasibility,
 negotiating a reasonable solution,
 specifying the solution unambiguously,
 validating the specification,
 managing the requirements as they are transformed into an
operational system.
 Requirements Engineering Activities
6

Requirement s
Feasibility Syst em requi rement s
specificat io n

studies specificat io n an d
mo deling

Requirements User requi rement s

specificat io n
elicitation and
analysis Busin ess requirement s
specificat io n

Requirements Syst em
validation requi rement s
elicit at ion
User
Feasibilit y
st udy
requi rement s
elicit at ion
Requirements Prot ot ypi ng

management
Requirement s
elicit at ion
Reviews Requirement s
validat ion

Sys tem requi rements

do cument

Spiral model of requirements engineering processes

 Feasibility Study (1)
7

 A feasibility study is a short, focused study which

aims to answer the following questions
 Does the system contribute to the overall objectives of the
organisation?
 Can the system be implemented using current technology
and within given cost and schedule constraints?
 Can the system be integrated with other systems which
are already in place?
 Feasibility Study (2)
8

 Carrying out a feasibility study involves

 information assessment phase identifies the information
which is required to answer the three questions set out
above
 Information collection: users, managers, experts are
interviewed to obtain relevant information.
 The input to the feasibility study is an outline description
of the system and how it will be used within an
organisation and the output should be a report which
recommends whether or not it is worth carrying on.
 Requirements Elicitation and Analysis (1)
9

 Concerned with learning and understanding the needs

of users and project sponsors with the ultimate aim of
communicating these needs to the system developers
 Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints
 May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
 Requirements Elicitation and Analysis (2)
10

 Stakeholders
 Any person or group who will be affected by the
system, directly or indirectly
 End-users
 Managers
 Engineers involved in development or maintenance
 Domain experts
 Trade union reps
 Requirements Elicitation and Analysis
11
Process (1)
Requirements
discovery

Requirements Requirement s
classificat ion and
Requirement s
priorit izat io n and
classification organi sat ion nego ti at ion

and
organisation

Requirements
prioritisation Requirement s Requirement s

and discov ery document at io n

negotiation

Requirements
documentation
 Requirements Elicitation and Analysis
Process (2)
12

 Requirements Discovery
 The process of interacting with stakeholders in the
system to collect their requirements.
 Domain requirements from stakeholders and
documentation are also discovered during this activity
 Requirements Classification and organisation
 Thisactivity takes the unstructured collection of
requirements, groups related requirements and
organises them into coherent clusters
 Requirements Elicitation and Analysis
Process (3)
13

 Requirements Prioritisation and Negotiation

 When it comes to selecting between different choices, it
becomes important to prioritize between the alternatives
 Prioritization helps to identify the most valuable
requirements from this set by distinguishing the critical few
from the trivial many
 Requirements Documentation
 The requirements are documented and input into the next
round of the spiral.
 Formal or informal requirements documents may be
produced
 Question 1
14

 Suggest who might be stakeholders in a university

student records system? Explain why it is almost
inevitable that the requirements of the different
stakeholders will conflict in some way
 Question 2
15

 Eliciting and understanding stakeholder

requirements is difficult for several reasons. Identify
the reasons underlying the difficulty.
 Problems of Elicitation
16

 Problems of scope
 boundary of system is ill-defined
 unnecessary design information may be given
 Problems of articulation
 users are aware of their needs but are unable to articulate them or afraid to articulate it
 users may not be aware of their needs
 Communication barriers
 user and analyst speak different languages
 limitations of the communication language
 Cognitive limitations
 analysts have poor knowledge of problem domain
 users have poor understanding of computer capabilities and limitations

 Technical issues
 requirements evolve over time
 rapid software & hardware technology changes
 Techniques for Requirements Elicitation
17
and Analysis (1)
 Viewpoints
 A way of structuring the requirements to represent the perspectives of
different stakeholders
 Interactor viewpoints
 People or other systems that interact directly with the system
 Indirect viewpoints
 Stakeholders who do not use the system themselves but who influence the
requirements
 Domain viewpoints
 Domain characteristics and constraints that influence the requirements
 Interviewing
 The RE team puts questions to stakeholders about the system that they
use and the system to be developed
 Closed interviews
 A pre-defined set of questions are answered
 Open interviews
 No pre-defined agenda and a range of issues are explored with
stakeholders
 Techniques for requirements elicitation
18
and analysis (2)
 Scenarios
 Real-life examples of how a system can be used
 A description of the starting situation
 A description of the normal flow of events
 A description of what can go wrong
 Information about other concurrent activities
 A description of the state when the scenario finishes
 Use-cases
 Scenario-based technique in the UML which identify the actors in
an interaction and which describe the interaction itself
 Ethnography
 Observation of the day-to-day work and notes made of the
actual task in which participants are involved
 Viewpoint-Oriented Analysis
19

 Stakeholders represent different ways of looking at a

problem or problem viewpoints
 This multi-perspective analysis is important as there is
no single correct way to analyse system requirements
 However, their perspectives are not completely
independent but usually overlap so that they have
common requirements.
 The VORD (Viewpoint- Oriented Requirements Definition)
method designed in 1996-1998 by Sommerville &
Kotonya as a service oriented framework for
requirements elicitation & analysis
 Types of viewpoint
20

 Data sources or sinks

 Viewpoints are responsible for producing or consuming data.
Analysis involves checking what data is produced and consumed and
validate assumptions.
 Representation frameworks
 Viewpoints represent particular types of system model. Each model
discovers different requirements.
 Receivers of services
 Viewpoints are external to the system and receive services from it.
Most suited to interactive systems
 Viewpoints as data source/sinks & representation are
particularly valuable for discovering requirements conflict.
 The VORD method
21

Viewpoint Viewpoint Viewpoint Viewpoint

identification structuring documenta tion system ma pping

 Viewpoint identification: Discover viewpoints which receive

system services and identify the services provided to each
viewpoint
 Viewpoint structuring: Group related viewpoints into a
hierarchy.
 Viewpoint documentation: Refine the description of the
identified viewpoints and services
 Viewpoint-system mapping: Transform the analysis to an
object-oriented design
 Autoteller viewpoints
22

 The example used here is an auto-teller system which

provides some automated banking services which include
cash withdrawal, message passing ,ordering a statement
and transferring funds
 The viewpoints are
 Bank customers
 Representatives of other banks
 Hardware and software maintenance engineers
 Marketing department
 Bank managers and counter staff
 Database administrators and security staff
 Communications engineers
 Personnel department
 Viewpoint identification
23

Query Get Customer Cash Transaction

balance transactions database withdrawal log

Manager Card Remote

Machine Order
returning software
supplies cheques
upgrade
Account Message Software
information log size Bank Invalid
User teller user
interface System cost Foreign
customer Printe
r Security
Account Stolen Order Hardware
card statement Card
holder maintenance retention
Message
passing
Remote Update Funds Card
Reliability account transfer
diagnostics validation
 Viewpoint Structuring
24

All VPs

Services
Query balance
Withdraw cash Customer Bank staff

Services Account Foreign

Teller Manager Engineer
holder customer
Order cheques
Send message
Transaction list
Order statement
Transfer funds
 Viewpoint Documentation
25

Reference: Customer Reference: Cash withdrawal

Attributes: Account number Rationale: To improve customer service

PIN and reduce paperwork
Start transaction
Events: Select service Specification: Users choose this service by
Cancel pressing the cash withdrawal
transaction button. They then enter the
End transaction amount required. This is
confirmed and, if funds allow,
Services: Cash withdrawal the balance is delivered.
Balance enquiry
VPs: Customer
Sub-VPs: Account holder
Foreign Non-funct. Deliver cash within 1 minute
customer requirements: of amount being confirmed

Provider: Filled in later

 Viewpoint Standard Forms
26

Viewpoin t template S ervice temp late

Ref eren ce: T he viewpoint nam e. Ref eren ce: T he service name.
Attrib utes: Attributes providing Rationale: R eason why the service is
viewpoint information. provided.
E ven ts: A reference to a set of event S pecification : R eference to a list of service
scenarios describing how specifications. These m ay
the system reacts to be expressed in different
viewpoint events. notations.
S ervices A reference to a set of Viewpoin ts: List of viewpoint names
service descriptions. receiving the service.
S ub -VPs: T he nam es of sub- Non -f un ction al R eference to a set of non -
viewpoints. requ irements: functional requirem ents
which constrain the service.
Provider: R eference to a list of system
objects which provide the
service.
 Question 3
27

 A software system is to be developed to manage

the records of patients who enter a clinic for
treatment. The records include records of the all
regular patient monitoring (temperature, blood
pressure, etc) treatments given, patient reactions
and so on. After treatment, the records of their stay
are sent to the patient’s doctor who maintains their
complete medical record. Identify the principal
viewpoints which might be taken into account in the
specification of this system and organize these using
a viewpoint hierarchy diagram.
 Question 4
28

 For the “Library manager”, “Users” and “System

managers” viewpoints identified in the library system,
LIBSYS (Diagram in next slide), suggest three requirements
that could be suggested by the stakeholders associated
with that viewpoint.
 The LIBSYS system has to include support for
cataloguing new documents where the system catalog
may be distributed across several machines. What
are likely to be the most important types of non-
functional requirements associated with the
cataloguing facilities?
 Question 4 (cont’d)
29

All VPs

Indirect Interactor Domain

Library Article Library UI Classificatio n

Fin ance Users standards system
manager providers staff

System
Students Staff Extern al Cataloguers
managers

Viewpoints in LIBSYS
 Software Requirements Validation
30

 Requirements validation is concerned with showing that the

requirements actually define the system which the customer
wants.
 Validity checks : Does the requirement meet the objectives of the system.
 Consistency checks : Requirements in the document should not conflict.
 Completeness checks : The requirements document should include
requirements which define all functions and constraints intended by the
system user.
 Realism checks : Using knowledge of existing technology, the requirements
should be checked to ensure that they can actually be implemented.
 Verifiability : requirements should be written such that a set of checks can
be designed to demonstrate that the delivered system meets that
requirement.
 Requirements Validation Techniques
31

 Reviews
 Systematic manual analysis of the requirements
 Verifiability
 Is the requirement realistically testable?
 Comprehensibility
 Is the requirement properly understood?
 Traceability
 Is the origin of the requirement clearly stated?
 Adaptability
 Can the requirement be changed without a large impact on other requirements?
 Prototyping
 Using an executable model of the system to check requirements
 Test-case generation
 Developing tests for requirements to check testability
 Requirements Management
32

Requirements management is the process of understanding and

controlling changes to system requirements.
 Different users have different requirements and priorities. It is often
discovered that priorities given to different users needs to be
changed.
 System customers impose requirements because of organisational
and budgetary constraints. These may conflict with end-user
requirements.
 The business and technical environment of the system changes and
these must be reflected in the system itself.
 New hardware may be introduced,
 business priorities may change with consequent changes in the system support
which is needed
 new legislation and regulations may be introduced which must be implemented by
the system.
 Requirements Classification
33

From an evolution perspective, requirements fall into two classes:

 Enduring requirements - These are relatively stable requirements

which derive from the core activity of the organisation and which
relate directly to the domain of the system.
Volatile requirements - These are requirements which are likely to
change during the system development or after the system has been
put into operation.
 Mutable Requirements - Requirements which change because of
changes to the environment in which the organisation is operating.
 Emergent - Requirements which emerge as the customer’s
understanding of the system develops.
 Consequential- Requirements which result from the introduction of the
computer system.
 Compatibility- Requirements which depend on the particular systems
or business processes within an organisation.
 Requirements Management Planning
34

Planning stage establishes the level of requirements management detail

which is required. During the requirements management stage, you have to
decide on:
 Requirements identification: Each requirement must be uniquely identified
that it can be cross-referenced by other requirements and so that it may be
us in traceability assessments.
 A change management process: This is the set of activities which assess
impact and cost of changes.
 Traceability policies: These policies define the relationships between
requirements and between the requirements and the system design that
should be recorded and how these records should be maintained. (Source,
Requirements & Design traceability)
 CASE tool support: Tools which may be used range from specialist
requirements management system to spreadsheets and simple database
systems.
 Requirements Change Management
35

 Requirements change management should be applied to

all proposed changes to the requirements. There are
three principal stages to a change management
process:
 Problem analysis and change specification
 The process starts with an identified requirements problem . The
problem is analysed to check that it is valid.
 Change analysis and costing
 The effect of the proposed change is using traceability
information and general knowledge of the system The cost of
making the change is estimated both in terms of the requirements
document and, if appropriate, to the system design
 Change implementation
 The requirements document and, where necessary, the system
design and implementation is modified.