Requirement Engineering

Week 5
 Software Requirement Engineering 2

Requirement
 Something required, something wanted or needed
 Webster’s dictionary

 There is a huge difference between wanted and needed and it should be

kept
in mind all the time

 Need- something you have to have

 Want -something you would like to have
 Software Requirement Engineering 3

Software Requirements

 A complete description of what the software system will do without

describing how it will do it is represented by the software requirements
 Software requirements are complete specification of the desired external
behavior of the software system to be built

Response of
 Software requirements may be: software
against the input
 Abstract statements of services

 Detailed mathematical functions

 Part of the bid of contract

 The contract itself

 Part of the technical document, which

describes a product
 Software Requirement Engineering 4

Requirement
Can be functionality
constraint

 A condition or capability that must be met or possessed by a

system...tosatisfy a contract, standard, specification, or other formally
imposed document.
IEEE Std729
 Software Requirement Engineering 5

Role of Requirements: A Contract

• The set of requirements constitutes a contract

between the client and the software developer
• Software requirement documents are the medium used
to communicate requirements to technical people
responsible for developing the software.

• Serves as a basis for project planning (schedule,

budget)

• Requirements document is used both to drive the

design stage, and as a basis for test planning.
 Software Requirement Engineering 6

Why Requirements are Important

Importance of Requirement Engineering
 Software Requirement Engineering 8

Importance of RE
• “Done well,
• requirements engineering presents an
opportunity to reduce costs and increase the
quality of software systems.
• Done poorly,
• it could lead to a software project failure.”
Software Engineering Institute (SEI)
Requirements engineering
• The process of finding out, analyzing, documenting and
checking the services that the customer requires and
constraints on its operation is called requirements
engineering (RE).

• The artifact that comes out of the process is SRS

document.
Requirement Engineering Process
RE Process Activities
• Requirements Elicitation
• The process through which the customers, buyers, or users of a
software system discover, reveal, articulate, and understand their
requirements
• Requirement Analysis
• The process of reasoning about the requirements that have been
elicited
• Involves examining requirements for conflicts or inconsistencies,
combining related requirements, and identifying missing
requirements
RE Process Activities
• Requirements Specification
• The process of recording the requirements in one or more forms,
including natural language and formal, symbolic, or graphical
representations
• Requirement Validation
• The process of confirming with the customer or user of the
software that the specified requirements are valid, correct, and
complete.
• Requirement Management
• The process of managing all the activities carried out during RE
Types of requirements
• User requirements
• Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written from
perspective of users.
• System requirements
• A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented.
• Perspective of developers.
 Chapter 4 Requirements engineering 14

User and system requirements ( R )

 Chapter 4 Requirements engineering 15

Readers of different types of requirements

specification ( R )
Functional and non-functional requirements

• Functional requirements
• 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
• constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
Functional requirements
Specify the software functionality that the developers
must build into the product to enable users to accomplish
their tasks, thereby satisfying the business requirements.

Almost any action, e.g. calculate, inspect, publish, or

most other active verbs can be a functional requirement.
Case Study: The LIBSYS system
• A library system that provides a single interface to a
number of databases of articles in different libraries.

• Users can search for, download and print these articles

for personal study.
Examples of functional requirements for LIBSYS

• The user shall be able to search either all of the initial set
of databases or select a subset from it.
• The system shall provide appropriate viewers for the user
to read documents in the document store.
• Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to the
account’s permanent storage area.
Examples of functional requirements for
MHC-PMS system
• 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.
 Chapter 4 Requirements engineering 21

Requirements imprecision
• Problems arise when requirements are not precisely
stated.
• Ambiguous requirements may be interpreted in different
ways by developers and users.
• Consider the term ‘search’ in requirement 1
• User intention – search for a patient name across all appointments
in all clinics;
• Developer interpretation – search for a patient name in an
individual clinic. User chooses clinic then search.
 Requirements completeness and consistency

• In principle, requirements should be both complete and

consistent.
• Complete
• They should include descriptions of all facilities required.
• Consistent
• There should be no conflicts or contradictions in the descriptions of the
system facilities.

In practice, it is impossible to produce a complete and consistent

requirements document.
Is this UR complete?
 UR Consistent
• REQ1 Dates shall be displayed in the mm/dd/yyyy format.
• REQ2 Dates shall be displayed in the dd/mm/yyyy format.

• REQ1 For users in the U.S., dates shall be displayed in the

mm/dd/yyyy format.
• REQ2 For users in France, dates shall be displayed in the
dd/mm/yyyy format.
Non-functional requirements
• Requirements that are not directly concerned with the
specific services delivered by the system to its users.

• These define system properties and constraints e.g.

reliability, response time and storage requirements.

• NFR may affect the overall architecture of a system

Non-functional classifications
• Product requirements
• Requirements which specify that the delivered product
must behave in a particular way e.g. execution speed,
reliability, etc.
• Organisational requirements
• Requirements which are a consequence of
organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are
external to the system and its development process
e.g. interoperability requirements, legislative
requirements, etc.
Non-functional requirement types
Non-functi onal
requir ement s

P roduct Organisat ional External

requir ement s requir ement s requir ement s

Efficiency Reli abili ty Porta bili ty Inter oper a bili ty Ethical

requir ement s requir ement s requir ement s requir ement s requir ement s

Usa bili ty Del ivery Implementa ti on Standar ds Legisl ative

requir ement s requir ement s requir ement s requir ement s requir ement s

Performance Space P rivacy Safet y

requir ement s requir ement s requir ement s requir ement s
Non-functional requirements examples
Product requirement
The MHC-PMS 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 MHC-PMS 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.
Functional vs. Non-functional requirements

 The difference is that non-functional requirements

describe
 how the system works or how the system should
behave

 While functional requirements describe

 what the system should do.
NFRs/QUALITY ATTRIBUTES
• Non-Functional Requirements (NFR) include
performance goals and descriptions of quality attributes.

• Quality attributes extend the description of the product's

functionality by describing the product's characteristics in
various dimensions that are important either to users or to
developers.
Examples: NFRs
 Other non-functional requirements

• Constraints that impose restrictions on the choices

available to the developer for design and construction of
the product.
• Example: The system development process and deliverable
documents shall conform to the MIL-STD-2167A.
• a constraint on opening an account at an online liquor store is that
customers must be at least 21 years old.
Example: Constraints
Benefits from a High-Quality Requirements
Process
• Fewer requirement defects
• Reduced development rework
• Fewer unnecessary features
• Faster development
• Fewer miscommunications
• Reduced scope creep
• Reduced project chaos
• More accurate system testing estimates
• Higher customer and team member satisfaction