Software Requirements and
the Requirements Engineering
Process
Chapters 5 and 6
References







Software Engineering. Ian Sommerville. 6th edition.
Pearson.
Code Complete. Steve McConnell. (CC)
The art of requirements triage. Alan M. Davis. Computer.
IEEE. March 2003.
Testing whether requirements are right. Robin F. Goldsmith,
JD. Go Pro Management Inc. NYC Spin Meeting. December
2004. (RG)
Software Requirements. Karl E. Wieger. Windows Press.
Dr. Gotel’s research web page
Dr. Barrett slides, NYU
Requirements elicitation and
analysis


Stakeholder: Person or group of persons who will be
affected by the system (directly or indirectly)
All stakeholders should be involved in requirements
elicitation and analysis





Stakeholders don’t know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organisational and political factors may influence the
system requirements
The requirements change during the analysis process. New
stakeholders may emerge and the business environment
change
Different techniques for requirements
elicitation and analysis

Different techniques for elicitation:








Brainstorming
Stories
Prototyping
Questionnaires
Interviewing
Viewpoint
Scenarios
Use cases
Requirements analysis

Read the paper ‘The Art of Requirements Triage’,
Alan Davis, IEEE computer, March 2003


Prioritization, estimation of the resources to satisfy
the requirements, subset of requirements that
optimizes the probability of the system’s success
MoSCoW Criteria for requirements triage:




M – Must have – mandatory requirements that are
fundamental to the system
S – Should have – important requirements that could
be omitted
C – Could have – optional requirements
W – Want to have – the requirements really can wait
Interviewing and
questionnaires



Interviewing: synchronous elicitation
technique
Questionnaires: asynchronous elicitation
technique
Based on:





Ask questions and listening/reading the answers
Be prepared to ask follow-up questions
Ask for documents you need
Log the answers (to support, complete or
contradict what was said/written)
Involve all the stakeholders
Viewpoints

Viewpoints permits us to classify stakeholders
and other sources of requirements


Multi-perspective analysis / diversity of source of
information are important
3 categories of viewpoints



Interactor viewpoints: People or other systems
that interact with the system
Indirect viewpoints: Stakeholders who do not use
the system directly but who influence the
requirements in some ways
Domain viewpoints: Domain characteristics and
constraints
Viewpoints

More specific viewpoints:






Providers and receivers of system services
Systems interfacing with the new system
Regulations and standards applying to the system
Sources of business and non-functional
requirements
Engineering viewpoints: developing, managing,
maintaining the system
Marketing viewpoints
The VORD method



This method implements a viewpoint-oriented approach for requirements
elicitation
VORD = Viewpoint Oriented Requirements Definition
It is based on:

Viewpoint identification


Viewpoint structuring




Allocating services to viewpoints
Viewpoint data/control
Group the viewpoints into a hierarchy
Viewpoint documentation



Discovering the viewpoints, services and constraints
Refine the description of the viewpoints, services and constraints
Use of a template
Viewpoint system mapping

Transform the analysis to an object-oriented design
VORD template
Vie wpoint te mplate
Re feren ce :
The viewpoint name.
Attribu tes:
Attributes
providing
viewp oint information.
Eve nts:
A reference to a set of event
scenarios describing
how
the system reacts to
viewp oint events.
S e rvices
A reference to a set of
service descriptions.
S ub-VPs:
The names of
subviewp oints.
S e rvice template
Re feren ce :
The service name.
Rationale:
Reason why the service is
provided.
S pecification:
Reference to a list of service
specifications. These
may
be expressed in different
notations.
Vie wpoints:
List of viewpoint names
receiving the service.
Non -function al
Reference to a set of non requiremen ts:
functional
requirements
which constrain the service.
Provider:
Reference to a list of system
objects which provide the
service.
Example: ATM
Viewpoint identification
Query
balance
Machine
supplies
Get
transactions
Customer
database
Account
holder
Remote
diagnostics
Card
returning
Manager
Message
log
Account
information
User
interface
System cost
Stolen
card
Reliability
Cash
withdrawal
Foreign
customer
Order
statement
Update
account
Software
size
Printe
r
Hardware
maintenance
Funds
transfer
Transaction
log
Remote
software
upgrade
Order
cheques
Bank
teller
Invalid
user
Security
Message
passing
Card
retention
Card
validation
Example: ATM
Viewpoint structuring: Allocating services to
viewpoints
ACCOUNT
HOLDER
Service list
Withdraw cash
Query balance
Or der cheques
Send message
Transaction list
Or der statement
Transfer funds
FOREIGN
CUSTOMER
Service list
Withdraw cash
Query balance
BANK
TELLER
Service list
Run diagnostics
Add cash
Add paper
Send message
Example: ATM
Viewpoint structuring: Viewpoint data/control
ACCOUNT
HOLDER
Control input
Start transaction
Cancel transaction
End transaction
Select service
Da ta input
Card details
PIN
Am ount required
Message
Example: ATM
Viewpoint structuring: Viewpoint hierarchy
All VPs
Services
Query balance
Withdraw cash
Services
Order cheques
Send message
Transaction list
Order statement
Transfer funds
Customer
Account
holder
Foreign
customer
Bank staff
Teller
Manager
Engineer
Example: ATM
Viewpoint documentation
Reference: Customer
Reference:
Cash withdrawal
Attributes: Account number
PIN
Start transaction
Events:
Select service
Cancel
transaction
End transaction
Rationale:
To improve customer service
and reduce paperwork
Services:
Cash withdrawal
Balance enquiry
Specification: Users choose this service by
pressing the cash withdrawal
button. They then enter the
amount required. This is
confirmed and, if funds allow,
the balance is delivered.
VPs:
Sub-VPs:
Account holder
Foreign
customer
Customer
Deliver cash within 1 minute
Non-funct.
requirements: of amount being confirmed
Provider:
Filled in later
Scenarios



If it often easier for people to relate on real-life
example rather than abstract statements
Scenarios are descriptions – sequences of events of how the system is used in practice.
Scenarios are composed of:





A description of the initial state of the system
A description of the normal flow of events in the scenario
A description of what can go wrong and how it is
handled
Information on other activities that might be going on
concurrency
A description of the final state of the system
Use cases







Use cases are a scenario-based technique for
describing requirements
Use cases identify the users of the system (actors)
Use cases identify the tasks (use cases)
Use cases relate the users and the tasks
Use cases are typically illustrated with UML as stick
figures or similar diagrams
A set of use cases should describe all possible
interactions with the system
Use cases are more effective in capturing
functional requirements
Example: Flights reservation
system
Use-cases relationships

Use cases have relationships

Inclusions:




Extensions:




A use case contain the behavior from another use case
(unconditional)
Can be seen as a factorization
Introduced by the <<include>> keyword
A use case conditionally interrupts the execution of
another use case to augment its functionality
An extension point may specify a precondition for the
extending behavior
Introduced by the <<extends>> keyword
Inheritance
Flights reservation system
Requirements specification

Examples of templates (Available in the
Blackboard):


Microsoft template. Karl E. Wiegers.
Software Requirements. Windows Press.
Volere template

http://www.volere.co.uk
Textual descriptions of a usecases

The textual description of a use case includes:












Use case ID
Use case name
Actors
Description
Pre-condition
Post-condition
Normal course
Alternative course
Exceptions
Includes
Priority
See also template of Karl E. Wiegers, Microsoft
Requirements validation

Requirements must be checked for:


Validity, comprehensibility, traceability (source, dependency between
requirements) consistency, completeness, realism and verifiability
Validation techniques:

Requirements reviews




Test-case generation



Tests are developed for the requirements
Prototyping
Mini-definitions of the requirements


Expert review, two independent reviews
Formal/informal
Involvement of the stakeholders necessary
A team redefine the requirements and compare them with the list of produced
requirements
There are lots of validation techniques (more than 21). Dr. Goldsmith’s
presentation.
Requirements management



Requirements management deals with the process
of managing changes in the requirements during
the requirements engineering process and system
development
Requirements traceability is concerned with the
relationships between requirements
(dependencies), their sources and the system
design
CASE tools are necessary for the requirements
storage and management
Traceability matrix

U: Uses
W: Weak
relationshi
p
A traceability matrix permits us to see
the relationships/dependencies between
requirements
Req.
id
1.1
1.2
1.3
2.1
2.2
2.3
3.1
3.2
1.1
1.2
1.3
U
R
U
R
2.1
2.2
2.3
3.1
R
3.2
U
R
R
R
U
U
U
U
R
R