Unit 1 Introduction to Software Engineering

1. Definition – Software Engineering is the systematic, disciplined, and quantifiable approach to

development, operation, and maintenance of software.
➤ Focuses on creating quality, maintainable, and scalable software.

2. Importance – Ensures cost-effective development with minimal errors and on-time delivery.
➤ Example: A banking application requires high security, so disciplined engineering prevents
critical failures.

3. Goal – To deliver software that satisfies user needs and business objectives.
➤ Example: A hospital management system must meet patient data and billing requirements
accurately.

4. Phases of Software Development –

1. Requirement Analysis

2. Design

3. Implementation

4. Testing

5. Deployment

6. Maintenance

Phases of Software Development Life Cycle (SDLC)

Requirement Analysis Phase

Definition:
It is the first phase of SDLC where the client’s needs are collected and analyzed to understand what
the software must do. The output is a detailed document known as the Software Requirement
Specification (SRS).

Example:
In an Online Shopping System, the requirement might be:

• “The user should be able to add products to the cart and make payments online.”

System Design Phase

 Definition:
In this phase, the system’s architecture and design are prepared based on the requirements. It
describes how the software will work internally — including data flow, database design, and user
interface layout.

Example:
For the shopping system:

• Designing a database with tables for Customers, Products, and Orders.

• Creating a login page layout for users.

Implementation (Coding) Phase

Definition:
This phase involves writing actual source code for all system modules as per the design document.
Programmers use suitable programming languages and follow coding standards.

Example:
Developers write Java code such as:

[Link]("Welcome to Online Shopping System!");

Testing Phase

Definition:
In this phase, the developed software is tested to find and fix defects. The goal is to ensure that the
software meets the requirements and works correctly under all conditions.

Example:
Testing whether the “Add to Cart” button correctly adds products and whether payments are
processed securely.

Deployment Phase

Definition:
The software is installed on the client’s system or released to end users. It may include pilot runs or
full production rollout depending on project size.
 Example:
Uploading the Online Shopping System to a live server so that customers can use it through a web
browser.

Maintenance Phase

Definition:
After deployment, the software enters the maintenance stage where bugs are fixed, updates are
made, and performance improvements are applied based on user feedback.

Example:
Adding a new feature like “Order Tracking” or fixing an issue where payment confirmation emails are
not sent.

Software Characteristics

1. Intangibility – Software cannot be physically touched; it’s logical and conceptual.

2. Complexity – Large systems may have millions of lines of code with interdependencies.

3. Flexibility – Software can easily be modified or updated.

4. No Wear & Tear – Software doesn’t degrade physically, but may fail due to bugs or
compatibility issues.

Example:
A word processor like MS Word doesn’t wear out, but may crash due to software bugs.

Software Myths and Software Crisis

1. Software Myths – Common misconceptions:

o “Once software is written, it’s done.”

o “Adding more programmers speeds up a delayed project.”

o “All requirements are known at the beginning.”

o “Software testing guarantees error-free systems.”

 2. Software Crisis – Term from 1960s describing difficulty in delivering error-free, maintainable
software on time.

3. Causes – Poor planning, changing requirements, inadequate testing.

4. Solution – Adoption of structured methods, SDLC models, and project management tools.

Software Process Models (SDLC Models)

1. Waterfall Model

o Linear and sequential phases (Requirement → Design → Code → Test → Deploy →

Maintain).

o Suitable for small, well-defined projects.

o Difficult to handle changing requirements.

2. Requirements → Design → Implementation → Testing → Deployment → Maintenance

3. Spiral Model

o Combines iterative development with risk analysis.

o Each loop represents a phase with planning, risk analysis, engineering, and evaluation.

o Best for large, high-risk projects.

4. Agile Model

o Iterative and incremental; focuses on customer collaboration and flexibility.

o Uses short cycles called Sprints.

o Example: Scrum, Kanban.

5. V-Model

o Verification and validation model mapping each development phase with its
corresponding testing phase.

o Ensures quality at every stage.

UNIT 2: Software Requirement Analysis and Specification

Requirement Engineering Process

1. Definition – Structured process of gathering, analyzing, documenting, and managing software

requirements.

2. Steps –

o Elicitation (finding what users need)

o Analysis (checking feasibility)

o Specification (documenting needs in SRS)

o Validation (ensuring correctness)

o Management (handling changes).

3. Goal – Understand “what” the software must do before deciding “how” to build it.

4. Example:
For an online food delivery app: Requirements include order tracking, payment gateway,
restaurant listing, etc.

Types of Requirements

1. Functional Requirements (FR):

o Define what the system should do.

o Example: “System shall allow user login using email and password.”

o Usually described as use cases or user stories.

2. Non-Functional Requirements (NFR):

o Define how the system performs functions.

o Examples: Performance, Security, Usability, Reliability.

o Example: “System shall handle 5000 users concurrently.”

3. Domain Requirements:

o Specific to the application domain.

o Example: Banking software must comply with RBI data regulations.

 4. Interface Requirements:

o Define how system interacts with other systems or hardware.

o Example: “System shall connect to payment gateway via REST API.”

Software Requirement Specification (SRS)

1. Definition – A formal document describing all system requirements clearly and precisely.

2. Purpose – Acts as a contract between client and developer.

3. Characteristics of a Good SRS – Complete, Consistent, Unambiguous, Verifiable, and Traceable.

4. Structure of SRS Document:

o Introduction

o Functional Requirements

o Non-Functional Requirements

o Interface Requirements

o Constraints and Assumptions

Example Snippet (SRS):

1.1 Purpose: Define a system for online course registration.

1.2 Functional Requirement: Users shall register and enroll in available courses.

1.3 Non-Functional Requirement: Response time should not exceed 2 seconds.

Requirements Elicitation & Validation Techniques

1. Elicitation Techniques

o Interviews: Direct interaction with stakeholders.

o Questionnaires: Collect responses from multiple users.

o Observation: Watch users perform current tasks.

o Document Analysis: Study existing manuals, forms, reports.

 o Prototyping: Create early system version to gather feedback.

2. Feasibility Study

o Evaluates whether the project is viable economically, technically, and operationally.

o Example: Checking if real-time tracking system is feasible with current hardware.

3. Requirement Validation & Verification

o Validation: Are we building the right product?

o Verification: Are we building the product right?

o Example: Validation through review meetings, Verification through testing.

4. Use Case Modeling

o Visual representation of interactions between user (actor) and system.

o Example:

o [User] ---> (Login)

o [User] ---> (Search Course)

o [Admin] ---> (Add Course)

o Helps identify functional requirements easily.

Summary Table

Concept Description Example

SDLC Framework for developing software Waterfall, Agile

Requirement Engineering Process of identifying system needs Login, performance, UI

Functional Req. System behavior “User can register”

Concept Description Example

Non-Functional Req. Quality attributes “System loads in 2s”

SRS Document of all requirements Formal contract

Elicitation Gathering user needs Interviews, Prototypes

Validation Building right product Review sessions