Requirements Analysis and

Cost Estimation
Presented by,
Dr.Neethu Anna Sabu
AP/SIESGST
• Software Requirements: Functional & non-functional – user-
system requirement engineering process – feasibility studies –
elicitation – validation & management – software prototyping –
S/W documentation – Analysis and modelling Requirement
Elicitation, Software requirement specification (SRS) 3Ps (people,
product and process) Process and Project metrics Software
Project Estimation: LOC, FP, Empirical Estimation Models-
COCOMO IIModel
• Requirements" are categorized into different types, primarily including
• user requirements (what the user needs)
• system requirements (technical specifications)
• software specifications (detailed description of the system),
• functional requirements (what the system should do) and
• non-functional requirements (how the system should perform)

• Functional and Nonfunctional requirements

• Functional :“Any Requirement Which Specifies What The System Should Do.”
• Nonfunctional requirements :“Any Requirement That Specifies How The System
Performs A Certain Function.”
• Functional Requirements
• Requirements, which are related to functional aspect of software fall into this
category.
• They define functions and functionality within and from the software system.
• Examples –
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Non-Functional Requirements
• Requirements, which are related to non- functional aspect of software, fall into
this category. They are implicit or expected characteristics of software, which
users make assumption of.
• Non-functional requirements include -
• Security
• Logging-recording events, errors, warnings, or any other relevant information
during the execution of a program
• Storage
• Configuration
Non functional requirements
 User-System Requirements Engineering
Process
• User-System Requirements Engineering Process is a crucial part
of the software engineering lifecycle, where you focus on
understanding and capturing the needs of both users and the
system, to ensure the developed system meets the users'
expectations.
• 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
stakeholders.
1.Feasibility Study

2.Requirements elicitation

3.Requirements specification

4.Requirements for verification and validation

5.Requirements management
Feasibility Study
• Technical Feasibility
• A process to assess whether the current hardware, software, and
technologies are sufficient to successfully develop a project.
• study reports whether there are correct required resources and
technologies that will be used for project development.
• 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
• degree of providing service to requirements is analyzed along
with how easy the product will be to operate and maintain
after deployment
Economic Feasibility
• cost and benefit of the project are analyzed.
• cost and benefit of the project are analyzed-a detailed analysis
is carried out - 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
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.
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
 Requirements Elicitation
• to gather information from stakeholders to understand their needs and the
system’s objectives.
• Activities:
• Interviews: Conduct one-on-one or group interviews with stakeholders to
understand their needs.
• Surveys/Questionnaires: Distribute surveys to a wider audience, especially when
dealing with a large user base.
• Workshops/Focus Groups: Collaborative sessions with stakeholders, often used
for refining requirements.
• Observation: Observe users interacting with current systems to identify
improvements.
• Document Analysis: Review existing documents, reports, or systems to
understand the current system’s functionalities.
• Prototyping: Building a simple prototype that helps to elicit more accurate
requirements by showing a working version of the system.
• Output: A list of initial requirements and user needs (both
functional and non-functional).
• Goal-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.
 Requirements Specification
• to produce formal software requirement models.
• process of documenting the requirements identified in the analysis step in a clear, consistent, and
unambiguous manner- ensuring they are understandable by both technical teams and non-technical
stakeholders.
• Several types of requirements are commonly specified in this step, including
1. Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user
interface.

2. Non-Functional Requirements: These describe how well the software system should do it. They
specify the quality attributes of the system, such as performance, reliability, usability, and security.

3. Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.

4. Acceptance Criteria: These describe the conditions that must be met for the software system to
be considered complete and ready for release.
• 5.Activities:Writing Requirements Documents: Create a Software
Requirements Specification (SRS) or a Requirements Document that clearly
describes each requirement.
• 6. Use Cases/User Stories: Document how the system will be used through
detailed use cases or user stories (especially in agile methodologies).
• 7.Acceptance Criteria: Specify clear conditions for each requirement,
defining when it will be considered "done."
• 8.Output: The formal, detailed Requirements Specification Document (e.g.,
SRS or User Stories).
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
• Activities:
• Reviews and Walkthroughs: Organize meetings with stakeholders
to review the documented requirements and ensure everything is
correct and complete.
• Prototyping: Use prototypes to gather user feedback on the
requirements.
• Model Validation: Validate that the models (e.g., use cases)
correctly represent the system's functionality.
• Testing: Develop test cases based on requirements and verify if they
can be met.
• Output: A validated and approved set of requirements ready for
implementation.
• Goal- ensure that the software system being developed meets
the requirements and that it is developed on time, within
budget, and to the required quality.
• not a one-time process, but it should be integrated and
continue throughout the software development process and
even in the maintenance stage.
Requirements Management
• Track, monitor, and maintain the requirements throughout the
development lifecycle to ensure they remain relevant and any
changes are properly handled.
• Activities:Traceability: Ensure each requirement can be traced from
its origin (e.g., a stakeholder) to its corresponding design and
implementation.
• Change Management: Handle changes in the requirements,
especially as new information emerges or priorities shift.
• Version Control: Keep track of multiple versions of the requirements
documents as the project progresses.
• Output: A change-controlled, traceable set of requirements
throughout the project lifecycle.
• Goal-ensure that the software system being developed meets the
needs and expectations of the stakeholders and that it is
developed on time, within budget, and to the required quality.
• Advantages of Requirements Engineering Process
• Helps ensure that the software being developed meets the needs
and expectations of the stakeholders

• Can help identify potential issues or problems early in the

development process, allowing for adjustments to be made before
significant

• Helps ensure that the software is developed in a cost-effective and

efficient manner

• Can improve communication and collaboration between the

development team and stakeholders
• Disadvantages of Requirements Engineering Process
• Can be time-consuming and costly, particularly if the requirements-
gathering process is not well-managed
• Can be difficult to ensure that all stakeholders’ needs and
expectations are taken into account
• It Can be challenging to ensure that the requirements are clear,
consistent, and complete
• Changes in requirements can lead to delays and increased costs in
the development process.
Software prototyping

• creating an idea, sketching it, and making it into a clickable prototype

that mimics real software.
• Software prototyping is a technique that can be used within the context
of various process models to help stakeholders better understand what
is to be built when requirements are not clear
• Key aspects:
• Communication: The process begins with communication between
the software team and stakeholders to define overall objectives,
identify known requirements, and areas needing further definition
• Quick Design: A "quick design" is created that focuses on aspects of
the software that will be visible to end users, such as the user interface
• Construction: A prototype is built based on the quick design
• Deployment and Feedback: The prototype is deployed and evaluated
by stakeholders who provide feedback for further refinement of the
requirements

• To provide users with a tangible and interactive model of the system,

allowing them to see and interact with features before the full
development is completed-Purpose
• Types of Prototypes
1.Throwaway/Rapid Prototyping:
1. A model is built quickly and then discarded after feedback is gathered.
2. Focuses on gathering user requirements and clarifying system specifications.
3. Example: A simplified user interface to collect feedback on layout and
functionality.
2. Evolutionary Prototyping:
• The prototype is continuously improved and refined over multiple iterations
based on user feedback until the final system is developed.
• More suited for systems with evolving or unclear requirements.
• Example: An agile-style development process where the prototype evolves
incrementally.
3. Incremental Prototyping
• The system is built in parts or increments, and each part is prototyped, tested,
and refined independently.
• After each iteration, a portion of the system is built and evaluated.
• Example: A modular e-commerce platform where each module (e.g., user login,
shopping cart) is prototyped and validated separately.
4. Extreme Prototyping (often used in web development):
• A form of evolutionary prototyping focused on web applications where the
prototype is quickly developed and deployed for testing, with rapid feedback and
continuous refinement.
Prototyping Process

• identify the problem of the software

and come up with a complete
version of the software solution
• outline of the application is
informally outlined and a few basic
functions will also be highlighted.
• create a more detailed functional
prototype of the software for their
own use and for the client’s review
• make revisions to the prototypes
created after taking the client’s
feedback & requirements into
consideration.
Advantages Of Software Prototyping

• Reduces Risk
• Offers Visual Guide
• Allows Detecting Errors at the Beginning
• Save Time And Money
• Improves Client’s Involvement
Disadvantages Of Software Prototyping

• Insufficient Analysis
• User Confusion
• Developer Misunderstanding of User Objectives
• Excessive Development Time
• Helps in translating to a significant financial advantage with no
wastage of development time.
• If the software prototype is great, it means that the entire system will
be perfect with minimal difficulties.
 SOFTWARE DOCUMENTATION
• When a software is developed, in addition to the executable files and the source code, several kinds of
documents-users’ manual, software requirements specification (SRS) document, design document, test
document, installation manual

• enhance understandability of code

• understand and effectively use the system.
• help to effectively tackle the manpower turnover problem
• Production of good documents helps the manager to effectively track the progress of the project
Internal Documentation

• code comprehension features provided in the source code itself-process of

understanding the functionality, structure, and design of a codebase
• The important types of internal documentation are the following:
• Comments embedded in the source code.
• Use of meaningful variable names.
• Module and function headers.
• Code indentation.
• Code structuring (i.e., code decomposed into modules and functions).
• Use of enumerated types.
• Use of constant identifiers.
• Use of user-defined data types.
 External Documentation

• various types of supporting documents such as users’ manual, software

requirements specification document, design document, test document, etc
• documents are of good quality and are produced in an orderly fashion.
• all the documents developed for a product should be up-to-date and every change
made to the code should be reflected in the relevant external documents.
• proper understandability by the category of users for whom the document is
designed-Gunning’s fog index is very useful.
Requirements Elicitation & Analysis
• It’s a process of interacting with customers and end-users to find out
about the domain requirements, what services the system should
provide, and the other constraints.
• involve different kinds of stockholders; end-users, managers, system
engineers, test engineers, maintenance engineers, etc.
• Requirements Discovery
• process of interacting with, and gathering the requirements from, the
stakeholders about the required system and the existing system-
interviews, scenarios, prototypes
Interviews
1.Closed-Ended Questions: A pre-defined set of questions.
2.Open-Ended questions: There is no pre-defined expected answer
• Use cases identify interactions between the system and its users or
even other external systems (using graphical notations), while a
scenario is a textual description of one or more of these interactions.
1.Actors: Are those who interact with the system; human or other
systems
2.Interaction (Use Case): It denotes the name of the interaction (verb).
It’s represented as a named ellipse.
3.Connection: Lines that link between the actors and the interactions.
4.Include Relationship: It denotes a connection between two
interactions when an interaction is invoked by another. As an
example, splitting a large interaction into several interactions.
5.Exclude Relationship: extended behavior can be added if needed,
but the core interaction remains functional on its own.
• use scenarios to describe the
interactions in each use case
textually
1.A description of the initial situation.
2.A description of the flow of the
events or interactions with the
system
3.A description of the exceptions, or in
other words, what can go wrong, and
how it can be handled.
4.Any concurrent activities should be
mentioned
5.A description of the final state.
Requirements Classification & Organization

• Putting related requirements together, and decomposing the system

into sub-components of related requirements.
• Define the relationship between these components.
• Help us in the decision of identifying the most suitable architectural
design patterns.
Requirements Prioritization & Negotiation

• Prioritizing your requirements -focus on the essentials and core

features of the system- meet the user expectations.
• It can be achieved by giving every piece of function a priority level.
• So, functions with higher priorities need higher attention and focus.
Requirements Specification

• The requirements are then documented

Software requirement specification (SRS)
• Complete specification and description of requirements of the software that
need to be fulfilled for the successful development of the software system-SRS
• These requirements can be functional as well as non-functional depending upon
the type of requirement
• SRS template

● Document title
● Author(S)
● Address
● Date
● Document version

1.Introduction

1. Purpose of SRS-why necessary?

2. Scope of Product-working and main objective of document , description of development cost and time

3. Overview-summary or overall review of product.

2.General Description:General functionality of the product such as system information,user
characteristics, goals.
3.Functional requirements:Highest ranked order
● 3.1 Description of the requirement-expected behavior of the system-which outputs should be
produced from the given inputs
● 3.2 Criticality:How essential is the requirement
● 3.3 Technical issues: Describe any issues involved in satisfying the requirements
● 3.4 Cost & schedule
● 3.5 Risk: describes the circumstances under which requirements may not be able to build.
● 3.6 Dependency on any other requirements(if any)
● 3.7 Any others
4.Interface requirements
● 4.1 User Interface requirements:How the product will interact with user
● 4.1.1 GUI:describe the number of screens which will illustrate the UI features-capturing all the
distinct views or layouts that a user interacts with to achieve a specific task
● 4.1.2 CLI:describe the command line interface for command description of all argument values
must be provided.
● 4.1.3 API: describe application program interface
 ● 4.2 Hardware interface
● 4.3 Communication Interface
● 4.4 SOftware interface
• 5.Performance requirements:Specify the speed,throughput,response time and memory
requirements.

• 6.Design constraints: Specify the constraints for design team such as H/w and S/W limitations.

7.Non-Functional requirements

Security, Compatibility, Reliability, Maintainability, Portability, Extensibility, Reusability, Application

compatibility, Resource utilization, Serviceability
8.Operational Scenarios: Uml diagrams-Unified Modeling Language (UML) that are applicable till
analysis phase-graphical notation techniques to create visual models of object-oriented software
systems

9. Preliminary schedule: Time given during planning phase.

10.10.Preliminary cost

11.Appendices

● 11.1 Definitions,Acronyms,Abbreviations
● 11.2 References.
3Ps (people, product and process)
• 3Ps in software engineering refer to three key concepts that are
foundational for understanding and managing software development
projects.
• People refers to the human aspects of a project, including the project
management, the team, and any stakeholders.
• Processes refers to the structured approach and plans that guide the project
and keep everything on track.
• Product refers to the end result of a project – the tangible or intangible
goal that the project aims to deliver.
• The Three Ps interact and influence each other throughout the project
lifecycle
• People are the driving force behind any project.
• This includes the project manager, the project team, stakeholders, and
anyone else involved in the project’s execution.
• The human element is often considered the most critical of the Three
Ps, and for good reason

• Leadership and Teamwork

• Communication
• Stakeholder Engagement
• Processes represent the structured approach that guides a
project from initiation to completion.
• They provide a roadmap for achieving project objectives and
keeping everything on track
• Planning
• Execution
• Monitoring and Controlling
• Risk Management
• Change Management
• The product represents the tangible or intangible outcome that the
project aims to deliver.
• It could be a physical product, a software application, a service, or any
other result that aligns with the project’s objectives.
• Definition and Clarity
• Customer Focus
• Quality Assurance
• Delivery and Deployment
• How the Three Ps Work Together
• People Drive the Processes
• Processes Support the People
• The Product is the Ultimate Goal
Process and Project metrics
• Process metrics and project metrics -essential tools for
evaluating and improving the quality, efficiency, and effectiveness
of software development.
• They provide insights into both the development process and the
progress of individual projects.
• Process Metrics
• Evaluating the overall effectiveness of a software development
process, understand how well the processes are functioning,
identify inefficiencies, and guide process improvement initiatives
• focus on various stages of the software development lifecycle
(SDLC)
• Effort variance, schedule variance, defect injection rate, and lead
time.
• effort variance -measures the difference between the estimated effort
(usually in terms of person-hours or person-days) and the actual effort
spent on a particular task or project phase.
• Schedule variance indicates the difference between the planned
schedule and the actual schedule.
• The defect injection rate measures how many defects are being
introduced into the codebase during each phase of development
• Lead time in software engineering refers to the total time it takes for a
task, feature, or user story to move from initiation to completion
• Work in Progress (WIP): Work in Progress (WIP) indicates the
number of tasks or features currently being worked on but not yet
completed
Project Metrics: The project metrics describes the characteristic and execution of
a project.
Examples include effort estimation accuracy, schedule deviation, cost variance,
and productivity.
Usually measures-
Number of software developer
Staffing patterns over the life cycle of software
Cost and schedule
Productivity
• Estimation accuracy measures the difference between the estimated values (e.g.,
time, effort, cost) and the actual values that occur during the project.
• It helps to assess how well project managers and teams can predict project
parameters during the planning phase.

• A low estimation error means that the project is well-planned, and future project estimations
may be more reliable
• high estimation error suggests that the team has difficulty predicting time/effort, which can
lead to delays and budget overruns.

• Schedule deviation measures the difference between the planned schedule and the
actual time taken to complete a task or project.
• It helps in tracking whether the project is on time, ahead, or behind the original
schedule.
• Cost variance measures the difference between the budgeted cost and the actual
cost of the work performed.
• It helps project managers understand whether a project is staying within its
financial constraints.

• Productivity in software engineering refers to the amount of output produced (e.g.,

features, lines of code, function points) relative to the input used (e.g., time, effort,
resources).
• It is a measure of how efficiently a team or individual produces software.
Software Project Estimation
• Software project estimation is an attempt to determine how much money, effort,
resources, and time it will take to build a specific software-based system or
product. It is a key activity in software project planning.
• Key aspects of software project estimation:
• Who does it? Software project managers typically conduct estimations, using
information from project stakeholders and software metrics data collected from
past projects.
• Why is it important? Estimating is important because it helps to establish a
budget and timeline before beginning software development.
• When does it happen? Estimation is done during the project planning phase.
• What affects estimates? Project complexity, project size, and the degree of
structural uncertainty all impact the reliability of estimates
• Estimation techniques:

• Decomposition techniques: These involve breaking down the project

into smaller, more manageable parts.
• This can be done by decomposing the problem or the process.
• Software Sizing: Before an estimate can be made, the scope and
"size" of the software must be understood.
• Size can be measured directly in lines of code (LOC) or indirectly in
function points (FP)
• Problem-Based Estimation: LOC or FP are estimated for each
function of the software-nature and complexity of the problems
• An expected value for software size can be computed using optimistic,
most likely, and pessimistic values.

• LOC-Based Estimation: size metric that estimates the size of a

software system based on the number of lines of executable code.
• FP-Based Estimation: identifying the functions the software
performs and estimating the complexity of these functions.
• Process-Based Estimation: The process is broken into tasks and the
effort for each task is estimated
• Estimation with Use Cases: User scenarios are used to estimate effort by
calculating LOC or FP per use case
• Empirical Estimation Models: These models use mathematical equations
based on historical data to predict effort, cost, and duration
• The structure of estimation models is generally expressed as d = f(vi), where d is
the estimated value and vi are independent parameters like LOC or FP
• The COCOMO II Model: Constructive Cost Model II- A model with three
stages: application composition, early design, and post-architecture
• Constructive Cost Model (COCOMO) is primarily based on Lines of Code (LOC)
as the main measure of software size, but it can also work with Function Points
(FP) in certain variations, especially in COCOMO II
• The Software Equation: A dynamic model that relates effort to project duration
and a "special skills factor"
 Line of code
• Line of code(LOC) is any line of text in a code that is not a comment
or blank line, and also header lines
• LOC (lines of code) is a metric used to measure project size by
counting the number of source instructions, excluding comment and
header lines, in the developed program
• Features of Lines of Code (LOC)
• Change Tracking: Variations in LOC as time passes can be tracked to
analyze the growth or reduction of a codebase, providing insights
into project progress.
• Limited Representation of Complexity: Despite LOC provides a
general idea of code size, it does not accurately depict code
complexity.
• Ease of Computation: LOC is an easy measure to obtain because it is
easy to calculate and takes little time.
• Easy to Understand: The idea of expressing code size in terms of
lines is one that stakeholders, even those who are not technically
inclined, can easily understand.
• Advantages of Lines of Code (LOC)
• Effort Estimation: LOC is occasionally used to estimate development efforts
and project deadlines at a high level. Although caution is necessary, project
planning can begin with this.
• Comparative Analysis: High-level productivity comparisons between several
projects or development teams can be made using LOC. It might provide an
approximate figure of the volume of code generated over a specific time frame.
• Benchmarking Tool: When comparing various iterations of the same program,
LOC can be used as a benchmarking tool.
• It may bring information on how modifications affect the codebase’s total size.
• Disadvantages of Lines of Code (LOC)
• Challenges in Agile Work Environments: Focusing on initial LOC estimates may
not adequately reflect the iterative and dynamic nature of development in agile
development, as requirements may change.
• Not Considering Into Account External Libraries: Code from other libraries or
frameworks, which can greatly enhance a project’s overall usefulness, is not taken
into account by LOC.
• Challenges with Maintenance: Higher LOC codebases are larger codebases that
typically demand more maintenance work.
Functional Point Analysis (FPA)
• Functional Point Analysis (FPA) is a software measurement
technique used to assess the size and complexity of a software system
based on its functionality
• It focuses on the number of different high-level functions or features
a software product supports
• categorizing the functions of the software, such as input screens,
output reports, inquiries, files, and interfaces, and assigning
weights to each based on their complexity
• Objective-measure and provide the software application functional
size to the client, customer, and the stakeholder on their request
• UFP (Unadjusted Function Points) and VAF (Value Adjustment
Factor) are components of the Function Point Analysis (FPA)
• UFP is calculated by evaluating five types of functional components
(also called function types)
•External Inputs (EI): Data or control information entering the system from external sources (e.g.,
user input forms, external systems-user registration form, product search form, add to cart)-Count it
•External Outputs (EO): Data or control information leaving the system, such as reports or
messages generated by the system-confirmation mail, invoice, order summary page-count it
•User Inquiries (EQ): Interactive transactions where the system responds to user queries (e.g.,
availability check, status, search queries, on-demand reports)-count
•Internal Logical Files (ILF): Logical groupings of data stored within the system, such as
databases or internal data structures-user data, product catalog, order data-count
•External Interface Files (EIF): Data files or data groups that are maintained by other systems and
accessed by the current system-payment gateway, shipping service interface
• The main goal of the weighing factor is to assign a specific point
value to each function type (e.g., External Inputs, External Outputs,
User Inquiries, Internal Logical Files, and External Interface Files)
based on its complexity.
• The complexity can range from low to high, and each level of
complexity is assigned a specific weight.
VAF-adjust the function point count based on various factors that can
influence the complexity and the overall functionality of the system
• 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.
• LOC versus Function Point (FP):
Function Point (FP) metric overcomes many of the shortcomings of the LOC metric.
• One of the important advantages of the function point metric over the LOC
metric is that it can easily be computed from the problem specification itself.
• Using the LOC metric, on the other hand, the size can accurately be determined
only after the product has fully been developed
• FP does not account for the algorithmic complexity of a function,
Constructive Cost Model (COCOMO)
• Constructive Cost Model (COCOMO) is a software cost estimation
model that helps predict the effort, cost, and schedule required for
a software development project.
• COCOMO uses a mathematical formula based on the size of the
software project, typically measured in lines of code (LOC).
• Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
• 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.
whole software is divided into different modules and
then we apply COCOMO in different modules to
estimate effort and then sum the effort.
• developing a project plan that outlines the
schedule, resources, and milestones
• defining the system’s overall structure, including
major components, their interactions, and the data
flow between them
• breaks down the system design into detailed
descriptions of each module, including data
structures, algorithms, and interfaces.
• coding the functionalities, implementing
algorithms, and developing interfaces.
• combining individual modules into a complete
system and ensuring that they work together as
intended.
• COCOMO) is a widely used method for
estimating the cost and effort required for software
development
• Types of COCOMO Model
• There are three types of COCOMO Model:

• Basic COCOMO Model

• Intermediate COCOMO Model
• Detailed COCOMO Model
Basic COCOMO Model
• uses a simple mathematical formula to predict how many person-months of work are
required based on the size of the project, measured in thousands of lines of code (KLOC).
• It estimates effort and time required for development using the following expression:
Intermediate COCOMO Model
• In reality, no system’s effort and schedule can be solely calculated based on
Lines of Code.
• For that, various other factors such as reliability, experience, and Capability.
• These factors are known as Cost Drivers (multipliers) and the Intermediate
Model utilizes 15 such drivers for cost estimation.
Each of the 15 such attributes can be rated on a six-point scale ranging
from “very low” to “extra high” in their relative order of importance
COCOMO Model- https://www.geeksforgeeks.org/software-engineering-
cocomo-model/

• Basic COCOMO
• COCOMO II

Explain each one with a numerical example.