Software Engineering Study Guide

Requirements, design principles, version control, testing, agile workflow, and maintenance

How to use these notes

This document is written as a standalone classroom-style study handout. It contains explanations, tables, revision
checklists, examples, and small practice tasks. The goal is to help a learner revise the topic without needing slides
or a textbook open side by side.
The notes are original, concise, and intentionally practical. Each section focuses on ideas that commonly appear in
assignments, viva questions, technical interviews, and semester examinations.

Original study document - prepared for educational reference Page 1

 1. Why Software Engineering Matters
Software engineering is the disciplined approach to building software that is understandable, testable, maintainable,
and useful. Programming is one part of it, but real projects also involve requirements, design, collaboration,
documentation, testing, deployment, and long-term maintenance.

A small script can be written quickly by one person. A production system may be used by thousands or millions of
people and must continue working when features change. Software engineering provides practices that reduce
confusion and risk as a codebase grows.
In practical study, why software engineering matters should be understood as a decision-making tool, not only as a
definition. When a learner can explain where it appears in a team software project, the concept becomes easier to
remember and apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.

• Good engineering makes future changes easier.

• Clear requirements reduce rework and misunderstanding.

• Testing catches defects before users experience them.

• Documentation preserves decisions that would otherwise be forgotten.

• Revision cue: connect this idea with one real example from a team software project.

• Answer cue: define the term, explain the working, then state a limitation or trade-off.

2. Requirement Analysis
Requirement analysis converts a vague need into specific behavior. A requirement should describe what the
system must do and, when needed, how well it must do it. Functional requirements describe features.
Non-functional requirements describe qualities such as performance, security, availability, and usability.

In practical study, requirement analysis should be understood as a decision-making tool, not only as a definition.
When a learner can explain where it appears in a team software project, the concept becomes easier to remember
and apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.

• Revision cue: connect this idea with one real example from a team software project.
• Answer cue: define the term, explain the working, then state a limitation or trade-off.
A weak requirement says: The app should be fast. A stronger requirement says: The dashboard should load within
three seconds for 95% of requests under normal traffic.

Requirement type Example

Functional Users can reset their password using an email verification link.

Performance Search results should load within two seconds for typical queries.

Security Passwords must never be stored in plain text.

Availability The service should tolerate one database replica going offline.

Practice / self-check
• Rewrite two vague requirements into measurable requirements.

Original study document - prepared for educational reference Page 2

 • List three non-functional requirements for an online exam portal.
• Explain why assumptions should be documented.

3. Design Principles
Design principles guide structure. They do not replace thinking, but they help engineers avoid common mistakes.
Low coupling means modules depend on each other as little as possible. High cohesion means each module has
one clear purpose.

In practical study, design principles should be understood as a decision-making tool, not only as a definition. When
a learner can explain where it appears in a team software project, the concept becomes easier to remember and
apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.
• Single responsibility: one class or module should have one main reason to change.

• Separation of concerns: keep UI, business rules, and data access logically separated.
• Abstraction: expose what is necessary and hide implementation details.

• Consistency: similar tasks should be implemented in similar ways.

• Revision cue: connect this idea with one real example from a team software project.
• Answer cue: define the term, explain the working, then state a limitation or trade-off.

Practice / self-check
• Give an example of a module with low cohesion.
• Explain how too many dependencies make testing difficult.
• Identify concerns in a food delivery application: UI, payment, delivery assignment, and notifications.

4. Version Control and Collaboration

Version control systems such as Git record changes over time. They allow multiple people to work on the same
project, review changes, and recover older versions. A good commit history tells the story of a project.

In practical study, version control and collaboration should be understood as a decision-making tool, not only as a
definition. When a learner can explain where it appears in a team software project, the concept becomes easier to
remember and apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.
• Revision cue: connect this idea with one real example from a team software project.

• Answer cue: define the term, explain the working, then state a limitation or trade-off.
Practical rule: commit small, related changes with meaningful messages. A message like fix bug is less useful than
handle empty cart during checkout.

Term Meaning

Commit A saved snapshot of changes with a message.

Branch A separate line of development for a feature, fix, or experiment.

Original study document - prepared for educational reference Page 3

 Merge Combining changes from one branch into another.

Pull request A review process before changes enter the main codebase.

Conflict A situation where changes overlap and must be resolved manually.

5. Testing Strategy
Testing checks whether software behaves as expected. Unit tests test small pieces of code. Integration tests test
interaction between components. End-to-end tests simulate realistic user flows. Manual testing is still valuable for
usability and exploratory discovery.
In practical study, testing strategy should be understood as a decision-making tool, not only as a definition. When a
learner can explain where it appears in a team software project, the concept becomes easier to remember and
apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.

• Revision cue: connect this idea with one real example from a team software project.

• Answer cue: define the term, explain the working, then state a limitation or trade-off.

Testing level Focus

Unit Small function, method, or class behavior.

Integration Database, API, service, or module interaction.

End-to-end Complete user journey through the system.

Regression Ensuring old features still work after changes.

Practice / self-check
• Write three unit test cases for a login validator.
• Explain why 100% test coverage does not guarantee zero bugs.

• Identify an integration test for a shopping cart system.

6. Agile, Scrum, and Kanban

Agile methods emphasize iterative development, feedback, and adaptability. Scrum organizes work into time-boxed
sprints with planning, daily syncs, reviews, and retrospectives. Kanban focuses on continuous flow and limiting work
in progress.

These methods are useful only when the team understands the goal. Meetings cannot compensate for unclear
requirements, poor communication, or lack of ownership.

In practical study, agile, scrum, and kanban should be understood as a decision-making tool, not only as a
definition. When a learner can explain where it appears in a team software project, the concept becomes easier to
remember and apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.

• Sprint planning selects work for a short iteration.

• Daily stand-up highlights progress and blockers.

Original study document - prepared for educational reference Page 4

 • Sprint review demonstrates completed work to stakeholders.
• Retrospective improves the team process.

• Kanban boards visualize workflow from backlog to done.

• Revision cue: connect this idea with one real example from a team software project.

• Answer cue: define the term, explain the working, then state a limitation or trade-off.

7. Maintenance and Technical Debt

Software lives after the first release. Maintenance includes fixing bugs, improving performance, updating
dependencies, adapting to new requirements, and removing obsolete code. Technical debt is the extra cost created
by shortcuts, weak design, or postponed cleanup.
Not every shortcut is bad. Sometimes a team makes a conscious trade-off to meet an urgent deadline. The
important point is to record the debt and plan repayment before it becomes expensive.

In practical study, maintenance and technical debt should be understood as a decision-making tool, not only as a
definition. When a learner can explain where it appears in a team software project, the concept becomes easier to
remember and apply in new questions.

A useful way to revise this part of software engineering is to ask three questions: what input is available, what rule
or mechanism is applied, and what output or behavior should be expected. This method also helps during viva
answers because it creates a clear explanation flow.

Common mistakes happen when students memorize the keyword but ignore the boundary conditions. Always note
what assumptions are being made, what can fail, and how the system should behave when the normal case is not
true.
For exam writing, begin with a one-line purpose, then add a short example, and finally mention one advantage or
limitation. This gives the answer structure and prevents it from becoming a copied definition without understanding.
• Revision cue: connect this idea with one real example from a team software project.

• Answer cue: define the term, explain the working, then state a limitation or trade-off.

Practice / self-check
• Give two examples of technical debt in a student project.
• Explain why documentation helps maintenance.

• List a safe process for refactoring a critical module.

Extended Glossary and Quick Recall

Term Quick recall note

Why Software Engineering Core idea number 1: define it, explain its working, and connect it with a real use
Matters case.

Requirement Analysis Core idea number 2: define it, explain its working, and connect it with a real use
case.

Design Principles Core idea number 3: define it, explain its working, and connect it with a real use
case.

Version Control and Collaboration Core idea number 4: define it, explain its working, and connect it with a real use
case.

Testing Strategy Core idea number 5: define it, explain its working, and connect it with a real use
case.

Original study document - prepared for educational reference Page 5

 Agile, Scrum, and Kanban Core idea number 6: define it, explain its working, and connect it with a real use
case.

Maintenance and Technical Debt Core idea number 7: define it, explain its working, and connect it with a real use
case.

Trade-off A situation where improving one quality may reduce another quality, such as
speed versus safety.

Boundary case An input or condition at the edge of normal behavior; many defects appear here.

Workflow The ordered path from input to processing to output.

Validation Checking whether data, assumptions, or behavior follow expected rules.

Mini Case Study

Imagine a student team has to explain this subject to juniors in a one-hour workshop. The team should first
introduce the problem that the topic solves, then demonstrate a small example, and finally ask students to identify
the same concept in a different situation. This method checks understanding better than asking learners to repeat
definitions.

For a written assignment, the case study can be converted into a short report. Start with the context, list the
important components, explain the sequence of events, and end with limitations. A good answer shows both the
normal case and what may go wrong when assumptions are violated.

Question Bank for Practice

• Explain why software engineering matters with one real-life example.

• Write two advantages and one limitation related to why software engineering matters.
• Explain requirement analysis with one real-life example.
• Write two advantages and one limitation related to requirement analysis.
• Explain design principles with one real-life example.
• Write two advantages and one limitation related to design principles.

• Explain version control and collaboration with one real-life example.

• Write two advantages and one limitation related to version control and collaboration.
• Explain testing strategy with one real-life example.

• Write two advantages and one limitation related to testing strategy.

• Explain agile, scrum, and kanban with one real-life example.

• Write two advantages and one limitation related to agile, scrum, and kanban.
• Explain maintenance and technical debt with one real-life example.

• Write two advantages and one limitation related to maintenance and technical debt.
• Create a two-column comparison table for two similar terms from this document.

• Write a five-line summary of the most important concept without using textbook language.

• Prepare one viva question and answer it in less than one minute.
• Identify one mistake a beginner may make and explain how to avoid it.

Original study document - prepared for educational reference Page 6

 Final Revision Checklist
• Can you explain the topic in simple language without memorizing a definition?
• Can you draw or list the main workflow from input to output?

• Can you compare two similar terms and state where each is used?
• Can you solve at least three small questions without checking the answer first?

• Can you identify one real-life example where this concept is useful?

Suggested one-hour revision plan

Time Activity

0-10 min Skim headings, tables, and highlighted boxes.

10-30 min Read the explanations and rewrite key ideas in your own words.

30-45 min Attempt practice questions without looking at notes.

45-60 min Correct mistakes, mark weak concepts, and create a mini cheat sheet.

Original study document - prepared for educational reference Page 7