Software Requirements

●​ 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

Types of Software Requirements

Software Requirements are mainly classified into three types:

●​ Functional requirements

●​ Non-functional requirements

●​ Domain requirements

1. Functional Requirements

Definition: Functional requirements describe what the software should do.

They define the functions or features that the system must have.

Examples:

●​ User Authentication: The system must allow users to log in using a

username and password.

●​ Search Functionality: The software should enable users to search

for products by name or category.

●​ Report Generation: The system should be able to generate sales

reports for a specified date range.

Explanation: Functional requirements specify the actions that the software
needs to perform. These are the basic features and functionalities that users
expect from the software.

2. Non-functional Requirements

Definition: Non-functional requirements describe how the software performs

a task rather than what it should do. They define the quality attributes,
performance criteria, and constraints.

Examples:

●​ Performance: The system should process 1,000 transactions per

second.

●​ Usability: The software should be easy to use and have a

user-friendly interface.

●​ Reliability: The system must have 99.9% uptime.

●​ Security: Data must be encrypted during transmission and storage.

Explanation: Non-functional requirements are about the system’s behavior,

quality, and constraints. They ensure that the software meets certain
standards of performance, usability, reliability, and security.

3. Domain Requirements

Definition: Domain requirements are specific to the domain or industry in

which the software operates. They include terminology, rules, and standards
relevant to that particular domain.

Examples:
 ●​ Healthcare: The software must comply with HIPAA regulations for

handling patient data.

●​ Finance: The system should adhere to GAAP standards for financial

reporting.

●​ E-commerce: The software should support various payment

gateways like PayPal, Stripe, and credit cards.

Explanation: Domain requirements reflect the unique needs and constraints

of a particular industry. They ensure that the software is relevant and
compliant with industry-specific regulations and standards.

Advantages of classifying software requirements include:

1.​ Better organization: Classifying software requirements helps

organize them into groups that are easier to manage, prioritize, and

track throughout the development process.

2.​ Improved communication: Clear classification of requirements

makes it easier to communicate them to stakeholders, developers,

and other team members. It also ensures that everyone is on the

same page about what is required.

3.​ Increased quality: By classifying requirements, potential conflicts or

gaps can be identified early in the development process. This

reduces the risk of errors, omissions, or misunderstandings, leading

to higher-quality software.
 4.​ Improved traceability: Classifying requirements helps establish

traceability, which is essential for demonstrating compliance with

regulatory or quality standards.

Disadvantages of classifying software requirements

Disadvantages of classifying software requirements include:

1.​ Complexity: Classifying software requirements can be complex,

especially if there are many stakeholders with different needs or

requirements. It can also be time-consuming to identify and classify

all the requirements.

2.​ Rigid structure: A rigid classification structure may limit the ability

to accommodate changes or evolving needs during the development

process. It can also lead to a siloed approach that prevents the

integration of new ideas or insights.

3.​ Misclassification: Misclassifying requirements can lead to errors or

misunderstandings that can be costly to correct later in the

development process.
 Basis Top-Down Approach Bottom-Up Approach

Approach Top-Down Approach is Bottom-Up Approach is

Theory-driven. Data-Driven.
Significance Emphasis is on doing things Emphasis is on data rather than
(algorithms). procedure.
Focus Large programs are divided Programs are divided into what
into smaller programs which is are known as objects is called
known as decomposition. Composition.
Interaction Communication is less among Communication is a key among
the modules. the modules.
Areas Widely used in debugging, Widely used in testing.
module documentation, etc.
Language The top-down approach is The bottom-up approach is used
mainly used by Structured by Object-Oriented programming
programming languages like languages like C++, C#, Java,
C, Fortran, etc. etc.
Redundancy May contains redundancy as This approach contains less
we break up the problem into redundancy if the data
smaller fragments, then build encapsulation and data hiding
that section separately. are being used.

Solves smaller problems and

1 focus on breaking the problem into
integrates them into a complete
. smaller, more manageable parts
system

Mainly used in Structured Mainly used in Object Oriented

2
programming languages like COBOL, Programming languages like C++,
.
Fortran, C, etc. C#, Python.
3 Each part is programmed separately Redundancy is minimized by using
. therefore contains redundancy. data encapsulation and data hiding.

4 communication is less among Modules must communicate to

. modules. integrate the system.

5 It is used for debugging and module

It is basically used in testing.
. documentation

Composition of the system happens

6 Decomposition of the system occurs, by combining low-level
. breaking it into smaller components. components into a higher-level
structure.

In this sometimes we can not build

7 The top function of system might be
a program from the piece we have
. hard to identify.
started.

Building a program can be difficult

8 implementation details can vary
if modules are not assembled in a
. throughout the process
logical order
 Validation
Verification

Validation refers to the set of

Verification refers to the set of
activities that ensure that the
activities that ensure software
Definition software that has been built is
correctly implements the
traceable to customer
specific function
requirements.

It includes checking documents, It includes testing and

Focus
designs, codes, and programs. validating the actual product.

Verification is the Static

Type of Testing Validation is Dynamic testing.
testing.

It does not include the It includes the execution of the

Execution
execution of the code. code.

Methods used in validation are

Methods used in verification are
Black Box Testing, White Box
Methods Used reviews, walkthroughs,
Testing and Non-Functional
inspections and desk-checking.
testing.

It checks whether the software

It checks whether the software
meets the requirements and
Purpose conforms to specifications or
expectations of a customer or
not.
not.
 It can only find the bugs that
It can find the Bugs in the early
Bug could not be found by the
stage of the development.
verification process.

The goal of verification is

The goal of validation is an
Goal application and software
actual product.
architecture and specification.

Verification is typically
Validation is performed by the
performed by the quality
testing team, which executes
assurance (QA) team, focusing
the software in real
Responsibility on reviewing documents,
environments to ensure it
designs, and code to ensure
meets user expectations and
compliance with specified
requirements.
requirements.

Timing It comes before validation. It comes after verification.

It consists of checking of It consists of execution of

Human or
documents/files and is program and is performed by
Computer
performed by human. computer.

After a valid and complete

Validation begins as soon as
Lifecycle specification the verification
project starts.
starts.

Verification is for prevention of Validation is for detection of

Error Focus
errors. errors.
 Verification is also termed as Validation can be termed as
Another white box testing or static black box testing or dynamic
Terminology testing as work product goes testing as work product is
through reviews. executed.

Verification finds about 50 to Validation finds about 20 to

Performance
60% of the defects. 30% of the defects.

Verification is based on the

Validation is based on the fact
Stability opinion of reviewer and may
and is often stable.
change from person to person.
1. Manual Testing

Manual Testing is a technique to test the software that is carried out using
the functions and features of an application. Which means manual testing
will check the defect manually with trying one by one function is working as
expected.

2. Automation Testing

Automation Testing It is a technique where the Tester writes scripts

independently and uses suitable Software or Automation Tools to test the
software. It is an Automation Process of a Manual Process. It allows for
executing repetitive tasks without the use of a Manual Tester.

Types of Manual Testing

Manual testing will be divided into further types which is following:

1. White Box Testing

White Box Testing is a software testing technique that involves testing the
internal structure and workings of a software application. The tester has
access to the source code and uses this knowledge to design test cases that
can verify the correctness of the software at the code level.

2. Black Box Testing

Black-Box Testing is a type of software testing in which the tester is not

concerned with the internal knowledge or implementation details of the
software but rather focuses on validating the functionality based on the
provided specifications or requirements.

3. Gray Box Testing

Gray Box Testing is a software testing technique that is a combination of the
Black Box Testing technique and the White Box Testing technique. In the
Black Box Testing technique, the tester is unaware of the internal structure of
the item being tested and in White Box Testing the internal structure is
known to the tester.

Types of Black Box Testing

Black Box Testing will be divided into further types which is following:

1. Functional Testing

Functional Testing is a type of Software Testing in which the system is

tested against the functional requirements and specifications. Functional
testing ensures that the requirements or specifications are properly satisfied
by the application.

2. Non-Functional Testing

Non-Functional Testing is a type of Software Testing that is performed to

verify the non-functional requirements of the application. It verifies whether
the behavior of the system is as per the requirement or not. It tests all the
aspects that are not tested in functional testing.

Types of Functional Testing

Functional Testing will be divided into further types which is following:

1. Unit Testing

Unit Testing is a method of testing individual units or components of a

software application. It is typically done by developers and is used to ensure
that the individual units of the software are working as intended.
2. Integration Testing

Integration Testing is a method of testing how different units or components

of a software application interact with each other. It is used to identify and
resolve any issues that may arise when different units of the software are
combined.

3. System Testing

System Testing is a type of software testing that evaluates the overall

functionality and performance of a complete and fully integrated software
solution. It tests if the system meets the specified requirements and if it is
suitable for delivery to the end-users.