17/04/1444
Software Requirements
Muhammad Rabee Shaheen, Ph.D
What is a requirement?
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 (proposal) 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.
2
1
17/04/1444
Requirements Engineering
Is important:


Engineering is about developing solutions to problems


Errors cost more the longer they go undetected


Cost of correcting a requirements error is 100 times greater in
the maintenance phase than in the requirement phase
Experience from failed software development projects


A good solution is only possible if the engineer fully understands
the problem
Failure to understand and manage requirements is the biggest
single cause of the cost and schedule over-runs
Analysis of safety problems


Safety-related errors tend to be errors in specifying requirements;
While non-safety errors tend to be errors in implementing
requirements
3
Present State of Practice
Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools
Tight project schedule
Communication barriers
Market-driven software development
Lack of resources







4
2
17/04/1444
Present State of Practice
Requirements are difficult to uncover




Difficulty to identify all the requirements
The description is always incomplete at start
Users & developers must resort to trial and error to identify
problems & solutions
Requirements change
Over-reliance on CASE tools
Tight project schedule
Communication barriers
Market-driven software development
Lack of resources






5
Present State of Practice …
Requirements are difficult to uncover
Requirements change





No user can come up with a complete list of requirements at
the outset (complete list are got gradually)
Project schedule is seldom adjusted to reflect all modifications
Hard to justify spending resources to make a SRS perfect!

Because requirements will soon change anyway
Over-reliance on CASE tools
Tight project schedule
Communication barriers
Market-driven software development
Lack of resources





6
3
17/04/1444
Present State of Practice
Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools





must not rely on requirements engineering tools without first
understanding and establishing requirements engineering
principles, techniques and process.
must have realistic expectations from the tools
Tight project schedule
Communication barriers
Market-driven software development
Lack of resources




7
Present State of Practice
Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools
Tight project schedule






Lack of planning or unreasonable customer demand 
insufficient time to do decent job
It is customary to reduce time (for analyze requirement), for
early start of designing & coding  disaster
Communication barriers
Market-driven software development
Lack of resources



8
4
17/04/1444
Present State of Practice
Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools
Tight project schedule
Communication barriers








RE is communication intensive activity
Users & developers have different vocabularies, backgrounds
Users prefer natural language, while developers want more
precise specifications

depending on just one may misunderstanding and confusion
Market-driven software development
Lack of resources


9
Present State of Practice






Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools
Tight project schedule
Communication barriers
Market-driven software development



Today, software are developed to satisfy anonymous customers
Keep customers coming back to buy upgrades
Lack of resources
10
5
17/04/1444
Present State of Practice







Requirements are difficult to uncover
Requirements change
Over-reliance on CASE tools
Tight project schedule
Communication barriers
Market-driven software development
Lack of resources

resource may not not be enough, therefore the most
important can be implemented first
11
Type of Requirements

Known requirements


Unknown requirements


Something a stakeholder believes to be implemented
Not needed right now or needed by another stakeholder
Undreamt requirements

Stakeholder may not be able to think of new requirements due
to limited domain knowledge
These requirements could be functional
or nonfunctional ones
12
6
17/04/1444
Types of Requirement

User requirements


Statements in natural language 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’s functions, services and operational constraints. Defines what
should be implemented so may be part of a contract between client
and contractor
13
Ex: Mental Health Care-Patient
Management System
14
7
17/04/1444
Essential Requirements Process

Understanding the problem

Use data gathering techniques to elicit requirements


Model and analyze the problem

Use some modeling method(s)


Structured analysis, OO analysis, Formal analysis
Attain agreement on the nature of the problem




Interviews, Questionnaires, Observation, Prototyping
Validation
Conflict resolution
Negotiation
Communicate the problem

Specification, documentation, review meetings
15
Essential Requirements Process

Manage change as the problem evolves

Requirements continue to evolve throughout software
development
16
8
17/04/1444
What vs. How

Requirements should specify what but not how

What refers to a system’s purpose



How refers to a system’s structure and behavior



It is external to the system
It is a property of the application domain
It is internal to the system
It is property of the machine domain
Requirements only exists in the application domain

Need to draw a boundary around the app. Domain

Which things are part of the problem you are analyzing and which are
not?
17
Functional vs. non-functional

Functional requirements



Fundamental functions of the system
Describe system services or functions
Non-functional requirements

Constraints/obligations



Compatibility with (and reuse of) legacy systems
Compliance with interface standards, data format,
communication protocols, …
Quality requirements (soft goals)



Security, Safety
Availability, Usability
Portability
18
9
17/04/1444
Functional requirements for the MHC-PMS



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 8-digit employee number.
19
Requirements imprecision (inaccuracy)



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.
20
10
17/04/1444
Requirements eng. activities
known as requirements gathering. Requirements are identified with the
help of customer & existing systems processes, if available
Known also as requirements verification. It is carried out to improve the
quality of SRS.
is the end product of requirements elicitation and analysis. Known as SRS
Starts with requirement elicitation. Requirements are analyzed in order
to identify inconsistencies, defects, omissions, etc. Requirements are
described in terms of relationships and also resolve conflicts, if any.
21
Elicitation

Identify potential sources of requirements




Goals [why the system is being developed]
Domain knowledge (The customer has knowledge of the
business application being written and what it is supposed
to do, this is the domain knowledge)
Stakeholders (A person, group, or organization that is
actively involved in a project, is affected by its outcome, or
can influence its outcome)
Operating environment


May be constrained by existing software and hardware
Organizational environment

Legal issues of keeping personal data, safety issues
22
11
17/04/1444
Requirements Elicitation Activities

Application domain understanding


Problem understanding


The details of the specific customer problem where the system
will be applied must be understood
Business understanding


is knowledge of the general area where the system is applied
You must understand how systems interact and contribute to
overall business goals
Understanding the needs and constraints of the system
stakeholders

You must understand, in detail, the specific needs of people
who require system support in their work
23
Requirements Analysis

Discover problems, incompleteness, inconsistencies
in the elicited requirements




Complete: it should include descriptions of all facilities
required
Consistence: it should be no conflicts or contradictions in
the descriptions of the system facilities
Detect and resolve conflicts
Feedback to stakeholders to resolve them through the
negotiation process
24
12
17/04/1444
Requirements Validation



Check that requirements define the system which the
customer really needs
Cost of fixing a requirement >> repairing design or
coding errors
Req. val. Process:





Validity checks [any set of requirements is inevitably a compromise across
the stakeholder community]
Consistency checks [no conflict]
Completeness [all functions]
Realism checks [technology, can actually be implemented, budget and
schedule]
Verifiability [customer and contractor, set of test]
25
Requirements Valid. tech

One or more:



Requirements reviews, by reviewers team who check for errors and
inconsistencies
Prototyping, executable model is demonstrated to end-users and
customers
Test-case generation, [writing test before code XP]
26
13
17/04/1444
Software Requirements Document

Official statement of what the system developers should
implement


Called also SRS
Includes:


User requirements for a system
Detailed specification of the system requirements
Agile development methods argue that requirements change so rapidly that
a requirements document is out of date as soon as it is written, so the
effort is largely wasted. Rather than a formal document, approaches such as
Extreme Programming collect user requirements incrementally and write
these on cards as user stories. The user then prioritizes requirements for
implementation in the next increment of the system.
27
Requirements Document’s Users
System Customers
Specify the requirements and read them to check that
they meet their needs.
Customers specify changes to the requirements.
Managers
Use the document to plan a bid for the system and to
plan the system development process.
System Engineers
Use the requirements to understand what system is to
be developed.
System Test Engineers
Use the requirements to develop validation tests for
the system.
System Maintenance
Engineers
Use the requirements to understand the system and
the relationships between its parts.
28
14
17/04/1444
Requirements Management

Requirements always change
1. Systems are usually developed to address problems that cannot be
completely defined. Because the problem cannot be fully defined, the
software requirements are bound to be incomplete.
2. The business and technical environment of the system always changes.
New hardware, new legislation and regulations.
3. The people who pay for a system and the users of that system are
rarely the same people.
Since the problem is constantly changing, The system requirements must
then also evolve to reflect this changed problem view.
29
Requirements Management …

Requirements management is the process of
understanding and controlling changes to system
requirements




keep track of individual requirements
maintain links between dependent requirements
so that you can assess the impact of requirements changes.
The process of requirements management should start as
soon as a draft version of the requirements document is
available.
 start planning how to manage changing requirements
during the requirements elicitation process
30
15
17/04/1444
Last word


There are more to talk about requirements
For more info read:



Mastering the Requirements Process
Software Requirements
Requirements Engineering
31
16