Requirements Engineering

Process
 Software Requirements

• A condition or capability that must be possessed by a

system (IEEE)
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
• This is inevitable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore must be open to
interpretation
– May be the basis for the contract itself - therefore must be defined in
detail
– Both these statements may be called requirements
 Types of requirements

• User requirements
– Statements in natural language (NL) plus diagrams of the services the
system provides and its operational constraints. Written for customers
• System requirements
– A structured document setting out detailed descriptions of the system
services. Written as a contract between client and contractor
• Software specification
– A detailed software description which can serve as a basis for a
design or implementation. Written for developers
 Requirements Targets

Client Managers
System end-users
User Contract managers
Requirements System architects

System System end-users

Client engineers
Requirements
System architects
Software developers
Software
Specification Client engineers
System architects
Software developers
 Requirements Types:

1. Functional requirements: services the system should

provide
2. Non-functional requirements: constraints on the
services of functions offered by the system. e.g.
speed, time to market
3. Domain requirements: related to the application
domain of the system (may be functional or non-
functional requirements)
 Functional requirements

• Functionality or services that the system is expected to

provide.
• Functional requirements may also explicitly state what
the system shouldn’t do.
• Functional requirements specification should be:
– Complete: All services required by the user should be defined
– Consistent: should not have contradictory definition (also avoid
ambiguity don’t leave room for different interpretations)
 Non-Functional requirements

• Requirements that are not directly concerned with the

specific functions delivered by the system
• Typically relate to the system as a whole rather than the
individual system features
• Often could be deciding factor on the survival of the
system (e.g. reliability, cost, response time)
Non-Functional requirements classifications:

Non-Functional
Requirements
Product requirements External requirements

•Efficiency •Interoperability
Organizational requirements
External requirements
•Reliability •Ethics
•Delivery External requirements
•Portability •Legislative
•Implementation
•Usability •Privacy
•Standards
•Performance •Safety
•Space
 Software requirements specification (SRS)
document

• A complete specification of what the proposed system

should do!
• Purpose
 SRS establishes basis of agreement between the user
and the supplier.
 Users needs have to be satisfied, but user may not understand
software
 Developers will develop the system, but may not know about
problem domain
 SRS is
 the medium to bridge the communications gap, and
 specifies user needs in a manner both can understand
Systems Requirements Specification

Table of Contents
I. Introduction
II. General Description
III. Functional Requirements
IV. Non Functional Requirements
V. System Architecture
VI. System Models
VII. Appendices
 Characteristics of a requirements specification
document

• Completeness: Are all functions required by the

customer included? if it is incomplete then additional
requirements will be identified downstream, possibly
upsetting the development entirely.
• Consistency: Are there any requirements conflicts? if
the document is inconsistent, then what should be built?
• Unambiguous: if there is ambiguity a system might be
built that does not satisfy the real requirements.
• Verifiability. Can the requirements be checked?
• Validity. Does the system provide the functions which
best support the customer’s needs?
• Real. Can the requirements be implemented given
available budget and technology
Requirements Engineering (RE) processes
• Processes used to discover, analyse and validate
system requirements
• RE vary widely depending on the application domain, the
people involved and the organization developing the
requirements
• However, there are a number of generic activities
common to all processes
– Requirements elicitation
– Requirements analysis
– Requirements validation
– Requirements management
A spiral view of the requirements engineering process
 Requirements elicitation and analysis

• Sometimes called 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.
 Requirements elicitation and analysis

• Software engineers work with a range of system

stakeholders to find out about the application domain, the
services that the system should provide, the required
system performance, hardware constraints, other
systems, etc.
• Stages include:
– Requirements discovery,
– Requirements classification and organization,
– Requirements prioritization and negotiation,
– Requirements specification.
The requirements elicitation and analysis process
 Process activities
• Requirements discovery
– Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
• Requirements classification and organisation
– Groups related requirements and organises them into coherent
clusters.
• Prioritisation and negotiation
– Prioritising requirements and resolving requirements conflicts.
• Requirements specification
– Requirements are documented and input into the next round of
the spiral.
Problems of 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.
 Requirements discovery

• The process of gathering information about the required

and existing systems and distilling the user and system
requirements from this information.
• Interaction is with system stakeholders from managers to
external regulators.
• Systems normally have a range of stakeholders.
 Interviewing

• RE’s meet with stakeholders to discuss the system

currently in place and the system to be developed.
• May be:
– formal or informal
– closed (with a pre-defined agenda), open (no pre-defined
agenda), or a mix
• Useful for learning how stakeholders might affect or be
affected by the system.
• Less useful for learning about domain requirements
since:
– RE’s may not understand domain-specific terminology;
– stakeholders may not communicate such requirements
because they are so obvious (to the stakeholders)
 Interviewing

• Effective interviewing
– Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
– Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
 Scenarios

• Depict examples or scripts of possible

system behaviour

• People often relate to these more readily than

to abstract statements of requirements “Give me an
example to help tie the parts together” (into a coherent
whole.)

• Particularly useful in elucidating fragmentary,

incomplete, or conflicting requirements
 Scenario elements

1. System state at the beginning of the scenario (if

relevant)
2. Sequence of events for a specific case of
some generic task the system is required to
accomplish.
3. Any relevant concurrent activities.
4. System state at the completion of the scenario.
 Scenario for a “start transaction” event

different
scenarios
different
scenarios
UML use-cases and sequence diagrams

• Graphical notations for representing abstract scenarios in

the UML. (UML is the de facto standard for OO Analysis & Design)
• Identify actors in an interaction and describe the
interaction itself.
• A set of use-cases should describe all types of
interactions with the system.
• Sequence diagrams show the sequence of event
processing.
Library use-cases
 Catalogue management sequence diagram

time
 Ethnography

• A social scientist observes and analyzes how

people actually work.
• Subjects do not have to explain or otherwise
articulate what they do.
• Social and organizational factors of importance
may be observed.
• Ethnographic studies have shown that work is
usually richer and more complex than
suggested by simple system models.
(Good for studying existing practices, but how will things
change when the new system is introduced?)
 Prototyping
• Incomplete versions of the software program being
developed. Prototyping can also be used by end users to
describe and prove requirements that developers have
not considered
Benefits
– The software designer and implementer can obtain feedback
from the users early in the project. The client and the contractor
can compare if the software made matches the software
specification, according to which the software program is built.
– It also allows the software engineer some insight into the
accuracy of initial project estimates and whether the deadlines
and milestones proposed can be successfully met.
– Software prototyping has many variants. However, all the
methods are in some way based on two major types of
prototyping: Throwaway Prototyping and Evolutionary
Prototyping.
 Requirements validation

• Concerned with whether or not the requirements define a

system that the customer really wants. (as opposed to needs?)
• Requirements error costs are high, so early validation is
very important. (Fixing a requirements error after
delivery may cost 100 times that of fixing an error during
implementation.)
 Requirements validation techniques
• Requirements reviews
– Systematic manual analysis of the requirements.
• Prototyping
– Using an executable model of the system to check requirements.
• Test-case generation
– Developing tests for requirements to check testability.
 Requirements 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.
 Requirements management planning

• Establishes the level of requirements management detail

that is required.
• Requirements management decisions:
– Requirements identification Each requirement must be uniquely
identified so that it can be cross-referenced with other requirements.
– A change management process This is the set of activities that
assess the impact and cost of changes. I discuss this process in
more detail in the following section.
– Traceability policies These policies define the relationships between
each requirement and between the requirements and the system
design that should be recorded.
– Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and simple
database systems.
 Requirements change management
• Deciding if a requirements change should be accepted
– Problem analysis and change specification
• During this stage, the problem or the change proposal is
analyzed to check that it is valid. This analysis is fed back to the
change requestor who may respond with a more specific
requirements change proposal, or decide to withdraw the
request.
– Change analysis and costing
• The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements.
Once this analysis is completed, a decision is made whether or
not to proceed with the requirements change.
– Change implementation
• The requirements document and, where necessary, the system
design and implementation, are modified. Ideally, the document
should be organized so that changes can be easily implemented.
Requirements change management