lOMoARcPSD|31067622

UNIT-II (SOFTWARE REQUIREMENTS)

Subject code & title: 21CSC303J & SEPM

In software engineering, requirements define what a system should do and how it should behave. They
serve as a foundation for software development, ensuring that the final product meets user needs and
business goals. Requirements help stakeholders, developers, and testers understand what is expected from
the software, minimizing errors and misunderstandings during development. Without well-defined
requirements, software projects may fail due to unclear expectations, scope creep, or poor system
performance.

Software requirements are classified into four main categories: functional requirements, non-functional
requirements, user requirements, and system requirements. Each category plays a critical role in
software development.

1. Functional Requirements

Functional requirements specify what the system should do. These requirements define the system's core
features and operations that fulfill its intended purpose.

Key Characteristics:

• Define specific system functionalities.

• Describe inputs, processing, and expected outputs.
• Ensure that the system meets business objectives.

Examples:

• An ATM system should allow users to withdraw cash, check their account balance, and transfer
funds.
• An e-commerce platform should enable users to add products to the cart, make payments, and
track orders.
• A library management system should allow users to search for books, issue books, and return
books.

2. Non-Functional Requirements

Non-functional requirements define how the system should perform rather than what it does. They focus
on quality attributes such as performance, security, reliability, and usability.

Key Characteristics:

• Specify system constraints and operational standards.

• Affect user experience and system efficiency.
• Ensure the system meets performance, security, and scalability expectations.

Examples:

• An ATM system should process transactions within 3 seconds.

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

• An e-commerce website should handle at least 10,000 concurrent users.

• A data storage system should provide 99.9% uptime and automatic backup every 24 hours.

3. User Requirements

User requirements describe the expectations and needs of end users in a simple and non-technical manner.
They serve as a bridge between stakeholders and developers, ensuring the system meets user expectations.

Key Characteristics:

• Express user needs in simple language.

• Do not include technical details.
• Focus on user experience and usability.

Examples:

• A customer on an e-commerce website wants an easy checkout process with multiple payment
options.
• A student using an online exam system wants to receive instant feedback on their answers.
• An ATM user wants the machine to provide receipt printing and support multiple languages.

4. System Requirements

System requirements define the technical specifications and constraints necessary for the software to
function properly. These are typically written for developers, system architects, and IT administrators.

Key Characteristics:

• Provide hardware, software, and network specifications.

• Ensure compatibility and smooth system operation.
• Define system security and storage requirements.

Examples:

• A banking application should run on Windows Server 2019 with 8GB RAM and 100GB
storage.
• An ATM system should operate on a Linux-based OS with 512MB RAM.
• A mobile application should be compatible with Android 10 and iOS 14 or later.

Interface Specification

An Interface Specification defines how different software components, systems, or external devices
communicate with each other. It provides a detailed description of the inputs, outputs, data formats, and
protocols used in these interactions.

Key Aspects of Interface Specification:

• Defines how two or more software modules interact.

• Specifies input and output data formats.

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

• Describes communication protocols (e.g., HTTP, REST, SOAP).

• Ensures compatibility between software components or external systems.

Example Scenario:

Imagine an online payment system integrated with an e-commerce website. The interface specification
will define:

• Inputs: The website sends user details, order amount, and payment method to the payment
gateway.
• Processing: The payment gateway validates the transaction.
• Outputs: The payment gateway sends a response (Success or Failure) to the website.

Software Requirements Document (SRD)

A Software Requirements Document (SRD) is a comprehensive document that outlines all the
requirements of a software system. It serves as a guide for developers, testers, project managers, and
stakeholders. The SRD ensures that everyone involved in the project understands what the software is
supposed to do and how it should function.

Key Sections of SRD:

1. Introduction – Overview of the project and its purpose.

2. Functional Requirements – Defines what the system should do.
3. Non-Functional Requirements – Describes performance, security, and usability.
4. User Requirements – Outlines the expectations of end users.
5. System Requirements – Specifies hardware, software, and network needs.
6. Interfaces – Describes user interfaces and system interactions.
7. Use Case Scenarios – Example interactions between users and the system.
8. Assumptions – Conditions assumed to be true for the system’s operation.
9. Constraints – Limitations or restrictions that impact the system.
10. Acceptance Criteria – The conditions that must be met for the system to be accepted.

Example: Software Requirements Document (SRD) for Library Management System (LMS)
1. Introduction

1.1 Purpose

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

The purpose of the Library Management System (LMS) is to digitalize library operations, allowing
students and staff to manage books efficiently. The system enables users to search, borrow, return, and
reserve books online. It also provides librarians with tools to manage inventory and track due dates.

1.2 Scope

This system will allow:

• Students to search for books, borrow books, and check due dates.
• Librarians to manage book inventory and track book availability.
• Administrators to handle user accounts and system configurations.

The system will be web-based and accessible via desktop and mobile browsers.

1.3 Intended Audience and Reading Suggestions

This document is intended for developers, testers, project managers, and stakeholders involved in the
development of the LMS.

1.4 Definitions and Acronyms

• LMS (Library Management System) – The software system managing library books and users.
• ISBN (International Standard Book Number) – A unique identifier for books.
• GUI (Graphical User Interface) – The visual part of the system that users interact with.

2. Functional Requirements

2.1 User Authentication

• Users must be able to log in using their university ID and password.

• Forgot password functionality should allow password reset via email.

2.2 Book Search and Filtering

• Users should be able to search for books by title, author, ISBN, or category.
• Users should be able to filter books based on availability and genre.

2.3 Borrowing and Returning Books

• Students should be able to borrow up to 3 books at a time.

• The borrowing period is 14 days, after which a fine is applied.
• Students must be able to return books via the system and get confirmation.

2.4 Book Reservation

• If a book is not available, students should be able to reserve it.

• The system should send email notifications when a reserved book becomes available.

2.5 Librarian Dashboard

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

• Librarians should be able to add, update, or remove books from the system.
• The system should allow tracking of overdue books and fines.

3. Non-Functional Requirements

3.1 Performance Requirements

• The system should respond to user requests within 2 seconds.

• The system should support 1,000 concurrent users.

3.2 Security Requirements

• User data should be encrypted using AES-256 encryption.

• Only librarians and administrators should have access to modify book inventory.

3.3 Usability Requirements

• The system should be user-friendly and accessible on both desktop and mobile browsers.
• The interface should follow WCAG 2.1 accessibility standards.

4. System Requirements

4.1 Hardware Requirements

• Server: Intel Xeon Processor, 16GB RAM, 1TB SSD Storage.

• Client Devices: Any modern laptop, tablet, or smartphone.

4.2 Software Requirements

• Operating System: Windows 10, Linux Ubuntu 20.04.

• Database: MySQL or PostgreSQL.
• Backend Framework: Django (Python) / [Link].
• Frontend Framework: [Link] or Angular.

4.3 Network Requirements

• Minimum 10 Mbps internet speed for smooth operation.

• Secure access via HTTPS.

5. Interfaces

5.1 User Interface (UI) Requirements

• A dashboard for students to view borrowed books and due dates.

• A dashboard for librarians to manage book inventory.

5.2 System Interface Requirements

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

• The system should integrate with the university’s student database.

• Payment gateway integration for fine payments.

6. Use Case Scenarios

Use Case 1: Borrowing a Book

Actors: Student, LMS

Preconditions: Student must be logged in.

Flow:

1. The student searches for a book.

2. If available, the student selects "Borrow" and confirms.
3. The system updates the book status as "Borrowed" and sets a due date.
4. The student receives a confirmation email.

Postcondition: The book is assigned to the student and unavailable for others.

7. Assumptions

• Students and librarians have stable internet access.

• Students will return books on time to avoid fines.
• The university provides a list of students eligible to access the system.
• Users will not attempt to exploit system vulnerabilities.

8. Constraints

• The system must be developed within 6 months.

• The maximum number of books a student can borrow is 3 at a time.
• The system must comply with GDPR for data privacy.
• The maximum book database capacity is 500,000 records.

9. Acceptance Criteria

• The system should allow students to search, borrow, and return books.
• Students should receive email notifications for overdue books.
• Librarians should be able to add, update, and delete books.
• The system should support at least 1,000 concurrent users without performance issues.
• Security protocols (encryption, authentication) must be properly implemented.

10. Appendix

LMS: Library Management System

ISBN: International Standard Book Number
AES-256: Advanced Encryption Standard for data security

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

Requirements Engineering Process

Introduction

The Requirements Engineering (RE) process is a fundamental phase in software development that
focuses on gathering, analyzing, documenting, and validating the needs of stakeholders. It ensures that the
final software system meets business goals, user expectations, and technical constraints. A well-defined RE
process reduces errors, improves project success rates, and minimizes costly rework during later stages of
development.

In software engineering, a requirement refers to a description of the system’s behavior, features, or

constraints that stakeholders expect. Requirements can be functional (defining what the system should
do) or non-functional (defining quality attributes like performance, security, and usability).

The Requirements Engineering Process consists of several key steps:

1. Requirements Elicitation

Definition

Requirements elicitation is the process of gathering information about what stakeholders need from a
system. It involves communication with users, customers, developers, and other involved parties to identify
their expectations and constraints.

Process

This step includes:

• Interviews: One-on-one discussions with stakeholders to understand their needs.

• Surveys & Questionnaires: Collecting data from a large group of users.
• Workshops & Brainstorming: Engaging multiple stakeholders in collaborative sessions.
• Observation: Studying how users currently perform tasks to identify areas of improvement.
• Prototyping: Creating mock-ups or prototypes to gather feedback.

Example

Consider a university planning to develop an online course registration system. The requirements
elicitation phase would involve:

• Interviewing students to understand how they select and register for courses.
• Consulting faculty members to know how they manage course capacity.
• Observing the manual process of course registration to identify inefficiencies.
• Developing a prototype and getting feedback from students.

2. Requirements Analysis & Negotiation

Definition

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

Once requirements are gathered, they must be analyzed to resolve conflicts, prioritize needs, and ensure
feasibility. Sometimes, different stakeholders may have conflicting demands, so negotiation is necessary
to reach a compromise.

Process

• Identifying inconsistencies: Checking for contradictions between different requirements.

• Prioritizing requirements: Using techniques like MoSCoW (Must-have, Should-have, Could-
have, Won’t-have) to determine essential vs. optional features.
• Feasibility analysis: Evaluating if the requirements are technically and financially viable.

Example

In the university course registration system, students may request an automatic waitlist feature, but
faculty might prefer manual approvals for over-enrolled courses. The analysis phase will determine
whether both requests can be implemented and negotiate a solution (e.g., automated waitlisting with manual
override options).

3. Requirements Specification

Definition

Once the requirements are analyzed and finalized, they must be formally documented in a structured
format known as the Software Requirements Specification (SRS) document.

Key Components of SRS:

• Functional Requirements: What the system should do (e.g., "The system must allow students to
enroll in up to five courses per semester").
• Non-functional Requirements: Quality aspects like security, performance, and usability (e.g.,
"The system must handle 10,000 concurrent users").
• Assumptions and Constraints: Conditions that affect development, such as budget limitations or
regulatory compliance.
• System Interfaces: Integration details with external systems.

Example

For the course registration system, an SRS document might include:

• Functional Requirement: "The system shall allow students to add or drop courses before the
semester starts."
• Non-functional Requirement: "The system shall respond to user queries within 2 seconds."
• Constraint: "The system must be compatible with existing university databases."

4. Requirements Validation & Verification

Definition

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

After documentation, requirements must be validated to ensure correctness, completeness, and

feasibility. Validation prevents errors from being carried into the design and development phases.

Techniques Used

• Reviews & Inspections: Stakeholders review the documented requirements.

• Prototyping: A working model is tested by users to confirm that the requirements are correct.
• Modeling & Simulation: Requirements are visualized using diagrams and test cases.

Example

For the university course registration system, validation might involve:

• A team review of the SRS document to check for missing details.

• Developing a clickable prototype to demonstrate how students will enroll in courses.
• Testing the prototype with students to confirm that it meets their expectations.

5. Requirements Management

Definition

Requirements management involves tracking, updating, and handling changes to requirements

throughout the software lifecycle. As business needs evolve, requirements may need modifications, and a
structured approach is necessary to prevent scope creep.

Key Activities in Requirements Management

• Version Control: Maintaining different versions of the requirement document.

• Change Management: Defining a structured process for modifying requirements.
• Traceability Matrix: Mapping requirements to design, development, and testing to ensure
coverage.

Example

If the university decides to introduce AI-based course recommendations for students, the original SRS
document must be updated to include this new requirement. The development team would evaluate the
impact of this change and implement necessary modifications.

Challenges in Requirements Engineering

Despite its importance, the RE process faces several challenges, including:

• Unclear Requirements: Stakeholders may not always know what they want.
• Changing Requirements: Business needs can evolve during development.
• Conflicting Stakeholder Needs: Different user groups may have different expectations.
• Limited User Involvement: If users are not actively engaged, the system may not meet their needs.

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

What is a Feasibility Study?

A Feasibility Study is an initial assessment conducted before starting a software development project. Its
purpose is to analyze whether the proposed system is practical, achievable, and beneficial for the
organization. It helps stakeholders decide whether to proceed with development or explore alternative
solutions.

A feasibility study typically answers the following questions:

• Can the system be developed within available resources?

• Will it meet the user and business requirements?
• Are there any risks or challenges that could impact development?
• Is the technology needed to develop the system available and compatible?

Types of Feasibility in Requirements Engineering

A feasibility study is conducted across different aspects to ensure the project's success. The five major types
of feasibility are:

1. Technical Feasibility

This examines whether the technology, tools, and infrastructure required for the project are available and
capable of supporting the system.

Key Considerations:

• Is the existing hardware/software sufficient to develop and run the system?

• Does the team have expertise in the required programming languages and tools?
• Are there any technical limitations (e.g., database capacity, processing speed)?

Example:

A company wants to develop an AI-powered chatbot for customer support. The feasibility study will check
if the company has access to Natural Language Processing (NLP) tools, servers for high data processing,
and skilled developers to build the chatbot.

2. Economic Feasibility (Cost-Benefit Analysis)

This determines whether the financial benefits of the system outweigh the costs of development,
implementation, and maintenance.

Key Considerations:

• How much will it cost to develop, deploy, and maintain the system?
• What are the expected financial benefits (e.g., increased revenue, cost savings)?
• Is there a budget available for the project?

Example:

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

A university wants to replace its manual library system with a digital LMS. The feasibility study will
compare the development costs, server costs, and training expenses with the savings in administrative
work and improved efficiency.

3. Operational Feasibility

This assesses whether the system will function effectively within the organization and if users will be
willing to adopt it.

Key Considerations:

• Will the system improve existing workflows and efficiency?

• Are employees/staff willing and able to use the new system?
• Will additional training be required for users?

Example:

A hospital plans to implement electronic health records (EHR) to replace paper-based records. The
feasibility study will check if doctors, nurses, and administrative staff are comfortable using digital
systems and whether training is necessary.

4. Legal Feasibility

This examines whether the project complies with legal, regulatory, and security requirements.

Key Considerations:

• Does the system comply with data protection laws (e.g., GDPR, HIPAA)?
• Are there any licensing restrictions for the software being used?
• Does the project follow intellectual property (IP) laws?

Example:

A financial institution developing an online banking system must ensure that the software complies with
banking regulations, cybersecurity policies, and data privacy laws.

5. Schedule Feasibility (Time Feasibility)

This evaluates whether the project can be completed within the required timeframe without affecting
other business operations.

Key Considerations:

• Is the proposed timeline realistic?

• Are there enough skilled resources to complete the project on time?
• What are the risks of project delays?

Example:

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

A retail company wants an e-commerce website ready before the holiday season. The feasibility study
will determine if the development, testing, and deployment can be completed in time.

Steps in Conducting a Feasibility Study

1. Identify Objectives: Define the goals of the project and what needs to be achieved.
2. Gather Requirements: Collect business, user, and technical requirements.
3. Analyze Different Feasibility Aspects: Evaluate the technical, economic, operational, legal,
and schedule feasibility.
4. Identify Risks and Challenges: List potential risks, such as budget overruns, technology
limitations, or legal issues.
5. Prepare a Feasibility Report: Document the findings and provide a recommendation on
whether to proceed with the project.

Outcome of a Feasibility Study

Based on the study, stakeholders can decide:

• Proceed with the project if it is feasible.

• Modify the project plan to address identified risks or constraints.
• Abandon the project if it is not viable.

Software Project Effort and Cost Estimation – COCOMO Model I

Introduction

Estimating the effort and cost of a software project is a crucial aspect of software engineering. Accurate
estimation ensures that projects are delivered on time, within budget, and with the required quality. One
of the most widely used models for estimating effort, cost, and development time is the COCOMO
(COnstructive COst MOdel) Model I, developed by Barry Boehm in 1981.

COCOMO I is a mathematical model that estimates the effort (in person-months), cost, and time
required to develop a software project based on its size (measured in KLOC – thousands of lines of code).
It provides a structured way to calculate effort and cost based on past project data and empirical
relationships.

COCOMO Model I: An Overview

COCOMO I is a hierarchical model that estimates software effort and cost in three different modes:

1. Organic Mode – Simple and small projects with well-understood requirements.

2. Semi-Detached Mode – Medium-sized projects with a mix of new and experienced team members.
3. Embedded Mode – Large and complex projects with strict constraints (e.g., real-time systems).

Each mode has a different mathematical equation for estimating effort (E), development time (T), and
staffing needs.

The basic COCOMO formula is:

Effort (E) Estimation: E = a × (KLOC)^b

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

where:

• E = effort in person-months (PM)

• KLOC = estimated size of the software in thousands of lines of code
• a and b are constants based on the project mode

Development Time (T) Estimation: T = c × (E)^d

where:

• T = development time in months

• E = effort (person-months) from the previous equation
• c and d are constants based on the project mode

The values of a, b, c, and d vary for different modes:

Mode a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Example: Applying COCOMO I

Scenario

A software company is developing a library management system. Based on similar past projects, the
estimated size of the software is 50 KLOC (50,000 lines of code). The project is classified as Semi-
Detached, meaning it involves a mix of new and experienced developers.

Step 1: Calculate Effort (E)

Using the formula:

E = 3.0 × (50)^1.12
E = 3.0 × 65.36
E = 196.08 person-months

So, the effort required is approximately 196 person-months (i.e., if one person works alone, it will take
196 months).

Step 2: Calculate Development Time (T)

Using the formula:

T = 2.5 × (196.08)^0.35
T = 2.5×7.82

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

T = 19.55 months

So, the estimated development time is approximately 19.5 months.

Step 3: Calculate Team Size

Team size can be calculated as:

Team Size = Effort/Development Time

= 196.08/19.55 = 10 developers

So, the company should allocate around 10 developers to complete the project on time.

Different Modes of COCOMO I and their Usage

1. Organic Mode (typically < 50,000 LOC or 50 KLOC) Example

o A small accounting software for a startup, where all requirements are clear, and a small
team is working in a familiar domain.
2. Semi-Detached Mode (typically 50,000-3,00,000 LOC or 50-300 KLOC) Example
o A library management system for a university, where part of the software is well
understood, but new features require experienced developers.
3. Embedded Mode (typically > 3,00,000 LOC or 300 KLOC) Example
o A real-time flight control system where the software must work under strict hardware
and security constraints.

Advantages of COCOMO I

• Simple and easy to understand mathematical model.

• Based on empirical data, making it more reliable for real-world projects.
• Helps in early-stage cost estimation, which aids in project budgeting.
• Can be adjusted for different project complexities.

Limitations of COCOMO I

• Does not consider modern software development methods like Agile and DevOps.
• Assumes that software size (KLOC) is known in advance, which is difficult in the early stages.
• Does not consider external factors like team productivity, tool efficiency, or market changes.

Intermediate and Complete COCOMO I Model

COCOMO I has three versions:

1. Basic COCOMO Model – Provides a rough estimate using only software size.
2. Intermediate COCOMO Model – Improves estimation by considering additional cost drivers
(e.g., team experience, hardware constraints).
3. Complete (Detailed) COCOMO Model – Extends the Intermediate model by applying cost
drivers to individual project phases (e.g., design, coding, testing).

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

1. Intermediate COCOMO Model

Overview

The Intermediate COCOMO model refines the Basic model by introducing 15 cost drivers that influence
project effort and cost. These cost drivers account for factors like team expertise, complexity, reliability
requirements, and development tools.

The Intermediate COCOMO equation is: 𝑬 = 𝒂 × (𝑲𝑳𝑶𝑪)𝒃 × ∏𝟏𝟓

𝒊=𝟏 𝑬𝑴𝒊

where:

• 𝐸𝑀𝑖 = Effort Multipliers (cost drivers) for different project characteristics

Cost Drivers in Intermediate COCOMO

These 15 cost drivers are categorized into four groups:

(1) Product Attributes (4 factors)

• Required Software Reliability (RELY) – High-reliability systems (e.g., banking software)

increase effort.
• Database Size (DATA) – Large databases require more effort.
• Product Complexity (CPLX) – Complex algorithms or user interfaces demand more effort.
• Required Reusability (RUSE) – Reusable components increase effort.

(2) Computer Attributes (3 factors)

• Execution Time Constraint (TIME) – Real-time systems require more effort.

• Main Storage Constraint (STOR) – Limited memory increases development effort.
• Platform Volatility (PVOL) – Unstable platforms increase maintenance effort.

(3) Personnel Attributes (4 factors)

• Analyst Capability (ACAP) – Skilled analysts reduce effort.

• Programmer Capability (PCAP) – Experienced programmers lower effort.
• Personnel Continuity (PCON) – Frequent team changes increase effort.
• Application Experience (APEX) – Familiarity with the domain reduces effort.

(4) Project Attributes (4 factors)

• Use of Software Tools (TOOL) – Advanced tools decrease effort.

• Development Schedule (SCED) – Shorter schedules increase workload.
• Multisite Development (SITE) – Distributed teams require extra coordination.
• Required Development Flexibility (FLEX) – High flexibility reduces effort.

Each factor has an Effort Multiplier (EM) value that ranges from very low to very high based on its
impact. The EM values associated with these levels are as follows:

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

Cost Driver Very Low Low Nominal High Very High Extra High
Product Attributes
Required Software Reliability (RELY) 0.75 0.88 1.00 1.15 1.40 —
Database Size (DATA) — 0.94 1.00 1.08 1.16 —
Product Complexity (CPLX) 0.70 0.85 1.00 1.15 1.30 1.66
Computer Attributes
Execution Time Constraint (TIME) — — 1.00 1.11 1.30 1.66
Main Storage Constraint (STOR) — — 1.00 1.06 1.21 1.56
Platform Volatility (PVOL) 0.87 0.94 1.00 1.07 1.15 —
Personnel Attributes
Analyst Capability (ACAP) 1.46 1.19 1.00 0.86 0.71 —
Programmer Capability (PCAP) 1.42 1.17 1.00 0.86 0.70 —
Personnel Continuity (PCON) 1.29 1.12 1.00 0.90 0.81 —
Application Experience (APEX) 1.22 1.10 1.00 0.88 0.81 —
Project Attributes
Use of Software Tools (TOOL) 1.24 1.10 1.00 0.91 0.82 —
Development Schedule (SCED) 1.23 1.08 1.00 1.04 1.10 —
Multisite Development (SITE) 1.25 1.10 1.00 0.92 0.84 —
Required Development Flexibility (FLEX) 1.29 1.12 1.00 0.90 0.81 —

Example: Intermediate COCOMO Calculation

Scenario

A company is developing a Hospital Management System (HMS) with an estimated 100 KLOC. The
project is Semi-Detached, and cost drivers are considered.

Step 1: Basic Effort Calculation

Using Semi-Detached mode constants (a = 3.0, b = 1.12):

𝐸 = 3.0 × (100)1.12 = 396.6 𝑃𝑀

Step 2: Adjust for Cost Drivers

Assume the following cost drivers:

• High Complexity (CPLX) = 1.3

• Database Size (DATA) = 1.1
• Low Application Experience (APEX) = 1.2

Total Effort Adjustment Factor (EAF):

EAF = 1.3 × 1.1 × 1.2 = 1.716

Step 3: Adjust Final Effort

E = 396.6 × 1.716 = 680.7 PM

So, the adjusted effort for HMS is approximately 681 person-months.

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

2. Complete (Detailed) COCOMO Model

Overview

The Complete COCOMO model extends the Intermediate model by applying cost drivers at each phase
of the project (e.g., requirements, design, coding, testing). This provides more granular estimates and
helps in resource allocation.

Key Difference from Intermediate Model

• Instead of applying a single effort multiplier to the entire project, the complete model breaks
down the project into phases.
• Each phase has different cost drivers. For example:
o Design phase may have high complexity.
o Coding phase may have low programmer experience.
o Testing phase may have strict reliability requirements.

Phases in Complete COCOMO

A typical software project is divided into five phases:

1. Planning & Requirements (6%) – Understanding user needs.

2. System Design (16%) – Architectural design and UI prototyping.
3. Detailed Design (26%) – Module-level design.
4. Coding & Unit Testing (42%) – Writing code and individual testing.
5. Integration & Testing (10%) – Final testing and deployment.

Example: Complete COCOMO Calculation

Scenario

A Banking Software System is being developed with 200 KLOC in an Embedded mode. The
Intermediate model effort was calculated as 1500 person-months.

Step 1: Distribute Effort across Phases

Based on typical effort distribution:

• Planning & Requirements (6%) → 1500 × 0.06=90

• System Design (16%) → 1500 × 0.16=240
• Detailed Design (26%) → 1500 × 0.26=390
• Coding & Unit Testing (42%) → 1500 × 0.42=630
• Integration & Testing (10%) → 1500 × 0.10=150

Step 2: Apply Cost Drivers to Each Phase

• Planning phase requires high reliability → EM = 1.4

• Coding phase has low experience programmers → EM = 1.3

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

Adjusted Effort for Coding:

630 × 1.3 = 819 PM

Total effort after adjustments across all phases: ~1750 person-months.

COCOMO II Model
Introduction
COCOMO II (Constructive Cost Model II) is an enhanced version of COCOMO I, developed by Barry
Boehm in the 1990s. It was designed to improve effort and cost estimation for modern software projects,
addressing the limitations of COCOMO I. Unlike COCOMO I, which was primarily focused on traditional
waterfall projects, COCOMO II supports:

✅ Object-Oriented Development
✅ Agile and Iterative Models
✅ Commercial-Off-The-Shelf (COTS) Software
✅ Reused and Reengineered Code

Key Differences Between COCOMO I and COCOMO II

Feature COCOMO I COCOMO II

Development Approach Waterfall Model Supports Agile, Spiral, Iterative
Cost Drivers 15 factors 17 factors
Effort Calculation Based on KLOC Based on Functional Size & KLOC
Phases Basic, Intermediate, Complete Early Design, Post-Architecture, Reuse
Supports Reusability No Yes
Flexibility Fixed model More adaptable

Three Sub-models of COCOMO II

COCOMO II consists of three different models based on the stage of software development:

1. Application Composition Model (For Rapid Development)

• Used for prototype-based or GUI-driven applications.

• Uses object points instead of KLOC for estimation.
• Ideal for early-stage cost estimation.

Example:
A startup developing a mobile app prototype with a heavy focus on drag-and-drop GUI elements would
use this model.

2. Early Design Model (For Initial Estimations)

• Used before full system architecture is defined.

• Estimates are based on function points instead of KLOC.
• Uses a simplified set of cost drivers.

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

Example:
A company is developing a customer relationship management (CRM) system. Before finalizing the
design, it uses the Early Design Model to estimate the effort needed.

Equation:

Effort = A × (Size)^B × ∏EM

Where:

• A, B = Constants (varies by project type)

• Size = Function Points or KLOC
• EM = Cost Drivers (Effort Multipliers)

3. Post-Architecture Model (For Final Estimations)

• Used after detailed system architecture is ready.

• Incorporates 17 cost drivers affecting effort and cost.
• Similar to Intermediate COCOMO I but more advanced.

Example:
A banking software system has completed its design phase, and detailed requirements are available. The
company now uses the Post-Architecture Model to estimate coding, testing, and maintenance efforts.

Equation:

Effort=A × (Size)^B × ∏EM

Where, the values for A, B and EM are refined using modern software metrics.

Cost Drivers in COCOMO II

COCOMO II refines the cost drivers used in COCOMO I, increasing them to 17 effort multipliers across
five categories:

1. Product Factors

• Required Software Reliability (RELY)

• Database Size (DATA)
• Product Complexity (CPLX)
• Required Reusability (RUSE)
• Documentation Match to Life Cycle Needs (DOCU)

2. Platform Factors

• Execution Time Constraints (TIME)

• Storage Constraints (STOR)
• Platform Volatility (PVOL)

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

3. Personnel Factors

• Analyst Capability (ACAP)

• Programmer Capability (PCAP)
• Personnel Experience (PEXP)
• Personnel Continuity (PCON)

4. Project Factors

• Development Flexibility (FLEX)

• Risk Resolution (RESL)
• Team Cohesion (TEAM)
• Process Maturity (PMAT)

Each factor is assigned a value (Effort Multiplier - EM) between 0.5 (low impact) to 2.0 (high impact).

Advantages of COCOMO II

✅ Supports modern development methodologies (Agile, Spiral, Object-Oriented).

✅ Includes reuse and reengineering efforts.
✅ More accurate than COCOMO I due to refined cost drivers.
✅ Handles different software types (GUI, embedded, enterprise).

LOC (Lines of Code) Based Estimation

What is LOC?

Lines of Code (LOC) refers to the total number of non-comment, non-blank lines of source code written
in a software project. It is used to estimate effort, cost, and time required for development.

Effort Estimation Using LOC

Effort is calculated using the COCOMO (Constructive Cost Model) formula.

Example Calculation (Using Basic COCOMO Model)

A simple inventory management system is expected to have 25,000 LOC (i.e., 25 KLOC).

Using COCOMO for an organic project:

Effort = 2.4 × (25)^1.05

Effort = 2.4 × 27.57 = 66.16 Person-Months

Thus, around 66 person-months of effort is required to complete the project.

Limitations of LOC-Based Estimation

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

🚫 Does not consider complexity of the code.

🚫 Discourages code reuse (as more LOC = more effort).
🚫 Different languages have different LOC for the same functionality (e.g., Python vs. C).
🚫 Cannot be used in early development stages (as LOC is unknown).

Function Point (FP) Based Estimation

What is a Function Point (FP)?

A Function Point (FP) is a measure of the functionality provided to the user, rather than the number of
lines of code written. It is based on user requirements and system complexity.

Steps for FP-Based Estimation

1. Identify five components in the system:

o External Inputs (EI) → User inputs (e.g., login form)
o External Outputs (EO) → Reports, messages (e.g., invoices)
o External Inquiries (EQ) → Queries & searches (e.g., customer search)
o Internal Logical Files (ILF) → Internal database (e.g., student records)
o External Interface Files (EIF) → External database interaction
2. Assign weights (Low, Average, High) to each component based on complexity.

Component Low Average High

EI (External Inputs) 3 4 6
EO (External Outputs) 4 5 7
EQ (External Inquiries) 3 4 6
ILF (Internal Logical Files) 7 10 15
EIF (External Interface Files) 5 7 10

3. Compute Unadjusted Function Points (UFP)

UFP = (EI × weight) + (EO × weight) + (EQ × weight) + (ILF × weight) + (EIF × weight)

4. Apply Complexity Adjustment Factor (CAF) (based on 14 general system factors).

Each characteristic is rated on a scale of 0 to 5 based on its impact on the system:

• 0 → No influence
• 1 → Incidental
• 2 → Moderate
• 3 → Average
• 4 → Significant
• 5 → Strong

General System Characteristic (GSC) Description

1. Data Communications Does the system communicate with external devices or systems?
2. Distributed Data Processing Does the system require processing across multiple locations?
3. Performance Requirements Does the system have strict performance requirements?
4. Heavily Used Configuration Is the software expected to run on heavily used hardware?

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])

 lOMoARcPSD|31067622

5. Transaction Rate Does the system handle a high volume of transactions?

6. Online Data Entry Does the system require real-time data entry?
7. End-User Efficiency Does the system provide user-friendly features?
8. Online Update Does the system allow real-time updates to stored data?
9. Complex Processing Does the system have complex business rules?
10. Reusability Can software components be reused?
11. Installation Ease Is the software easy to install and configure?
12. Operational Ease Does the software require minimal training for operation?
13. Multiple Sites Is the system intended for multiple locations?
14. Facilitate Change How easy is it to modify the system after deployment?

5. Compute Adjusted Function Points (AFP)

AFP = UFP × (0.65 + (0.01 × CAF))

Example Calculation

A Library Management System has:

• 5 External Inputs (EI) (Low Complexity) → 5 × 3 = 15

• 4 External Outputs (EO) (Average Complexity) → 4 × 5 = 20
• 6 External Inquiries (EQ) (Low Complexity) → 6 × 3 = 18
• 3 Internal Logical Files (ILF) (High Complexity) → 3 × 15 = 45
• 2 External Interface Files (EIF) (Average Complexity) → 2 × 7 = 14

UFP = 15 + 20 + 18 + 45 + 14 = 112

Assume CAF = 30

AFP=112 × (0.65 + (0.01 × 30))

AFP = 112 × (0.65 + 0.30) = 112 × 0.95 = 106.4≈106 Function Points

Now, assuming Productivity Rate = 10 Hours/FP, the total effort required:

Effort = 106 × 10 = 1060 Hours

Downloaded by Rimmalapudi Srihari (sriharirimmalapudi1213@[Link])