CH 06 Hout

Requirements engineering processes
The processes used in requirement engineering vary widely

depending on the application domain, the people involved and
the organization developing the requirements. Nevertheless,
Chapter 6 there are four activities common to all:
• Requirements elicitation
Requirements Engineering Processes • Requirements analysis
Processes used to discover, analyze, and • Requirements validation
validate system requirements • Requirements management
©IS&JCH050207 Software Engineering, Chapter 6 Slide 0 of 55 ©IS&JCH050207 Software Engineering, Chapter 6 Slide 1 of 55
The requirements engineering process Feasibility studies

Feasibility Requirements Designed to determine whether or not the proposed
elicitation and
study
analysis
Requirements
system
specification • will contribute to organizational objectives,
Feasibility Requirements
report validation • can be built with current technology within budget, and
System
models • can be integrated with other systems in use.
User and system
requirements
Requirements
document
Feasibility study (continued) Elicitation and analysis

● It involves information assessment, information ● It involves the technical staff working with the
collection and report writing. customers to understand the application domain, and to
● Questions for people in the organization determine the services that the system should provide
• What if the system wasn’t implemented? as well as the system's operational constraints.
• What are current process problems? ● May involve end-users, managers, engineers involved
• How will the proposed system help?
in maintenance, domain experts, trade unions, etc.
• What will be the integration problems?
• Is new technology needed? What skills?
They are called stakeholders.
• What must be supported by the proposed system?
Problems of requirements analysis Elicitation and analysis activities
● Stakeholders don’t know what they really want. ● Domain understanding
● Stakeholders express requirements in their own terms. ● Requirements collection
● Stakeholders may have conflicting requirements. ● Classification
● Organizational and political factors may influence the ● Conflict resolution
system requirements. ● Prioritization
● The requirements may change during the analysis ● Requirements checking
process due to emergence of new stakeholders or
change in business environment.
Elicitation and analysis process Viewpoint-oriented elicitation

Requirements
definition and ● Stakeholders represent different ways of looking
specification
Requirements
validation
at a problem
● This multi-perspective analysis is important as
Domain
Prioritization there is no single correct way to analyze system
understanding
Process requirements
entry
Requirements Conflict
collection resolution
Classification
Banking ATM system Different viewpoints toward an ATM

● The example used here is an automated-teller- ● Bank customers
machine system which provides some automated ● Representatives of other banks
banking services. ● Hardware and software maintenance engineers
● It is a simple system that offers some services to ● Marketing department
customers of the bank who own the system and a
narrower range of services to other customers. ● Bank managers and counter staff
● Services include cash withdrawal, message ● Database administrators and security staff
passing (send a message to request a service), ● Communications engineers
ordering a statement and transferring funds. ● Personnel department
Types of viewpoint External viewpoints
● Data sources or sinks ● Viewpoints are a natural way to structure
Viewpoints are responsible for producing or consuming data. requirements elicitation process
Analysis involves checking that data is produced and consumed and
that assumptions about the source and sink of data are valid. ● It is relatively easy to decide if a viewpoint is
● Representation frameworks valid
Viewpoints represent particular types of system model. These may be ● Viewpoints and services may be used to structure
compared to discover requirements that would be missed using a non-functional requirements
single representation. Particularly suitable for real-time systems.
● Receivers of services
Viewpoints are external to the system and receive services from it.
Most suited to interactive systems.
Method-based analysis The VORD method

● A widely used approach, it depends on the application
of a structured method to understand the system.
● Methods have different emphases. Some are designed
for requirements elicitation, others are close to design
Viewpoint Viewpoint Viewpoint Viewpoint
methods identification structuring documentation system mapping
● A viewpoint-oriented method (VORD) is used as an

example here. It also illustrates the use of viewpoints.
VORD process model VORD standard forms

Viewpoint template Service template
● Viewpoint identification Reference: The viewpoint name. Reference: The service name.
Attributes: Attributes providing Rationale: Reasonwhy the service is
Discover viewpoints which receive system services and identify viewpoint information. provided.
the services provided to each viewpoint Events: A reference to a setevent
of Specification: Reference tolist
a of service
scenarios describinghow specifications. These may
● Viewpoint structuring the system reacts to be expressed in different
Group related viewpoints into a hierarchy. Common services are viewpoint events. notations.
provided at higher-levels in the hierarchy Services A reference to a set of Viewpoints: List of viewpoint names
service descriptions. receiving the service.
● Viewpoint documentation Sub-VPs: The names of sub- Non-functional Reference toa set of non -
Refine the description of the identified viewpoints and services viewpoints. requirements: functional requirements
which constrain the service
● Viewpoint-system mapping Provider: Reference tolist
a of system
Transform the analysis to an object-oriented design objects which provide the
service.
Viewpoint identification Viewpoint service information
Query Get Customer Cash Transaction
balance transactions database withdrawal log
ACCOUNT FOREIGN BANK
HOLDER CUSTOMER TELLER
Manager Card Remote
Machine returning Order
software Service list Service list Service list
supplies cheques
upgrade
Account Message Software
information log size Withdraw cash Withdraw cash Run diagnostics
Bank Invalid
User teller user Query balance Query balance Add cash
interface System cost Foreign
customer Printe Order cheques Add paper
r Security Send message Send message
Account Stolen Order Hardware Transaction list
card statement Card
holder maintenance retention Order statement
Message
passing Transfer funds
Remote Update Funds Card
Reliability account transfer
diagnostics validation
Viewpoint data/control Viewpoint hierarchy

All VPs
ACCOUNT Services
HOLDER Control input Data input Query balance
Withdraw cash Customer Bank staff
Start transaction Card details
Cancel transaction PIN
End transaction Amount required
Account Foreign
Select service Message Services
holder customer
Teller Manager Engineer
Order cheques
Send message
Transaction list
Order statement
Transfer funds
Customer/cash withdrawal templates Scenarios

Reference: Customer Reference: Cash withdrawal
● Scenarios are descriptions of how a system is used in
Attributes: Account number
PIN
Rationale: To improve customer service
and reduce paperwork practice.
Events:
Start transaction
Select service Specification: Users choose this service by ● They are helpful in requirements elicitation as people
Cancel
transaction
pressing the cash withdrawal
button. They then enter the
can relate to these more readily than abstract
End transaction amount required. This is statement of what they require from a system.
confirmed and, if funds allow,
Services: Cash withdrawal the balance is delivered. ● Scenarios are particularly useful for adding detail to
Balance enquiry
VPs: Customer an outline requirements description.
Sub-VPs: Account holder
Foreign Non-funct. Deliver cash within 1 minute
customer requirements: of amount being confirmed
Provider: Filled in later
Scenario descriptions Event scenarios
● System state at the beginning of the scenario ● Event scenarios may be used to describe how a
● Normal flow of events in the scenario system responds to the occurrence of some
● What can go wrong and how this is handled particular event such as ‘start transaction’
● Other concurrent activities ● VORD includes a diagrammatic convention for
event scenarios.
● System state on completion of the scenario • Data provided and delivered
• Control information
• Exception processing
• The next expected event
Event scenario - start transaction Notation for data and control analysis
Card present
Valid card ● Ellipses. data provided from or delivered to a

User OK
viewpoint
Card
Request PIN
PIN
Account Validate user Account ● Control information enters and leaves at the top
number
number
PIN
Select
service of each box
Timeout
Return card Incorrect PIN ● Data leaves from the right of each box
Re-enter PIN ● Exceptions are shown at the bottom of each box
Invalid card
Return card ● Name of next event is in box with thick edges

Incorrect PIN
Stolen card Return card
Retain card
Exception description Use cases

● Most methods do not include facilities for describing ● Use-cases are a scenario based technique in the UML
exceptions which identify the actors in an interaction and which
● In this example, exceptions are describe the interaction itself
• Timeout. Customer fails to enter a PIN within the allowed time limit ● A set of use cases should describe all possible
• Invalid card. The card is not recognized and is returned interactions with the system
• Stolen card. The card has been registered as stolen and is retained by
the machine ● Sequence diagrams may be used to add detail to use-
cases by showing the sequence of event processing in
the system
Lending use-case Library use-cases
Lending services
Library
User
User administration
Library
Lending services Staff
Supplier Catalog services
Social and organizational factors Example

● Software systems are used in a social and ● Consider a system which allows senior
organizational context. This can influence or even management to access information without going
dominate the system requirements through middle managers
● Social and organizational factors are not a single • Managerial status. Senior managers may feel that they are too
important to use a keyboard. This may limit the type of system
viewpoint but are influences on all viewpoints interface used
● Good analysts must be sensitive to these factors but • Managerial responsibilities. Managers may have no
uninterrupted time where they can learn to use the system
currently no systematic way to tackle their analysis • Organizational resistance. Middle managers who will be made
redundant may deliberately provide misleading or incomplete
information so that the system will fail
Ethnography Focused ethnography

● It is an observational technique that can be used to ● Developed in a project studying the air traffic
understand social and organizational requirements control process
● An analyst immerses himself in the working ● Combines ethnography with prototyping
environment where the system will be used ● Prototype development results in unanswered
● The day-to-day work is observed and notes made of questions which focus the ethnographic analysis
the actual tasks in which participants are involved ● Problem with ethnography is that it studies
● The value of ethnography is that it helps discover existing practices which may have some
implicit system requirements historical basis which is no longer relevant
Ethnography and prototyping Scope of ethnography
● Requirements that are derived from the way that
people actually work rather than the way in which
Ethnographic Debriefing Focused process definitions suggest that they ought to
analysis meetings ethnography
work
Prototype
evaluation ● Requirements that are derived from cooperation
Generic system System and awareness of other people’s activities
development protoyping
Requirements validation Requirements checking

● Concerned with demonstrating that the requirements ● Validity. Does the system provide the functions which
define the system that the customer really wants best support the customer’s needs?
● Requirements error costs are high so validation is ● Consistency. Are there any requirements conflicts?
very important ● Completeness. Are all functions required by the
• Fixing a requirements error after delivery may cost up to 100 times customer included?
the cost of fixing an implementation error
● Realism. Can the requirements be implemented given
available budget and technology
● Verifiability. Can the requirements be checked?
Requirements validation techniques Requirements reviews

● Requirements reviews ● Regular reviews should be held while the
• Systematic manual analysis of the requirements requirements definition is being formulated
● Prototyping ● Both client and contractor staff should be involved in
• Using an executable model of the system to check requirements. reviews
Covered in Chapter 8
● Reviews may be formal (with completed documents)
● Test-case generation
• Developing tests for requirements to check testability
or informal.
● Consistency analysis
• Checking the consistency of a structured requirements description
Review checks Automated consistency checking
● Verifiability. Is the requirement realistically
Requirements Requirements
testable? in a formal language problem report
● Comprehensibility. Is the requirement properly
understood?
Requirements Requirements
● Traceability. Is the origin of the requirement processor analyser
clearly stated?
● Adaptability. Can the requirement be changed Requirements
database
without a large impact on other requirements?
Requirements management Requirements change

● It is the process of managing changing requirements ● The priority of requirements from different viewpoints
during the requirements engineering process and changes during the development process.
system development ● System customers may specify requirements from a
● Requirements are inevitably incomplete and business perspective that conflict with end-user
inconsistent requirements.
• New requirements emerge during the process as business needs ● The business and technical environment of the system
change and a better understanding of the system is developed
• Different viewpoints have different requirements and these are often changes during its development
contradictory
Enduring and volatile requirements Classification of requirements

● Enduring requirements. Stable requirements ● Mutable requirements
derived from the core activity of the customer • Requirements that change due to the system’s environment
organization. E.g. a hospital will always have ● Emergent requirements
doctors, nurses, etc. May be derived from domain • Requirements that emerge as understanding of the system develops
models ● Consequential requirements
● Volatile requirements. Requirements which • Requirements that result from the introduction of the computer system
change during development or when the system is ● Compatibility requirements
in use. In a hospital, requirements derived from • Requirements that depend on other systems or organizational
processes
health-care policy
Requirements management planning Traceability
Plan for: Three types of traceability information may be maintained:
● Requirements identification: How requirements are ● Source traceability
individually identified? • Links from requirements to stakeholders who proposed these
● A change management process: How to assess the requirements
impact and cost of changes? ● Requirements traceability
● Traceability policies: What relationships among • Links between dependent requirements
requirements and system design need to be ● Design traceability
maintained? • Links from the requirements to the design
● CASE tool support
A traceability matrix CASE tool support

Req 1.1 1.2 1.3 2.1 2.2 3.1 3.2 3.3 ● Requirements storage
1.1 U R • Requirements should be managed in a secure, managed data store
1.2 U R U ● Change management
1.3 R R • The process of change management is a workflow process whose
stages can be defined and information flow between these stages
2.1 R U partially automated.
2.2 U ● Traceability management
3.1 R U • Automated retrieval of the links among requirements
3.2 R
3.3 R
Requirements change management A common problem

● Should apply to all proposed changes to the If a requirements change to a system is urgently
requirements required, there is always a temptation to make
● Principal stages that change to the system and then retrospectively
1. Problem analysis. Discuss requirements problems and modify the requirements document.
propose changes
2. Change analysis and costing. Assess effects and costs of Resist this temptation!
change on other requirements
3. Change implementation. Modify requirements document
and other documents to reflect change
Key points Key points (continued)
● The process includes a feasibility study, and elicitation, ● Social and organizational factors influence system
analysis, specification, and management of requirements.
requirements. ● Requirements validation is concerned with checks for
● Requirements analysis involves domain understanding, validity, consistency, completeness, realism and
and requirements collection, classification, structuring, verifiability.
prioritization, and validation. ● Business changes inevitably lead to changes in
● Each system have multiple stakeholders with different requirements.
requirements. ● Requirements management includes planning and
change management.

CH 06 Hout

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 06 Hout

Uploaded by

Copyright:

Available Formats

Requirements engineering processes

The processes used in requirement engineering vary widely

The requirements engineering process Feasibility studies

Feasibility study (continued) Elicitation and analysis

Elicitation and analysis process Viewpoint-oriented elicitation

Banking ATM system Different viewpoints toward an ATM

Method-based analysis The VORD method

● A viewpoint-oriented method (VORD) is used as an

VORD process model VORD standard forms

Viewpoint data/control Viewpoint hierarchy

Customer/cash withdrawal templates Scenarios

Provider: Filled in later

Valid card ● Ellipses. data provided from or delivered to a

Return card ● Name of next event is in box with thick edges

Stolen card Return card

Exception description Use cases

Supplier Catalog services

Social and organizational factors Example

Ethnography Focused ethnography

Requirements validation Requirements checking

Requirements validation techniques Requirements reviews

Requirements management Requirements change

Enduring and volatile requirements Classification of requirements

A traceability matrix CASE tool support

Requirements change management A common problem

You might also like