0% found this document useful (0 votes)
16 views37 pages

Week 06

The document outlines the various types of software requirements, including functional, non-functional, domain, inverse, and design constraints. It emphasizes the importance of clear and complete requirements to avoid ambiguity and ensure software quality. Additionally, it discusses the sources of requirements and the critical role they play in meeting stakeholder needs and compliance with standards.

Uploaded by

aareebaarif32
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views37 pages

Week 06

The document outlines the various types of software requirements, including functional, non-functional, domain, inverse, and design constraints. It emphasizes the importance of clear and complete requirements to avoid ambiguity and ensure software quality. Additionally, it discusses the sources of requirements and the critical role they play in meeting stakeholder needs and compliance with standards.

Uploaded by

aareebaarif32
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 37

Software Requirements -

1
 A complete description of what the
software system will do without
describing how it will do it is
represented by the software
requirements

1
IEEE Definition

 A condition or capability that must


be met or possessed by a system...to
satisfy a contract, standard,
specification, or other formally
imposed document
 IEEE Std 729

2
Sources of Requirements

 Stakeholders
 People affected in some way by the
system
 Documents
 Existing system
 Domain/business area

3
4
Kinds of Software
Requirements
 Functional requirements
 Non-functional requirements
 Domain requirements
 Inverse requirements
 Design and implementation
constraints

5
6
Functional Requirements
- 1
 Statements describing what the
system does

 Functionality of the system

7
Functional Requirements
- 4
 Functional requirements should be
complete and consistent

 Customers and developers usually


focus all their attention on functional
requirements

8
Functional Requirements
Example # 1
 The system shall solve a quadratic
equation using the following formula

x = (-b+sqrt(b2 –
4*a*c))/2*a

9
Functional Requirements
Example # 3
 The system shall provide appropriate
viewers for the user to read
documents in the document store

10
Comments on Examples

 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

x = (-b+sqrt(b2 –
4*a*c))/2*a

11
Comments on Examples

 Incomplete and ambiguous


requirements are open to multiple
interpretations and assumptions

 This can lead to the development of


poor quality, or faulty, software
products

12
Non-Functional
Requirements - 1
 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.

14
Non-Functional
Requirements - 2
 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

15
Non-Functional
Requirements -
 For example, 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

16
Non-Functional
Requirements - 5
 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.

17
Non-Functional
Requirements
Non-Functional
requirements

Product Organizational External


requirements requirements requirements

18
Product Requirements

Product
requirements

Usability Efficiency Reliability Portability


requirements requirements requirements requirements

Performance Space
requirements requirements

19
Product 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

20
Organizational
Requirements
Organizational
requirements

Standards Implementation Delivery


requirements requirements requirements

21
Organizational Requirements
Examples
 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

22
External Requirements

External
requirements

Interoperability Ethical Legislative


requirements requirements requirements

Privacy Safety
requirements requirements

23
External Requirements
Examples
 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

24
Non-Functional Requirements
Discussion
 NFRs are very important to capture the
emergent behavior of the system in
these there major dimensions
 Product
 Usability, reliability, portability, efficiency
(performance, space)
 Organizational
 Standards, implementation, delivery
 External
 Interoperability, ethical, legislative (privacy,
safety)

25
Domain Requirements - 1

 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

27
Domain Requirements - 2

 These requirements, sometimes, are


not explicitly mentioned
 Domain experts find it difficult to
convey domain requirements
 Their absence can cause significant
dissatisfaction

28
Domain Requirements - 3

 Domain requirements can impose


strict constraints on solutions. This
is particularly true for scientific and
engineering domains
 Domain-specific terminology can also
cause confusion

29
Domain Requirements - 4

 Example:
In a commission-based sales
businesses, there is no concept of
negative commission. However, if
care is not taken novice developers
can be lured into developing
systems, which calculate negative
commission

30
Domain Requirements - 5

 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

31
Inverse Requirements - 1

 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
33
Inverse Requirements - 2

 Example:
The system shall not use red color in
the user interface, whenever it is
asking for inputs from the end-user

34
Design and Implementation
Constraints - 1
 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

36
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

37

You might also like