Requirement Analysis and

Cost Estimation
- By Shravanti Hable
2.1 Software Requirements: Functional and non-functional requirements, User
requirements,System requirements,

2.2 Requirements engineering process: Feasibility studies, elicitation,

Requirements validation, Requirements management.

2.3 Software Prototyping- S/W documentation - Analysis and modelling,

Requirements elicitation, Software requirements Specifications(SRS), 3Ps(people,
product, process) Process and project metrics software

2.4 Project Estimations - LOC, FP, Empirical Estimation,

2.5 Models - COCOMO II Model

2.1 Software Requirements: Functional and Non-functional
requirements, User requirements,System requirements,
IEEE defines Requirement as :
1. A condition or capability needed by a user to solve a problem or
achieve an objective
2. A condition or capability that must be met or possessed by a system
or a system component to satisfy constract, standard, specification or
formally imposed document.
3. Requirements define what the stakeholders need and how the
system should perform.
SOFTWARE REQUIREMENTS: Encompasses both the User’s view of the
requirements( the external view ) and the Developer’s view( inside characteristics)

User’s Requirements: Statements in a natural language plus diagram, describing

the services the system is expected to provide and the constraints.

System Requirements: Describe the system’s function, services and operational

condition.
1. Functional Requirements (FR)

Functional requirements define what the system does. They describe the specific
services, tasks, or functions that a software system must perform.

They describe system behavior under specific conditions.

They are usually expressed in the form "The system shall [do something].

Examples:

○ Search: "The user shall be able to search the inventory by product name."
○ Transaction: "The system shall process credit card payments using an
external gateway."
○ Reporting: "The system shall generate a weekly sales report every Sunday
at 11:59 PM.
2. Non-Functional Requirements (NFR)
Non-functional requirements define how the system performs. They act as constraints
on the functions offered by the system (often called "Quality Attributes").

○ Performance: Response time, throughput, and utilization.

○ Usability: Ease of learning and user satisfaction.
○ Reliability: Ability to remain functional over time (availability).
○ Security: Protection against unauthorized access and data integrity.
○ Portability: Ability to work across different platforms (Windows, Linux, iOS).

Example: "The system must respond to any user query within 2 seconds
(Performance)" or "The system must have an uptime of 99.9% (Availability)."
3. User Requirements

User Requirements are high-level statements in natural language plus diagrams

that describe the services the system is expected to provide and the constraints
under which it must operate.

Written for the "Business" side (clients, end-users, project managers).

They focus on the user's goals and needs rather than technical implementation.

Example:

The teacher needs a way to mark attendance quickly on a tablet.

4. System Requirements
System Requirements are detailed descriptions of the software system’s functions,
services, and operational constraints. They represent a technical "contract" between
the client and the developer.

They are Written for the "Technical" side (developers, testers, architects).

These are derived from user requirements but provide the "how" in technical terms.

These ares often documented in the Software Requirements Specification (SRS)

document.

Example:

"The system shall provide a RESTful API endpoint /attendance/mark that accepts a
JSON payload of Student IDs and timestamps."
2.2 Requirements engineering process:
Feasibility studies, elicitation, Requirements validation,
Requirements management.
Requirements Engineering Process in Software Engineering

Requirements Engineering is the process of identifying, eliciting,

analyzing, specifying, validating, and managing the needs and
expectations of stakeholders for a software system.

● A systematic and strict approach to the definition, creation, and

verification of requirements for a software system is known as
requirements engineering.
● To guarantee the effective creation of a software product, the
requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to
established standards.

Types of Feasibility:

1. Technical Feasibility

2. Operational Feasibility

3. Economic Feasibility
1. Technical Feasibility -
● Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.

● 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 -
● Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer
requirements.
● 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 -
● Economic feasibility decides whether the necessary software can generate
financial profits for an organization.
● 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.
2. Requirements Elicitation
● Requirements elicitation is the process of gathering information about
the needs and expectations of stakeholders for a software system
● 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.
● 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,
surveys, brainstorming, task analysis,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.
Several techniques can be used to elicit requirements, including:

● Interviews: These are one-on-one conversations with stakeholders

to gather information about their needs and expectations.
● Surveys: These are questionnaires that are distributed to
stakeholders to gather information about their needs and
expectations.
● Focus Groups: These are small groups of stakeholders who are
brought together to discuss their needs and expectations for the
software system.
● Observation: This technique involves observing the stakeholders in
their work environment to gather information about their needs and
expectations.
3. Requirements Specification

● 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.
● 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
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 difference between verification and validation is as follows:

Verification is checking that the requirements are complete,

consistent, and accurate. It involves reviewing the requirements to
ensure that they are clear, testable, and free of errors and
inconsistencies.

Validation is the process of checking that the requirements meet

the needs and expectations of the stakeholders. It involves testing
the requirements to ensure that they are valid and that the software
system being developed will meet the needs of the stakeholders.
5. Requirements Management

Requirements management is the process of managing the requirements throughout the software
development life cycle, including tracking and controlling changes, and ensuring that the
requirements are still valid and relevant.

Requirement management is the process of analyzing, documenting, tracking, prioritizing, and

agreeing on the requirement and controlling the communication with relevant stakeholders.

Several key activities are involved in requirements management, including:

1. Tracking and controlling changes

2. Version control:
3. Traceability:
4. Communication:
5. Monitoring and reporting:
Tools Involved in Requirement Engineering
● Observation report
● Questionnaire ( survey, poll )
● Use cases
● User stories
● Requirement workshop
● Mind mapping
● Roleplaying
● Prototyping
2.3 Software Prototyping- S/W documentation - Analysis and modelling, Requirements elicitation, Software requirements
Specifications(SRS), 3Ps(people, product, process) Process and project metrics software
Analysis Modelling in Software Engineering

Analysis Model is a technical representation of the system. It acts

as a link between the system description and the design model. In
Analysis Modelling, information, behavior, and functions of the system
are defined and translated into the architecture, component, and
interface level design in the design modeling.
Objectives of Analysis Modelling
● Understanding Needs: The process of analysis modelling helps in
the understanding and extraction of user needs for the software
system.
● Communication: Analysis models facilitate communication between
users, clients, developers, and testers, among other stakeholders.
● Clarifying Ambiguities: Analysis models assist in resolving
requirements disputes and providing clarification on unclear areas.
● Finding the Data Requirements: Analysis modelling assists in
determining the relationships, entities, and qualities of the data that
the system needs.
● Defining Behavior: Analysis modelling aids in the definition of the
Elements of Analysis Model
Data Dictionary:

It is a repository that consists of a description of all data objects used

or produced by the software. It stores the collection of data present in
the software. It is a very crucial element of the analysis model.
Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting

data modeling activities. The attributes of each object in the Entity-
Relationship Diagram can be described using Data object description. It
provides the basis for activity related to data design.
Data Flow Diagram (DFD):

It depicts the functions that transform data flow, and it also shows how
data is transformed when moving from input to output.
State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the transitions from one state to another
state in the system.

Process Specification:

It stores the description of each function present in the data flow diagram. It describes the input to a function, the
algorithm that is applied for the transformation of input, and the output that is produced.

Control Specification:

It stores additional information about the control aspects of the software. It is used to indicate how the software
behaves when an event occurs and which processes are invoked due to the occurrence of the event.

Data Object Description:

It stores and provides complete knowledge about a data object present and used in the software. It also gives us
the details of attributes of the data object present in the Entity Relationship Diagram.