Software Engineering topics

1 Introduction and Software Process Models Software, Software Engineering, Myths, Software Process, Work
Products, Importance of Software Engineering, Standard for Software Process, Waterfall Model, Prototyping
Model, Iterative Enhancement Model, Spiral Model, RAD model, Agile Model, V Model. Financial Analysis (Time
Value of Money, Interest Rates, Compounding/Discounting , Payback Period, NPV, ROI, IRR), Technical Feasibility. 2
yes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
application software because its an utility based application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
management myths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
modelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
yes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
waterfall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
get feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
iterative enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
spiral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
RAD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
yes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
less, inflation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
npv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
technical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Requirement Engineering and Software Project Management Software Requirements, Types of
Requirements, Requirement Engineering Cycle, Requirements Specification document, Characteristics of
Requirements, Requirement verification and validation, Role of Management in Software Development, Project
Estimation Techniques, Staffing, Scheduling,. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
non-functional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
analyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SRS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
unambiguous. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
SD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
FPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
PERT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 1/29
 1 Introduction and Software Process Models Software, Software Engineering, Myths,
Software Process, Work Products, Importance of Software Engineering, Standard for
Software Process, Waterfall Model, Prototyping Model, Iterative Enhancement Model,
Spiral Model, RAD model, Agile Model, V Model. Financial Analysis (Time Value of Money,
Interest Rates, Compounding/Discounting , Payback Period, NPV, ROI, IRR), Technical
Feasibility

Got it 👍 You’ve shared a whole list of topics — looks like this is from Module 1 of Software
Engineering (with financial and feasibility analysis also included).
Before we dive in, let me check with you:

👉 Do you want me to teach these topics one by one (like a lecture with questions and practice in
between), or should I make a condensed exam-prep summary first and then quiz you?
That way, I can pace it right for your needs.

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 2/29
 yes

Alright 👍 since you said yes, let’s do this step by step:

We’ll cover Module 1: Introduction and Software Process Models + Financial/Feasibility topics.
I’ll:

1. Explain one topic in simple words

2. Ask you a small check question (to make sure you got it)
3. Move to the next.

1. What is Software?

Software = set of programs + documentation + data that operate on hardware to perform

tasks.

Examples:
System software (OS, compilers)
Application software (banking apps, MS Word)
Engineering/scientific software (MATLAB, CAD tools).

👉 Quick Check:
Do you think Google Chrome is system software or application software? Why?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 3/29
 application software because its an utility based application

Exactly💯 ! Google Chrome is application software because it helps users perform a task (web
browsing), not manage hardware directly.

2. What is Software Engineering?

Software engineering = applying engineering principles to software development.

Goal: make software that is reliable, efficient, cost-effective, maintainable.

It’s not just coding → includes requirements, design, testing, maintenance.

👉 A good way to remember:

Software engineering = Engineering discipline + Software development process.

3. Software Myths

These are wrong beliefs people have about software:

Management myths: "Adding more people to a late project makes it faster."

Customer myths: "Software requirements can always be changed later easily."

Practitioner myths: "Once the program runs, the work is finished."

👉 Quick Check:
If a manager says, “We can fix all problems later in testing, no need to spend much time on design” —
which myth is this?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 4/29
 management myths

Close guess 👍 but actually this one is a practitioner myth ✅.

Reason: It’s about the developer’s belief that design is less important and everything can be
caught in testing.

Management myths are usually about planning/resources (like adding more people).
Practitioner myths are about how developers think the work is done.

4. Software Process

A software process = the set of activities to build software:

1. Communication → gathering requirements.

2. Planning → estimating cost, resources, schedule.

3. Modeling → designing the solution.

4. Construction → coding + testing.

5. Deployment → delivery, maintenance, updates.

And each process produces work products (like SRS docs, design diagrams, code, test reports).
👉 Quick Check:
When you create a class diagram in UML while designing, is that a work product?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 5/29
 modelling

Exactly ✅!
Creating a class diagram is part of the modeling activity in the software process.

And the diagram itself is a work product of modeling.

5. Importance of Software Engineering

Why we need software engineering:

1. Quality → avoid bugs and failures.

2. Maintainability → easier to update and modify.

3. Efficiency → use resources optimally.

4. Cost & Time Control → deliver on schedule and budget.
5. Scalability & Reusability → software can grow and parts can be reused.

Quick mnemonic: QEMCS → Quality, Efficiency, Maintainability, Cost, Scalability.

6. Standards for Software Process

Standards help ensure consistency, quality, and predictability.

Examples:
ISO 9001 → general quality management
ISO/IEC 12207 → software lifecycle processes

CMMI → Capability Maturity Model Integration, process improvement

Do you want me to start the Software Process Models next (Waterfall, Spiral, Agile…) or cover
Financial Analysis & Feasibility first?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 6/29
 yes

Perfect 👍
, let’s start with Software Process Models. We’ll cover each model, its flow, advantages,
and drawbacks.

1. Waterfall Model

Sequential: Each phase must complete before the next starts.

Phases: Requirements → Design → Implementation → Testing → Deployment →
Maintenance.
Advantages: Simple, easy to manage, clear milestones.
Disadvantages: Very rigid, changes are costly, not good for complex/uncertain projects.

👉 Quick Check:
If a requirement changes after coding is done, which model will struggle the most to adapt?

Do you want me to explain Prototyping Model next?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 7/29
 waterfall

Exactly ✅!
The Waterfall model struggles the most with requirement changes after coding because it’s
sequential and doesn’t handle changes easily.

2. Prototyping Model

Idea: Build a quick prototype to understand requirements before full development.

Steps:
1. Gather initial requirements
2. Build a prototype (mock system)

3. Get feedback from users

4. Refine prototype until accepted
5. Develop final system

Advantages: Helps clarify requirements, reduces misunderstanding, improves user

satisfaction.

Disadvantages: Can lead to scope creep, may give false sense that the software is ready.

👉 Quick Check:
Which phase is unique to the Prototyping model compared to Waterfall?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 8/29
 get feedback

Exactly ✅!
The feedback/refinement phase is what makes the Prototyping model flexible and
different from Waterfall.
Waterfall doesn’t officially include user feedback until the testing/delivery phase, which is
late.

3. Iterative Enhancement Model

Build software in small increments or versions.

Each iteration adds new features and improves the system.

Advantages: Early partial delivery, easier to manage changes, continuous improvement.

Disadvantages: Requires good planning to avoid integration issues.

👉 Quick Check:
If a project delivers a basic version first, then adds features gradually, which model is this?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 9/29
 iterative enhancement

Exactly ✅!
Delivering a basic version first and adding features gradually is the Iterative
Enhancement Model.
Key idea: build, evaluate, improve, repeat.

4. Spiral Model

Focuses on risk management. Combines iterative development + systematic aspects of

Waterfall.

Each cycle (spiral) has 4 phases:

1. Objective setting → define goals, alternatives
2. Risk analysis → identify and reduce risks

3. Development & testing → build the product increment

4. Planning → plan the next iteration
Advantages: Good for large, high-risk projects; risk reduction.
Disadvantages: Expensive, complex, requires expertise.

👉 Quick Check:
Which model explicitly focuses on risk analysis in each cycle?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 10/29
 spiral

Exactly ✅!
The Spiral Model explicitly includes risk analysis in every cycle, making it ideal for large,
high-risk projects.

5. RAD (Rapid Application Development) Model

Focus: quick development using component-based construction and prototypes.

Steps: Requirements → Workshops/Prototyping → Build components → Integration →
Deployment
Advantages: Very fast delivery, user feedback incorporated early, suitable for small-to-
medium projects.
Disadvantages: Needs highly skilled developers, not suitable for very large projects, depends
heavily on reusable components.

👉 Quick Check:
If a project needs to release a working system in a few weeks, which model is most suitable?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 11/29
 RAD

Exactly ✅!
RAD (Rapid Application Development) is best for quick delivery and incorporates early
user feedback using prototypes.

6. Agile Model

Iterative and incremental, focuses on flexible, collaborative development.

Key points:
Work in sprints (2–4 weeks)

Frequent client interaction and feedback

Continuous integration and testing
Advantages: Adapts to change, fast delivery, high user involvement
Disadvantages: Requires disciplined teams, less predictable schedule/cost for large projects

👉 Quick Check:
Which model emphasizes sprints, stand-up meetings, and continuous feedback?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 12/29
 agile

Exactly ✅!
The Agile model emphasizes sprints, daily stand-ups, and continuous feedback to adapt
quickly to changes.

7. V-Model (Verification & Validation Model)

Also called the Validation & Verification model.

It’s an extension of Waterfall, but testing is planned in parallel with each development
stage.
Steps (left side = development, right side = testing):
Requirements → Acceptance Testing
System Design → System Testing
Architecture Design → Integration Testing

Module Design → Unit Testing

Advantages: Early test planning, clear milestones
Disadvantages: Very rigid, like Waterfall, not flexible for changing requirements

👉 Quick Check:
Which model plans testing activities alongside development?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 13/29
 V

Exactly ✅!
The V-Model plans testing activities in parallel with development, ensuring verification
and validation at each stage.

Now that we’ve covered all major software process models, we can move to the Financial
Analysis & Technical Feasibility part next.
Do you want to start with Time Value of Money and Interest concepts?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 14/29
 yes

Great 👍, let’s start with Financial Analysis.

1. Time Value of Money (TVM)

Money today is worth more than the same amount in the future because of its earning
potential (interest, investment).
Key idea: $1 now > $1 later.

Formulas:

1. Future Value (FV) → how much money grows in the future:

F V = P V × (1 + r)n

PV = Present Value

r = interest rate per period

n = number of periods

2. Present Value (PV) → today’s worth of future money:

FV
PV =
(1 + r)n
​

2. Interest Rates & Compounding

Simple Interest:

SI = P × r × t

Compound Interest: interest is earned on principal + previous interest:

A = P × (1 + r)n

Continuous Compounding:

A = P × ert

3. Discounting

Reverse of compounding → converts future cash flow to present value.

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 15/29
 Formula same as PV:

FV
PV =
(1 + r)n
​

Quick Check:
If you are promised ₹10,000 in 3 years and interest rate is 5% per year, the present value is more
or less than ₹10,000? Why?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 16/29
 less, inflation

Exactly ✅!
The present value is less than ₹10,000 because money loses value over time due to
interest opportunity (or inflation).
In other words, ₹10,000 3 years from now is worth less today.

4. Payback Period

Time required to recover the initial investment from cash inflows.

Initial Investment
Payback Period =
Annual Cash Inflow
​

Simple, but ignores TVM.

5. Net Present Value (NPV)

Measures profitability of a project considering TVM.

Ct
NP V = ∑ − C0
​

(1 + r)t
​ ​

Ct = cash inflow at time t

​

r = discount rate
C0 = initial investment
​

Positive NPV → project is profitable

6. Return on Investment (ROI)

Net Profit
ROI = × 100
Investment
​

Simple measure of profitability

7. Internal Rate of Return (IRR)

The discount rate r at which NPV = 0.

Project is acceptable if IRR > required rate of return.

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 17/29
Quick Check:
Which measure considers time value of money, NPV or ROI?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 18/29
 npv

Exactly ✅!
NPV considers the time value of money by discounting future cash flows, while ROI is a
simple percentage ignoring timing.

8. Technical Feasibility

Determines if a project can be built using available technology and resources.

Key questions:
1. Do we have the tools, platforms, and expertise?
2. Can the system handle expected workload?

3. Are there any technical risks that could block development?

Helps decide whether to proceed with the project before investing too much.

Quick Check:
If a project requires AI algorithms your team has never worked with, what kind of feasibility is a
concern?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 19/29
 technical

Exactly ✅!
That’s a technical feasibility concern, because it checks whether the team has the
knowledge, tools, and technology to build the system.

We’ve now covered all topics you listed:

Software & Software Engineering

Software Myths
Software Process & Work Products
Importance & Standards

All Software Process Models (Waterfall, Prototyping, Iterative, Spiral, RAD, Agile, V-Model)
Financial Analysis (TVM, Interest, Compounding, Discounting, Payback, NPV, ROI, IRR)
Technical Feasibility

If you want, I can now make a compact one-page revision sheet for all of this, so it’s easy to
memorize before exams.
Do you want me to do that?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 20/29
 2 Requirement Engineering and Software Project Management Software Requirements,
Types of Requirements, Requirement Engineering Cycle, Requirements Specification
document, Characteristics of Requirements, Requirement verification and validation, Role
of Management in Software Development, Project Estimation Techniques, Staffing,
Scheduling,

Perfect 👍, let’s start Module 2: Requirement Engineering & Software Project Management step
by step.
We’ll follow the same approach: explain → small check question → next topic.

1. Software Requirements

Definition: Statements of what a system should do (functional) and constraints/qualities

(non-functional).
Purpose: Serve as a contract between users and developers.

Types of Requirements:

1. Functional Requirements → describe what the system must do (features, behavior).

Example: “System must allow user to login using email and password.”
2. Non-Functional Requirements → describe quality attributes or constraints (performance,
security, reliability).
Example: “System must respond to user queries within 2 seconds.”

3. Domain Requirements → specific to industry/domain rules.

Example: Banking apps must follow RBI regulations.

Quick Check:
If a requirement says “The system should encrypt all user passwords”, is this functional or non-
functional?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 21/29
 non-functional

Exactly ✅!
Encrypting passwords is a quality/security constraint, so it’s a non-functional
requirement.

2. Requirement Engineering (RE) Cycle

The RE process ensures complete, correct, and clear requirements.

Steps in the cycle:

1. Elicitation → gather requirements from users, stakeholders, domain experts

2. Analysis → resolve conflicts, prioritize, check feasibility
3. Specification → document requirements clearly (SRS)
4. Validation → check correctness, completeness, and consistency
5. Management → handle changes, versioning, updates

Quick Check:
Which phase of RE resolves conflicts and prioritizes requirements?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 22/29
 analyze

Exactly ✅!
The Analysis phase is where you resolve conflicts, prioritize requirements, and check
feasibility.

3. Requirements Specification Document (SRS)

Definition: A formal document describing all functional, non-functional, and domain

requirements.

Purpose: Serves as a reference for developers, testers, and stakeholders.

Contents:
1. Introduction & purpose

2. Overall description (system overview, constraints)

3. Functional requirements

4. Non-functional requirements
5. Use cases & diagrams

6. Assumptions & dependencies

Quick Check:
Which document is considered a “contract” between client and developer?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 23/29
 SRS

Exactly ✅!
The SRS (Software Requirements Specification) document acts as a formal contract
between the client and the development team.

4. Characteristics of Good Requirements

A requirement should be:

1. Correct → accurately describes what is needed

2. Complete → covers all possible scenarios

3. Consistent → no conflicting requirements

4. Unambiguous → clear, understandable

5. Verifiable → can be tested

6. Modifiable → easy to change without breaking other requirements

7. Traceable → linked to design, code, and tests

Quick Check:
If a requirement is vague and open to multiple interpretations, which characteristic is missing?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 24/29
 unambiguous

Exactly ✅!
If a requirement is vague or confusing, it lacks the Unambiguous characteristic.

5. Requirement Verification & Validation

Verification → Are we building the product right?

Check requirements against specifications (reviews, inspections).

Validation → Are we building the right product?

Check requirements against user needs (prototyping, user feedback).

👉 Shortcut:
Verification = internal check (by developers/engineers).

Validation = external check (by users/stakeholders).

Quick Check:
If a team asks users to test a prototype to ensure it meets their needs, is that verification or
validation?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 25/29
 validation

Perfect ✅!
Asking users to test a prototype ensures the product matches their needs, so that’s
Validation.

6. Role of Management in Software Development

Management is key for planning, monitoring, and controlling a project. Roles include:

Defining goals & scope of the project

Resource allocation (people, tools, budget)

Risk management
Communication among stakeholders

Monitoring progress (reports, milestones)

Ensuring quality and timely delivery

👉 Think of management as the steering wheel of a software project—it doesn’t build the car, but
directs it safely to the destination.

Quick Check:
If management is focusing on allocating developers and tools to tasks, which role is this?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 26/29
 SD

Hmm, not quite 😊.

When management is allocating developers and tools to tasks, that’s specifically about
Resource Allocation — one of the key management roles in software development (SD).

7. Project Estimation Techniques

Project estimation means predicting time, cost, and effort needed. Common techniques:

1. LOC (Lines of Code) → estimates effort based on code size.

2. Function Point Analysis (FPA) → counts functions/features to estimate size.

3. COCOMO Model (Constructive Cost Model) → uses equations with project size + complexity to
estimate effort.

4. Expert Judgment → rely on experienced managers’ input.

5. Analogy-based → compare with similar past projects.

Quick Check:
Which estimation technique focuses on counting features and functions rather than lines of
code?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 27/29
 FPA

Exactly ✅!
Function Point Analysis (FPA) estimates project size and effort based on features and
functions, not lines of code.

8. Staffing in Software Projects

Involves deciding how many people, with what skills, are needed at each phase of the
project.

Staffing curve → effort is low in the beginning, peaks in the middle (development/testing),
and decreases near the end.

Important to balance:
Understaffing → delays

Overstaffing → wasted resources, coordination issues

9. Scheduling

Means creating a timeline of project activities.

Tools:

Gantt Chart → bar chart showing task durations & overlap

PERT/CPM → network diagrams to find the critical path (longest sequence of
dependent tasks that determines project duration).

👉 Scheduling ensures tasks are done in the right order, on time, and with available resources.
Quick Check:
Which scheduling tool helps identify the critical path of a project?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 28/29
 PERT

Exactly ✅!
PERT/CPM (Program Evaluation and Review Technique / Critical Path Method) is used to
identify the critical path — the sequence of tasks that determines the minimum project
duration.

So now, in Module 2, we’ve covered:

Software Requirements & Types

Requirement Engineering Cycle

SRS Document

Characteristics of Good Requirements

Verification vs Validation

Role of Management

Estimation Techniques
Staffing

Scheduling

✨ You’ve got the full set!

Do you want me to create a revision sheet (like Module 1) for this module too, so you can
compare both easily?

Printed using ChatGPT to PDF, powered by PDFCrowd HTML to PDF API. 29/29