SOFTWARE ENGINEERING

Complete Study Notes

Exam Preparation — All Questions Covered

SECTION A — SHORT QUESTIONS (Page 0)

Q1: What is Software / Nature of Software?

Q2: What is Software Engineering / Overview?

Q3: Requirement Engineering Process / SRS Structure

Q4: Functional and Non-Functional Requirements

Q5: Verification and Validation

Q6: Use Case Diagram in UML

Q7: Agile Development Techniques / Methods

SECTION B — LONG QUESTIONS (Page 1)

Q1: SDLC Process (All 12 Stages)

Q2: Software Development Models/Paradigms

Q3: Agile Model / Agile Software Development Practices

Q4: Agile Development Techniques / Methods

SECTION A — SHORT QUESTIONS

Q1. What is Software? / Nature of Software

Definition:
Software is a set of programs, instructions, and data that tells a computer what to do. It is not a physical
thing — you cannot touch it. Software controls hardware and provides a way for users to interact with the
computer system.

Key Features (Nature of Software):

• Software is developed/engineered, not manufactured like physical products.
• Software does not wear out over time like hardware.
• Software can be copied easily without loss of quality.
• Software is complex — even small programs can have millions of lines of code.
• Software requires maintenance to fix bugs and update features.
• Software is intangible — it has no physical presence.

Example:
Microsoft Word, WhatsApp, Android OS, and a banking app are all examples of software.

Q2. What is Software Engineering? / Overview of Software Engineering

Definition:
Software Engineering is the systematic application of engineering principles to the design, development,
testing, and maintenance of software. The goal is to produce high-quality software on time and within
budget.

Key Features:
• It follows a structured process (SDLC) to build software.
• It focuses on quality, reliability, and maintainability.
• Uses tools, techniques, and methods to manage the software process.
• Applies both computer science and engineering principles.
• Involves teamwork, project management, and documentation.

Example:
Building an e-commerce website like Amazon involves software engineering: gathering requirements,
designing the system, coding it, testing it, and then deploying it for users.

Q3. Requirement Engineering Process / SRS and SRS Structure

Definition:
Requirement Engineering is the process of finding out, documenting, and managing the needs
(requirements) of a software system. It ensures the software does exactly what the user wants.

Steps in Requirement Engineering:

 • Elicitation — Gathering requirements from users, interviews, surveys.
• Analysis — Understanding and resolving conflicts in requirements.
• Specification — Writing requirements in a clear document (SRS).
• Validation — Confirming requirements are correct and complete.
• Management — Tracking changes to requirements over time.

What is SRS (Software Requirement Specification)?

SRS is a document that clearly describes what the software must do. It is created after gathering all
requirements and serves as a contract between the development team and the client.

SRS Structure:
• Introduction (purpose, scope, definitions)
• Overall Description (product overview, user characteristics)
• Functional Requirements (what the system must do)
• Non-Functional Requirements (performance, security, reliability)
• External Interface Requirements (UI, hardware, software interfaces)
• Constraints and Assumptions

Example:
For a hospital app, the SRS would list requirements like: 'The system must allow doctors to view patient
records' (functional) and 'The system must load patient data within 2 seconds' (non-functional).

Q4. Functional and Non-Functional Requirements

Functional Requirements — Definition:
Functional requirements describe WHAT the system should do — the specific features and functions the
software must perform.

Key Features:
• Describe specific behavior or functions.
• Directly visible to the user.
• Can be tested by running the feature.
• Defined in use cases and user stories.

Examples:
• User should be able to log in with email and password.
• The system must send an email confirmation after registration.
• Admin can delete any user account.

Non-Functional Requirements — Definition:

Non-functional requirements describe HOW the system should work — the quality and performance
standards the software must meet.

Key Features:
• Define performance, security, reliability, usability.
• Not directly visible as features but critical to system quality.
• Harder to test but very important.
 • Include constraints like speed, capacity, and availability.

Examples:
• The app must load within 3 seconds (Performance).
• The system must be available 99.9% of the time (Reliability).
• All passwords must be encrypted (Security).
• The system must support 10,000 simultaneous users (Scalability).

Q5. Verification and Validation

Verification — Definition:
Verification checks whether we are building the software correctly. It checks that the software matches its
design and specifications. The key question is: 'Are we building the product right?'

Key Features:
• Done during development (not just at the end).
• Involves reviews, walkthroughs, inspections.
• Checks code, design documents, and test plans.
• Does not involve running the actual software.

Example:
Code review, design inspection, checking that the code follows the design document.

Validation — Definition:
Validation checks whether we have built the right software. It ensures the software meets the actual needs
of the user. The key question is: 'Are we building the right product?'

Key Features:
• Done at the end or during testing.
• Involves running the actual software.
• Checks if software matches user requirements.
• Includes system testing, acceptance testing, user testing.

Example:
User acceptance testing (UAT), running the software to see if it does what the user wanted.

Easy Memory Trick:

Verification = Correct process (right way) | Validation = Correct product (right thing)

Q6. Use Case Diagram in UML for Software Engineering

Definition:
A Use Case Diagram is a visual representation (diagram) in UML (Unified Modeling Language) that shows
how users (actors) interact with a system. It describes what a system does, not how it does it.

Key Components:
• Actor — A person or external system that interacts with the software (shown as a stick figure).
 • Use Case — A specific function or action the system can perform (shown as an oval).
• System Boundary — A box that shows what is inside the system.
• Association — A line connecting actor to use case.
• Include — One use case always calls another use case.
• Extend — One use case optionally calls another use case.

Why Use Case Diagrams are Important:

• They help communicate requirements between users and developers.
• Easy to understand even for non-technical people.
• Help identify all the features the system needs.

Example:
For an ATM system: Actors = Customer, Bank. Use Cases = Withdraw Money, Check Balance, Deposit
Money, Change PIN.

Q7. Agile Development Techniques / Methods

Definition:
Agile development techniques are flexible, iterative methods of building software. Instead of building the
whole system at once, Agile builds it in small pieces (sprints/iterations) with continuous feedback from the
customer.

Key Agile Methods:

• Scrum — Work is divided into sprints (2-4 weeks). Team has daily stand-up meetings.
• XP (Extreme Programming) — Focus on coding quality: pair programming, test-driven development.
• Kanban — Visual board showing tasks in 'To Do', 'In Progress', 'Done' columns.
• DSDM — Dynamic Systems Development Method — timeboxed delivery.
• Crystal — Lightweight method focused on team communication.
• FDD (Feature Driven Development) — Build features one by one.

Example:
A company uses Scrum to build a mobile app. In each 2-week sprint, the team delivers a working feature
like 'user login', then 'product search', then 'checkout'.
SECTION B — LONG QUESTIONS

Q1. SDLC Process (Software Development Life Cycle)

What is SDLC?
SDLC (Software Development Life Cycle) is a well-defined, structured sequence of stages used by the
software industry to design, develop, and test high-quality software. The goal is to produce software that
meets or exceeds customer expectations, completed on time and within cost estimates.

SDLC Activities / 12 Stages:

Stage 1: Communication
This is the very first step. The user contacts the service provider to request software. They negotiate terms
and submit their request in writing.

Stage 2: Requirement Gathering

The development team collects detailed requirements from all stakeholders. Requirements are gathered
through interviews, questionnaires, studying existing systems, and database reference. They are divided
into user, system, and functional requirements.

Stage 3: Feasibility Study

The team studies whether the software can be built to meet all requirements. They check if the project is
financially, practically, and technologically feasible. Algorithms help conclude the feasibility of the project.

Stage 4: System Analysis

Developers decide the roadmap and select the best software model. This includes understanding
limitations, identifying impacts on organization, planning schedule, and allocating resources.

Stage 5: Software Design

All gathered knowledge is converted into a software design. The output is two designs: Logical Design
(what the system does) and Physical Design (how the system does it). Engineers produce data flow
diagrams, logical diagrams, and sometimes pseudo codes.

Stage 6: Coding
This is the programming phase. Software design is implemented as program code in a suitable
programming language (C, C++, Java, PHP, etc.). The goal is to write error-free, executable programs
efficiently.

Stage 7: Testing
About 50% of development time should be spent on testing. Testing is done at module level, program
level, product level, and user level. Early discovery of errors is the key to reliable software.

Stage 8: Integration
The software may need to connect with libraries, databases, and other programs. This stage integrates the
software with all external world entities.

Stage 9: Implementation
This means installing the software on user machines. Software is tested for portability and adaptability.
Post-installation configurations are done at the user's end.
Stage 10: Operations and Maintenance
This phase confirms the software works efficiently with fewer errors. Users are trained, and software is
updated regularly. This phase faces challenges from hidden bugs and real-world problems.

Stage 11: Documentation

All processes, designs, code, and user manuals are properly documented. Good documentation helps
future teams understand and maintain the software.

Stage 12: Disposition

When software becomes obsolete or outdated, this phase handles archiving data, closing down the
system, and planning the end-of-system activities.
Q2. Software Development Models / Paradigms
Short Explanation:
A Software Development Paradigm (or model) helps developers choose a strategy to build software. Each
model has its own tools, methods, and procedures that define the development life cycle. The most
popular models are: Waterfall, Iterative, Spiral, V-Model, and Big Bang.

1. Waterfall Model
Definition:

Waterfall Model is the simplest and oldest SDLC model. All phases are done one after another in a linear
sequence. A phase starts only after the previous one is fully complete. It is also called the linear-sequential
life cycle model.

Phases:

Requirement Gathering → System Analysis → Coding → Testing → Implementation → Operations &

Maintenance

Advantages:

• Simple and easy to understand.

• Clear, defined stages.
• Easy to manage.
• Works well for small projects with well-known requirements.
• Good documentation.
Disadvantages:

• Cannot go back to change something once a phase is done.

• No working software until the end.
• High risk and uncertainty.
• Not good for complex or changing requirements.

2. Iterative Model
Definition:

Iterative Model develops software in repeated cycles (iterations). It starts with a small part of the software,
then adds more features in each cycle. Each iteration produces a working, improved version of the
software.

Advantages:

• Working software available early.

• Easy to test and debug small parts.
• Supports changing requirements.
• Better risk management.
• Parallel development possible.
Disadvantages:

• Requires more resources.

• Not suitable for small projects.
 • System architecture issues may arise.
• High management complexity.

3. Spiral Model
Definition:

Spiral Model combines both iterative development and one SDLC model. It focuses heavily on risk
analysis. The project passes through four phases repeatedly in loops called spirals.

Four Phases of Spiral Model:

• Identification — Gather business and system requirements.

• Design — Conceptual, architectural, and physical design.
• Construct or Build — Build the actual software product (prototype/build).
• Evaluation and Risk Analysis — Identify and resolve risks; customer evaluates the software.
Advantages:

• Handles changing requirements well.

• Users see the system early.
• Risk is managed proactively.
• Works well for large, complex, high-risk projects.
Disadvantages:

• Complex to manage.
• Expensive for small projects.
• Spiral may go on indefinitely.
• Requires risk management expertise.

4. V-Model (Verification and Validation Model)

Definition:

V-Model is an extension of the Waterfall model where every development phase has a corresponding
testing phase. Processes happen in a V-shape — the left side is verification (development), the right side
is validation (testing), and coding joins the two sides at the bottom.

Verification Phases (Left side):

• Business Requirement Analysis

• System Design
• Architectural Design
• Module Design
Coding Phase (Bottom):

• Actual code is written based on the design.

Validation Phases (Right side):

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
Advantages:

• Highly disciplined, phases completed one at a time.

• Easy to understand.
• Works well for small projects with clear requirements.
Disadvantages:

• Not flexible to changes.

• No working software until late in the cycle.
• High risk and uncertainty.
• Not suitable for long or complex projects.

5. Big Bang Model

Definition:

Big Bang Model is the simplest model with very little planning. All resources (time, money, efforts) are put
together and the software is developed without following any specific process. The requirements are
implemented as they come.

Advantages:

• Very simple, little or no planning needed.

• Easy to manage.
• Good for small projects and academic learning.
• Gives flexibility to developers.
Disadvantages:

• Very high risk and uncertainty.

• Misunderstood requirements can cause complete project failure.
• Not suitable for complex or large projects.
• Can be very expensive if requirements change.
Q3. Agile Model / Agile Software Development Practices
Definition:
Agile SDLC model is a combination of iterative and incremental process models. It focuses on process
adaptability and customer satisfaction by rapidly delivering working software. Agile breaks the product into
small incremental builds delivered in iterations. Each iteration typically lasts 1 to 3 weeks.

Explanation:
In Agile, every iteration involves cross-functional teams working simultaneously on: Planning,
Requirements Analysis, Design, Coding, Unit Testing, and Acceptance Testing. At the end of each
iteration, a working product is shown to the customer and stakeholders for feedback. Agile believes every
project is different and methods should be tailored to suit project requirements.

Agile Manifesto Principles:

• Individuals and Interactions — People and communication are more important than processes and
tools.
• Working Software — Delivering functional software is the best way to measure progress.
• Customer Collaboration — Continuous customer involvement throughout development.
• Responding to Change — Agile embraces and adapts to changing requirements quickly.

Agile vs Traditional SDLC Models:

Agile Traditional (Waterfall)

Adaptive approach Predictive approach

No detailed planning upfront Complete planning at start

Customer involved throughout Customer involved at start & end

Flexible to changes Difficult to change mid-project

Working software delivered each sprint Software delivered at end

Minimal documentation Heavy documentation

Advantages of Agile:
• Realistic approach to software development.
• Promotes teamwork and cross-training.
• Functionality can be developed rapidly and demonstrated.
• Suitable for both fixed and changing requirements.
• Delivers early partial working solutions.
• Easy to manage with minimal rules.

Disadvantages of Agile:
• Not suitable for handling complex dependencies.
• Requires an experienced agile leader.
• High dependency on customer interaction.
• Difficult to document clearly due to minimal paperwork.
• Technology transfer to new team members is challenging.
Q4. Agile Development Techniques / Methods (Detailed)
Overview:
Agile development techniques are specific methodologies that follow the Agile philosophy. The most
popular Agile methods include Scrum (1995), Extreme Programming (XP) (1996), Kanban, Crystal,
Feature Driven Development (FDD), and Dynamic Systems Development Method (DSDM) (1995). All
these are collectively called Agile Methodologies after the Agile Manifesto was published in 2001.

1. Scrum
Scrum is the most widely used Agile framework. Work is divided into fixed-length sprints (usually 2-4
weeks). There are three key roles: Scrum Master (facilitator), Product Owner (represents the customer),
and Development Team. Daily stand-up meetings (15 min) are held. At the end of each sprint, a working
product increment is delivered.

• Sprint: A fixed time period (2-4 weeks) to complete a set of tasks.

• Sprint Backlog: List of tasks for the current sprint.
• Product Backlog: Full list of all features to be built.
• Daily Scrum: Short 15-minute meeting to discuss progress.
• Sprint Review: Demo of working software to stakeholders.

2. Extreme Programming (XP)

XP focuses on producing higher quality code through frequent releases and collaboration. It is best for
projects with constantly changing requirements.

• Pair Programming: Two programmers work together at one computer.

• Test Driven Development (TDD): Write tests before writing code.
• Continuous Integration: Code is integrated and tested frequently.
• Refactoring: Constantly improving code quality.
• Simple Design: Keep the design as simple as possible.

3. Kanban
Kanban is a visual workflow management method. Tasks are represented as cards on a board with
columns like 'To Do', 'In Progress', and 'Done'. It focuses on limiting work in progress to avoid overload.

• Visual Board: Shows all work items and their status.

• WIP Limit: Only a set number of tasks can be in progress at once.
• Continuous delivery: No fixed sprint, work flows continuously.
• Great for support and maintenance teams.

4. DSDM (Dynamic Systems Development Method)

DSDM is a timeboxed Agile method that ensures delivery on time and budget. It focuses on fixing time and
cost, and adjusting the scope (features) accordingly.

• Timeboxing: Fixed time periods for delivery.

• MoSCoW Prioritization: Must have, Should have, Could have, Won't have.
• Continuous user involvement is required.
• Best for projects with strict deadlines.
5. Crystal Methods
Crystal is a lightweight Agile method that focuses on team communication and simplicity. Different Crystal
variants exist based on team size: Crystal Clear (small teams), Crystal Yellow, Crystal Orange (larger
teams).

• Focus on people over processes.

• Frequent delivery of working software.
• Reflective improvement after each cycle.
• Best suited for small co-located teams.

6. Feature Driven Development (FDD)

FDD builds software feature by feature. It starts by building a domain model, then creates a feature list,
and builds each feature one by one.

• Develop overall model first.

• Build a feature list.
• Plan by feature.
• Design and build feature by feature.
• Best for larger teams with complex domain models.

GOOD LUCK IN YOUR EXAM! You've got this.