Scribd
Upload
9 views

Type of Software Requirements

The document discusses different types of software requirements including functional requirements, non-functional requirements, domain requirements, inverse requirements, design and implementation constraints, reliability requirements, and safety requirements. Functional requirements describe the services or functions a system should provide, while non-functional requirements define properties like performance, reliability, and storage. Domain requirements reflect the characteristics of the application area. Inverse requirements describe what a system should not do. Design constraints guide system development. Reliability and safety requirements ensure proper system operation.

Uploaded by

Afifa Azam
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
9 views

Type of Software Requirements

The document discusses different types of software requirements including functional requirements, non-functional requirements, domain requirements, inverse requirements, design and implementation constraints, reliability requirements, and safety requirements. Functional requirements describe the services or functions a system should provide, while non-functional requirements define properties like performance, reliability, and storage. Domain requirements reflect the characteristics of the application area. Inverse requirements describe what a system should not do. Design constraints guide system development. Reliability and safety requirements ensure proper system operation.

Uploaded by

Afifa Azam
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

Type of

Software Requirements

By:
Maham Tariq
Type of
Software Requirements
1. Functional Requirements
2. Non-Functional Requirements
3. Domain Requirements
4. Inverse Requirements
5. Design and implementation constraints
6. Reliability Requirements
7. Safety Requirements
Functional and non-functional require-
ments
 Functional requirements
• Statements of services or functions the system
should provide, how the system should react
to particular inputs and how the system should
behave in particular situations.
 Non-functional requirements
• Define system properties and constraints e.g.
reliability, response time and storage require-
ments. Constraints are I/O device capability,
system representations, etc.
• Non-functional requirements may be more crit-
ical than functional requirements. If these are
not met, the system is useless.
Functional requirements
 Describe functionality or system services
 Depend on the type of software, expected
users and the type of system where the
software is used
 Functional user requirements may be
high-level statements of what the system
should do but functional system require-
ments should describe the system services
in detail
Examples of
Functional Requirements
 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 perman-
ent storage area.
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 or-
ganisational policies and procedures e.g. pro-
cess standards used, implementation require-
ments, etc.
 External requirements
• Requirements which arise from factors which
are external to the system and its development
process e.g. inter-operate requirements, legis-
lative requirements, etc.
Note: Interoperability is a property referring to the ability of diverse
systems and organizations to work together (inter-operate)
Non-functional requirement types
Non-functional
requir ements

Product Or ganizational External


requirements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical


requir ements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative


requirements requirements requir ements requirements requirements

Performance Space Privacy Safety


requirements requir ements requirements requirements
Domain Re-
quirements
Domain Requirements
 Requirements that come from the
application domain and reflect fun-
damental characteristics of that ap-
plication domain(sphere of influence)
 These can be both the functional or
non-functional requirements.
Domain Requirements
 Example-1:
In a commission-based sales busi-
nesses, there is no concept of nega-
tive commission. However, if care is
not taken novice developers can be
developed systems, which calculate
negative commission.
Domain Requirements
 Example-2:
Banking domain has its own specific
constraints, for example, most banks
do not allow over-draw on most ac-
counts, however, most banks allow
some accounts to be over-drawn.
Domain Requirements
 These requirements, sometimes, are
not clearly mentioned
 Req. engineers find it difficult to con-
vey domain requirements
 So Domain experts get it properly.
 Their absence can cause significant
dissatisfaction
Domain Requirements
 Domain requirements can impose
strict constraints on solutions. This
is particularly true for scientific and
engineering domains
 Domain-specific terminology can also
cause confusion
Inverse Requirements
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 unwanted


needs of customers about certain aspects
of a new software product
Inverse Requirements
 Example:
The system shall not use red color in
the user interface, whenever it is
asking for inputs from the end-user
Design and Implementa-
tion Constraints
Design and Implementation Constraints

 They are development guidelines


within which the designer must work
 These requirements can seriously
limit design and implementation op-
tions.
 Can also have impact on human re-
sources due to change in scope of
work.
Design and Implementation
Constraints Examples
 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.
Safety Requirements
 Safety requirements cover not only human
safety, but also equipment and data safety.
Human safety considerations include protecting
the operator from moving parts, electrical cir-
cuitry and other physical dangers. There may
be special operating procedures, which if ig-
nored may lead to a dangerous condition oc-
curring. Equipment safety includes safeguarding
the software system from unauthorized access
either electronically or physically. An example of
a safety requirement may be that a security
monitor used in the system.

20
Reliability Requirements
 Reliability requirements are those which the software
must meet in order to perform a specific function
under certain stated conditions, for a given period of
time.
 The level of reliability requirement can be dependant
on the type of system, i.e. the more critical or life
threatening the system, the higher the level of relia-
bility required.
 Reliability can be measured in a number of ways in-
cluding number of bugs per x lines of code, mean
time to failure.

21

You might also like