🧩 Introduction to Software Engineering (Simplified

Notes)

🧠 What is Software?
Software is not just a program — it includes:

1.​ Programs – instructions that make the computer do specific tasks.​

2.​ Data – information that programs use.​

3.​ Documentation – manuals and guides for users and developers.​

4.​ Configuration data – files/settings needed for the software to run correctly.​

👉 In short:​
Software = Programs + Data + Documents

💻 Types of Software Products

1.​ Generic Products​

○​ Made for many customers.​

○​ Example: MS Word, Photoshop.​

2.​ Customized Products​

○​ Made for one specific customer or organization.​

○​ Example: Software for a specific bank or hospital.​

⚙️ What is Software Engineering?
Software Engineering is:

“The systematic and disciplined approach to designing, developing, testing, and

maintaining software.”

It applies engineering principles (like planning, design, testing, etc.) to make software that is:

●​ Reliable​

●​ Efficient​

●​ Maintainable​

●​ Cost-effective​

🎯 Why Learn Software Engineering?

Because it teaches how to:

●​ Build high-quality and error-free software.​

●​ Work in teams using systematic methods.​

●​ Manage large and complex projects.​

Software engineers can work as:

Developers, Test Engineers, Project Managers, Architects, Quality Engineers, or

Researchers.

💼 What Do Software Engineers Actually Do?

They don’t just code — only about 10% of time is spent coding.​
Other 90% includes:

●​ Gathering and writing requirements​

 ●​ Designing and documenting​

●​ Testing and debugging​

●​ Writing manuals​

●​ Attending meetings​

●​ Maintaining and improving software​

🧾 Characteristics (Qualities) of Good Software

Good software isn’t just about working — it must also be:

Quality Meaning (Simple)

Reliability Works correctly for a long time without crashing

Correctness Meets all the requirements exactly

Performance Works fast and efficiently

Usability Easy to use and user-friendly

Interoperability Works with other systems/software

Maintainability Easy to fix and update

Evolvability Can grow with new features

Repairability Easy to correct bugs

Portability Runs on different platforms easily

Verifiability Easy to test and check correctness

Traceability Every requirement can be traced from start to

end

💡 Reliability in Detail
 ●​ Means how dependable the software is.​

●​ A reliable system:​

○​ Has very few crashes.​

○​ Recovers from errors gracefully.​

○​ Has low downtime.​

Formula (concept):​
[​
r(t) = P(T > t)​
]​
Reliability = Probability that the system will run without failure for time t.

🧭 Note: In software, failures decrease over time as bugs are found and fixed.

⚖️ Correctness
●​ Software is correct if it behaves exactly as the requirements say.​

●​ Even a small deviation = incorrect.​

●​ Measured by number of defects or failures found.​

⚡ Performance
●​ Measures how fast and efficient the system is.​

●​ Example:​

○​ ATM must process transactions within 5 seconds.​

○​ A system should handle 100 users at once.​

👩‍💻 Usability
●​ How easy it is for a user to learn and use the software.​

●​ Measured by user feedback, surveys, and error rates.​

🔗 Interoperability
●​ Software’s ability to work with other systems.​

●​ Achieved through:​

○​ Standards​

○​ Middleware​

○​ APIs​

Example: A hospital system talking to a pharmacy system.

🔧 Maintainability, Evolvability & Repairability

●​ Maintainability: Easy to update and manage.​

●​ Evolvability: Easy to add new features.​

●​ Repairability: Easy to fix bugs.​

Well-designed and modular code improves maintainability.

🌍 Portability
●​ Software can easily run on different hardware or operating systems.​

●​ Example: A game that runs on Windows, Linux, and Mac.​

🧩 Verifiability
●​ Easy to test whether software meets its goals.​

●​ Achieved through:​

○​ Modular design​

○​ Documentation​

○​ Testing code and metrics​

🔍 Traceability
●​ Ability to trace each requirement throughout the development process — from analysis
to final code.​

●​ Ensures nothing is missed and everything can be verified.​

🚫 Negative Qualities (Things to Avoid)

Negative Quality Meaning

Fragility One change breaks other parts of code

Immobility Code is hard to reuse

Needless Over-complicated design (“gold plating”)

complexity

Needless repetition Copy-paste code everywhere

Opacity Code is unclear

Rigidity Hard to change because of too many

dependencies

Viscosity Easier to do wrong fix than the proper one

✅ In short:
“Good software = Reliable + Maintainable + Efficient + Usable + Portable +
Traceable”

🧩 Software System Life Cycle (Simplified Notes)

Building software sounds simple —

“Take an idea and turn it into a useful program.”

But in reality, many things can go wrong —

●​ Developers may misunderstand what users need.​

●​ The program might have bugs.​

●​ It may be hard to fix or upgrade later.​

That’s why we follow a Software Engineering Life Cycle (SDLC) —​

It helps make software usable, reliable, and delivered on time.

🔄 Phases of Software Life Cycle

1.​ Requirements Gathering (Analysis)​

2.​ Design (High-level & Low-level)​

3.​ Development (Coding)​

4.​ Testing​

5.​ Deployment (Implementation)​

6.​ Maintenance​
🧾 1️⃣ Requirements Gathering (Analysis)
📘 Meaning:​
Understanding what the customer wants and needs before building the software.

“No big project can succeed without a plan.”

The plan explains:

●​ What to build​

●​ When to build​

●​ How long it will take​

●​ What the goals are​

📌 Purpose:​
To collect requirements → convert them into a clear Requirements Document.

💡 Throughout the project, these requirements act as a roadmap for developers and
customers.

✅ Characteristics of Good Requirements

Quality Meaning

Clear Easy to understand and not confusing

Unambiguou Only one possible meaning

s

Consistent No contradictions between requirements

Prioritized Important features come first

Verifiable Can be tested to check if implemented

correctly

📊 MOSCOW Method (for Prioritizing Features)

Letter Meaning Example

M - Must Essential features Login system

S- Important but not critical Profile picture

Should

C - Could Nice to have Dark mode

W - Won’t Not in this version AI assistant

📂 Requirement Categories
Type Description

Business Requirements High-level project goals

User Requirements What users expect (stakeholder view)

 Functional Requirements What the system does (features)

Non-Functional Requirements How the system behaves (speed, security,

reliability)

Implementation Temporary or transition needs during system

Requirements change

🧠 2️⃣ Design Phase

Once requirements are ready, we design a blueprint of the system.

“Design translates requirements into a structure that developers can build.”

🧩 Why Design is Important

●​ Ensures quality and clarity​

●​ Defines how the system will be built​

●​ Reduces future errors​

⭐ Quality Attributes (FURPS Model)

Letter Meaning Explanation

F – Functionality What the system does Features,

security
U – Usability Easy to use Interface design

R – Reliability Works correctly over time Error handling

P – Performance Speed and efficiency Response time

S – Supportability Easy to fix and extend Maintainability

🧱 Types of Design
🔹 High-Level Design (HLD)
●​ Focuses on what the system does.​

●​ Includes architecture, data design, modules, and interactions.​

●​ Example: Dividing project into modules like Login, Dashboard, Reports.​

🔹 Low-Level Design (LLD)

●​ Focuses on how each module works internally.​

●​ Defines algorithms, logic, and data structures for each part.​

HLD = “What to do”​

LLD = “How to do it”

🧩 Good Design Principles

🔸 Modularity
●​ Breaking system into small, independent modules.​
 ●​ Each module does one clear job.​

🔸 Cohesion
●​ How closely related the tasks inside a module are.​

●​ High cohesion = Good design​

Types of Cohesion (from weak → strong):

1.​ Coincidental​

2.​ Logical​

3.​ Temporal​

4.​ Procedural​

5.​ Communicational​

6.​ Sequential​

7.​ Functional ✅ (Best)​

🔸 Coupling
●​ How dependent modules are on each other.​

●​ Low coupling = Good design​

Types of Coupling (from low → high):

1.​ No coupling​

2.​ Data coupling​

3.​ Stamp coupling​

4.​ Control coupling​

5.​ Common coupling​

 6.​ Content coupling ❌ (Worst)​

📦 Parnas Partitioning (Information Hiding)

●​ Hide details that might change later.​

●​ Other modules only see what it does, not how it does it.​

●​ Makes updates easier and safer.​

💻 3️⃣ Development (Coding)

“Now the programmers bring the design to life.”

🔹 Activities in Development
●​ Writing and refining code​

●​ Testing code as they build​

●​ Managing versions (configuration control)​

●​ Documenting changes and problems​

●​ Following coding standards​

🔹 Refactoring
Improving code internally (structure, readability) without changing what it does.

Benefits:​
✔ Easier to read​
✔ Fewer bugs​
✔ Faster performance
🧪 4️⃣ Testing Phase
“Testing improves quality — even bad testing helps!”

🧾 Purpose of Testing
●​ Find bugs and errors​

●​ Check if software meets requirements​

●​ Build trust that it works correctly​

⚖️ Verification vs Validation
Term Question Meaning

Verification “Am I building the product right?” Checking design & code against
requirements

Validation “Am I building the right product?” Checking final system against user needs

🧰 Basic Principles
●​ Every test must trace to a requirement​

●​ Plan tests early​

●​ 80/20 rule: 80% of bugs from 20% of code​

●​ Start small (unit tests) → move to large (system tests)​

●​ Independent testers are preferred​

●​ Stop testing when no new bugs are found or time runs out​
🧩 Levels / Types of Testing
🧱 1. Unit Testing
Tests each small piece of code (class, function, module).

🔸 Black Box Testing

●​ Test inputs and outputs only (don’t look inside the code).​

●​ Examples:​

○​ Exhaustive Testing​

○​ Boundary Value Testing​

○​ Random Testing​

○​ Equivalence Class Testing​

🔸 White Box Testing

●​ Tests the internal logic of code.​

●​ Examples:​

○​ DD Path Testing​

○​ DU Path Testing​

○​ McCabe’s Method​

○​ Code Inspections​

🔗 2. Integration Testing
Tests how modules work together.

●​ Top-Down Testing: Start with main system → add modules below​

 ●​ Bottom-Up Testing: Start with components → build upward​

●​ Sandwich / Pair-wise / Interface Testing: Mixed approaches​

🧩 3. System Testing
Tests the entire software end-to-end.

Includes:

●​ Functional Testing​

●​ Performance Testing​

●​ Stress & Recovery Testing​

●​ Compatibility Testing​

●​ Security Testing​

●​ Installation Testing​

●​ Accessibility Testing​

✅ 4. Acceptance Testing
Checks if the final product meets customer needs.

●​ Alpha Testing: Done by users at developer’s site.​

●​ Beta Testing: Done by users at their own site.​

⚙️ 5. Regression Testing
After code changes, retest the whole system to ensure nothing else broke.
🧭 When to Stop Testing
1.​ No new bugs found​

2.​ Time or budget ends​

3.​ Test coverage complete​

4.​ Reaching point of diminishing returns​

5.​ All critical faults fixed​

🚀 5️⃣ Deployment (Implementation)

“Delivering software to the user.”

Deployment means installing the system in the real environment.

💡 Key Issues
1.​ Business Process: Customer must adapt workflow​

2.​ Training: Users must know how to use it​

3.​ Deployment Steps: Installation, configuration​

4.​ Equipment: Hardware compatibility​

5.​ Expertise: Technical support needed​

6.​ Integration: Should work with other systems​

🛠️ 6️⃣ Maintenance Phase

“Software never really finishes — it evolves.”

After delivery, users will find:

 ●​ Bugs 🐞​
●​ Need for improvements​

●​ New feature requests​

This is where maintenance begins.

🔧 Types of Maintenance
Type Meaning

Corrective Fixing bugs or errors

Perfective Adding improvements or new features

Adaptive Changing system for new environments (e.g., OS

upgrade)

Preventiv Code clean-up and restructuring to avoid future problems

e

🔁 Re-engineering
When old systems become hard to maintain — we transform or redesign them for better
performance and longer life.

🏁 Summary Table
 Phase Purpose

Requirement Understand what to build

s

Design Plan how to build it

Development Write and test code

Testing Ensure quality and correctness

Deployment Deliver to users

Maintenance Fix, improve, and adapt software

🧩 PLANNING PHASE OVERVIEW

🎯 Project Planning Objective
●​ Provides a framework for estimating resources, cost, and schedule.​

●​ Must include best-case and worst-case scenarios.​

●​ Should be adapted and updated throughout the project lifecycle.​

📘 Software Scope
 ●​ Defines functions, features, inputs/outputs, and constraints.​

●​ Two techniques to define scope:​

1.​ Narrative description after communicating with stakeholders.​

2.​ Use cases developed by end users.​

●​ Used to evaluate functions for estimation.​

💰 Cost Estimation Models

●​ A method to predict financial effort required to develop and test software.​

Types:

1.​ Empirical Estimation​

○​ Uses empirical (historical) data and formulas.​

○​ Based on previous projects, assumptions, and guesses.​

○​ Example: COCOMO model.​

2.​ Heuristic Estimation​

○​ Uses practical problem-solving shortcuts.​

○​ Flexible and helps in quick decision-making.​

○​ Relates project parameters using mathematical equations.​

3.​ Analytical Estimation​

○​ Breaks down tasks into component operations.​

○​ Uses standard times or expert judgment.​

○​ Based on basic assumptions about the project.​

⚙️ COCOMO (Constructive Cost Model)
●​ Developed by Barry W. Boehm.​

●​ Regression-based model using Lines of Code (LOC).​

●​ Used to estimate effort, cost, time, and quality.​

Levels:

1.​ Basic – uses only LOC.​

2.​ Intermediate – adds 15 cost drivers.​

3.​ Advanced – allows phase-based and component-level adjustments.​

Development Modes:

Mode Description

Organic (Simple) Small, simple projects, experienced team, flexible

requirements.

Semi-detached Medium projects, mixed experience, semi-rigid requirements.

Embedded Large, complex systems with hardware/software constraints.

Basic COCOMO Formula:

[​
Effort = a \times (KLOC)^b​
]​
Where:
 ●​ a and b are constants depending on development mode.​

●​ Effort measured in person-months.​

Example Problem:

Calculate effort for an embedded project of 60 KLOC​

Cost drivers: Product - Low, Computer - High, Personnel - Nominal, Project - High.​
(Would use the Intermediate COCOMO formula with driver multipliers to compute
effort.)

🚀 COCOMO II
●​ Evolved version of original COCOMO.​

●​ Uses Object Points, Function Points, or Lines of Code for sizing.​

Object Points represent:

1.​ Screens​

2.​ Reports​

3.​ Components​

Each classified as:

●​ Simple, Medium, or Difficult (based on data tables and complexity).​

Adjusted Object Points:

[​
NOP = (Object\ Points) \times (1 - \frac{%Reuse}{100})​
]

👥 Software Project Staffing

Definition:
Filling and maintaining project positions with qualified personnel.

Major Issues:

1.​ Managers chosen for technical, not managerial, skills.​

2.​ Productivity varies widely among individuals.​

3.​ Lack of trained graduates in software management.​

4.​ Poor training and development programs.​

🧠 Staffing Factors
Factor Considerations

Education Minimum qualification and potential for growth.

Experience Relevant and sufficient experience.

Training Knowledge of language, tools, and domain.

Motivation Willingness and enthusiasm to perform.

Commitment Loyalty to project and organization.

Self-Motivation Ability to work independently.

Group Affinity Compatibility with team.

 Intelligence Ability to learn and adapt.

🧾 Sources of Qualified Individuals

1.​ Transfers within the project.​

2.​ Transfers from other projects.​

3.​ New hires from other companies.​

4.​ Campus recruitment or referrals.​

5.​ Hire motivated trainees and provide training.​

📋 Personnel Planning
●​ Assigning the right people to the right tasks.​

●​ Matching capabilities with project goals.​

Iterative Development :

Iterative development means building software step by step, improving it with each step
(called an iteration).

Here’s how it works 👇

1.​ Start small:​
You don’t try to build the entire software at once.​
Instead, you build a small part that works and is useful — even if it’s not complete.​

2.​ Get feedback:​

After building that small part, you show it to users or the team, get their feedback, and
see what needs to be improved.​
 3.​ Improve and repeat:​
You then refine what you’ve built and add new features in the next iteration.​
Each iteration gives you a better and more complete version of the software.​

4.​ End result:​

After several iterations, you end up with a fully developed, well-tested, and
user-approved software product.​

🌀 Example:
Imagine you’re building a mobile app for a coffee shop ☕:
●​ Iteration 1: Build a simple app that just shows the menu.​

●​ Iteration 2: Add an option to order coffee online.​

●​ Iteration 3: Add a payment system.​

●​ Iteration 4: Add customer reviews and loyalty points.​

At each step, users can test the app and suggest improvements before the next update.

✅ Advantages:
●​ You find and fix problems early.​

●​ Easier to adapt to changing requirements.​

●​ Users can see progress quickly.​

●​ Better quality and satisfaction since you improve continuously.​

⚠️ Disadvantages:
●​ Needs regular feedback and user involvement.​
 ●​ Planning is a bit flexible, not fixed.​

●​ Can take more management effort to track iterations.​

In short:

Iterative development = Build → Test → Get feedback → Improve → Repeat​

It’s like learning by doing — you make progress with every round.

👍
👇
Perfect — here’s your Module 1: Software Requirements Specification (SRS) notes
rewritten in a simple, clear, and exam-friendly way

🧩 Module 1 – Software Requirements

Specification (SRS)

🧠 What is Software Requirement Specification (SRS)?

●​ A requirement means what the software should do.​

●​ An SRS is a document that describes what the system should do — not how it will do
it.​

●​ It captures both functional (what the system does) and non-functional (how it
performs) requirements.​

●​ SRS provides a complete description of system behavior for designers and

developers.​

🎯 Purpose of SRS
 ●​ To understand what the client wants clearly.​

●​ To serve as a contract between customer and developer.​

●​ To validate, analyze, and verify the system requirements.​

●​ Helps in estimating cost, effort, and future maintenance.​

⚙️ Requirements Engineering Activities

Requirements Engineering = The process of finding, documenting, and managing software
needs.

Steps:

1.​ Requirements Elicitation → Collecting requirements from stakeholders (through

interviews, surveys, etc.)​

2.​ Requirements Analysis → Checking for missing, conflicting, or unclear requirements.​

3.​ Requirements Specification → Writing the requirements clearly in the SRS document.​

4.​ Requirements Validation → Making sure the requirements match user needs.​

5.​ Requirements Management → Controlling and tracking any changes in requirements.​

🧾 Types of Software Requirements

1. User Requirements

●​ Written in simple language for clients/users.​

●​ Describes what the user expects from the system.​

2. System Requirements
 ●​ More detailed and technical version of user requirements.​

●​ Acts as a contract between the client and the development team.​

3. Software Design Specifications

●​ The most detailed level — used by programmers and designers.​

⚖️ Functional vs Non-Functional Requirements

Type Description Examples

Functional What the system should do Login, Register, Generate

Reports

Non-Functional How the system should Speed, Security, Reliability

perform

🔹 Functional Requirements Include:

●​ Interface specifications: How system connects with others.​

●​ Performance requirements: Response time, speed, etc.​

●​ System attributes: Security, reliability, availability.​

●​ Database requirements: Data storage, relationships, retention, etc.​

🔹 Non-Functional Requirements Include:

●​ Domain requirements: Industry rules (e.g., airline ticket standards).​
 ●​ Design constraints: Technology or hardware limitations.​

💡 Feasibility Study
Before building the software, we must check if it’s possible and worthwhile.

It checks:

1.​ Does the system meet business goals?​

2.​ Can it be built with current technology?​

3.​ Can it be done within budget and time?​

4.​ Can it work with existing systems?​

Questions answered:

●​ What happens if we don’t build it?​

●​ What problems exist now?​

●​ How will the new system help?​

●​ What new skills or facilities are needed?​

👥 Requirements Elicitation Techniques

1. Joint Application Design (JAD)

●​ Structured group meetings between users and developers.​

●​ Conducted over 1–2 weeks.​

●​ Used for gathering requirements, designing systems, and planning tests.​

Rules for JAD:

●​ Stick to the agenda​

●​ Stay on schedule​

●​ Avoid jargon​

●​ Resolve conflicts​

●​ Encourage participation​

2. Quality Function Deployment (QFD)

●​ Developed in Japan by Yoji Akao.​

●​ Focuses on the Voice of the Customer (VOC).​

●​ Uses a matrix (called the “House of Quality”) to relate customer needs with technical
requirements.​

Advantages:

●​ Improves user involvement​

●​ Reduces development time​

●​ Prevents loss of customer information​

3. Designer as Apprentice

●​ The requirements engineer “learns by observing” how users work.​

●​ Like an apprentice watching a master craftsman.​

●​ Helps the designer deeply understand user workflow, challenges, and environment.​
🔷 Requirements Modeling
●​ Modeling means representing requirements visually or mathematically.​

●​ Can use:​

○​ Natural language (simple English)​

○​ Use case diagrams​

○​ User stories​

○​ Flowcharts or structured diagrams​

🎭 Use Cases
●​ Describe how users interact with the system.​

●​ A use case diagram shows:​

○​ System (box)​

○​ Actors (stick figures)​

○​ Use cases (ovals showing actions)​

Example:​
Actor → “Student”​
Use Case → “Register for Exam”

Each use case includes:

●​ Scenarios (how the process happens)​

●​ Preconditions (what must be true before)​

●​ Postconditions (what happens after)​

✍️ User Stories (Used in Agile/Scrum)
●​ Short, simple descriptions written by users.​

●​ Used for initial requirement discovery and planning.​

Format:

As a [user type], I want to [goal], so that [reason].

Example:

As a student, I want to view my marks, so that I can track my performance.

In Scrum:

●​ All user stories are stored in the Product Backlog.​

●​ Developers select stories for each Sprint (short development cycle).​

📘 Requirements Documentation (SRS Document)

●​ The official record of what to build.​

●​ Used by customers, developers, testers, and managers.​

Characteristics of a Good SRS

Quality Description

Clear Easy to read and understand

Unambiguou Only one possible meaning
s

Complete Covers everything needed

Consistent No contradictions

Ranked Prioritized by importance

Verifiable Can be tested

Modifiable Easy to change

Traceable Linked to design and testing

stages

🧩 Requirement Categories
Category Description

Business Requirements Overall business goals and purpose

User Requirements What end users need or expect

Functional Requirements Specific features and actions

 Non-Functional Requirements Quality aspects like speed, security, etc.

Implementation Temporary setup or migration

Requirements requirements

🗣️ Gathering Requirements
To collect good requirements:

1.​ Listen carefully to customers.​

2.​ Use Brainstorming sessions for ideas.​

3.​ Apply Five Ws and One H:​

○​ Who → uses the system​

○​ What → needs to be done​

○​ When → it will be used​

○​ Where → location of use​

○​ Why → purpose or benefit​

○​ How → possible ways to achieve it​

📝 How to Write an SRS Document (Step-by-Step)

1. Define Purpose (Outline)

Include:

1.​ Introduction​
 ○​ Purpose​

○​ Intended audience​

○​ Scope​

○​ Definitions​

2.​ Overall Description​

○​ User needs​

○​ Assumptions and dependencies​

3.​ System Features and Requirements​

○​ Functional​

○​ Non-functional​

○​ Interface details​

2. Define Product Purpose

●​ Who will use it?​

●​ What are the business goals?​

●​ Define all terms and acronyms clearly.​

3. Describe What You Will Build

●​ Explain why and for whom the product is being built.​

●​ Define user needs, assumptions, and dependencies.​

4. Detail All Requirements

(a) Functional Requirements:

●​ What the system must do (e.g., login, report generation)​

(b) External Interface Requirements:

●​ How the system connects with users, hardware, or other software.​

(c) Non-Functional Requirements:

●​ Speed, security, usability, performance, scalability, etc.​

5. Deliver for Approval

●​ Review the SRS with all stakeholders (developers, testers, clients).​

●​ Get formal approval before starting development.​

✅ In Short Summary:
SRS = A detailed document that explains WHAT the software will do and WHY,
not HOW.​
It ensures clarity, understanding, and agreement between developers and
clients.