Requirements

engineering
 Requirements Engineering

The requirements for a system are the
descriptions of what the system should do

The process of finding out, analyzing,
documenting and checking these services
and constraints is called Requirements
Engineering (RE).
 Requirements Engineering

The term ‘requirement’ is not used consistently in the
software industry.

In some cases, a requirement is simply a high-level,
abstract statement of a service that a system should
provide or a constraint on a system.

At the other extreme, it is a detailed, formal
definition of a system function.

SRS=User Requirements + System 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.

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. In some cases,
the functional requirements may also explicitly state what the system
should not do.

Non-functional requirements These are constraints on the services or
functions offered by the system. They include timing constraints,
constraints on the devel opment process, and constraints imposed by
standards. Non-functional requirements often apply to the system as a
whole, rather than individual system features or services.
Example of Functional requirements

A user shall be able to search the appointments lists
for all clinics.

The system shall generate each day, for each clinic, a
list of patients who are expected to attend
appointments that day.

Each staff member using the system shall be uniquely
identified by his or her eight-digit employee number.

Imprecision in the requirements specification is the cause
of many software engineering problems.

In principle, the functional requirements specification of a
system should be both complete and consistent.

Completeness means that all services required by the user
should be defined.

Consistency means that requirements should not have
contradictory definitions.
 Non-functional requirements

Non-functional requirements are performance, security,
or availability, usually specify or constrain
characteristics of the system as a whole. Eg:

reliability, response time, store occupancy,
interoperability,safety, and confidentiality

Non-functional requirements are often more critical
than individual functional requirements.
Types of non-functionalrequirement
Eg of non-functional requirements in
the MHC-PMS

you should write non-functional requirements
quantitatively so that they can be objectively
tested

Non-functional requirements often conflict and
interact with other functional or non-functional
requirements.
Metrics for specifying objectively testable non-functional
requirements
 software requirements document

The software requirements document (sometimes
called the software requirements specification or
SRS) is an official statement of what the system
developers should implement.

SRS=User Requirements + System Requirement

Requirements documents are essential when an outside
contractor is developing the software system.
Agile Argue Otherwise(let’s talk)

Requirements change
so rapidly

Effort is largely wasted

Incrementally write user stories on
cards

User prioritizes requirements for
implementation in the next
increment
 Take away

For business systems where requirements are
unstable, Agile approach is a good one.
Users of a Requirements Document

The level of detail that you should include in a
requirements document depends on the type of
system that is being developed and the development
process used. Eg:

Critical systems = detailed requirements

Outsourcing Development= detailed and precise

inhouse, iterative development= less detailed
IEEE Standard for Requirements Documents (IEEE, 1998)
Problems with using natural language for requirements
specification
Requirements specification

Requirements specification is the process of
writing down the user and system requirements
in a requirements document.

SRS=User Requirements + System Requirement
 user requirements

The user requirements for a system should
describe the functional and non-functional
requirements so that they are understandable
by system users who don’t have detailed
technical knowledge.

user requirements = functional + non-functional - software jargon

Ideally, the user and system requirements should be
clear, unambiguous, easy to understand, complete,
and consistent.

you should not use software jargon, structured
notations, or formal notations.

You should use natural language, with simple
tables, forms, and intuitive diagrams.
 System requirements

System requirements are expanded versions
of the user requirements that are used by
software engineers as the starting point for the
system design

System requirements = user requirements + More Details + software jargon
 System requirements

They add detail and explain how the user
requirements should be provided by the system.

They may be used as part of the contract for the
implementation

They should not be concerned with how the
system should be designed or implemented.
Ways of writing a system requirements specification

User requirements are almost always written in
natural language supplemented by appropriate
diagrams and tables in the requirements document.

System requirements may also be written in natural
language but other notations based on forms,
graphical system models, or mathematical
system models can also be used.

Graphical models are most useful when you need to
show how a state changes or when you need to
describe a sequence of actions eg UML

Formal mathematical specifications are sometimes
used to describe the requirements for safety- or
security-critical systems, but are rarely used in
other circumstances.
 Natural language specification

Natural language has been used to write
requirements for software since the beginning of
software engineering.

It is expressive, intuitive, and universal.

It is also potentially vague, ambiguous, and its
meaning depends on the background of the reader
 To minimize misunderstandings when writing natural
language requirement

Invent a standard format(eg 1 requirment : 1 sentence)

Use language consistently (eg ‘shall’ for must have)

Use text highlighting (bold, italic, or color) to pick out key parts of
the requirement.

Do not assume that readers understand technical software
engineering language(words like ‘architecture’ and ‘module’)

Whenever possible, you should try to associate a rationale with
each user requirement(Why The Reuirement).
Example requirements for the insulin pump software system
 Structured specifications

Structured natural language is a way of writing system
requirements where the freedom of the requirements writer is
limited and all requirements are written in a standard way.

This approach maintains most of the expressiveness and
understandability of natural language but ensures that some
uniformity is imposed on the specification.

Structured language notations use templates to specify
system requirements.
A structured specification of a requirement for an insulin pump
 The Robertsons (Robertson and Robertson, 1999) Book
recommend

that user requirements be initially written on
cards, one requirement per card.

They suggest a number of fields on each card,
such as the requirements rationale, the
dependencies on other requirements, the
source of the requirements, supporting
materials
 To Use standard form for specifying functional requirements
included:
1. A description of the function or entity being specified.
2. A description of its inputs and where these come from.
3. A description of its outputs and where these go to.
4. Information that is needed for the computation or other entities in the system that
are used (the ‘requires’ part).
5. A description of the action to be taken.
6. If a functional approach is used, a pre-condition setting out what must be true
before the function is called, and a post-condition specifying what is true after the
function is called.
7. A description of the side effects (if any) of the operation.

Using structured specifications removes some of the
problems of natural language specification.

However, it is still sometimes difficult to write
requirements in a clear and unambiguous way,
particularly when complex computations

Solution: Tables are particularly useful (see next
slide)
Tabular specification of computation
for an insulin pump
 Exercise Scenario: Landmark University Bread Industry
Software Development


Landmark University's Bread Industry is looking to
modernize its bread production process and supply by
developing a software system to manage various aspects
of the production, inventory, and sales.

Students are tasked with writing structured
specifications for the software system(10 min).
 THANKS
(More on “Requirements
engineering processes........!!!)

Q&A