WEEK 3

REQUIREMENTS

1
 Requirement

• User requirements are statements, in a natural language

plus diagrams, of what services the system is expected
to provide to system users and the constraints under
which it must operate.
• System requirements are more detailed descriptions of
the software system’s functions, services, and
operational constraints. The system requirements
document (sometimes called a functional specification)
should define exactly what is to be implemented. It may
be part of the contract between the system buyer and
the software developers.

2
 Functional and Non Functional
Requirements

• Software system requirements are often classified as

functional requirements or non-functional requirements:
– Functional requirements These are statements of
services the system should provide, how the system
should react to particular inputs, and how the system
should behave in particular situations.
– Non-functional requirements These are constraints on
the services or functions offered by the system. They
include timing constraints, constraints on the
development process, and constraints imposed by
standards.

3
 Functional Requirements

• The functional requirements for a system describe what

the system should do.
• Example of patient management system:
1.A user shall be able to search the appointments lists
for all clinics.
2.The system shall generate each day, for each clinic, a
list of patients who are expected to attend
appointments that day.
3.Each staff member using the system shall be uniquely
identified by his or her eight-digit employee number.

4
 Non-functional Requirements

• Requirements that are not directly concerned with the

specific services delivered by the system to its users.
• They may relate to:
– Emergent system properties such as reliability,
response time, and store occupancy
– Constraints on the system implementation such as
the capabilities of I/O devices, performance, security,
or availability
• Failing to meet a non-functional requirement can mean
that the whole system is unusable.
– For example, if an aircraft system does not meet its
reliability requirements, it will not be certified as safe
for operation
5
Type of Non-Functional Requirements

6
 Type of Non-Functional Requirements (cont.)

• Product requirements Requirements specify of the

software. Examples: performance requirements on how
fast the system must execute and how much memory it
requires, reliability requirements that set out the
acceptable failure rate, security requirements, and
usability requirements.
• Organizational requirements Policies and procedures in
the customer’s and developer’s organization. Examples:
operational process requirements that define how the
system will be used, development process requirements
that specify the programming language, and
environmental requirements that specify the operating
environment of the system.
7
 Type of Non-Functional Requirements (cont.)

• External requirements Covers all requirements that are

derived from factors external to the system and its
development process. These may include regulatory
requirements that set out what must be done for the
system to be approved for use by a regulator, such as a
central bank; legislative requirements that must be
followed to ensure that the system operates within the
law; and ethical requirements that ensure that the
system will be acceptable to its users and the general
public.

8
 Type of Non-Functional Requirements (cont.)

• Example non functional requirements on patient

management system:
– Product requirement
• System shall be available to all clinics during
normal working hours (Mon–Fri, 08.30–17.30).
Downtime within normal working hours shall not
exceed five seconds in any one day.
– Organizational requirement
• Users of the system shall authenticate themselves
using their health authority identity card.
– External requirement
• The system shall implement patient privacy
provisions as set out in HStan-03-2006-priv.
9
Requirements Engineering Tasks
• There are 7 tasks in requirements engineering.
1. Inception: how does a software project get started
2. Elicitation: Ask the stakeholders what are their objective for the
system or product, find out what is to accomplished.
1. Problems of scope
2. Problems of Understanding
3. Problems of volatility
3. Elaboration: focused on developing a refined technical model of
software functions, features and constraints. Composed of
modeling and refinement tasks (how users will interact with the
system)

10
 Requirements Engineering Tasks
4. Negotiation: Conflict on requirements is resolved, risks
analysed and avoided
5. Specification: The final work product produced, describes
the function and performance of a computer based
system and constraints that will govern its development
6. Validation: Examining Specification to ensure that all
requirements are stated correctly, no errors and that it
conforms to standards established for the process.
7. Requirements Management: it’s a set of activities that
help project team to identify, control and track
requirements and their changes as the project proceeds.

11
 R.E process

Requir ements
Feasibility elicitation and
stud y
anal ysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document

12
 Requirements Engineering

Requirements
specification
S ystem requirements
specification and
modeling

User requirements
specification

Business requirements
specification

S ystem
F easibility
requirements User
elicitation study
requirements
elicitation
Prototyping

Requirements
elicitation
Reviews Requirements
validation

Syst em requirements
document
13
 Viewpoints

• Viewpoints are a way of structuring the requirements to

represent the perspectives of different stakeholders.
Stakeholders may be classified under different
viewpoints.
• This multi-perspective analysis is important as there is no
single correct way to analyse system requirements.

14
Techniques to gather requirements
• Requirements Elicitation: making sure that indeed there
is a need for a system before developing system
requirements
• Obtrusive Observation: Obtained requirements directly
from the stakeholders
• Unobtrusive Observation: observe stakeholders at
random times when they don’t know.
• Interview: talking to the stakehokders concerned.

15
Techniques to gather requirements
Social and organisational factors
• Software systems are used in a social and organisational
context. This can influence or even dominate the system
requirements.
• Social and organisational factors are not a single
viewpoint but are influences on all viewpoints.
• Good analysts must be sensitive to these factors but
currently no systematic way to tackle their analysis.

16
 Requirements gathering
Ethnography
• A social scientists spends a considerable time observing
and analysing how people actually work.
• People do not have to explain or articulate their work.
• Social and organisational factors of importance may be
observed.
• Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.

17
 Interview
• In formal or informal interviewing, the RE team puts
questions to stakeholders about the system that they use
and the system to be developed.
• There are two types of interview
– Closed interviews where a pre-defined set of
questions are answered.
– Open interviews where there is no pre-defined agenda
and a range of issues are explored with stakeholders.

18
 Interviews in Practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact
with the system.
• Interviews are not good for understanding domain
requirements
– Requirements engineers cannot understand specific
domain terminology;
– Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn’t worth
articulating.

19
 Requirements Validation
• Concerned with demonstrating that the requirements
define the system that the customer really wants.
• Requirements error costs are high so validation is very
important
– Fixing a requirements error after delivery may cost up
to 100 times the cost of fixing an implementation
error.

20
 Requirements Checking
• Validity. Does the system provide the functions which
best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer
included?
• Realism. Can the requirements be implemented given
available budget and technology
• Verifiability. Can the requirements be checked?

21
 Requirements Validation Techniques

• Requirements reviews
– Systematic manual analysis of the requirements.
• Prototyping
– Using an executable model of the system to check
requirements. Covered in Chapter 17.
• Test-case generation
– Developing tests for requirements to check testability.

22
 Requirement Reviews
• Regular reviews should be held while the requirements
definition is being formulated.
• Both client and contractor staff should be involved in
reviews.
• Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.

23
 Review Checks

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?

24
 Requirement Management

• Requirements management is the process of managing

changing requirements during the requirements
engineering process and system development.
• Requirements are inevitably incomplete and inconsistent
– New requirements emerge during the process as
business needs change and a better understanding of
the system is developed;
– Different viewpoints have different requirements and
these are often contradictory.

25
 Requirements change

• The priority of requirements from different viewpoints

changes during the development process.
• System customers may specify requirements from a
business perspective that conflict with end-user
requirements.
• The business and technical environment of the system
changes during its development.

26
 Requirements management planning
• During the requirements engineering process, you have
to plan:
– Requirements identification
• How requirements are individually identified;
– A change management process
• The process followed when analysing a
requirements change;
– Traceability policies
• The amount of information about requirements
relationships that is maintained;
– CASE tool support
• The tool support required to help manage
requirements change; 27
 Requirements change management

• Should apply to all proposed changes to the

requirements.
• Principal stages
– Problem analysis. Discuss requirements problem and
propose change;
– Change analysis and costing. Assess effects of change
on other requirements;
– Change implementation. Modify requirements
document and other documents to reflect change.

28
 Traceability
• Traceability is concerned with the relationships between
requirements, their sources and the system design
• Source traceability
– Links from requirements to stakeholders who
proposed these requirements;
• Requirements traceability
– Links between dependent requirements;
• Design traceability
– Links from the requirements to the design;

29
 CASE tool support
• Requirements storage
– Requirements should be managed in a secure,
managed data store.
• Change management
– The process of change management is a workflow
process whose stages can be defined and information
flow between these stages partially automated.
• Traceability management
– Automated retrieval of the links between requirements.

30
 Feasibility Study

• A feasibility study decides whether or not the proposed

system is worthwhile.
• A short focused study that checks
– If the system contributes to organisational objectives;
– If the system can be engineered using current
technology and within budget;
– If the system can be integrated with other systems
that are used.

31
 Feasibility Study Implementation
• Based on information assessment (what is required), information
collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed system?

32
 Elicitation and Analysis
• Sometimes called requirements elicitation or
requirements discovery.
• 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.

33
 Requirement Analysis problems
• 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.

34
 Scenarios

• Scenarios are real-life examples of how a system can be

used.
• They should include
– 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.

35
 Library System scenario
Initial assumption: The user has logged on to the LIBSYS system and has
located the journal containing the copy of the article.

Normal: The user selects the article to be copied. He or she is then prompted
by the system to either provide subscriber information for the journal or to
indicate how they will pay for the article. Alternative payment methods are by
credit card or by quoting an organisational account number.

The user is then asked to fill in a copyright form that maintains details of the
transaction and they then submit this to the LIBSYS system.

The copyright form is checked and, if OK, the PDF version of the article is
downloaded to the LIBSYS working area on the user’s computer and the user
is informed that it is available. The user is asked to select a printer and a copy
of the article is printed. If the article has been flagged as ‘print-only’ it is
deleted from the user’s system once the user has confirmed that printing is
complete.

36
 Library System cont..

What can go wrong: The user may fail to fill in the copyright form
correctly. In this case, the form should be re-presented to the user for
correction. If the resubmitted form is still incorrect then the user’s request
for the article is rejected.
The payment may be rejected by the system. The user’s request for the
article is rejected.

The article download may fail. Retry until successful or the user
terminates the session.
It may not be possible to print the article. If the article is not flagged as
‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article
is deleted and the user’s account credited with the cost of the article.

Other activities: Simultaneous downloads of other articles.

System state on completion: User is logged on. The downloaded
article has been deleted from LIBSYS workspace if it has been flagged as
print-only.
37
 Use Cases

• Use-cases are a scenario based technique in the UML

which identify the actors in an interaction and which
describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• Sequence diagrams may be used to add detail to use-
cases by showing the sequence of event processing in
the system.

38
 Library use case

Article search

Library Article printing

User

User administration Library

Staff

Supplier Catalogue services

39
 Article printing

item: copyrightF orm: myWorkspace: myPrinter:

Article Form Workspace Printe r

User

request
request

complete

return

copyright OK

deliver

article OK

print
send

inform confirm

delete

40
 Requirements classification

Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

41
 Key Points

• Social and organisation factors influence system

requirements.
• Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability.
• Business changes inevitably lead to changing
requirements.
• Requirements management includes planning and
change management.

42
 Tasks
• Identify and explain 7 points in requirements engineering.
• Define view points and give an example.
• Describe techniques in gathering requirements.
• Identify problems in requirements analysis.
• Explain requirements elicitation and analysis.
• Explain feasibility study.
• Explain in detail, what is covered in Traceability, pertaining to
requirements.
• Identify requirement review techniques and explain them,
explain why there is a need for review.
• Explain all requirements validation techniques.
• Explain requirement management.

43