Classification of Software

Requirements
Classification of Software Requirements
• The software requirements are description of features and
functionalities of the target system.
• Requirements convey the expectations of users from the software
product.
• The requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
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.
Types of software requirement
• Main types of software requirement can be of 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements
• Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer.
• It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what function
a system is likely to perform.
• All these functionalities need to be necessarily incorporated into the
system as a part of the contract.
• These are represented or stated in the form of input to be given to the
system, the operation performed and the output expected.
• They are basically the requirements stated by the user which one can see
directly in the final product, unlike the non-functional requirements.
• For example, in a hospital management system, a doctor should be
able to retrieve the information of his patients.
• Each high-level functional requirement may involve several
interactions or dialogues between the system and the outside world.
• In order to accurately describe the functional requirements, all
scenarios must be enumerated.
• There are many ways of expressing functional requirements e.g.
formal specification language with proper syntax.
• Functional Requirements in Software Engineering are also called
Functional Specification.
• Non-functional requirements: These are basically the quality
constraints that the system must satisfy according to the project
contract.
• Nonfunctional requirements, not related to the system functionality,
rather define how the system should perform The priority or extent to
which these factors are implemented varies from one project to
other.
• They are also called non-behavioral requirements.
• They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
NFR’s are classified into following types:

• NFR’s are classified into following types:

• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability, 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.
• They are divided into two main categories:
• Execution qualities like security and usability, which are observable at
run time.
• Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software
system.
• Domain requirements: Domain requirements are the requirements
which are characteristic of a particular category or domain of
projects.
• Domain requirements can be functional or nonfunctional.
• Domain requirements engineering is a continuous process of
proactively defining the requirements for all foreseeable applications
to be developed in the software product line.
• The basic functions that a system of a specific domain must
necessarily exhibit come under this category. 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.
Other common classifications
• User requirements: These requirements describe what the end-user
wants from the software system. User requirements are usually
expressed in natural language and are typically gathered through
interviews, surveys, or user feedback.
• System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces.
System requirements are typically expressed in technical terms and
are often used as a basis for system design.
• Business requirements: These requirements describe the business
goals and objectives that the software system is expected to achieve.
Business requirements are usually expressed in terms of revenue,
market share, customer satisfaction, or other business metrics.
• Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other
legal compliance requirements.
• Interface requirements: These requirements specify the interactions
between the software system and external systems or components,
such as databases, web services, or other software applications.
• Design requirements: These requirements describe the technical
design of the software system. They include information about the
software architecture, data structures, algorithms, and other
technical aspects of the software.
• By classifying software requirements, it becomes easier to manage,
prioritize, and document them effectively. It also helps ensure that all
important aspects of the system are considered during the
development process.
Advantages of classifying software
requirements include:
• Better organization: Classifying software requirements helps organize
them into groups that are easier to manage, prioritize, and track
throughout the development process.
• 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.
• 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.
• Improved traceability: Classifying requirements helps establish traceability,
which is essential for demonstrating compliance with regulatory or quality
standards.
Disadvantages of classifying software
requirements include:
• 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.
• 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.
• Misclassification: Misclassifying requirements can lead to errors or
misunderstandings that can be costly to correct later in the
development process.
• Overall, the advantages of classifying software requirements
outweigh the disadvantages, as it helps ensure that the software
system meets the needs of all stakeholders and is delivered on time,
within budget, and with the required quality.
• Thank You