Module-2

Requirement Engineering
Mr. Deepak V Ulape. (Assistant Professor)
2.1 Requirement Engineering
• 2.1.1 Types of Requirements – Functional and Nonfunctional
• 2 .1.2 Four Phases of Requirement Engineering
• 2.1.3 Software requirement Specification (SRS)
• 2.2.4 Structure and contents of SRS
• 2.1.5 IEEE standard format for SRS
2.1.1 Types of Requirements – Functional and
Nonfunctional
• 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.
Four Phases of Requirement Engineering
1. Feasibility Study
• A feasibility study is an assessment of the practicality of a proposed
plan or project. It analyzes the viability of the project to determine
whether it is likely to succeed and identifies potential issues and
problems that could arise during its execution
Feasibility Study types:
1.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.
2.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.
3.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.
 2. Requirements Elicitation
• It is related to the various ways used to gain knowledge about the project
domain and requirements.
• The various sources of domain knowledge include customers, business
manuals, the existing software of the same type, standards, and other
stakeholders of the project.
• The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc.. Elicitation
does not produce formal models of the requirements understood. Instead,
it widens the domain knowledge of the analyst and thus helps in providing
input to the next stage.
• Requirements elicitation is the process of gathering information about the
needs and expectations of stakeholders for a software system. This is the
first step in the requirements engineering process and it is critical to the
success of the software development project. The goal of this step is to
understand the problem that the software system is intended to solve and
the needs and expectations of the stakeholders who will use the system.
3. Requirements Specification
• This activity is used to produce formal software requirement models.
All the requirements including the functional as well as the non-
functional requirements and the constraints are specified by these
models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation
process. The models used at this stage include ER diagrams, data
flow diagrams(DFDs), function decomposition diagrams(FDDs), data
dictionaries, etc.
• Requirements specification is the process of documenting the
requirements identified in the analysis step in a clear, consistent, and
unambiguous manner. This step also involves prioritizing and
grouping the requirements into manageable chunks.
• The goal of this step is to create a clear and comprehensive
document that describes the requirements for the software system.
This document should be understandable by both the development
team and the stakeholders.
4. Requirements Verification and Validation
• Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.
• Validation: It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer requirements. If
requirements are not validated, errors in the requirement definitions
would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
1.The requirements should be consistent with all the other
requirements i.e. no two requirements should conflict with each other.
2.The requirements should be complete in every sense.
3.The requirements should be practically achievable.
 Software Requirement Specification (SRS)
• Software Requirement Specification (SRS) Format as the name
suggests, is a complete specification and description of
requirements of the software that need to be fulfilled for the
successful development of the software system. These
requirements can be functional as well as non-functional
depending upon the type of requirement. The interaction between
different customers and contractors is done because it is
necessary to fully understand the needs of customers.
 Introduction
• Purpose of this Document – At first, main aim of why this document
is necessary and what’s purpose of document is explained and
described.
• Scope of this document – In this, overall working and main objective
of document and what value it will provide to customer is described
and explained. It also includes a description of development cost and
time required.
• Overview – In this, description of product is explained. It’s simply
summary or overall review of product.
• General description
• In this, general functions of product which includes objective of user, a
user characteristic, features, benefits, about why its importance is
mentioned. It also describes features of user community.
• Functional Requirements
• In this, possible outcome of software system which includes effects due to operation
of program is fully explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order. Functional
requirements specify the expected behavior of the system-which outputs should be
produced from the given inputs. They describe the relationship between the input
and output of the system. For each functional requirement, detailed description all
the data inputs and their source, the units of measure, and the range of valid inputs
must be specified.
• Interface Requirements
• In this, software interfaces which mean how software program communicates with
each other or users either in form of any language, code, or message are fully
described and explained. Examples can be shared memory, data streams, etc.
• Performance Requirements
• In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.
The performance requirements part of an SRS specifies the performance constraints
on the software system. All the requirements relating to the performance
characteristics of the system must be clearly specified. There are two types of
performance requirements: static and dynamic. Static requirements are those that do
not impose constraint on the execution characteristics of the system. Dynamic
requirements specify constraints on the execution behaviour of the system.
Design Constraints
• In this, constraints which simply means limitation or restriction
are specified and explained for design team. Examples may
include use of a particular algorithm, hardware and software
limitations, etc. There are a number of factors in the client’s
environment that may restrict the choices of a designer leading
to design constraints such factors include standards that must
be followed resource limits, operating environment, reliability
and security requirements and policies that may have an
impact on the design of the system. An SRS should identify
and specify all such constraints.
• Non-Functional Attributes
• In this, non-functional attributes are explained that are required by
software system for better performance. An example may include
Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
• Preliminary Schedule and Budget
• In this, initial version and budget of project plan are explained
which include overall time duration required and overall cost
required for development of project.
• Appendices
• In this, additional information like references from where
information is gathered, definitions of some specific terms,
acronyms, abbreviations, etc. are given and explained.
 Uses of SRS document
• Development team require it for developing product according to
the need.
• Test plans are generated by testing group based on the describe
external behaviour.
• Maintenance and support staff need it to understand what the
software product is supposed to do.
• Project manager base their plans and estimates of schedule, effort
and resources on it.
• customer rely on it to know that product they can expect.
• As a contract between developer and customer.
• in documentation purpose.
IEEE standard format for SRS
• The IEEE (Institute of Electrical and Electronics Engineers) standard for Software Requirements
Specifications (SRS) is defined in IEEE 830-1998, titled "IEEE Recommended Practice for Software
Requirements Specifications." This standard provides a structured approach to documenting the
requirements for a software system.

• 1. Introduction
- 1.1 Purpose: Defines the purpose of the SRS and the intended audience.
- 1.2 Scope: Outlines the software product to be specified, including its boundaries, major
features, and goals.
- 1.3 Definitions, Acronyms, and Abbreviations: Provides definitions for terms, acronyms, and
abbreviations used in the SRS.
- 1.4 References: Lists any references to other documents or standards that are pertinent to the
SRS.
- 1.5 Overview: Gives an overview of the remaining sections of the SRS.
2. Overall Description
- 2.1 Product Perspective: Describes the context and origin of the product, including its
relationship to other systems.
- 2.2 Product Functions: Provides a high-level summary of the software’s functions.
- 2.3 User Classes and Characteristics: Identifies the different user types and their needs.
- 2.4 Operating Environment: Specifies the hardware, software, and other environmental
constraints.
- 2.5 Design and Implementation Constraints: Lists any constraints on design and
implementation.
- 2.6 User Documentation: Details the documentation and training materials provided to
users.
- 2.7 Assumptions and Dependencies: Describes any assumptions and dependencies that
could impact the software requirements.
3. Specific Requirements
Functional Requirements: Provides detailed descriptions of the functions the software
- 3.1

must perform.
- 3.2 External Interface Requirements: Details interactions between the software and other
systems or users.
- 3.2.1 User Interfaces: Specifies the user interface requirements.
- 3.2.2 Hardware Interfaces: Describes the hardware interfaces if applicable.
- 3.2.3 Software Interfaces: Outlines any software interfaces.
- 3.2.4 Communications Interfaces: Defines the communication protocols and standards.
- 3.3 Performance Requirements: Specifies performance constraints and criteria.
- 3.4 Design Constraints: Describes constraints related to the design of the software.
- 3.5 Software System Attributes: Details attributes such as reliability, availability, security, and
maintainability.
- 3.6 Other Requirements: Includes any other requirements not covered in the above sections.
4. Appendices
- 4.1 Glossary: Provides a glossary of terms used in the SRS.
- 4.2 Analysis Models: Includes diagrams and models that support the
requirements, such as data flow diagrams or use case diagrams.
- 4.3 Issue Tracking: Optional section for tracking unresolved issues or
changes.
Introduction to Web Engineering :

• Web Engineering is a discipline that focuses on the design,

development, and maintenance of web applications and systems. It
combines principles from computer science, software engineering,
and web development to create robust, scalable, and user-friendly
web solutions.
Agile Methodology
• The Agile methodology is a project management and software
development approach that emphasizes flexibility, collaboration,
and customer-centricity. It is the latest model used by major
companies today like Facebook, google, amazon, etc.

• Agile is a project management and software development approach

that aims to be more effective.
1.It focuses on delivering smaller pieces of work regularly instead
of one big launch.
2.This allows teams to adapt to changes quickly and provide
customer value faster.
• Agile methodologies are iterative and incremental, which
means it’s known for breaking a project into smaller parts and
adjusting to changing requirements.
1.They prioritize flexibility, collaboration, and customer
satisfaction.
2.Major companies like Facebook, Google, and Amazon use
Agile because of its adaptability and customer-focused
approach.
Life cycle of Agile Methodology
The Agile software development life cycle helps you break down each project you
take on into six simple stages:
• 1. Requirement Gathering
• In this stage, the project team identifies and documents the needs and
expectations of various stakeholders, including clients, users, and subject matter
experts.
• It involves defining the project’s scope, objectives, and requirements.
• Establishing a budget and schedule.
• Creating a project plan and allocating resources.

• 2. Design
• Developing a high-level system architecture.
• Creating detailed specifications, which include data structures, algorithms, and
interfaces.
• Planning for the software’s user interface.
3. Development (Coding)
Writing the actual code for the software. Conducting unit testing to verify the
functionality of individual components.

4. Testing
This phase involves several types of testing:
Integration Testing: Ensuring that different components work together.
System Testing: Testing the entire system as a whole.
User Acceptance Testing: Confirming that the software meets user requirements.
Performance Testing: Assessing the system’s speed, scalability, and stability.

5. Deployment
Deploying the software to a production environment.
Put the software into the real world where people can use it.
Make sure it works smoothly in the real world.
Providing training and support for end-users.
6. Review (Maintenance)
Addressing and resolving any issues that may arise after deployment.
Releasing updates and patches to enhance the software and address
problems.
Adaptive Software Development (ASD) is a software development
methodology that emphasizes adaptability to respond to changing requirements
and environments. It focuses on continuous learning and is considered a part of
agile software development.
1.Iterative Development: ASD breaks down the project into small, manageable
iterations, delivering incremental values.
2.Risk Management: ASD involves identifying and addressing risks early in the
development process.
3.Continuous Testing: It integrates testing throughout the development process
to ensure high-quality outcomes.
4.Decentralized Control: It encourages decision-making at the team level instead
of relying on top-down directives.
5.Customer Satisfaction: It prioritizes customer satisfaction by delivering products
that meet their needs and expectations.
Characteristics of ASD Process
principles of ASD that distinguish it from more traditional, plan-driven
methodologies:
1.Adaptability: ASD focuses on high-level adaptive planning instead of detailed,
fixed plans.
2.Collaborative Environment: In ASD, a strong focus is on collaboration within
the team, thus promoting a culture of open communication.
3.Continuous Learning: It emphasizes learning from each iteration and using
feedback to improve the process and the product.
4.Iterative Development: In ASD, the development is broken into small,
manageable increments. Each increment delivers a piece of functional software.
5.Responsive to Change: It allows the project to quickly adapt to the changes in
requirements, technology, and market conditions.
Phases of ASD Process
ASD life cycle incorporates three phases
namely:
1.Speculation
2.Collaboration
3.Learning
These are explained below:
1. Speculation
During this phase project is initiated and planning is conducted. The project plan uses project
initiation information like project requirements, user needs, customer mission statement, etc,
to define a set of release cycles that the project wants.

2. Collaboration
It is the difficult part of ASD as it needs the workers to be motivated. It collaborates
communication and teamwork but emphasizes individualism as individual creativity plays a
major role in creative thinking. People working together must trust each other to
Criticize without animosity,
Assist without resentment,
Work as hard as possible,
Possession of skill set,
Communicate problems to find effective solutions.
3. Learning
The workers may have an overestimate of their understanding of
the technology which may not lead to the desired result.
Learning helps the workers to increase their level of
understanding of the project.

The learning process is in 3 ways:

1.Focus groups
2.Technical reviews
3.Project postmortem
Strengths of ASD
key strengths of Adaptive Software Development (ASD):
1.Customer Focus: Regular and active involvement of customers to
make sure that the product meets their needs and expectations.
2.Continuous Delivery: Delivering functional software in small,
manageable increments allows for early and continuous delivery of
value.
3.Early Problem Detection: Regular testing and releases help to
identify and resolve issues early in the development process.
4.Strong Teamwork: Emphasizes teamwork among the team
members, thus fostering a supportive environment.
Weakness of ASD
weaknesses of Adaptive Software Development (ASD):
1.Requires High Level of Skill: Successful implementation of ASD
requires a team with a high-level of skill, experience, and familiarity
with the agile principles.
2.Changing Requirements: The flexible nature of ASD may result in
frequent changes of requirements, which might result in scope
creep if it is not managed properly.
3.Customer Availability: ASD relies heavily on active and continuous
customer participation, which can be difficult to achieve in cases
when the customer is not fully engaged or not available.
4.Uncertain Project Outcomes: The iterative and adaptive nature of
ASD makes it difficult to predict the outcome of the project.
Dynamic Systems Development :

• The Dynamic Systems Development technique (DSDM) is an associate degree

agile code development approach that provides a framework for building and
maintaining systems. The DSDM philosophy is borrowed from a modified
version of the sociologist principle—80 % of An application is often delivered in
twenty percent of the time it’d desire deliver the entire (100 percent) application.

• DSDM is An iterative code method within which every iteration follows the 80%
rule that simply enough work is needed for every increment to facilitate
movement to the following increment. The remaining detail is often completed
later once a lot of business necessities are noted or changes are requested and
accommodated.
Scrum in software development:
• Scrum is a management framework that teams use to self-
organize tasks and work towards a common goal. It is a
framework within which people can address complex adaptive
problems while the productivity and creativity of delivering
products are at the highest possible value. Scrum is a
management framework that teams use to self-organize and
work towards a common goal.
• Scrum allows us to develop products of the highest value
while making sure that we maintain creativity and productivity.
• The iterative and incremental approach used in scrum allows
the teams to adapt to the changing requirements.
Silent features of Scrum
• Scrum is a light-weighted framework
• Scrum emphasizes self-organization
• Scrum is simple to understand
• Scrum framework helps the team to work together
• Lifecycle of Scrum
Advantage of Scrum framework
• Scrum framework is fast moving and money efficient.
• Scrum framework works by dividing the large product into
small sub-products. It’s like a divide and conquer strategy
• In Scrum customer satisfaction is very important.
• Scrum is adaptive in nature because it have short sprint.
• As Scrum framework rely on constant feedback therefore the
quality of product increases in less amount of time
Disadvantage of Scrum framework :
• Scrum framework do not allow changes into their sprint.
• Scrum framework is not fully described model. If you wanna
adopt it you need to fill in the framework with your own details
like Extreme Programming(XP), Kanban, Dynamic Systems
Development Method (DSDM).
• It can be difficult for the Scrum to plan, structure and organize
a project that lacks a clear definition.
• The daily Scrum meetings and frequent reviews require
substantial resources.
Fig: Scrum MOdel
• Sprint: A Sprint is a time box of one month or less. A new Sprint starts
immediately after the completion of the previous Sprint. Release: When the
product is completed, it goes to the Release stage.

• Sprint Review: If the product still has some non-achievable features, it will be
checked in this stage and then passed to the Sprint Retrospective stage.

• Sprint Retrospective: In this stage quality or status of the product is

checked. Product Backlog: According to the prioritize features the product is
organized.

• Sprint Backlog: Sprint Backlog is divided into two parts Product assigned
features to sprint and Sprint planning meeting.