Week 2 Classifying software requirements v2

1. Classifying software requirements

CLASSIFYING
SOFTWARE
REQUIREMENTS
DR. CHANDRA REKA

2. OUTLINE

IMPORTANCE OF STATING CLEAR & DETAIL REQUIREMENTS
CLASSIFYING SOFTWARE REQUIREMENTS
DEFINITION OF FR & NFR
IDENTIFICATION OF FR & NFR
EXAMPLES OF EACH OF FR & NFR

3. Importance of stating detail & clear requirements

Importance of stating detail & clear
requirements
◦ Define the terms and roles. Requirements help to ensure that the development team and stakeholders
are on the same page to avoid misunderstandings in the future.
◦ Reduce communication time. Close cooperation with BA ensures much clearer requirements and less
development time. Such an approach reduces the time required for communication during the
development stage, as well as the project's cost.
◦ Make the project estimation more precise. Detailed requirements help us to estimate the development
time and cost more accurately.
◦ See the possible mistakes beforehand. When the team visualizes the project details during the discovery
(inception) phase, they may identify errors in the initial stage of development. Therefore, they save your
time and budget.
◦ Create more predictable projects. High-quality requirements and wireframes help to predict the result
and develop the project that meets your expectations.

4. Remember this!

◦ UNCLEAR
requirements
increase the project
timeline and
budget up to 60%!

5.

◦ A software requirement
can be of 3 types:
• Functional
requirements
• Non-functional
requirements
• Domain requirements

6. Functional Requirements

◦ Describe functionality or system services (features).
◦ 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.
◦ Functional system requirements should describe the system services in detail.

7. Non Functional Requirements

◦ NON-FUNCTIONAL REQUIREMENT (NFR) specifies the quality attribute of a software system.
◦ They judge the software system based on Responsiveness, Usability, Security, Portability and other nonfunctional standards that are critical to the success of the software system.
◦ Example of nonfunctional requirement, “how fast does the website load?” Failing to meet non-functional
requirements can result in systems that fail to satisfy user needs.

8. Definition of functional requirements

◦ Functional requirements describe
what the system should do
◦ things that can be captured in
use cases
◦ things that can be analyzed by
drawing sequence diagrams,
statecharts, etc.
◦ Functional requirements will
probably trace to individual
chunks of a program
◦ A functional requirement defines a
system or its component
◦ The Functional Requirements
Document (FRD) is a formal
statement of an application’s
functional requirements.
◦ FRD serves the same purpose as a
contract / agreement between
developers and clients.
Example: A
functional
requirement
for a milk
carton would
be “ability to
contain fluid
without
leaking”

9. Non Functional Requirements

“Any Requirement That Specifies How The System Performs A
Certain Function.”
NFR’s are classified into following types:
◦ Interface constraints
◦ Performance constraints: response time,
security, storage space, etc.
◦ Operating constraints
◦ Life cycle constraints: mantainability,
portability, etc.
◦ Economic constraints
The process of specifying non-functional
requirements requires the knowledge of the
functionality of the system, as well as the
knowledge of the context within which the
system will operate.
Example: A nonfunctional requirement
for a hard hat might be
“must not break under
pressure of less than
10,000 PSI”

10. Comparison

◦ 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. In some
cases, the functional requirements may also explicitly state what the
system should not do.
◦ Non-Functional Requirements:
◦ constraints on the services or functions offered by the system.
◦ include timing constraints, constraints on the development process,
and constraints imposed by standards.
◦ Non-functional requirements often apply to the system as a whole,
rather than individual system features or services.

11.

Parameters
What is it?
Requirement
Capturing type
Functional Requirement
Non-Functional Requirement
Verb
Attributes
It is mandatory
It is non-mandatory
It is captured in use case.
It is captured as a quality attribute.
Product feature
Product properties
Easy to capture
Hard to capture
Objective
Helps you verify the functionality of the
software.
Helps you to verify the performance of the
software.
Area of focus
Focus on user requirement
Concentrates on the user's expectation.
Documentation
Describe what the product does
Describes how the product works
Type of Testing
Functional Testing like System, Integration, End Non-Functional Testing like Performance,
to End, API testing, etc.
Stress, Usability, Security testing, etc.
Test Execution
Test Execution is done before non-functional
testing.
End-result
Capturing
Product Info
Product Features
After the functional testing
Product Properties

12. Quantitative Vs Qualitative

For non-functional requirements to help teams
measure the success of a system, a non-functional
requirement must first and foremost be measurable.
An example of a non-functional requirement that
could be made quantitative to reinforce the
purpose of NFR’s:
◦ Qualitative NFR – “The system should
be scalable to handle enterprise expansion.”
(valid, but not testable or measurable)
◦ Quantitative NFR – “The system should
be scalable to 10,000 users within the next 2
years.”

13. Domain requirements

20
▶ Derived from the application domain and describe system characteristics
and features that reflect the domain
▶ May be new functional requirements, constraints on existing requirements
or define specific computations
▶ If domain requirements are not satisfied, the system may be unworkable

14. Domain requirements problems

21
▶ Understandability
▶ Requirements are expressed in the language of the application domain
▶ This is often not understood by software engineers developing the system
▶ Implicitness
▶ Domain specialists understand the area so well that they do not think of making the
domain requirements explicit

15. Domain requirements

◦ Domain requirements are the requirements which are characteristic of a particular category or
domain of projects.
◦ Domain requirements reflect the environment in which the system operates so, when we talk
about an application domain we mean environments such as train operation, medical records, ecommerce etc.
◦ For instance, in an academic software that maintains records of a school or college, the
functionality of being able to access the list of faculty and list of students of each grade is a
domain requirement. These requirements are therefore identified from that domain model and are
not user specific.

16. Example of Domain requirements

In a commission based business, there is
no concept of negative commission.
However if care is not taken properly,
developers may not notice the
calculation of negative commission.
Example of
Domain
requirements
In a banking domain, most banks do
not allow over drawn on most
accounts, however some banks can
allow this operation to occur.
In a train operation system need to take
into account the braking characteristics
in different weather conditions.

17. Build, organize, and map your itineraries in a free travel app designed for vacations & road trips

Build, organize, and map your itineraries in a free travel app
designed for vacations & road trips
Write down at least FIVE Functional Requirements and FIVE Non Functional Requirements.

18. REFERENCES

◦ https://www.modernrequirements.com/blogs/pillar/what-are-non-functional-requirements/
◦ https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/