Module 2

Requirements Analysis and Cost

Estimation
By
Ms. Rujuta Varatk

1
Software Requirements
• 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
• There are two types
• 1. functional
• 2. Non-functional

2
Functional
• 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.
• For example, in a hospital management system, a doctor should be
able to retrieve the information of his patients

3
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 They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

4
User-System Requirement Engineering
Process
• It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

5
6
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 - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer requirements within
the time and budget.
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.
3. Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization.

7
Requirement Elicitation and Analysis:
• This is also known as the gathering of requirements. Here, requirements are
identified with the help of customers and existing systems processes, if available.
• Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.
• Problems of Elicitation and Analysis:
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.

8
• This process involves several techniques, such as:
• Interviews: Direct communication with stakeholders to gather
information.
• Surveys: Distributing questionnaires to collect opinions and
preferences.
• Workshops: Group sessions to brainstorm and gather requirements
collaboratively.
• Observation: Actively observing users to understand their workflow
and needs.
• Prototyping: Building a preliminary version of the software to elicit
feedback.
9
Software Requirement Specification:

• In this phase, the gathered and analyzed requirements are

documented formally. The Software Requirement Specification (SRS)
document is created, which serves as a blueprint for the development
process. The SRS includes the following components:
• Functional Requirements: Descriptions of what the system should
do in terms of specific functions and features.
• Non-functional Requirements: Constraints and qualities the system
must possess (e.g., performance, security).
• User Interfaces: Descriptions of how users will interact with the
system.
• Data Requirements: Details about the data the system will store,
process, and manage.
10
Software Requirement Validation
This step involves validating the documented requirements to
ensure they accurately represent the stakeholders' needs and
expectations. The aim is to identify and rectify any errors or
misunderstandings before development begins. Techniques used
for requirement validation include:
1. Reviews: Expert reviews and walkthroughs to identify issues in the
SRS.
2. Prototyping: Building a working model of the software to validate
requirements.
3. Simulation: Simulating the software's behavior to test its alignment
with requirements.

11
Software Requirement Management:
Requirement management is an ongoing process that involves
maintaining and tracking changes to requirements throughout the
software development lifecycle. It includes activities such as:
1. Version Control: Managing different versions of the requirements
document.
2. Change Control: Managing and documenting changes to
requirements and their impact.
3. Traceability: Establishing links between requirements and design,
implementation, and testing.
4. Prioritization: Assigning priorities to requirements to guide
development efforts.
5. Communication: Ensuring stakeholders are informed about changes
and updates to requirements.
12
Software Prototyping
• Prototyping is defined as the process of developing a working
replication of a product or system that has to be engineered. It offers a
small-scale facsimile of the end product and is used for obtaining
customer feedback.

13
Software Prototyping

14
• Step-1: Requirements gathering and analysis :
• Requirement analysis is the first step in developing a prototyping model. During
this phase, the system’s desires are precisely defined. During the method, system
users are interviewed to determine what they expect from the system.
• Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design. During
this stage, the system’s basic design is formed. However, it is not a complete
design. It provides the user with a quick overview of the system. The rapid design
aids in the development of the prototype.
• Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the knowledge gained
from quick design. It is a small low-level working model of the desired system.

15
• Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at this stage.
It is beneficial to investigate the performance model’s strengths and weaknesses.
Customer feedback and suggestions are gathered and forwarded to the developer.
• Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to improve the type
that responds to user feedback and suggestions. When the user is satisfied with the
upgraded model, a final system based on the approved final type is created.
• Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it was
developed to support the original version. To reduce downtime and prevent major
failures, the programmer is run on a regular basis.

16
S/W Documentation
• Software documentation is written text or illustration that provides
information about an application or other software product.
• Documentation for software includes two target viewers: software
engineers and product end users. Documentation in software
engineering refers to information and publications that assist
professionals comprehend the planning, coding, and implementation
of a product.
• This documentation enables developers to comprehend, update, and
customize software from the ground up.

17
Software Documentation Types

• Administrative Records
• Administrative paperwork can comprise project documents such as
guidelines, roadmaps, product specifications, and project information
such as progress reports and meeting notes.
• Documentation for end user/customers : Software for End-User
Documentation Customers documentation is a type of documentation
for processes that explains how to use, install, and configure your
program. Having this type of documentation available helps people
understand how to utilise your programme. User directs, databases of
information, instructions, troubleshooting manuals, reference directs,
and release notes are examples of end-user documentation.

18
• Documentation for Developers
• Developer documentation is the documentation for the product that describes how your
software should function so that developers understand what they're working on. These
papers include build requirements, which describe what the program is expected to
perform, architectural information, which describes the parts and features of the programs,
and checklists, which assist developers through the software development process.
• Documentation "Just-In-Time"
• The 'just-in-time' (JIT) documentation strategy involves developing documentation as
needed and providing users with support documents at the point of need. It is built on agile
techniques and focuses on customer feedback. If you release a piece of software, you
develop just the necessary amount of documentation rather than a library of information
based on preconceptions about what your consumers need help with. When your customers
have questions or encounter issues, you add the solutions to your documentation and make
those resources available to them in their processes, allowing them to maintain high
productivity and become self-sufficient users of your good.

19
Analysis and modelling Requirement
Elicitation
• We typically start by gathering the requirements, this could be
done through a general discussion or interviews with your
stakeholders, also it may involve some graphical notation.
• Then you organize the related requirements into
sub-components and prioritize them, and finally, you refine them
by removing any ambiguous requirements that may arise from
some conflicts.
• Here are the 4 main processes of requirements elicitation and
analysis.

20
21
Software Requirements 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.
• Depending upon information gathered after interaction, SRS is developed which
describes requirements of software that may include changes and modifications
that is needed to be done to increase quality of product and to satisfy customer’s
demand.

• NOTE: kindly refer attached document for SRS

22
3Ps Process
• People, Product & Process provide principles for successful
engineering leadership.
• People : People are at the heart of solving problems. Software
engineers, testers, program/project managers, product
managers, ux researchers, technical writers, support engineers,
etc make an engineering team. Organization structures may
vary from one company to the other, but you find these key
players in every software organization. A great investment of
money and time should be hiring, retaining, growing, and
coaching talent.

23
Continue..
• Product : Product is any physical device or service that gets
the job done for a customer.
• This includes the objectives, benefits, outcomes, and deliverables of
the project
• Process : Software engineers despise process governance and
lately the increasing trend of blueprints, checklists and dossiers
are burning out engineering teams at the expense of delivering
customer value. In my view process is important if it serves
outwardly — delivery of product features and inwardly — cover
all bases from design to quality to performance and security.

24
Software metrics
• A software metric is a measure of software characteristics which are
measurable or countable. Software metrics are valuable for many
reasons, including measuring software performance, planning work
items, measuring productivity, and many other uses.

25
Types of Software Metrics

• 1. Process Metrics
• Process metrics are used to measure the characteristics of the
process of software development. The example includes the
efficiency of detection of fault etc. The characteristics of the methods,
tools, and techniques used for software development can be
measured using process metrics.
• 2. Product Metrics
• The characteristics of the software product are measured using
product metrics. Some of the important characteristics of the software
are:
• Software size and complexity
• Software reliability and quality
• Computation of these metrics is done for different stages of the
software development lifecycle. 26
Continue..
• 3. Internal Metrics
• The properties which are of great importance to a software developer can be
measured using the metrics called internal metrics. An example is a measure of
Lines of code (LOC).
• 4. External Metrics
• The properties which are of great importance to a user can be measured using the
metrics called external metrics. An example is portability, reliability, usability, etc.
• 5. Project Metrics
• The progress of the project is checked by the project manager using the metrics
called project metrics. Various metrics such as time, cost, etc., are collected by
using the data from the projects in the past, and they are used as an estimate for
the new software. The project manager checks the progress of the project from
time to time, and effort, time and cost are compared with the original effort, time
and cost. The cost of development, efforts, risks and time can be reduced by using
these metrics. The quality of the project can also be improved. With the increase in
quality, there is a reduction in the number of errors, time, cost, etc.

27
Project Estimation
• It is used to examine the analysis model with the objective of
predicting the size of resultant system.
• LOC
• FP

28
LOC Metrics

• It is one of the earliest and simpler metrics for calculating the size of
the computer program. It is generally used in calculating and
comparing the productivity of programmers. These metrics are derived
by normalizing the quality and productivity measures by considering
the size of the product as a metric.

29
Example

void selSort(int x[], int n) {

//Below function sorts an array in ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}

So, now If LOC is simply a count of the number of lines then the above function shown
contains 13 lines of code (LOC). But when comments and blank lines are ignored, the
function shown above contains 12 lines of code (LOC).

30
Advantages and Disadvantages
• Advantages of LOC
1. Simple to measure
• Disadvantage of LOC
1. It is defined on the code. For example, it cannot measure the size of the
specification.
2. It characterizes only one specific view of size, namely length, it takes no
account of functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

31
Functional Point
• It is derived by using a relationship between complexity of software and the
information domain value.
• FPA is used to make estimate of the software project, including its testing in terms
of functionality or function size of the software product. However, functional point
analysis may be used for the test estimation of the product. The functional size of
the product is measured in terms of the function point, which is a standard of
measurement to measure the software application.
• FPs of an application is found out by counting the number and types of functions
used in the applications.
• FP characterizes the complexity of the software system and hence can be used to
depict the project time and the manpower requirement.
• The effort required to develop the project depends on what the software does.
• FP is programming language independent.

32
Types of FP Attribute
Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

33
The FPA functional units are shown in Fig:

34
Formulas:

Total pages of documentation = technical document + user document

Documentation = Pages of documentation/FP

35
Problem:
• Given the following values, compute function point when all
complexity adjustment factor (CAF) and weighting factors are
average.
• User Input = 50
• User Output = 40
• User Inquiries = 35
• User Files = 6
• External Interface = 4

36
Solution
• Unadjusted Function Point(UFP) = (50*4) + (40*5) + (35*4) + (6*10) +
(4*7) = 628
• As complexity adjustment factor is average (given in question), hence,
scale = 3.
Fi = 14 * 3 = 42

• Function Point = Count-total * [0.65 + 0.01 *∑(fi)]

628*[0.65 + ( 0.01 * 42 ) ]
628 * 1.07 = 671.96

37
Problem 2
• Compute the function point, productivity, documentation, cost per function for the
following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month
• Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

38
Empirical Estimation Models
• Based on the data taken from previous projects
• There are two types.
• 1. Expert Judgement Technique.
It is the most widely used empirical software estimation technique. In this approach, an
expert makes an executed guess of problem size and hence the effort required after analyzing
the problem thoroughly.
• 2. Delphi Cost Estimation
• The Delphi cost estimation approach overcomes come of the shortcomings of the expert
judgement approach. Delphi estimation is carried out by a group of experts and a
coordinator. Who provides each estimator with a copy of the software requirement
specification(SRS) and a form for recording the cost estimate.
• The estimators after giving their individual estimate submit it to the coordinator who then
prepares and distributes the summary of the responses of all the estimators. In this process,
any unusual rationale is also noted by the coordinator based on this summary the estimators
re-estimate and the process iterates for several rounds. After which the co-ordinator finally
compiles the result of the final estimate.

39
COCOMO-II Model
• COCOMO 2 is another cost-estimating methodology utilized to calculate the
cost of software development. It is a modified version of the
original COCOMO that was developed at the University of Southern
California. It was mainly designed to resolve the shortcomings of the
COCOMO 1 model. Its primary goal is to offer methodologies, quantitative
analytic structure, and tools. It computes the total development time and
effort that is based on the estimates of all individual subsystems.
• It is based on the non-linear reuse formula. This approach assists in offering
estimates that represent one standard deviation of the most common
estimate. Five scale factors define its effort equation exponent, and it has 17
cost drivers attributed to it. It is useful in the software development cycle
(SDLC) non-sequential, reuse, rapid development, and reengineering
models.
40
COCOMO 2 estimation models

• here are mainly 3 types of COCOMO 2 estimation models. These

models are as follows:
• 1. Application Composition Model
• 2. Early Design Estimation Model
• 3. Post Architecture Estimation

41
1. Application Composition Estimation Model

• Application Composition Estimation Model allows one to estimate the

cost, and effort at stage 1 of the COCOMO II Model. In this model,
size is first estimated using Object Points. Object Points are easy to
identify and count. Object Points define screen, reports, and
third-generation (3GL) modules as objects
• Focus on those applications which can be quickly developed using
interoperable components.
• Example. GUI, database Manager etc..

42
Steps for Efforts Estimation
• 1.Access Object Counts
• Estimate the number of screens, reports and 3GL components that will
comprise this application.
• 2. Classify Complexity Levels of Each Object
• We have to classify each object instance into simple, medium and
difficult complexity level depending on values of its characteristics.
Complexity levels are assigned according to the given table.
•

43
44
• 3. Assign Complexity Weights to Each Object
• The weights are used for three object types i.e, screens, reports and
3GL components. Complexity weight are assigned according to
object’s complexity level using following table.
•

45
• 4. Determine Object Points
• Add all the weighted object instances to get one number and this is
known as object point count.
• Object Point = Sigma (number of object instances) * (Complexity
weight of each object instance)
• 5. Compute New Object Points (NOP)
• We have to estimate the %reuse to be achieved in a project.
Depending on %reuse
• NOP = [(object points) * (100 – % reuse)] / 100
• NOP are the object point that will need to be developed and differ
from the object point count because there may be reuse of some object
instance in project.

46
• 6. Calculate Productivity rate (PROD)
• Productivity rate is calculated on the basis of information given about
developer’s experience and capability. For calculating it, we use
following table.

47
7. Compute the estimated Effort
• Effort to develop a project can be calculated as:
• Effort = NOP / PROD
• Effort is measured in person-month.

48
Example

• Consider a database application project with

1. The application has four screens with four views each and seven data
tables for three servers and four clients.
2. Application may generate two reports of six section each from seven
data tables for two servers and three clients.
3. 10% reuse of object points.
4. Developer’s experience and capability in similar environment is low.
• Calculate the object point count, New object point and effort to
develop such project.

49
Solution
Step 1: Number of screens = 4 and Number of records = 2
Step 2: For screens,
Number of views = 4
Number of data tables = 7
Number of servers = 3
Number of clients = 4
By using above given information and table (For Screens), Complexity level for
each screen = medium
For reports,
Number of sections = 6
Number of data tables = 7
Number of servers = 2
Number of clients = 3
By using above given information and table (For Reports),
Complexity level for each report = difficult. 50
Step 3: By using complexity weight table we can assign complexity weight to each object instance
depending upon their complexity level.
Complexity weight for each screen = 2
Complexity weight for each report = 8

Step 4:
Object point count = sigma (Number of object instances) * (its Complexity weight)
= 4 * 2 + 2 * 8 = 24
Step 5:
%reuse of object points = 10% (given)
NOP = [object points * (100 – %reuse)] / 100
= [24 * (100 -10)]/100 = 21.6

51
Step 6:
Developer’s experience and capability is low (given) Using information given about developer and
productivity rate table
Productivity rate (PROD) of given project = 7

Step 7:
Effort = NOP / PROD
= 21.6/7
= 3.086 person-month
Therefore, effort to develop the given project = 3.086 person-month.

52
2. Early Design Model : COCOMO-II

• It is used at the Stage – II in COCOMO -II models and supports

estimation in early design stage of project. Base equation used in
COCOMO – II models is as follows –
• PMnominal = A * (size)B
• where PMnominal = Effort for the project in person months
• A = constant representing the nominal productivity where A = 2.5
• B = Scale Factor
• Size = size of the Software
• The early design model uses Unadjusted Function Points (UFP) as
measure of size.
53
3. Post Architecture Estimation
• It supports estimation in the post architecture stage of a project. For
this it uses Post Architecture Estimation Model. This model is used
after the completion of the detailed architecture of application
generator, infrastructure, system integration.
• Master Software Testing and Automation in an efficient and
time-bound manner by mentors with real-time industry experience.
Join our Software Automation Course and embark on an exciting
journey, mastering the skill set with ease!

54