Types & Characteristics of

Requirements
Lecture 8
 2

Software Requirement Specification (SRS)Characteristics

• a) Correct = correct if, and only if, every requirement stated there in is one that the software shall meet.
• b) Unambiguous; = every requirement stated therein has only one interpretation
• c) Complete;= All significant requirements, whether relating to functionality, performance, design
constraints. Definition of the responses of the software to all classes of input data in all possibilities of
situations, attributes, or external interfaces. Full labels and references to all figures, tables, and diagrams.
• d) Consistent;= Consistency refers to internal consistency. If an SRS does not agree with some
higher-level document, such as a system requirements specification, then it is not correct
• e) Ranked for importance and/or stability;= if each requirement in it has an identifier
to indicate either the importance or stability of that particular requirement.
• f) Verifiable;= requirement is verifiable if, and only if, there exists some finite cost-effective process
with which a person or machine can check that the software product meets the requirement
• g) Modifiable;= any changes to the requirements can be made easily, completely, and consistently
while retaining the structure
• h) Traceable;= if the origin of each of its requirements is clear and if it facilitates the referencing of
each requirement in future development or enhancement documentation
 3

Kinds of Software Requirements

• Functional requirements
• Non-functional requirements
• Domain requirements
• Inverse requirements
• Design and implementation constraints
 4

Studying the requirements of

“Parking Ticket System”
Requirements Of Parking System:
Req-1: Log on to the parking system.
Req-2: Enter vehicle number and Identify row number.
Req-3: Issue ticket.
Req-4: Identify person for log out to system.
Req-5: Check ticket.
Req-6: Identify payment method.
Req-7: Check vehicle number.
Req-8: Log out to system.
 5

More Requirements Examples

Issue ticket to vehicle user when he requests.

I. Issue Ticket .
Log on to the library system by entering your
II. Log on to library system. username and password on login screen.

III. Check ticket. Who is checking ticket.?? Guard or software or by

what method this checking is done?? And at what
time this checking is done..? before leaving or
IV. Match the vehicle number. what?

V. Update library record after new entry. Tickets are checked by the parking guard before
the vehicle leaves the parking. Ticket holder and
vehicle number is validated by matching the id
VI. Entrance of vehicle and record its number in the list. card number and vehicle registration number.

VII. Search catalog . When we are checking the vehicle number ? Either
before entering the parking or at time of leaving the
VIII. Id of student is matched & book is issued to student.parking..? or this process is being followed at both
times? Specify that ..

IX. Issue book and update record . You are merging two requirements either state
them separately or identify them by using sub
X. Log out from the system. heading/sub bullets. Like;

Req-1. Allow entrance to vehicles which have

verified tickets by opening the parking gate.

Req1.1. record the number of entered vehicles in

Search on what basis..???? the database/record.
Functional Requirements
 7

Functional Requirements
• Statements describing what the system does
▫ Functionality of the system
• Statements of services the system should provide
▫ Reaction to particular inputs
▫ Behavior in particular situations
• Abnormal behavior is also documented as
functional requirements in the form of exception
handling
 8

Functional Requirements
• Functional requirements should be complete and
consistent
• Customers and developers usually focus all their
attention on functional requirements
▫ example:
 The system shall solve a quadratic equation using the
following formula
x = (-b+sqrt(b2 – 4*a*c))/2*a
• Notice the ambiguity in the requirement for solving
the quadratic equation.
▫ The requirement does not speak about the possibility
when the value of ‘a’ is zero
 9

Non-Functional Requirements
• Most non-functional requirements relate to the
system as a whole.
▫ They include constraints on timing, performance,
reliability, security, maintainability, accuracy, the
development process, standards, etc.
• They are often more critical than individual
functional requirements
▫ Capture the emergent behavior of the system, that is
they relate to system as a whole
• Failure to meet a non-functional system
requirement may make the whole system unusable
 10

Non-Functional Requirements
• Failure to meet a non-functional system
requirement may make the whole system unusable
▫ If an aircraft system does not meet reliability
requirements, it will not be certified as ‘safe’
▫ If a real-time control system fails to meet its
performance requirements, the control functions will
not operate correctly
• Non-functional requirements arise through user
needs,
▫ because of budget constraints,
▫ because of organizational policies,
▫ because of the need of interoperability with other
software and hardware systems, or
▫ because of external factors such as safety regulations,
privacy legislation, etc.
 11

Non-Functional Requirements
Non-Functional
requirements

Product Organizational External

requirements requirements requirements
Non-Functional Requirements
• Examples
▫ The system shall allow one hundred thousand hits per minute on the
website
▫ The system shall not have down time of more than one second for
continuous execution of one thousand hours

12
Organizational Requirements
• Example
▫ The system development process and deliverable documents shall
conform to the MIL-STD-2167A
▫ Any development work sub-contracted by the development
organization shall be carried out in accordance with Capability
Maturity Model

13
External Requirements
• Example
▫ The system shall not disclose any personal information about
members of the library system to other members except system
administrators
▫ The system shall comply with the local and national laws regarding
the use of software tools

14
 15

Observations on NFRs
• Non-functional requirements can be written to
reflect general goals for the system.
▫ Examples include:
 Ease of use
 Recovery from failure
 Rapid user response
• Goals are open to misinterpretation
• Non-functional requirements should be written in a
quantitative manner as much as possible, which is
not always easy for customers
▫ For some goals, there are no quantitative measures,
e.g., maintainability
 16

Observations on NFR
• Goals can be useful to designers and developers, as
they give clues to them about priorities of the
customers
• Chances of conflicts within non-functional
requirements are fairly high, because information is
coming from different stakeholders.
▫ For example, different stakeholders can give different
response times or failure tolerance levels, etc
• Some negotiations must be done among different
stakeholders, to achieve an agreement in these
situations
 17

Domain Requirements
• Requirements that come from the application
domain and reflect fundamental characteristics of
that application domain
▫ These can be both the functional or non-functional
requirements
 These requirements, sometimes, are not explicitly
mentioned
 Domain experts find it difficult to convey domain
requirements
▫ Their absence can cause significant dissatisfaction
▫ Domain-specific terminology can also cause confusion
• Banking domain has its own specific constraints,
▫ for example, most banks do not allow over-draw on
most accounts, however, most banks allow some
accounts to be over-drawn
 18

Inverse Requirements
• They explain what the system shall not do.
▫ Many people find it convenient to describe their
needs in this manner
• These requirements indicate the indecisive
nature of customers about certain aspects of
a new software product
▫ Example:
 The system shall not use red color in the user interface,
whenever it is asking for inputs from the end-user
 19

Design and Implementation Constraints

• They are development guidelines within
which the designer must work
▫ These requirements can seriously limit design
and implementation options
 Can also have impact on human resources
▫ Example
 The system shall be developed using the
Microsoft .Net platform
 The system shall be developed using open source
tools and shall run on Linux operating system
 20

Requirements Problems
• The requirements don’t reflect the real needs of the
customer for the system.
• Requirements are inconsistent and/or incomplete
• It is expensive to make changes to requirements after
they have been agreed upon.
• There are misunderstandings between customers, those
developing the system requirements, and software
engineers developing or maintaining the system
 21

Problems with NL
• Requirement specification in natural language
pose some problems which include
▫ Lack of clarity
▫ Requirements confusion
▫ Requirements amalgamation
• Natural language understanding relies on the
specification readers and writers using the same
words for same concept
▫ A natural language requirements specification is
over-flexible.
“You can say the same thing in completely
different ways”
 22

Clarifying Requirements
infeasible, incorrect, in-concise, ambiguous , in-complete, in-consistent,
not Verifiable, non-Traceable, Design dependent

System will register the users.

Library system will allow users to search books.
System should be user friendly and easy to use.
All transactions should be completed within 5 minutes requiring a response time
of less than 3 sec time.
ATM machine can take input via touch screen as well as from keyboard.

All requirements of ATM system will remain same as stated in previous

document.