Software Requirements:

Analysis and Specification

Ensuring Project Success Through Effective
Requirements Management
 Before we start to develop our software, it becomes quite
essential for us to understand and document the exact
requirement of the customer.

Introduction Experienced members of the development team (system

analysts) carry out this job.

A requirement is a feature of the system or a description

of something the system is capable of doing in order to
fulfill the system's purposes.

Requirements describe the "what” of a system not the

'how"
Requirement
Engineering
Requirements Engineering
Requirement Engineering is the process of defining, documenting and maintaining the
requirements.
It is a process of gathering and defining service provided by the system.
It mainly focus on ‘What a System must do’ and not ‘how’.
Requirements engineering consists one large document contains a description of what a
system without describing how it will do

Requirements engineering consists of 4 steps

1. Requirement elicitation

2. Requirement analysis

3. Requirement documentation

4. Requirement review
 Requirements elicitation
Requirements are gathered with the help of customers
and existing systems.

Requirements analysis
Requirement Identifying defects, omissions, and inconsistencies.

Engineering
Requirement documentation
It is the end product of the elicitation and analysis. The
document prepared in this step is called SRS (software
requirement specification)

Requirement review
Verifying the SRS for quality and completeness
 Known requirements:
Types of Something a stakeholder believes to be implemented.

Requirements Unknown requirements

Forgotten by one stakeholder because they are not needed now
The software requirements are
or needed only by another stakeholder.
description of features and
functionalities of the target system.
Undreamt requirements:
Requirements convey the
expectations of users from the Stakeholder may not be able to think of new requirements due to
software product. limited domain knowledge.

The requirements can be obvious

or hidden, known or unknown,
expected or unexpected from
Stakeholder: Anyone who should have some direct or
client’s point of view.
indirect influence on the system requirements. A
The known and unknown
known, Unknown, Undreamt requirement may be
requirements may be functional or
functional or non-functional.
non functional
Functional and Non-functional Requirements

Functional Requirements Non-Functional Requirements

Functional requirements describe what Non Functional requirements are mostly

the software has to do. quality requirements that stipulate how well
They are often called product features. the software does, what it has to do.
These are directly related to customer's These requirements make customers happy
and satisfied.
expectations and are essential for the
Requirements important to users include
acceptance of the product.
availability, reliability, usability and flexibility
and important to developers include
maintainability, portability and testability
 User and system requirements

User requirements System requirements

Written for users, simple language. Derived from user needs, detailed
Focus on external behavior, constraints, technical terms.
quality. For designers (input to design).
Overview, no design details.
Domain requirements

Domain requirements are the requirements which are characteristic of a particular

category or domain of projects.
The basic functions that a system of a specific domain must necessarily exhibit
come under this category.
Feasibility Study
Feasibility Studies
Feasibility study is defined as “evaluation or analysis of the potential impact of a
proposed project or program.”
Feasibility study is one of stage among important four stages of Software Project
Management Process.
As name suggests feasibility study is the feasibility analysis or it is a measure of
the software product in terms of how much beneficial product development will be
for the organization in a practical point of view.
Feasibility study is carried out based on many purposes to analyze whether
software product will be right in terms of development, implantation, contribution
of project to the organization etc.
Types of Feasibility
Various types of feasibility that are commonly considered include technical feasibility, operational feasibility,
and economic feasibility

Technical Operational Economic

feasibility feasibility feasibility

current resources both Analyse how much easy In Economic Feasibility study
hardware software along with product will be to operate and cost and benefit of the project
required technology are maintenance after is analyzed.
analyzed/assessed to develop deployment. Study a detail analysis is
project. carried out what will be cost
Report whether there exists of the project for
correct required resources and development
technologies which will be used It includes all required cost for
for project development. final development like
Analyzes technical skills and hardware and software
capabilities of technical team, resource required, design and
development cost
Requirements
elicitation
Requirements elicitation
Gathering Requirements Effectively
Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development.
It can be successful only through an effective customer-developer partnership.
It is needed to know what the users really need.
There are a number of requirements elicitation methods.
Few of them are listed below
• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case Approach
 Objective: Understand customer expectations.
Interviews -
Types: Open-ended or structured.
One-on-One Insights
In open-ended interview there is no preset agenda.
In structured interview, agenda of fairly open
questions is prepared

Entry level personnel:- They may not have sufficient domain knowledge and experience, but
may be very useful for fresh ideas and different views
Mid-level stakeholders:- They have better domain knowledge and experience of the project.
They can answer complex and critical questions about project.
Managers: Higher level management like MD, CEO should also be interviewed. They can give
information in a different view point
Users of the software: Most useful information may get from them as they spend more time
with the system.
Brainstorming Sessions -
It is a group discussion technique
Collaborative Ideas
It is intended to generate lots of new ideas hence
providing a platform to share views

A highly trained facilitator is required to handle

group bias and group conflicts.

Every idea is documented so that everyone can see it.

Finally, a document is prepared which consists of the

list of requirements and their priority if possible.
 Facilitated Application
Specification Technique
(FAST)
Arrange a meeting at a neutral site for customers and
developers.
Its objective is to bridge the Establish rules for preparation and participation.
expectation gap—difference
between what the developers think
they are supposed to build and Informal agenda to encourage free flow of ideas.
what customers think they are Appoint a facilitator
going to get.
A team oriented approach is Prepare definition mechanism board, worksheets, wall
developed for requirements stickier etc.
gathering Participants should not criticize or debate.
Quality Function
Deployment
Normal requirements – In this the objective and goals of
the proposed software are discussed with the customer.
Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc
In this technique customer
satisfaction is of prime concern,
hence it emphasizes on the Expected requirements – These requirements are so
requirements which are valuable to obvious that the customer need not explicitly state them.
the customer. Example – protection from unauthorized access.
3 types of requirements are
identified – Exciting requirements – It includes features that are
beyond customer’s expectations and prove to be very
satisfying when present. Example – when unauthorized
access is detected, it should backup and shutdown all
processes.
 1. Actor-
An actor maybe a person, machine etc.
Use Case Approach It is represented as a stick figure.
Actors can be primary actors or secondary actors.
This technique combines text and  Primary actors – It requires assistance from the
pictures to provide a better system to achieve a goal.
understanding of the requirements.  Secondary actor – It is an actor from which the
system needs assistance.
The use cases describe the ‘what’,
of a system and not ‘how’. Use cases –
They describe the sequence of interactions between
Hence, they only give a functional actors and the system.
view of the system.

The component of the use case Use case diagram –

design includes three major things A use case diagram graphically represents what
– Actor, Use cases, and use case happens when an actor interacts with a system. It
diagram. captures the functional aspect of the system.
Requirements
Analysis
Requirements Analysis
Requirement analysis is significant and
essential activity after elicitation.
We analyze, refine, and scrutinize the
gathered requirements to make
consistent and unambiguous
requirements.
This activity reviews all requirements and
may provide a graphical view of the
entire system.
After the completion of the analysis, it is
expected that the understandability of the
project may improve significantly.
Draw the context diagram

The context diagram is a simple

model that defines the boundaries
and interfaces of the proposed
systems with the external world.

It identifies the entities outside the

proposed system that interact with
the system.

The context diagram of student

result management system is
given below
 One effective way to find out what the customer wants is
to construct a prototype, something that looks and
preferably acts as part of the system they say they want.
Development of a
Prototype (optional)
We can use their feedback to modify the prototype until
the customer is satisfied continuously.

A Data Flow Diagram (DFD) is a traditional visual

representation of the information flows within a system.

Model the A neat and clear DFD can depict the right amount of the
requirements system requirement graphically.

It shows how data enters and leaves the system, what

changes the information, and where data is stored.

Such models include the Data Flow diagram, Entity-

Relationship diagram, Data Dictionaries, State-transition
diagrams, etc.
Symbols for Data
Flow Diagrams
Example
Entity-Relationship diagram
An ER diagram shows the relationship among entity sets.
An entity set is a group of similar entities and these entities can have attributes.

Entity Attributes Relationship

An Entity may be an object Each entity has attributes. A relationship is an association

with a physical existence between several entities
An attribute defines set of
– a particular person, car, properties that are used to
house, or employee describe an entity.
– or it may be an object with a
conceptual existence For example, an employee
– a company, a job, or a entity has attributes like
university course. employeeid, employee_name,
designation, salary etc,,
Relationships
ER Diagram
Example
Data dictionaries
A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership, data
relationships to other objects, and other data

The data dictionary, in general, includes information about the following:

o Name of the data item

o Aliases
o Description/purpose
o Related data items
o Range of values
o Data structure definition/Forms
 Requirements
Documentation
REQUIREMENTS DOCUMENTATION
It is the activity after requirement elicitation and analysis. This is the way to
represent requirements in a consistent format. The requirement documentation is
called SRS(Software requirement specification). SRS is a document created by
system analyst after the requirements are collected

Nature of Software Characteristics of a good SRS

Requirement Specification 1. Correctness
2. Completeness
(SRS)
3. Consistency
1. Functionality 4. Unambiguousness
5. Ranking for importance and stability
2. External Interfaces
6. Modifiability
3. Performance
7. Verifiability
4. Attributes 8. Traceability
5. Design Constraints Imposed on an 9. Design Independence
Implementation 10. Testability
11. Understandable by the customer
Organization of
good SRS
IEEE has published guidelines and
standards to organize an SRS.
There are different ways of
organizing an SRS document. First
two sections are same in all. The
specific tailoring occurs in
section-3.
Requirements
Validation
REQUIREMENTS validation
The requirements document should be formulated and organized according to the standards
of the organization.
 The organizational knowledge is used to estimate the realism of the requirements of the
system.
 The organizational standards are specified standards followed by the organization according
to which the system is to be developed.
 The lists of problems indicate the problems encountered in the” requirements document of
the requirements validation process.
 The agreed actions is a list that displays the actions to be performed to resolve the problems
depicted in the problem list.
Requirement
review
REQUIREMENTS validation
In this process a group of people will read the SRS document and look for possible
errors

Plan review:- the review team is selected and the time and place for the meeting is fixed
Distribute SRS document:-The SRS document is distributed to all the members
Read the SRS document:-each member read the document carefully to find the omissions,
inconsistencies, deviations etc
Organise the review meeting:-each member present his/her views and indentified
problems
Follow-up-actions:-corresponding actions regarding the problems are identified
Revise the SRS document:- the SRS document is revised to reflect the changes
Software Project
Planning
Software Project Planning
After the finalization of SRS (sometimes even prior to finalization), customers would like to
estimate size, cost and development time of the project which are the key issues during planning.
Software managers are responsible for planning.
They supervise the work to ensure that it follows project plan.
In order to conduct a successful software project, we must understand
Scope of work to be done
The risk to be incurred
The resources required
The task to be accomplished
The cost to be expended
The schedule to be followed
Size Estimation
Estimation of the size of software is an essential part of Software Project Management.

It helps the project manager to further predict the effort and time which will be needed to build

the project.

Various measures are used in project size estimation. Some of these are:

Lines of Code

Number of entities in ER diagram

Total number of processes in detailed data flow diagram

Function points
Lines of Code(LOC)
As the name suggest, LOC count the total number of lines of source code in a project.
The units of LOC are:
KLOC- Thousand lines of code
NLOC- Non comment lines of code
KDSI- Thousands of delivered source instruction The size is estimated by comparing it with the
existing systems of same kind.
The experts use it to predict the required size of various components of software and then add
them to get the total size
Advantages
Universally accepted and is used in many models like COCOMO.
Estimation is closer to developer’s perspective.
Simple to use.
2. Number of entities in ER diagram
The number of entities in ER model can be used to measure the estimation of size of project.

Number of entities depends on the size of the project.

This is because more entities needed more classes/structures thus leading to more coding.

Advantages:

Size estimation can be done during initial stages of planning.

Number of entities is independent of programming technologies used.

3. Total number of processes in detailed
data flow diagram
Data Flow Diagram(DFD) represents the functional view of a software.

Utilization of number of functions in DFD is used to predict software size.

Advantages:

It is independent of programming language.

Each major processes can be decomposed into smaller processes.

This will increase the accuracy of estimation

4. Function Point Analysis
Function Point Analysis was initially developed by Allan J. Albercht in 1979 at IBM and it has been

further modified by the International Function Point Users Group (IFPUG).

FPA provides standardized method to functionally size the software work product.

Types of FPA:

Transactional Functional Type

Data Functional Type

Cost Estimation
Cost Estimation
A model may be static or dynamic.

In a static model, a single variable is taken as a key element for calculating cost and time.

In a dynamic model, all variable are interdependent, and there is no basic variable
 Static, Single Variable Models
When a model makes use of single variables to
calculate desired values such as cost, time,
efforts, etc. is said to be a single variable model.
The most common equation is:

Cost C=aLb
Where C = Costs L= size a and b are constants

Estimation Static, Multivariable Models

In some model, several variables are needed to
describe the software development process,
and selected equation combined these
variables to give the estimate of time & cost.
These models are called multivariable models.
COCOMO MODEL
 The Constructive Cost Model (COCOMO) is a

The software cost estimation model that helps

Constructive predict the effort, cost, and schedule

required for a software development project.

Cost Model Developed by Barry Boehm in 1981, COCOMO

(COCOMO)
uses a mathematical formula based on the

size of the software project, typically

measured in lines of code (LOC).

cocomo model
The key parameters that define the quality of any software product, which are

also an outcome of COCOMO, are primarily effort and schedule:

1. Effort: Amount of labor that will be required to complete a task. It is

measured in person-months units.

2. Schedule: This simply means the amount of time required for the

completion of the job, which is, of course, proportional to the effort put in. It

is measured in the units of time such as weeks, and months.

Types of Projects in the COCOMO Model
Organic Semi-detached Embedded

A software project is said to be a

A software project is said to be
Semi-detached type if the vital A software project requiring the
an organic type if the team size characteristics such as team size, highest level of complexity,
required is adequately small, the experience, and knowledge of the creativity, and experience
various programming requirement falls under this
problem is well understood and
category. Such software requires
environments lie in between
has been solved in the past and a larger team size than the other
organic and embedded. The
also the team members have a two models and also the
projects classified as Semi-
developers need to be sufficiently
nominal experience regarding Detached are comparatively less experienced and creative to
the problem. familiar and difficult to develop develop such complex models.
compared to the organic ones and
require more experience better
guidance and creativity. Eg:
Compilers or different Embedded
Systems can be considered Semi-
Detached types.
Comparison of COCOMO model
Six Phases of COCOMO Model
Planning and requirements: This initial phase involves
defining the scope, objectives, and constraints of the
project. It includes developing a project plan that outlines
the schedule, resources, and milestones
System design: : In this phase, the high-level architecture
of the software system is created. This includes defining
the system’s overall structure, including major
components, their interactions, and the data flow
between them.
Detailed design: This phase involves creating detailed
specifications for each component of the system. It
breaks down the system design into detailed
descriptions of each module, including data structures,
algorithms, and interfaces.
Six Phases of COCOMO Model
Module code and test: This involves writing the actual source
code for each module or component as defined in the detailed
design. It includes coding the functionalities, implementing
algorithms, and developing interfaces.
Integration and test: This phase involves combining individual
modules into a complete system and ensuring that they work
together as intended.
Cost Constructive model: The Constructive Cost Model
(COCOMO) is a widely used method for estimating the cost
and effort required for software development projects.
Types of COCOMO Model

Basic Intermediate Detailed

COCOMO COCOMO COCOMO
Model Model Model
 1. Basic
COCOMO
E = a*(KLOC)b PM
Tdev = c*(E)d
Model Person required = Effort/ Time
Where,
The Basic COCOMO model is a
straightforward way to estimate the E is effort applied in Person-Months
effort needed for a software KLOC is the estimated size of the software
development project.
product indicate in Kilo Lines of Code
It uses a simple mathematical formula
Tdev is the development time in months
to predict how many person-months
of work are required based on the size a, b, c are constants determined by the category of
of the project, measured in thousands
software project given in below table.
of lines of code (KLOC).
The above formula is used for the cost estimation of the basic COCOMO model and also is used in the
subsequent models. The constant values a, b, c, and d for the Basic Model for the different categories of the
software projects are:
 E = a*(KLOC)b * EAF PM

2. Intermediate Tdev = c*(E)d

COCOMO Where,

Model E is effort applied in Person-Months

KLOC is the estimated size of the software
product indicate in Kilo Lines of Code
EAF is the Effort Adjustment Factor (EAF) is a
multiplier used to refine the effort estimate
obtained from the basic COCOMO model.
Tdev is the development time in months
a, b, c are constants determined by the
category of software project given in below
table.
The above formula is used for the cost estimation of the Intermediate COCOMO model and also is used in
the subsequent models. The constant values a, b, c, and d for the Basic Model for the different categories of
the software projects are:
 Detailed COCOMO goes beyond Basic and

3. Detailed Intermediate COCOMO by diving deeper into

COCOMO project-specific factors.

Model It considers a wider range of parameters, like

team experience, development practices, and
software complexity.
By analyzing these factors in more detail,
Detailed COCOMO provides a highly accurate
estimation of effort, time, and cost for software
projects.
It’s like zooming in on a project’s unique
characteristics to get a clearer picture of what it
will take to complete it successfully.
 NASA Space Shuttle Software Development: NASA
estimated the time and money needed to build the
software for the Space Shuttle program using the
COCOMO model. NASA was able to make well-informed

CASE Studies decisions on resource allocation and project scheduling

and Examples by taking into account variables including project size,

complexity, and team experience.
Big Business Software Development: The COCOMO model
has been widely used by big businesses to project the
time and money needed to construct intricate business
software systems. These organizations were able to better
plan and allocate resources for their software projects by
using COCOMO’s estimation methodology.