Unit 2

Software Requirement Analysis and Specification

• Every new software product or service developed in any corporation is
in response to a business requirement. Despite spending significant
time and money on the development, there may be a mismatch
between the needed product (according to the business requirement)
and the final result. Hence, to avoid severe problems in the future, a
focused and complete requirements analysis is required in the early
stages of every project. The process of determining the needs and
expectations of a new product is known as 'requirements analysis' or
'requirements engineering'. It entails continuous communication with
the product's stakeholders and end-users to set expectations, manage
issues, and document all critical needs.
What is a Software Requirement?
• A software requirement is a capability that the user requires to solve
an issue or achieve a goal.
• In other words, a requirement is a software capability that a system or
system module must meet to satisfy a contract, standard, or
specification.
• Ultimately, we want to provide high-quality software that matches
clients' actual needs on schedule and within budget.
What is a Software Requirement?
• All project stakeholders - developers, end users, software managers,
and customer managers - must agree on what the product will look
like, or someone will be surprised when it is delivered, which is an
undesirable event.
• Therefore, while establishing the requirements for a software
product, we need methods to accurately capture, interpret, and
express the voice of the customer.
What is Requirement Analysis in Software
Engineering?
• The process of defining user expectations to build a new software
product or to modify an existing one is known as requirement
analysis, sometimes known as requirement engineering requirements
gathering, or requirements capture in software engineering.
• The tasks that go into determining the needs or conditions to meet
for a new or altered product, taking into account the potentially
conflicting requirements of the various stakeholders, and analyzing,
documenting, validating, and managing software or system
requirements are all included in requirements analysis.
What is Requirement Analysis in Software
Engineering?
• This exercise goes over all of the requirements and may provide a
graphical representation of the entire system.
• As a result, the project's understandability is predicted to improve
significantly after the study is completed.
• We may also leverage the contact with the customer to clear up any
confusion and determine which requirements are more crucial than
others.
Steps Involved in Requirement Analysis
• Step 1: Recognize the Problem

• The primary goal of requirement analysis is to thoroughly grasp the

main objective of the requirement, which includes why it is needed,
whether it adds value to the product, whether it will be beneficial,
whether it will raise the quality of the project, and whether it will
have any other effect. These factors are appropriately acknowledged
in this step so that fundamental requirements for solving business
problems can be met.
Steps Involved in Requirement Analysis
• Step 2: Evaluation and Synthesis

• Evaluation is to decide whether something is valuable or not, and

synthesis means to build or develop anything. The following tasks are
critical in the evaluation and synthesis stage of requirements analysis
(not an exhaustive list):

• To define all software functions that are required.

• To define all data objects that are visible to the outside world.
• To determine whether or not a data flow is valuable.
Steps Involved in Requirement Analysis
• To thoroughly comprehend the whole behaviour of the system, that
is, the overall operation of the system.
• The system interface must be defined and established to fully
comprehend how the system communicates with two or more
components or with one another.
• To find and discover designed constraints.
Steps Involved in Requirement Analysis
• Step 3: Modelling the Requirements

• This step typically includes graphical representations of the functions,

data entities, external entities, and their relationships. The visual
perspective may aid in discovering inaccurate, inconsistent, missing,
or excessive requirements. Data flow diagrams, entity-relationship
diagrams, data dictionaries, state-transition diagrams, and other
models fall under this category.
Steps Involved in Requirement Analysis
• Step 4: Specification

• We have a better knowledge of the system behaviour after modelling

the requirements. Inconsistencies and ambiguities have been
recognized and resolved. The data flow between modules has been
examined. The actions of elicitation and analysis have generated a
greater understanding of the system. We have completed the needs
analysis in the previous steps, and in this step, we document these
requirements in the SRS (Software Requirements Specification)
document.
Steps Involved in Requirement Analysis
• Step 5: Review

• After creating the SRS, it must be reviewed to see if it can be

enhanced and polished to make it better and higher in quality.
What is Software Requirements?
• 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.
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.
What are Functional Requirements?
• Functional Requirements 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 that 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.
Functional Requirements
• They are 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.
• To accurately describe the functional requirements, all scenarios must
be enumerated.
Functional Requirements
• There are many ways of expressing functional requirements e.g.,
natural language, a structured or formatted language with no rigorous
syntax, and formal specification language with proper syntax.
• Functional Requirements in Software Engineering are also called
Functional Specification.
What are 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.
Non-functional Requirements
• They basically deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Non-functional Requirements
Non-functional requirements are classified into the following types:

• Interface constraints
• Performance constraints: response time, security, storage space, etc.
• Operating constraints
• Life cycle constraints: maintainability, portability, etc.
• Economic constraints
What are Domain requirements?
• Domain requirements are the requirements that 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.
What are Domain requirements?
• The basic functions that a system of a specific domain must
necessarily exhibit come under this category.
• For instance, in 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.
Classifications of Software Requirements
• 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.
Classifications of Software Requirements
• 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.
Classifications of Software 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.
Feasibility study
• When the client approaches the organization for getting the desired
product developed, it comes up with rough idea about what all
functions the software must perform and which all features are
expected from the software.

• Referencing to this information, the analysts does a detailed study

about whether the desired system and its functionality are feasible to
develop.
Feasibility study
• This feasibility study is focused towards goal of the organization. This
study analyzes whether the software product can be practically
materialized in terms of implementation, contribution of project to
organization, cost constraints and as per values and objectives of the
organization. It explores technical aspects of the project and product
such as usability, maintainability, productivity and integration ability.

• The output of this phase should be a feasibility study report that

should contain adequate comments and recommendations for
management about whether or not the project should be
undertaken.
The feasibility study mainly concentrates on below
five mentioned areas below:
• Technical Feasibility
• Operational Feasibility
• Economic Feasibility
• Legal Feasibility
• Schedule Feasibility
Technical Feasibility
• In Technical Feasibility current resources both hardware software
along required technology are analyzed/assessed to develop the
project.
• This technical feasibility study reports whether there are correct
required resources and technologies that will be used for project
development.
• Along with this, the feasibility study also analyzes the technical skills
and capabilities of the technical team, whether existing technology
can be used or not, whether maintenance and up-gradation are easy
or not for the chosen technology, etc.
Operational Feasibility
• In Operational Feasibility degree of providing service to requirements
is analyzed along with how easy the product will be to operate and
maintain after deployment.
• Along with this other operational scopes are determining the usability
of the product, Determining suggested solution by the software
development team is acceptable or not, etc.
Economic Feasibility
• In the Economic Feasibility study cost and benefit of the project are
analyzed.
• This means under this feasibility study a detailed analysis is carried
out will be cost of the project for development which includes all
required costs for final development hardware and software
resources required, design and development costs operational costs,
and so on.
• After that, it is analyzed whether the project will be beneficial in
terms of finance for the organization or not.
Legal Feasibility
• In legal feasibility, the project is ensured to comply with all relevant
laws, regulations, and standards.
• It identifies any legal constraints that could impact the project and
reviews existing contracts and agreements to assess their effect on
the project's execution.
• Additionally, legal feasibility considers issues related to intellectual
property, such as patents and copyrights, to safeguard the project's
innovation and originality.
Schedule Feasibility
• In schedule feasibility, the project timeline is evaluated to determine
if it is realistic and achievable.
• Significant milestones are identified, and deadlines are established to
track progress effectively.
• Resource availability is assessed to ensure that the necessary
resources are accessible to meet the project schedule.
• Furthermore, any time constraints that might affect project delivery
are considered to ensure timely completion. This focus on schedule
feasibility is crucial for the successful planning and execution of a
project.