WHAT IS A SOFTWARE REQUIREMENT?

A Software Requirement is a documented condition that a particular software service or

product needs to meet to be considered complete. These particular requirements are mostly
derived from the stakeholder’s and customer's needs. It serves as the fundamental part of the
software development process.

Software Requirements guide planning, designing, implementation, testing and maintenance

stages, acting as a critical link amongst all aspects of the project. They elucidate their
significance, characteristics, and how they are interrelated to shape a successful software
project.

According to IEEE standard 729, a requirement is defined as follows:

 A condition or capability needed by a user to solve a problem or achieve an objective

 A condition or capability that must be met or possessed by a system or system component to

satisfy a contract, standard, specification or other formally imposed documents

 A documented representation of a condition or capability, as in 1 and 2.

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 for a contract - therefore must be open to interpretation
 May be the basis for the contract itself - therefore must be defined in detail
 Both of these statements may be called requirements

Typically, requirements are presented into two levels of detail; user and system requirements, where
user need a high-level statement of the requirements, while system developers need a more detailed
system specification. So, user and system requirements just refer to different levels of detail.

Having different levels of detail is useful because it communicates information about the system
being developed for different types of readers.

So, end-users will not be concerned with the detail, they need a generic, abstracted written
requirement.
While the people who are involved in the development need to know what exactly the system should
do.

You will probably end up with a lot of problems and misunderstandings if you didn’t have a clear
separation between the different level details.

1. USER REQUIREMENTS
 It describes the services that the system should provide and the constraints under which it
must operate. We don’t expect to see any level of detail, or what exactly the system will do,
it’s more of generic requirements.
 It is defined using natural language tables and diagrams in order that non-technical clients can
better understand the requirements and point out potential problems.
 It’s should describe functional and non-functional requirements so that they are
understandable by system users who don’t have detailed technical knowledge.
 We provide a definition for a user requirement.

Example:

 Requirement: "Users should be able to search for products using keywords and filter
results by price range."
 Explanation: This outlines what users want to achieve with the system in simple
terms, emphasizing usability

2. SYSTEM REQUIREMENTS
 The system requirements mean a more detailed description of the system services and the
operational constraints such as how the system will be used and development constraints such
as the programming languages.
 This level of detail is needed by those who are involved in the system development, like
engineers, system architects, testers, etc.
 Written as a contract between client and contractor
 We provide a specification for a system requirement.

Example:

 Requirement: "The application shall run on Windows 10 or higher and require at

least 4 GB of RAM and 500 MB of disk space."
 Explanation: This outlines the necessary environment for the software to operate,
providing specific technical details.

3. FUNCTIONAL REQUIREMENT
 It covers the main functions that should be provided by the system. When expressed
as user requirements, they are usually described in an abstract way.
 However, more specific functional system requirements describe the system functions,
its inputs, processing; how it’s going to react to a particular input, and what the
expected output is.
Example:

 Requirement: "The system shall allow users to create an account by providing their
email address and a password."
 Explanation: This requirement defines a specific function of the system: account
creation. It tells developers exactly what the system must be able to do.

4. NON-FUNCTIONAL REQUIREMENTS

 Non-functional requirements specify how a system must behave. These are qualities,
standards, constraints upon the systems services that are specified with respect to a product,
organization, and external environment.
 It is non-negotiable obligations that must be supported by the software.
 Its capture those requirements of the customer that cannot be expressed as functions.
 It is related to functional requirements, i.e., how efficiently, by how much volume, how fast,
at what quality, how safely, etc., a function is performed by a particular system.
 Aspects concerning external interfaces, user interfaces, maintainability, portability, usability,
maximum number of concurrent users, timing, and throughput.
 The non-functional requirements can be critical in the sense that any failure by the developed
software to achieve some minimum defined level in these requirements can be considered as a
failure and make the software unacceptable by the customer.

Example:

 Requirement: "The system shall be able to handle 1000 simultaneous users with a
response time of less than 2 seconds."
 Explanation: This specifies performance criteria. It doesn’t describe a feature but sets
a standard for system performance under load.

The different types of non functional requirements are as follows:

4.1 PRODUCT REQUIREMENTS:

 These requirements specify how software product performs. Product requirements comprise
of the following:
 Efficiency requirements: Describe the extent to which software makes optimal use of
resources, the speed with which system executes, and the memory it consumes for its
operation. For example, system should be able to operate at least three times faster than
the existing system.
 Reliability requirements: Describe the acceptable failure rate of the software. For
example, software should be able to operate even if a hazard occurs.
 Portability requirements: Describe the ease with which software can be transferred
from one platform to another. For example, it should be easy to port software to different
operating system without the need to redesign the entire software.
 Usability requirements: Describe the ease with which users are able to operate the
software. For example, software should be able to provide access to functionality with
fewer keystrokes and mouse clicks.

4.2 ORGANIZATIONAL REQUIREMENTS:

These requirements are derived from the policies and procedures of an organization.
Organizational requirements comprise of the following:
 Delivery requirements: Specify when software and its documentation are to be delivered
to the user.
 Implementation requirements: Describe requirements, such as programming language
and design method.
 Standards requirements: Describe the process standards to be used during software
development. For example, software should be developed using standards specified by
ISO (International Organization for Standardization) and IEEE standards.

4.3 EXTERNAL REQUIREMENTS:

These requirements include all the requirements that affect the software or its development
process externally. External requirements comprise of the following:
 Interoperability requirements: Define the way in which different computer-based
systems interact with each other in one or more organizations.
 Ethical requirements: Specify the rules and regulations of the software so that they are
acceptable to users.
 Legislative requirements: Ensure that software operates within the legal jurisdiction.
For example, pirated software should not be sold.

Non-functional requirements may be very difficult to state precisely and imprecise

requirements may be difficult to verify. If they are stated as a goal (a general intention of the
user such as ease of use), they should be rewritten as a verifiable non-functional requirement
(a statement using some quantifiable metric that can be objectively tested). Goals are helpful
to developers as they convey the intentions of the system users.
Non-functional requirements should be measurable

Whenever possible, we should write non-functional requirements quantitatively, so that they

can be tested. You can measure them when the system is being tested to check whether the
system meets its non-functional requirements.
In practice, customers for a system often find it difficult to translate their goals into
measurable requirements. They don’t understand what some numbers define as the required
speed or reliability. For some goals, such as maintainability, there’re no metrics that can be
used.

The cost of verifying measurable non-functional requirements can be very high and the
customers may not think that these costs are justified.

5. DOMAIN REQUIREMENTS
 Derived from the application domain and describe system characteristics and features
that reflect the domain.
 Domain requirements may be new functional requirements, constraints on existing
requirements or define specific computations.
 Understandability
o Requirements are expressed in the language of the application domain
o This is often not understood by software engineers developing the system (e.g.
consider the previous slide) would they understand the Physics/Engineering
 Implicitness
o Domain specialists understand the area so well that they do not think of
making the domain requirements explicit which leads to problems later if
software developer implements the requirements in the wrong way

Example:

 Requirement: "The application must comply with HIPAA regulations for healthcare
data privacy."
  Explanation: This requirement ensures that the software adheres to specific legal
standards relevant to healthcare, affecting how data is stored and accessed.

6. INTERFACE REQUIREMENTS

These define how the system interacts with other systems or components.

Example:

 Requirement: "The system shall integrate with the payment gateway API, using
HTTPS for secure communication."
 Explanation: This specifies how the system will connect to an external service,
detailing the security protocol to be used.