Software Engineering Lecture 1 Notes

Software
1. Complexity and Scale: Modern software systems are increasingly complex, requiring
larger teams to manage and develop. This complexity is evident in the size of the
codebase, which can be vast and intricate, supporting various functionalities.
● Examples: Chat servers, email clients, and Electronic Health Record (EHR)
Systems exemplify the complexity and the broad scope of modern software
applications.
2. Diversity of Programs: Software development encompasses a wide variety of
programs, each designed to meet specific needs or solve particular problems. This
diversity necessitates comprehensive associated documentation to ensure proper usage
and maintenance.
3. Wide Application Range: Software finds applications across numerous sectors,
including but not limited to business intelligence, healthcare, and education. This
widespread use underscores the importance of software in modern society and the
need for high-quality development practices.
Bad Software
1. Privacy Concerns: Poorly designed software can compromise user privacy,
exposing sensitive information to unauthorized parties.
2. Security Vulnerability: Vulnerabilities in software can be exploited by
attackers, leading to data breaches and other security incidents.
3. Performance Issues: Bad software can be a performance nightmare, with slow
response times and inefficient resource use affecting user experience.
4. Unwanted Features or Ads: The inclusion of unnecessary features or
invasive advertising can detract from the core functionality and user
satisfaction.
5. Lack of Support and Updates: Without regular updates and support, software
can quickly become obsolete, insecure, or incompatible with other systems.
Software Engineering
1. Definition: Software engineering is defined as the application of a systematic,
disciplined, and quantifiable approach to the development, operation, and
maintenance of software.
● Engineering Approach: This approach emphasizes clarity, predictability,
and quantifiable outcomes, utilizing theories, methodologies, frameworks,
and tools to produce a quality product in a cost-effective manner.
Software Engineering: Layered View
1. Process: The foundation of software engineering, focusing on activities that yield
predictable results.
2. Methods: Techniques employed to carry out specific activities within the
software development process, ensuring efficiency and effectiveness.
3. Tools: Support for both processes and methods, tools facilitate the application
of various techniques in software engineering, enhancing productivity and
quality.
Software Engineering Myths
1. Management Myths:
● Belief that existing standards and procedures are sufficient for all software
development needs.
● Misconception that adding more programmers to a delayed project can help
catch up.
 ●Outsourcing a project does not absolve the original management from
responsibility; oversight and engagement remain crucial.
2. Customer Myths:
● A general statement of objectives is not enough to commence
development; detailed planning and specifications are necessary.
● Software, while flexible, requires careful consideration and planning to
modify or extend.
3. Practitioner's Myths:
● Completing a program does not signify the end of the developer's job;
maintenance and quality assessment are ongoing requirements.
● Quality can and should be assessed before completion through various testing
and evaluation methodologies.
● The belief that software engineering leads to unnecessary documentation is a
misconception. Proper documentation is vital for maintenance, scalability,
and knowledge transfer, contributing to rather than detracting from efficiency.

Lecture 2

● Many different software processes but all involve:

● Specification – defining what the system should do;
● Design and implementation – defining the organization of the system
and implementing the system;
● Validation – checking that it does what the customer wants;
● Evolution – changing the system in response to changing customer
needs.

Software Development Life Cycle (SDLC)

1. Definition: The SDLC is a structured process used for planning, creating, testing, and
deploying an information system. It comprises several distinct phases that cover the
complete lifecycle of a software application.
2. Core Activities:
● Feasibility Study: Evaluating the project's viability.
● Planning: Outlining the project scope, resources, and timeline.
● Requirement Analysis: Identifying the needs or conditions to meet for a
new or altered product.
● Design: Conceptualizing the software architecture and user interface.
● Development: Actual coding and building of the software.
● Testing: Verifying the software's functionality against requirements.
● Deployment: Implementing the software in a live environment.
● Maintenance: Ongoing support and updates post-deployment.
3. Organization of Activities: Activities can be organized sequentially or
interleaved, often containing sub-activities like unit testing and requirement
validation.
Software Development Process Models
1. Plan driven :
● Models organize the phases of SDLC in different ways to address specific
project needs or constraints.
● Common models include Waterfall, Agile, Spiral, and DevOps.
 2. Value-Driven Process Model:
● Focuses on delivering the maximum value to stakeholders, prioritizing
features based on their contribution to the overall project goals.
3.Integration and configuration:
● Based on software reuse where systems are integrated from existing components or application systems
(sometimes called COTS -Commercial-off-the-shelf) systems).
● Reused elements may be configured to adapt their behaviour and functionality to a user’s requirements
●
●
●
Reuse is now the standard approach for building many types of business system

Models Adv Disadv

Waterfall - Clear structure and Inflexible to changes.

documentation. - Late testing phase may
- Easy to manage with well- cause issues.
defined phases. - Not suitable for evolving
- Good for stable projects projects.
with well-known
requirements.

Agile - Quick iterations allow for - Requires active customer

continuous improvement. involvement.
- Customer feedback is - Not ideal for projects with
integrated regularly. strict deadlines.
- More flexible to - Can be difficult to manage
requirement changes. in large teams.

Spiral(every iteration Strong risk management. Expensive and time-

involves risk assessment - Allows for iterative consuming.
beore moving toanother development with feedback. - Requires experienced
iteration) - Best for complex and high- developers.
risk projects. - Can be difficult to manage

DEvops - Faster deployment and Requires cultural and

integration. organizational changes.
- Continuous monitoring and - Needs strong DevOps tools
automation. and automation.
- Improves collaboration - Security and compliance
between development and challenges.
operations.
Value driven Focuses on delivering Hard to quantify "value" for
business value. every feature.
- Helps prioritize important - Requires active stakeholder
features. engagement.
- Works well with Agile and - May deprioritize
Lean methodologies. technically important tasks.

Reuse based development Faster development using Customization limitations.

existing software. - May have compatibility or
- Reduces cost and effort. licensing issues.
- Standardized components - Vendor dependency (for
improve reliability. COTS systems).

RAD(Projects needing quick Requires Skilled Team:

development with frequent Needs experienced designers
user feedback, such as Encourages and developers to be
UI/UX-heavy applications.) rapid effective.
prototyping Not Suitable for Large
, reducing Projects: Complex systems
developme require more structured
nt time. approaches.
High Dependency on
Customer Involvement:
User- Success depends on active
Centric: user participation
Frequent Difficult to Manage:
user Multiple iterations can be
feedback hard to track.
ensures the
final
product
aligns with
expectations
.

Flexible .
to
Changes:
Easy to
modify
based on
changing
requireme
nts.

Reduces
Risk: Early
prototypes
help
identify
potential
risks.
V-model(requires testing at Rigid & Inflexible: Hard to
each stage ,essential for Early implement changes once
highly test-centered product Defect development starts.
such as medical appliances) Detection: High Cost & Time-
Testing Consuming: Every stage
happens at requires corresponding test
every stage, plans.
reducing Requires Comprehensive
late-stage Documentation: Extensive
errors. documentation increases
workload
Testing Needs Extensive
Clear Resources: More resources
Structure are required for test case
: Well- creation and execution.
defined
phases
make it
easy to
manage.

Ensures
High
Quality:
Each
development
phase has a
correspondin
g validation
phase,
ensuring
reliability.

Easy to .
Track
Progress:
Verificatio
n at each
stage
provides
clear
checkpoint
s.

Works Well
for Mission-
Critical
Application
s: Used in
industries
where
 failures can
have severe
consequence
s.

Design

● Architectural design, where you identify the overall structure of the system, the principal
components (subsystems or modules), their relationships and how they are distributed.
● Database design, where you design the system data structures and how these are to be
represented in a database.
● Interface design, where you define the interfaces between system components.
● Component selection and design

Testing:
component testing
● Individual components are tested independently;
● Components may be functions or objects or coherent groupings of these entities.
● System testing
● Testing of the system as a whole. Testing of emergent properties is particularly important.
● Customer testing
● Testing with customer data to check that the system meets the customer’s needs.
Evolution:

● System prototyping, where a version of the system or part of the system is

developed quickly to check the customer’s requirements and the feasibility
of design decisions. This approach supports change anticipation.

● Incremental delivery, where system increments are delivered to the

customer for comment and experimentation. This supports both change
avoidance and change tolerance.

Process improvements:
● Process measurement
● You measure one or more attributes of the software process or product. These measurements
forms a baseline that helps you decide if process improvements have been effective.
● Process analysis
 ● The current process is assessed, and process weaknesses and bottlenecks are identified.
Process models (sometimes called process maps) that describe the process may be
developed.
● Process change
● Process changes are proposed to address some of the identified process weaknesses. These
are introduced and the cycle resumes to collect data about the effectiveness of the changes
Components of Software Development Process
1. Stakeholders:
● Include users, requirement engineers, designers, developers, testers, and
managers, each playing a critical role in the project's success.
2. Process:
● A structured set of activities designed to produce a software product,
with predefined pre and post conditions to guide each phase.
3. Product:
● The final software application, developed to meet the identified requirements
and specifications.
Umbrella Activities
1. User Experience: Ensuring the software is intuitive, accessible, and satisfying for the
user.
2. Quality Assurance: Systematic monitoring and evaluation of the various aspects of
a project to ensure standards of quality are met.
3. Configuration Management: Handling changes systematically to maintain the
integrity and traceability of the configuration throughout the project lifecycle.
4. Project Planning: Defining objectives, scope, procedures, and roles within the
project.
Detailed Software Development Process Activities
1. Planning:
● Identifies the purpose, end-user, key features, and UI/UX
design considerations of the application.
2. Requirement Analysis:
● Involves gathering, analyzing, verifying requirements, and creating a
Requirement Traceability Matrix and Software Requirement
Specification (SRS) document.
3. Design and Development:
● Translates requirements into a workable design, documented in the Design
Document Specification, followed by the actual software implementation.
4. Testing:
● Ensures the software is deployed in multiple test environments for bug
detection and stability before release.
5. Deployment and Maintenance:
● Involves software setup, user training, performance monitoring, and regular
debugging. Maintenance is categorized into:
● Perfective: Enhancements for improving performance or
maintainability.
● Adaptive: Adjusting the software to changes in the environment.
● Preventive: Modifications to prevent future problems.
● Corrective: Fixing identified faults.

Software development process models provide a framework for organizing the activities
involved in creating and maintaining software. These models can be broadly categorized into
plan-driven (traditional) and value-driven (Agile), with specific approaches like incremental
and iterative models offering different strategies for managing development.
Plan-Driven (Traditional) Models

1. Characteristics:
● Rigid Structure: Plan-driven models follow a rigid and linear sequence of
phases, including requirements, design, implementation, testing, and
maintenance.
● Invisibility of Progress: Due to the phase-wise approach, progress can be less
visible until later stages.
● Plan-Centered: Emphasis is placed on detailed planning and documentation
from the outset.
● Phase-Wise Outcome: Deliverables are produced at the end of each phase,
often resulting in a single major release.
● Well-Documented: Extensive documentation is produced throughout the
development process to guide development and ensure compliance with initial
plans.
2. Approach:
● Focus on thorough planning, sequential activities, and achieving a single,
comprehensive outcome.
● Reliance on documented knowledge, aiming to meet both current and future
requirements.
● Suited for larger teams and projects where requirements are well-understood
and changes are minimal.

Value-Driven (Agile) Models

1. Characteristics:
● Flexible: Agile models are adaptable to changes in project scope or direction.
● Visible Progress: Work is broken down into small, manageable
increments, making progress more visible and measurable.
● Customer-Centered: Prioritizes customer feedback and involvement in
the development process.
● Quick Solutions: Aims to deliver working software quickly and iteratively
to address customer needs.
2. Approach:
● Adopts a variable plan with a series of sprints or iterations, each delivering a
potentially shippable product increment.
● Emphasizes interpersonal knowledge and customer feedback over extensive
documentation.
● Architectured for current requirements, making it ideal for projects where
needs are expected to evolve.
● Generally involves smaller teams focused on rapid delivery and
responsiveness to change.
Incremental vs Iterative Models
● Iterative Model: Focuses on creating a complete project outline, then refining and
improving it through multiple iterations. Each iteration includes planning, design,
coding, and testing phases, allowing for gradual enhancement based on feedback and
evaluation.
● Incremental Model: Builds the final product piece by piece. Each increment is a
portion of the functionality or a working part of the product, delivered over time until
the complete system is finished.
Brief Examples :

● Waterfall Model: A linear and sequential approach where each phase must
be completed before the next begins.
● Scrum: An Agile framework for managing knowledge work, with an emphasis on
software development. It is designed for teams of three to nine members who break
their work into actions that can be completed within timeboxed iterations, called
sprints.
● Spiral Model: Combines elements of both design and prototyping in stages, in an
effort to combine advantages of top-down and bottom-up concept

Agile Manifesto Values

● Preference for individuals and interactions over processes and tools.

● Emphasis on working software over comprehensive documentation.
● Customer collaboration is valued more than contract negotiation.
● Responding to change is prioritized over following a plan.

Twelve Principles of Agile Development

1. Early and continuous delivery of valuable software.
2. Welcoming changing requirements, even late in development.
3. Deliver working software frequently.
4. Close, daily cooperation between business people and developers.
5. Projects are built around motivated individuals.
6. Face-to-face conversation is the best form of communication.
7. Working software is the primary measure of progress.
8. Sustainable development pace.
9. Continuous attention to technical excellence and good design.
10. Simplicity is essential.
11. Best architectures, requirements, and designs emerge from self-organizing teams.
12. Regularly, the team reflects on how to become more effective.

Agile Process Models

● Agile methodologies are a mix of incremental and iterative approaches. They aim for
small increments or working products, minimizing documentation while maximizing
product adaptability and team communication.
Lecture 3

Agile Process models include:

● SCRUM: A framework that facilitates team collaboration on complex projects.

● Extreme Programming (XP): Focuses on improving software quality

and responsiveness to changing customer requirements.

● KANBAN: A visual approach to managing work as it moves through a process.

SCRUM is widely adopted by leading companies due to its iterative and incremental nature,
offering scalable solutions for improved communication and cooperation. It utilizes time-
boxed iterations, known as sprints, typically lasting 1-4 weeks, to manage and complete work
efficiently.

Key Terms:
● Requirement: A statement outlining a need.
● Project: Comprises end-user requirements.
● Sprint: A time-boxed event for achieving specific work, usually 1-4 weeks.
● Project Backlog: The current list of project requirements.
● Sprint Backlog: A subset of the project backlog selected for development in a sprint.
● User Story: A simple description of a software feature from an end-user perspective.
● Tasks: Specific activities required to complete backlog items.

SCRUM Workflow:
● Begins with identifying features to develop, moving tasks through a queue, in
progress, and then to completion, culminating in the feature completion.

Scrum Framework Components:

● Roles: Product Owner, Scrum Master, and Scrum Team.
● Events: Include daily scrums, sprint reviews, and sprint retrospectives.
● Artifacts: Product backlogs and sprint backlogs.

Scrum Roles:
● Product Owner: Defines and prioritizes features, decides release dates, and accepts
or rejects project results.
● Scrum Master: Manages the project, ensures adherence to SCRUM values, and
facilitates coordination.
● Scrum Team: Consists of 5-9 cross-functional, full-time members who are
self- organizing. Membership ideally changes only between sprints.

Scrum Meetings:
● Daily Scrum: A quick, stand-up meeting to discuss yesterday's achievements,
today's goals, and any obstacles.
● Sprint Review: An informal meeting to demonstrate new increments to
stakeholders and plan the next steps.
● Sprint Retrospective: A session to reflect on the sprint's successes and areas
for improvement, leading to actionable commitments for the next sprint.
Product Backlog: An ordered list of everything that might be needed in the product,
constantly evolving and serving as a source of requirements for any changes to be made to
the product.

Example of Product Backlog: Imagine a product backlog for a new social media
application, including tasks like "Implement user authentication", "Develop profile
customization features", "Code the news feed algorithm", and "Integrate messaging
functionality". Each item is prioritized based on business value and technical feasibility.

Sprint Backlog Example: A detailed plan for a sprint might include tasks such as coding
user interfaces, developing the middle tier, testing components, writing help documentation,
and implementing specific classes or functionalities. Tasks are assigned daily effort estimates
and adjusted as the sprint progresses.

User Stories
User stories are a fundamental component in Agile methodologies, particularly in Scrum and
XP (Extreme Programming), serving as a simple way to convey user requirements. Here's an
elaboration on the examples provided and an expanded template for writing user stories.

Examples Elaborated:

1. Power User Story:

● As a power user, I can specify files or folders to back up based on file size,
date created, and date modified. This feature allows for more efficient and
targeted backups, ensuring that only necessary data is stored, which optimizes
storage use and saves time during the backup process.
2. General User Story:
● As a user, I can indicate folders not to back up so that my backup drive isn't
filled up with things I don't need saved. This functionality provides users with
the flexibility to exclude non-essential data from backups, conserving space on
the backup drive and streamlining the backup and recovery process

User Story Template Expanded:

● Title: Brief description of the story

● As a [role], I can [feature] so that [benefit]. This format focuses on the user's need,
the task they want to accomplish, and the reason behind it, ensuring that the
development team understands the value of the feature from the user's perspective.
● Acceptance Criteria: Define what must be true for the story to be considered
completed, providing clear, testable conditions that can be used to verify that
the functionality meets the user's needs.
● Notes/Comments: Additional information or considerations that provide context
or clarify requirements.
Progress Monitoring

1. Release Burndown Chart: Tracks the remaining work across the time available for
a release. It helps teams understand how much work is left and whether they are on
track to complete it by the deadline.
2. Story Monitoring: Involves tracking the progress of individual user stories within a
sprint to ensure they are moving towards completion according to the plan.
3. Sprints: Short, time-boxed periods (usually 2-4 weeks) during which a team works to
complete a set amount of work. Monitoring progress within sprints involves daily
stand-ups and updating task boards to reflect current statuses.

Scope Creeping:

when product backlog increaes due to no of features making it tight for the software to be
established in the required time/duration8
Scalable Scrum: Scrum of Scrums
● This approach is used to coordinate multiple Scrum teams working on the same
project. It involves representatives from each team meeting regularly to discuss
progress, dependencies, and impediments, ensuring alignment and integration across
teams.

Issues with Scrum

● Fixed Sprint Durations: Can be challenging when priorities shift suddenly.
● Scrum Master Dependency: Teams may become too reliant on the Scrum Master.
● Complexity in Large Teams: Scaling Scrum for large, distributed teams
can introduce coordination challenges.

Recommended Duration for a Sprint in Scrum

● The recommended duration is generally 2-4 weeks, allowing enough time for
significant progress while maintaining the agility to respond to changes
quickly.

Kanban
Kanban, originating from Toyota, is a lean agile model that emphasizes visual management of
work through boards, representing the team's current work and workflow. Unlike Scrum, it
does not use time-boxed iterations but focuses on visualizing work, limiting work in progress
(WIP), and facilitating continuous, incremental changes.

Key Principles:
1. Visualize Your Work: Use boards to make work and workflow visible for
easy monitoring, adaptation, and improvement.
2. Limit Work in Progress (WIP): By limiting WIP, teams can reduce cycle times,
prioritize high-value tasks, and minimize multitasking, leading to more focused and
efficient work.
3. Push vs. Pull Work Allocations: In Kanban, work is pulled as capacity allows,
rather than being pushed onto teams, which helps in managing workload and
reducing bottlenecks.
4. Monitor and Improve: Continuous observation of the workflow allows teams to
identify and implement improvements, making the process more efficient over time.
Scrum vs. Kanban
● Scrum is structured around fixed-length sprints and roles, while Kanban is more
flexible, focusing on continuous delivery and not predefined roles.
● Kanban boards may show work selected upfront, to-do lists, and emphasize keeping
queues empty and prioritizing top-priority work, allowing for a flexible, ongoing list
with a focus on limiting WIP to ensure efficiency.

Team Structures
● Small Collocated Teams: Often use Scrum effectively, benefiting from
close communication and quick problem resolution.
● Large Distributed Teams: May find Kanban or a hybrid model more suitable due
to its flexibility and emphasis on visual management, which can help coordinate
complex workflows across different locations.

eXtreme Programming (XP)

eXtreme Programming (XP) is an Agile software development methodology designed to

improve software quality and responsiveness to changing customer requirements. It
emphasizes frequent releases in short development cycles, which improves productivity and
introduces checkpoints where new customer requirements can be adopted.

XP Values and Principles

XP is built on four core values and aligns closely with Agile principles, incorporating
practices like full-time customer engagement and pair programming to foster collective
ownership and support change through continuous releases.
Four Values of XP:
1. Communication: Encourages open and clear communication within the team and
with stakeholders to ensure alignment and understanding.
2. Simplicity: Advocates for the simplest solution that works, minimizing
complexity and focusing on functionality that is truly needed.
3. Feedback: Places a strong emphasis on customer feedback and collaboration,
prioritizing adjustments based on actual user experience and needs.
4. Courage: Encourages team members to make tough decisions, such as refactoring or
changing direction based on feedback, even if it's challenging.
XP Practices

XP involves twelve key practices, extended in various ways to support its principles,
including:
● Iterative Development: Delivering new versions possibly several times a day to
ensure rapid feedback and continuous improvement.
● Increments: Working in increments with releases every two weeks, allowing
for regular review and adaptation.
● Test-Driven Development (TDD): Writing tests before code to ensure each feature
is tested and functions as expected.

Methodology Keywords Summary

● SCRUM:
● Sprints, Product Backlog, and Daily Stand-ups focus on structured
iterations, prioritized work, and regular team communication.
● Kanban:
● Emphasizes WIP Limits, Visual Boards, and a Pull System to
manage workflow efficiently and transparently.
● XP:
● Known for Pair Programming, Test-Driven Development (TDD),
and Frequent Releases, highlighting collaboration, quality assurance,
and customer feedback.

Lecture 4

Plan-driven Process Models

Plan-driven process models are characterized by their structured approach to software

development, where detailed planning, scheduling, and documentation precede the execution
of project activities. Among these models, the Waterfall and Prototype models stand out for
their distinctive methodologies and applications.

Waterfall Model

Overview:
● The Waterfall model is a sequential approach that divides the project into distinct
phases: specification, development, testing, and maintenance. Each phase must be
completed before moving to the next.
● It emphasizes a linear and plan-driven process, requiring thorough planning and
scheduling before project initiation.

Advantages:

● Clarity and Documentation: The structured approach provides clarity,

simplifies management, and emphasizes comprehensive documentation, making
 it easier to understand project progress and details.
● Well-defined Requirements: Ensures that requirements are clear and well-
defined from the outset, facilitating a smoother development process.
Limitations:

● Inflexibility: Offers limited flexibility for accommodating changes once the project is
underway, which can lead to challenges if requirements evolve.
● Late Feedback Incorporation: Customer feedback is integrated only at the end,
potentially resulting in a final product that may not fully meet customer expectations.

SWOT Analysis:
● Strengths: Clear, well-documented requirements and a structured approach
aid effective management.
● Weaknesses: Limited flexibility for changes and late detection of defects.
● Opportunities: The methodical structure is advantageous for managing large-scale
or safety-critical projects where stability is paramount.
● Threats: Potential for late discovery of issues, leading to costly revisions.

Applicability:
● Suitable for projects where requirements are well-defined and unlikely to change,
such as large-scale, safety-critical applications, or when a high degree of oversight is
needed.

Prototype Model

Overview:
● Involves developing a working prototype early in the development process to gather
user feedback and refine requirements. This model is especially beneficial when
project requirements are unclear or expected to change.

Types:
1. Throw-away Prototype: A preliminary model built to understand
requirements, which is discarded once its purpose is fulfilled.
● Example: A simple mock-up of a new application's user interface to
gather initial feedback before full-scale development.
2. Evolutionary Prototype: Continuously developed and refined based on user
feedback until it becomes the final product.
● Example: Developing a web application's core functionality and enhancing it
iteratively based on user testing.
3. Incremental Prototype: Combines elements of the final system developed in
increments, allowing testing and refinement of each part before moving to the next.
● Example: A complex system where individual modules are prototyped
and then integrated to form the complete system.
4. Extreme Prototype: Used mainly for web development, where the process starts with
a static mock-up, evolves into a functional prototype, and ends with the
implementation of the final solution.
● Example: Creating a static website layout, followed by adding dynamic
elements and backend functionality in stages.
Advantages:
● User Involvement: Ensures early and continuous user feedback, leading to higher
satisfaction and a product that aligns with user needs.
● Understanding and Refinement: Facilitates a deeper understanding of user
requirements and allows for early identification and correction of design flaws.
● Design Flaw Identification: Early prototype testing helps uncover and address design
issues, reducing later rework.

Limitations:
● Documentation and Maintainability: Rapid development may neglect thorough
documentation and long-term maintainability.
● Scope Creep: The iterative nature risks expanding project scope and timelines if not
carefully managed.

SWOT Analysis:
● Strengths: Direct user feedback and the ability to refine the system based on that
feedback enhance user satisfaction.
● Weaknesses: Potential for poor maintainability due to the focus on rapid
prototype development.
● Opportunities: Prototyping offers a unique opportunity to refine the system
continually based on user input.
● Threats: The iterative development process may lead to project delays if scope creep
is not controlled.

Spiral Model - Meta Model

Overview: The Spiral model is a sophisticated, risk-driven process model that integrates the
linear progression of the Waterfall model with the flexibility of iterative and incremental
development models. It's designed to accommodate complex projects by incorporating
thorough risk analysis and iterative enhancements within a structured framework.

Process:
1. Objective Determination: Identifying project goals and alternative solutions.
2. Risk Identification and Resolution: Analyzing potential risks at each phase
and developing strategies to mitigate them.
3. Development: Iteratively developing the next version of the product, incorporating
lessons learned from the risk analysis.
4. Review: Assessing the current phase's outcomes and planning for the next cycle.

Advantages:
● Risk Management: Proactively addresses risks throughout the development process,
allowing for timely adjustments.
● Adaptability: Capable of accommodating changes and refining the product based on
evolving customer feedback and project requirements.
Limitations:

● Complexity: Its comprehensive approach can be intricate and demanding to

implement.

● Cost: Potentially expensive due to the iterative nature and the need for ongoing risk
assessment.

SWOT Analysis:

● Strengths: Effective risk management and adaptability to changes.

● Weaknesses: Complexity and potential for high costs.
● Opportunities: Flexibility to refine the project based on feedback and changing
needs.
● Threats: Increased project costs due to extensive risk management and iterations.

V- model

Overview: An extension of the Waterfall model, the V-model emphasizes rigorous

verification and validation at each development phase, mapping development activities
directly to testing phases to ensure thorough quality checks.

Advantages:
● Quality Assurance: Ensures a high-quality product through systematic testing at
each phase.
● Early Defect Detection: Facilitates the identification and resolution of defects early
in the development process.

Limitations:
● Inflexibility: Struggles to adapt to changing requirements or project scope
adjustments.
● Potential Delays: The parallel development and testing phases can introduce delays if
issues are discovered late in the process.

SWOT Analysis:
● Strengths: High-quality deliverables due to integrated testing.
● Weaknesses: Lack of flexibility and potential for project delays.
● Opportunities: Early detection and resolution of defects.
● Threats: Delays and increased costs due to rigid structure and extensive testing
requirements.

Sequential Model Characteristics

● Customer Feedback: Lacks mechanisms for incorporating customer feedback during

development.
 ● Prototyping: Does not typically involve prototyping, focusing instead on predefined
deliverables for each phase.
● Test-centric: Well-suited for projects where thorough testing and validation
are critical.
● Rigidity: Each phase has specific deliverables and must be completed before moving
to the next, making it less adaptable to change.

When to Use Specific Models

● Waterfall Model: Best for large-scale projects with fixed requirements and a
clear understanding of the outcome. Suitable for projects requiring significant
oversight.
● Prototype Model: Ideal for projects with ambiguous or evolving requirements, where
early and continuous customer feedback is crucial to refine the system.
● Spiral Model: Suited for projects with complex requirements, significant risks, and
the need for regular evaluation and adaptation. Effective for long-term projects
requiring thorough risk management.
● V Model: Recommended for projects where test-driven development is paramount,
such as in military or defense systems, and for projects with well-defined
requirements.

Use Cases for Plan-Driven Models

● Critical Applications: Essential for safety-critical applications where stability
and reliability are more important than cost or time constraints.
● Stable Requirements: Projects with constant, albeit possibly vague, requirements
benefit from the structured approach of plan-driven models.
● High Oversight: Projects in regulated industries or those requiring a high degree of
accountability.

Summary of Software Process Models

● Waterfall: Linear and sequential, suitable for projects with well-defined stages
and stable requirements.
● Prototyping: Focuses on developing a quick prototype to clarify requirements, ideal
for projects with uncertain or evolving needs.
● Incremental Development: Builds the product in increments, allowing for feedback
and adjustments over time.
● Spiral: Combines features from Waterfall and Prototyping with a focus on
risk management, suitable for complex and high-risk projects.
● V Model: Emphasizes testing at each stage of development, ensuring a high-quality
outcome but may lack flexibility.

Choosing the Right Process Model

Selecting an appropriate process model depends on the project's complexity, stability of
requirements, criticality, and the level of user interaction needed. Models like the Spiral or V-
model are preferred for high-stakes projects requiring rigorous testing and quality assurance,
while Prototyping and Incremental Development offer flexibility for evolving requirements
and user feedback.
Lecture 4 continued(Requirement Engineering): Planning and Analysis Phase
Requirements
● Definition: A requirement is a condition or capability needed by a user to solve a
problem or achieve an objective, or a condition that a system must satisfy to fulfill a
contract, standard, specification, or other formally imposed documents as per IEEE
Standard Glossary 729.
Examples of Requirements
● Payment Records System: The system shall maintain records of all payments made
to employees, including salaries, bonuses, and allowances.
● Retail Store Interface: The system shall interface with the central computer to
send daily sales and inventory data from every retail store.
Stakeholders
● Project Stakeholders: Include Project Managers, Developers, and Business Analysts.
● Business Stakeholders: Comprise Project Sponsors, Users/Managers, and Subject
Matter Experts.
● External Stakeholders: Involve Suppliers, Customers, and Regulators.

Requirements Engineering (RE) is the systematic process of defining,

documenting, and maintaining software requirements. It is important because it
ensures that software meets user needs, reduces errors, minimizes project risks,
and improves overall project success.

How does Requirements Engineering help in minimizing project failures?

➡ RE helps by:

● Ensuring clear, well-defined requirements.

● Reducing miscommunication between stakeholders.
● Managing changing requirements effectively.
● Identifying technical and business constraints early.

Requirement Engineering Activities

● Elicitation: Gathering requirements from stakeholders via
interview,meetings and survey
● Documentation/Modeling: Recording and possibly creating models of the
requirements.
● Validation and Negotiation: Ensuring requirements accurately reflect
stakeholder needs and resolving conflicts.
● Management: Overseeing the development, tracking, and fulfillment of
requirements and any potential changes.
Requirement Types
● Business Requirements: Outline the objectives and scope of the project.
● User Requirements: Describe services the system will provide and constraints
under which it must operate. They are written for customers without technical
details.
● System Requirements: Provide a detailed description of functions, services, and
operational constraints. These are more technical and detailed than user requirements.

Examples of Requirements
● User Requirement: The system shall accurately compute sale totals, print
receipts, and update inventory counts.
● System Requirement Examples:
 ● Sales transaction identification.
● Association of sales items with sales IDs.
● Rebate processing within sales transactions.
● Single receipt printing per sale.

System Specification Examples

● User Requirement for Automated Bag Processing: The system shall process 5
bags per minute.
● System Requirement Detailing:
● Processing capability of 5 baggage events per minute in operational mode.
● Exception handling for scenarios exceeding 5 baggage events per minute.

Types of System Requirements

 ● Functional Requirements: Define the specific functions and operations of the
system.
● Quality Requirements: Address quality aspects not covered by
functional requirements, influencing system architecture.
● Constraints: Limitations that restrict the solution space beyond functional and quality
requirements.

Functional Requirements (FR)

Functional Requirements describe the specific behaviors or functions of a system. They detail
what the system should do and include tasks, data manipulation, and processing, directly
related to the system's functionality.
Examples:
1. Appointment Searches: A user can search appointment lists for all clinics.
2. Daily Patient Lists: The system generates a daily list of expected patients for each
clinic.
3. Staff Identification: Each staff member is uniquely identified by an eight-digit
employee number.
Non-Functional Requirements (NFRs)
Non-Functional Requirements specify criteria that judge the operation of a system, rather
than specific behaviors. They impact the overall architecture and can influence many
functional requirements.
Key Aspects:
● Implementation Differences: Affect how the system is designed and built.
● Architectural Impact: Influence the overall system architecture.
● Service Definitions: May define a new set of services or how existing services are
implemented.
Examples:
1. Product Requirement: Availability during working hours with limited downtime.
2. Organizational Requirement: Authentication using health authority identity cards.
3. External Requirement: Compliance with patient privacy standards.

Detailed Non-Functional Requirements

● Efficiency: The system should operate quickly without compromising speed.
● Storage: Use of minimal storage is emphasized.
● Usability: The system should be user-friendly.
● Reliability: High system reliability is required.
● Robustness: The system must be able to handle errors and recover from failures
efficiently.
Metrics:
● Speed: Measured in transactions per second, response times, and screen refresh times.
● Size: Specified in kilobytes or other units of measurement.
● Ease of Use: Determined by training time and the availability of help resources.
● Reliability: Includes mean time to failure, availability, and failure rates.
● Robustness: Evaluated by the system's recovery time after failure and the impact of
failures.
Functional vs. Non-Functional Requirements
1-5. Functional as they describe specific actions or tasks the system must perform, such as
browsing for events, selecting ticket prices, and choosing seats.
6-10. Mix of Functional and Non-Functional:
● Functional: Registered customers buying tickets, generating daily sales reports,
preventing double-booking, and requiring ad hoc reporting capabilities.
● Non-Functional: Backup of data nightly (related to reliability), displaying ticket
availability within five seconds (performance), and ensuring 24/7 ticket purchasing
(availability).

Requirement Elicitation Sources

● Stakeholders: Primary source of requirements, including users, managers, and
external parties.
● Documents: Standards, legal documents, and other universal documents provide a
basis for requirements.
● Systems in Operation: Existing systems, whether legacy or competitive, offer
insights into necessary features and potential improvements.
Requirement Categorization - Kano Model
● Dissatisfiers: Basic expectations that are taken for granted.
● Satisfiers: Explicitly demanded features and functionalities.
● Delighters: Unexpected features that enhance user satisfaction.
Elicitation Techniques
1. Survey Techniques: Interviews and questionnaires.
2. Creativity Techniques: Brainstorming, 6-3-5 method, and Six Thinking Hats
for perspective changes.
3. Document-centric Techniques: System archaeology and reuse of existing solutions.
4. Observation Techniques: Field observation to understand operational procedures.
5. Support Techniques: Mind mapping, workshops, CRC cards, audio/video
recording, action sequence modeling, and prototypes.
Requirement Specification Documents
● Informal: Natural language descriptions, which may lack clarity and structure.
● Semi-Formal: Use of conceptual models like Use Cases, Class Diagrams, Activity
Diagrams, and Statechart Diagrams to provide an overview of system functionality
and behavior.
● Formal: Mathematical specifications for precise requirement definition.
● Hybrid: Combines elements of informal, semi-formal, and formal documentation
methods.
Examples
● Structured Specification: Detailed description of a function, such as computing
insulin doses, including inputs, outputs, actions, pre-conditions, and post-conditions.
● Tabular Specifications: Conditions and actions presented in a table format for
clarity and ease of understanding.
Formal vs. Semi-Formal Documentation
● Formal Documentation: Offers precision and unambiguity but can be complex and
difficult for all stakeholders to understand.
● Semi-Formal Documentation: Provides a balance between detail and
accessibility, using models and diagrams to illustrate system aspects without the
complexity of formal mathematical notation.

Requirements Specification & Documentation:

Q16: What is a Software Requirements Specification (SRS) document?

➡ The SRS is a formal document that defines functional and non-functional
requirements, constraints, and expected system behavior.

Q17: What key components are included in an SRS?

➡ Key components include:

● Introduction (Project overview).

● Functional Requirements.
● Non-Functional Requirements.
● User Requirements.
● System Constraints.

Q18: Why is it important to write clear and unambiguous requirements?

➡ To avoid misinterpretation, reduce development errors, and ensure all stakeholders
have a shared understanding.

Requirements Validation & Verification

Q19: What is the purpose of Requirements Validation?
➡ Validation ensures that requirements accurately reflect user needs and align with
project goals.

Q20: What techniques are used for validating requirements?

➡ Techniques include:

● Reviews (Stakeholder discussions).

● Prototyping (Testing system models).
 ● Formal methods (Mathematical proof of correctness).

Q21: How does Requirements Verification ensure correctness in software projects?

➡ It checks if requirements are complete, feasible, and testable before development
starts.

7. Managing Changing Requirements

Q22: What is Requirements Management, and why is it needed?
➡ Requirements Management ensures that changes are tracked, prioritized, and
documented throughout the project.

Q23: How do agile methodologies handle changing requirements?

➡ Agile uses iterative development, allowing requirements to evolve based on feedback
through sprints.

Q24: What is scope creep, and how can it be controlled in a project?

➡ Scope Creep happens when additional requirements are added without proper control.
It can be controlled by:

● Setting clear priorities.

● Using a Change Control Board.
● Defining a strict project scope.

1. Fundamentals of Use Case Modeling

1.1 Introduction to Use Cases

Q1: What is a use case, and how does it help in requirement documentation?
➡ A use case is a structured description of how a user (actor) interacts with a system to
achieve a goal. It helps document functional requirements clearly, ensuring all stakeholders
understand system behavior.

Q2: How does use case-based requirement engineering assist in designing object-
oriented software?
➡ Use cases identify system interactions, which help in defining:
✔ Classes & objects needed.
✔ Methods & attributes for each class.
✔ System behavior & workflows.

Q3: Define scenario-based requirements elicitation and explain how it helps in

identifying system behavior.
➡ Scenario-based elicitation uses descriptive stories to extract system requirements.
✔ Helps stakeholders visualize real-world interactions.
✔ Converts user expectations into formal system behavior.

Q4: What is the significance of UML (Unified Modeling Language) in software

engineering?
➡ UML is a visual modeling language that standardizes software design representation.

Q5: List and explain three UML diagrams other than use case diagrams.
✔ Class Diagram – Represents system classes, attributes, and relationships.
✔ Sequence Diagram – Shows object interactions over time.
✔ State Diagram – Represents state transitions of an object.

Q6: How do use cases help in writing Software Requirements Specification (SRS)?
➡ Use cases serve as a foundation for functional requirements in an SRS by
defining:
✔ Actors, system behavior, and flows.
✔ Preconditions & postconditions.
✔ Exceptions & alternate scenarios.

2. Elements of a Use Case Diagram

2.1 Use Case Symbols & Components

Q7: Match the following UML symbols with their descriptions:

Symbol Description

🟢 Oval Represents a use case (system function).

👤 Stick Represents an actor (user or external

Figure system).

🔲 Rectangle Defines the system boundary.

➖ Solid Line Represents an association (interaction).

➔ Dotted Represents an extend relationship.

Arrow
Q8: What is the difference between primary actors and secondary actors in a use case
diagram?
➡ Primary Actor: Initiates interaction (e.g., Customer).
➡ Secondary Actor: Supports system operations (e.g., Payment Gateway).

Q9: Explain the purpose of system boundaries in a use case diagram.

➡ The system boundary (🔲) defines what is part of the system and what is external.

Q10: How do actors in a use case relate to system functionalities? Give an example.
➡ Actors interact with use cases to achieve their goals.
✔ Example: Customer ➡ "Place Order" in an e-commerce system.

3. Use Case Relationships

3.1 Association, Include, and Extend Relationships

Q11: Define the following relationships in use case diagrams:

✔ Association (➖) – Direct interaction between actor & use case.
✔ Include (➡) – Mandatory functionality shared between use cases.
✔ Extend (➔) – Optional behavior that occurs only in special cases.

Q12: Differentiate between include and extend relationships with suitable examples.

Featur Include Extend

e
Definit Mandatory sub-use case Optional behavior
ion
Examp "Checkout" ➡ «include» "Validate "Checkout" ➔ «extend» "Apply
le
Payment" Discount"

Trigge Always happens Only happens in specific cases

r

Q13: Identify whether the following statements represent Include or Extend relationships:

● ✔ "Logging in to the system is required before accessing any feature." → Include

● ✔ "A discount is applied only if the user enters a valid promo code." → Extend

Q14: Describe a real-world example where the Include relationship is essential in a

system.
✔ Example: Online Banking
"Transfer Money" ➡ «include» "Authenticate User"

Q15: Explain why the Extend relationship should be used sparingly in use case
diagrams.
➡ Extend relationships make diagrams complex and harder to maintain.

4. Writing Use Case Flow of Events

Q16: What are the four major components of a Use Case Flow of Events?
✔ Preconditions – Requirements before execution.
✔ Main Flow – Normal sequence of steps.
✔ Subflows – Additional steps within the main flow.
✔ Alternative Flows – Exceptions & errors.

5. Misuse Cases (Security & Privacy)

Q26: What is a misuse case, and how does it differ from a standard use case?
✔ Misuse case: Describes system threats.
✔ Standard use case: Describes intended interactions.

📌 Example:
👤 Hacker ➡ «threatens» Obtain Password ➡ Login System

Q28: Given the following security threats, create a misuse case for each:
✔ Hacker stealing user credentials
👤 Hacker ➡ «threatens» Brute Force Attack ➡ Login

✔ Fraudulent customer bypassing authentication

👤 Fraudster ➡ «threatens» Bypass Payment ➡ Checkout

6. Use Cases vs. User Stories

Q31: Compare use cases and user stories in Agile development.

Featu Use Case User Story

re
 Form Structured flow of One-liner requirement
at events

Purpo Defines system behavior Expresses user needs

se
Exam "Withdraw Cash" Use "As a user, I want to withdraw
ple Case cash."

Q32: When should an Agile team use user stories instead of use cases?
✔ When requirements are high-level & iterative.

7. Practical Scenarios & Advanced Use Case Relationships

Q34: Design a use case diagram for a soft drink vending machine.

📌 Actors & Use Cases:

👤 Customer ➖ Select Drink, Insert Money, Receive Drink
👤 Maintenance Staff ➖ Refill Machine

Q37: Identify potential misuse cases for an ATM machine and provide mitigation
strategies.
✔ Misuse Case: Hacker attempts to steal PINs
✔ Mitigation: Implement Two-Factor Authentication

In place of include comes extends if the relationship is optional btw use cases like discount
stuff in the payment method.
Steps for Drawing a Sequence Diagram

1. Identify the Use Case & Scenario

○ Define the process to model (e.g., "User Login").

○ Identify actors (users/external systems) interacting with the system.
○ List all objects (components) involved.
2. Draw Lifelines for Participants

○ Represent each actor & object with a vertical dashed line (lifeline).
○ Label each lifeline at the top.
3. Add Messages (Interactions)

○ Use solid arrows (→) for synchronous messages (caller waits for response).
○ Use dashed arrows (--> ) for asynchronous messages (no waiting).
○ Label each message with a verb (e.g., "Validate User").
4. Indicate Activation Bars

○ Draw thin rectangles on lifelines where objects are active (processing).

5. Add Return Messages

○ Use dashed arrows (---►) for responses from objects.

○ Label return messages with results (e.g., "User Found").
6. Handle Alternative Paths (If Needed)

○ Use Alt (Alternative), Opt (Optional), or Loop boxes for conditions &
loops.
7. Review & Optimize

○ Ensure logical flow of messages.

○ Check for missing interactions or alternative flows.
○ Keep the diagram simple & readable.

. Introduction to System Modeling

 ● System modeling is the process of creating abstract representations of a system.
● Helps in understanding system functionality and communicating with stakeholders.
● Now mostly done using graphical UML (Unified Modeling Language) notations.

Purpose of System Modeling:

✔ Helps analyze existing system strengths & weaknesses.

✔ Assists in requirement gathering for new systems.
✔ Helps in system documentation & design discussions.

2. Perspectives of System Modeling

System models can be viewed from different perspectives:

Perspective Description

External Defines system boundaries and interactions with external

Perspective entities.

Interaction Shows interactions between the system and external

Perspective components.

Structural Represents system architecture & data organization.

Perspective
Behavioral Models the system’s response to events (dynamic behavior).
Perspective

📌 Diagram Mentioned:
✔ Mentcare System Context Model – Example of external system dependencies.

3. UML Diagram Types (Used in System Modeling)

📌 The slides mention the following UML diagrams:

UML Diagram Purpose

Activity Shows workflow & process execution steps.

Diagram
Use Case Models user interactions with the system.
Diagram
Sequence Represents interactions between system components &
Diagram actors.
Class Diagram Displays system objects & their relationships.

State Diagram Shows state transitions based on system events.

4. Context Models & System Boundaries

Context Models:

● Illustrate system context (what’s inside vs. outside the system).

● Helps define external dependencies (e.g., databases, APIs).
● Architectural models show system structure & interactions.

System Boundaries:

✔ Defines what is inside and outside the system.

✔ Affects system requirements significantly.
✔ Often influenced by organizational & political factors.

📌 Diagram Mentioned:
✔ Mentcare System Context Model (Defining boundaries & external systems).

5. Interaction Models
● Interaction models focus on system-user and system-system interactions.
● Helps in detecting communication issues & performance problems.

📌 Diagrams Mentioned:
✔ Use Case Diagrams (models how users interact with the system).
✔ Sequence Diagrams (visualizes event flow between components).

Use Case Modeling:

✔ Developed for requirements elicitation.

✔ Each use case represents a specific task involving system interaction.
✔ Actors can be users or other systems.

📌 Diagram Mentioned:
✔ Mentcare System Use Case Diagram (e.g., Transfer Data Use Case).

6. Sequence Diagrams
 ● Models event sequences & object interactions in a system.
● Helps understand workflow execution in detail.

📌 Diagrams Mentioned:
✔ View Patient Information Sequence Diagram
✔ Transfer Data Sequence Diagram

✔ Components of a Sequence Diagram:

1. Actors & Objects – Who interacts with the system?

2. Lifelines – Vertical dashed lines showing object lifespan.
3. Messages (Arrows) – Communication between system components.

7. Structural Models
● Used to represent system architecture & relationships.
● Includes static (design-time) & dynamic (execution-time) models.

📌 Diagrams Mentioned:
✔ Class Diagrams – Shows objects & their relationships.
✔ MHC-PMS Class Diagram – Example from Medical Healthcare System.

✔ Key Concepts in Class Diagrams:

● Classes – Define objects in a system.

● Associations – Show relationships between objects.

8. Behavioral Models
● Shows how a system reacts to external/internal events.
● Includes:
1. Data-Driven Models – Focus on data processing & workflows.
2. Event-Driven Models – Models real-time event responses.

📌 Diagrams Mentioned:
✔ Insulin Pump Activity Diagram (Example of data-driven modeling).
✔ Microwave Oven State Diagram (Example of event-driven modeling).

✔ State Machine Models:

● Represent system states & transitions.

● Statecharts are used in UML to model state behavior.
9. Model-Driven Engineering (MDE)
● Approach where models drive software development instead of code.
● Helps in code generation from UML models.

📌 Diagrams Mentioned:
✔ MDA Transformations (Shows Model-Driven Architecture process).
✔ Multiple Platform-Specific Models (Mapping system models to platforms).

✔ Types of Models in MDE:

1. Computation Independent Model (CIM) – Business concepts.

2. Platform Independent Model (PIM) – System behavior without platform details.
3. Platform-Specific Model (PSM) – Adds platform-specific execution details.

✔ Pros of MDE:
✔ Reduces manual coding effort.
✔ Allows higher-level system abstraction.

✔ Cons of MDE:
❌ Requires specialized tools.
❌ Not widely adopted due to complexity & high cost.

10. Key Takeaways for Exam

Concept Key Points

System Modeling Abstract representation of system functionality.

Context Models Define system boundaries & external

dependencies.
Use Case Diagrams Show system interactions with external actors.

Sequence Diagrams Show event & message flow between objects.

Class Diagrams Represent system structure & object

relationships.

State Diagrams Model system state transitions.

Activity Diagrams Represent step-by-step business processes.

Structural Models Show system architecture & organization.

 Behavioral Models Model system behavior in response to stimuli.

Model-Driven Engineering Uses models to generate executable code

(MDE)

Class diagramms:

visibility notation:
○ + for public (visible to all classes)

○ - for private (visible only within the class)

○ # for protected (visible to subclasses)

○ ~ for package or default visibility (visible to classes in the

same
benefits of class diagrams:
● Class diagrams represent the system’s classes, attributes,

methods, and relationships, providing a clear view of its

architecture.

● They shows various relationships between classes, such as

associations and inheritance, helping stakeholders understand

component connectivity.

● Class diagrams serve as a visual tool for communication among

team members and stakeholders, bridging gaps between

technical and non-technical audiences

Example of designing a system modelfor ATm system:

Here's a summarized version of your readings for the System Modeling exam in a structured
bullet format:

1. Introduction to Object-Oriented Analysis and Design (OOAD)

● OOAD Process: Helps analyze project requirements and design an efficient system
before coding.
● UML (Unified Modeling Language): A widely accepted graphical language for
OOAD.
● Key Steps:
○ Define system requirements.
 ○ Identify system components (classes, objects).
○ Model interactions using UML diagrams.

2. System Requirements & ATM Case Study

● Requirements Document: Defines the system’s purpose and functionality.

● ATM System Overview:
○ Users can view balance, withdraw cash, deposit funds.
○ Authentication required via account number and PIN.
○ Transactions involve interacting with a bank database.
○ System interfaces with hardware like screen, keypad, cash dispenser, and
deposit slot.

3. UML Diagrams for System Modeling

● Use Case Diagram: Represents how external users (actors) interact with the system.
● Class Diagram: Shows system components (classes) and their relationships.
● State Machine Diagram: Models object states and transitions.
● Activity Diagram: Represents the sequence of operations performed by objects.
● Sequence Diagram: Shows interactions between objects in a specific sequence.

4. Identifying System Classes

● Extract Nouns from Requirements Document: These usually indicate potential

classes.
● Identified Classes for ATM:
○ ATM, Screen, Keypad, CashDispenser, DepositSlot, Account,
BankDatabase, BalanceInquiry, Withdrawal, Deposit.
● Class Relationships:
○ ATM is composed of Screen, Keypad, CashDispenser, and DepositSlot.
○ BankDatabase contains multiple Accounts.
○ Transactions (BalanceInquiry, Withdrawal, Deposit) interact with
BankDatabase.

5. Class Attributes & Object State Management

● Class Attributes:
○ ATM: userAuthenticated (Boolean)
○ Balance Inquiry: accountNumber (Integer)
○ Account: accountNumber, pin, availableBalance,
totalBalance
○ CashDispenser: count (Number of bills)
● State Diagrams:
○ Models object states and state transitions (e.g., ATM switches between
authenticated and unauthenticated states).
6. Activity Diagrams for Workflow Modeling

● Balance Inquiry Process:

1. Retrieve available balance from BankDatabase.
2. Retrieve total balance from BankDatabase.
3. Display both balances on Screen.
● Withdrawal Process:
1. Show withdrawal amount options.
2. Verify sufficient balance in user’s account.
3. Check if cash is available in ATM.
4. Dispense cash & update database.

7. Identifying Class Operations

● Operations represent object behaviors (methods).

● ATM Class:
○ executeTransaction()
○ authenticateUser()
● Account Class:
○ validatePIN()
○ getAvailableBalance()
○ debit(amount)
○ credit(amount)
● Transaction Classes (Withdrawal, Deposit, Balance Inquiry):
○ Each has an execute() method.

ACtivity state diagrams:

State transition diagram:
slide 8:
Architectural design:

Architectural Design Notes

1. Introduction
● Architectural design defines the high-level structure of a software system.
● It describes:
1. Components (modules, subsystems).
2. Relationships (how components interact).
3. Principles & constraints guiding system organization.
● It acts as a bridge between requirements engineering and implementation.
● Two main goals:
1. Ensure functional requirements are met.
2. Address non-functional requirements (performance, security, scalability).

2. Architectural Styles & Patterns

● An architectural style defines the general structure and interaction of system
components.
● Two broad categories:
○ Monolithic Architecture – One large codebase with tightly coupled
 components.
○ Distributed Architecture – Components communicate over a network.

Common Architectural Styles

1. Layered Architecture

○ Organizes the system into horizontal layers.

○ Each layer has specific responsibilities and interacts only with adjacent
layers.
○ Example: OSI Model (Networking), MVC (Web Applications).
○ Advantages:
■ Increases modularity and separation of concerns.
■ Enhances maintainability.
○ Disadvantages:
■ Can introduce performance overhead.
■ Strict separation may make interactions less efficient.
2. Client-Server Architecture

○ Clients send requests to a centralized server.

○ Server processes and responds to requests.
○ Example: Web applications (browsers as clients, web servers as backend).
○ Advantages:
■ Centralized control & management.
■ Scalable as more servers can be added.
○ Disadvantages:
■ Single point of failure if the server goes down.
■ High network dependency.
3. Microservices Architecture

○ System is divided into small, independent services that communicate over

APIs.
○ Example: Netflix, Amazon, Kubernetes-based apps.
○ Advantages:
■ Scalability – Each service scales independently.
■ Fault isolation – A failure in one service doesn’t break the whole
system.
○ Disadvantages:
■ Complex communication between services.
■ Difficult debugging due to distributed nature.
4. Pipe-and-Filter Architecture

○ Data flows through processing units (filters), each performing a

transformation.
○ Example: Compilers (Lexical Analysis → Parsing → Code Generation).
○ Advantages:
■ Easy to extend by adding new filters.
■ Reusability of components.
○ Disadvantages:
■ Performance overhead due to multiple processing stages.

3. Architectural Components & Considerations

 ● Structural Organization: Defines major system components and their layout.
● Interaction Patterns: Defines how components communicate (e.g., messaging, API
calls).
● Deployment Considerations: Whether components run on single or multiple
machines.
● Quality Attributes: Addressing scalability, security, performance, maintainability.

4. Architectural Decisions
● Two types of decisions:
○ High-Level Decisions (Overall structure, interaction model).
○ Low-Level Decisions (Technology stack, implementation details).
● Factors influencing decisions:
○ Scalability & Performance: Load balancing, caching.
○ Security Considerations: Authentication, encryption.
○ Maintainability & Modifiability: Ease of updates & extensions.
○ Reliability & Fault Tolerance: Redundancy, failover mechanisms.

5. Documenting Software Architecture

● Two types of documentation:
○ Technical Documentation: Includes diagrams, API references,
configuration details.
○ Design Rationales: Justifications for key architectural decisions.
● Architectural Views:
○ Logical View: Shows key components and their relationships.
○ Physical View: Represents hardware and deployment infrastructure.
○ Development View: Focuses on code structure and module interactions.
○ Process View: Describes runtime behavior and communication.
● UML Diagrams Used:
○ Use Case Diagrams – Show user interactions.
○ Class Diagrams – Show system components & relationships.
○ Sequence Diagrams – Show interactions between components.

slide 9:. Introduction

● OO design principles improve modularity, maintainability, and scalability of
software.
● Key Benefits:
○ Reduces tight coupling between components.
○ Enhances code reusability.
○ Makes debugging and modification easier.
● The SOLID principles are the foundation of good OO design.

2. SOLID Principles Overview

 ● SOLID is an acronym for five key OO design principles:
1. Single Responsibility Principle (SRP)
2. Open-Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

3. Detailed Explanation of SOLID Principles

1. Single Responsibility Principle (SRP)

● Definition: A class should have only one reason to change.

● Explanation:
○ Each class should focus on one responsibility.
○ If a class has multiple responsibilities, it becomes hard to modify.
● Example:
○ Bad Design: A User class handling both authentication and data storage.
○ Good Design: Separate AuthService for authentication and
UserRepository for data storage.
● Benefits:
○ Easier to understand, test, and modify.

2. Open-Closed Principle (OCP)

● Definition: A class should be open for extension but closed for modification.
● Explanation:
○ You should be able to add new functionality without modifying existing
code.
● Example:
○ Bad Design: Adding new file formats requires modifying a FileParser
class.
○ Good Design: Use polymorphism with an abstract Parser class and extend
new formats.
● Benefits:
○ Reduces regression bugs.
○ Improves code maintainability.

3. Liskov Substitution Principle (LSP)

● Definition: Subtypes must be substitutable for their base types.

● Explanation:
○ A derived class should extend behavior without changing parent class
expectations.
● Example:
○ Bad Design: A Rectangle class with setWidth() and setHeight()
breaks if extended into a Square class.
○ Good Design: Use a separate Square class without inheriting from
 Rectangle.
● Benefits:
○ Ensures consistent behavior in an inheritance hierarchy.

4. Interface Segregation Principle (ISP)

● Definition: A class should not be forced to implement methods it does not use.
● Explanation:
○ Large interfaces should be split into smaller, specific ones.
● Example:
○ Bad Design: A Printer interface with print(), scan(), and fax(),
forcing simple printers to implement unnecessary methods.
○ Good Design: Separate Printable, Scannable, and Faxable
interfaces.
● Benefits:
○ Avoids unnecessary dependencies.
○ Improves code clarity.

5. Dependency Inversion Principle (DIP)

● Definition: High-level modules should not depend on low-level modules. Both

should depend on abstractions.
● Explanation:
○ Avoid tight coupling by depending on interfaces rather than concrete classes.
● Example:
○ Bad Design: A DatabaseManager directly calling MySQLDatabase.
○ Good Design: DatabaseManager depends on a DatabaseInterface,
allowing easy database switching.
● Benefits:
○ Makes the system more flexible and testable.

4. Additional OO Design Best Practices

Encapsulation
● Hides internal details of a class and provides controlled access.
● Example: Use private variables with getter and setter methods.

Polymorphism
● Allows one interface, multiple implementations.
● Example: Different shapes (Circle, Square, Triangle) implementing a
common draw() method.

Cohesion vs. Coupling

● Cohesion: How focused a class is on a single task (high cohesion is better).
● Coupling: How dependent one class is on another (low coupling is better).
5. Summary
● SOLID principles help design scalable, maintainable software.
● Follow encapsulation, cohesion, and loose coupling for better OO design.
● Use interfaces and abstractions to improve flexibility

Feature Static Binding (Early Binding) Dynamic Binding (Late Binding)

Method Resolution Compile-time Runtime

Used Method overloading, static, final, Method overriding

for private methods (polymorphism)

Speed Faster (less overhead) Slower (dynamic lookup at runtime)

Flexibilit Less flexible (fixed method More flexible (polymorphism allows different
y calls) behaviors)

Exampl method(int a, int b) vs Dog.sound() overriding

e method(double a, double b) Animal.sound()

lecture 12:

DEsign principles:
1)Meangingful names:Use descriptive, intention-revealing names.

Avoid misleading names or abbreviations.

Class names should be noun phrases (e.g., UserManager, DatabaseHandler).

Method names should be verb phrases (e.g., calculateTotal(),

fetchUserData()).

Use consistent terminology for similar concepts.

2) Small, Focused Functions

● A function should do only one thing and do it well.

● Avoid long functions—each function should fit on one screen.
● Keep parameters minimal (preferably ≤2).
● Avoid deeply nested code (use early return)

3) Proper Use of Comments

● Write self-explanatory code, so comments aren’t needed.

● Only use comments to explain why, not what.
● Avoid redundant, misleading, or outdated comments.
● Good comments include legal notices, TODOs, and warnings.

4)Code Formatting and Structure

● Keep consistent indentation (use a linter).

● Limit line length (80-120 characters).
● Group related lines with blank spaces.
● Keep related functions near each other for readability

5) Keep Classes and Methods Small

● Each class should have a single responsibility.

● Avoid large, bloated classes—break them down.
● More small classes > Fewer large classes.
● Cohesion: A method should access most of the class variables.

6)

Error Handling with Exceptions (Not Return Codes)

● Use exceptions instead of returning error codes.

● Don’t clutter business logic with try-catch—handle exceptions separately.
● Provide meaningful error messages.
● Wrap third-party APIs to avoid exposing external exception

7)

Avoid Duplication

● DRY (Don't Repeat Yourself)—avoid repeating the same logic in multiple places.
 ● Extract common logic into reusable methods or utility classes.
● Use constants instead of repeating hardcoded values.

8) Encapsulation and Data Hiding

● Keep instance variables private (use getters and setters).

● Follow the Law of Demeter:
○ "A method should only call methods of its own class, objects it creates, or
parameters."
● Avoid exposing internal data structures directly.

9)Clean Boundaries (Third-Party Code)

● Minimize dependency on third-party libraries.

● Wrap third-party APIs in your own classes so changes don’t affect your whole
system.
● Write tests for third-party code usage.

10)write automated unit testcases for each component

lecture 13:

1⃣ Introduction to User Interface (UI)

● User Interface (UI): The point of interaction between a user and a system.
● Graphical User Interface (GUI): A UI that includes visual elements (buttons,
menus, icons).
● System Interface: Interface between software/hardware that requires minimal or no
user interaction.

2⃣ UI Design Objectives

To create an effective UI, focus on:

✔ Matching UI to the task – Ensure UI supports user goals.
✔ Efficiency – Reduce unnecessary steps and streamline workflows.
✔ Providing feedback – Show visual/auditory confirmation of actions.
✔ Generating usable queries – Enable easy data retrieval and filtering.
✔ Improving productivity – Help users complete tasks quickly and accurately.

3⃣ Types of User Interfaces

1⃣ Natural-Language Interfaces – Users interact using spoken or written language (e.g.,

Siri, Alexa).
2⃣ Question-and-Answer Interfaces – System asks questions, and the user responds
(e.g., online forms).
3⃣ WIMP Interfaces – Windows, Icons, Menus, Pointers (e.g., desktop OS).
4⃣ Graphical User Interfaces (GUIs) – UI with buttons, forms, and menus (e.g., mobile
& desktop apps).
5⃣ Gesture-Based Interfaces – Users interact using touch/swipe gestures (e.g.,
touchscreen devices).
6⃣ Voice-Based Interfaces – Users speak commands to interact (e.g., Google
Assistant).
7⃣ Command-Line Interfaces (CLI) – Text-based interface using commands (e.g., Linux
Terminal).

4⃣ Role of UI in Software

✔ To end users, UI = The System.

✔ UI provides access to system functionality & displays output.
✔ UI involves user perception (seeing, hearing, touching).
✔ Studied in Human-Computer Interaction (HCI).

5⃣ Good GUI Design Rules

1⃣ Understand People – Know user expectations and needs.

2⃣ Be Careful of Different Perspectives – Different users interact in different ways.
3⃣ Design for Clarity – UI should be self-explanatory and intuitive.
4⃣ Design for Consistency – Keep UI uniform across the system.
5⃣ Provide Visual Feedback – Indicate when actions succeed or fail.
6⃣ Be Careful With Audible Feedback – Use sounds thoughtfully to avoid distractions.
7⃣ Keep Text Clear – Avoid long, complex labels; use concise and meaningful words.
8⃣ Provide Traceable Paths – Allow users to easily navigate back.
9⃣ Provide Keyboard Support – Ensure UI can be used via keyboard shortcuts.
🔟 Watch the Presentation Model – Keep the layout clean and structured.
1⃣1⃣ Use Modal vs. Modeless Dialogs Appropriately –

● Use modal dialogs for important actions.

● Use modeless dialogs for optional interactions.
1⃣2⃣ Use Controls Correctly – Buttons, dropdowns, and inputs should behave as
expected.
6⃣ The UI Design Process
UI design is an iterative process involving:

1. User Analysis

● Understand what users will do with the system.

● Identify common tasks and workflows.

2. System Prototyping

● Develop interactive prototypes for user testing.

● Improve UI based on feedback.

3. Interface Evaluation

● Test UI with real users.

● Measure efficiency, usability, and satisfaction.

7⃣ User-Centered Design (UCD)

✔ Focuses on user needs over system constraints.

✔ Involves users throughout the design process.
✔ Always requires prototyping and testing before finalizing UI.

8⃣ General UI Design Principles

🔹 Accessibility → UI should be usable for all users, including those with disabilities.
🔹 Aesthetic Appeal → UI should be visually pleasing and engaging.
🔹 Availability → The system should be accessible anytime.
🔹 Clarity → Avoid clutter, keep information easy to find.
🔹 Consistency → Follow standard UI patterns across all pages.
🔹 Efficiency → UI should minimize extra steps for users.
🔹 Flexibility → Allow customization (e.g., dark mode, font size settings).
🔹 Safety → Prevent accidental actions (e.g., "Are you sure?" confirmations).
🔹 Visibility → Important elements should be easy to spot.

9⃣ HCI (Human-Computer Interaction) Principles

💡 Shneiderman’s “Golden Rules” (3C 2S)
✔ Control → User should control interactions, not the system.
✔ Consistency → Keep design elements uniform.
✔ Closure → Actions should have clear results.
✔ Reversal of Actions → Users should undo mistakes easily.
✔ Error Handling → UI should help users recover from errors.
✔ Feedback → Provide immediate responses to actions.
✔ Shortcuts → Offer quick actions for experienced users.
✔ Minimize Memory Load → Reduce how much users need to remember.

🔟 Key Takeaways
✅ A good UI = better user experience (UX).
✅ Simplicity and clarity improve usability.
✅ UI should be tested and refined iteratively.
✅ User-centered design ensures better adoption and satisfaction.

difference btw UI and UX:

Aspect User Interface (UI) User Experience (UX)

Definitio The visual and interactive The overall experience of a user while
n elements of a system. using a product.

Focus Looks and feel – Ensures the interface Usability and satisfaction – Ensures
is visually appealing and functional. users can achieve their goals smoothly.
 Include Colors, typography, buttons, layouts, Navigation, user journey,
s animations, icons, and responsiveness. accessibility, efficiency, and
emotions.

Goal Make the interface intuitive and Make the product user-friendly,
aesthetically pleasing. efficient, and enjoyable.

lecture 14:

Creational Patterns (Object Creation Mechanisms)

1. Factory Method – Defines an interface for object creation but lets subclasses decide
the concrete class.

○ Example: ShapeFactory returns Circle or Square based on input.

2. Abstract Factory – Provides an interface for creating families of related objects
without specifying their concrete classes.

○ Example: GUIFactory creates WinButton or MacButton depending on

OS.
3. Builder – Separates object construction from representation, allowing step-by-step
creation.

○ Example: CarBuilder builds a Car with different configurations (engine,

seats).
4. Prototype – Creates new objects by copying an existing object (cloning).

○ Example: DocumentPrototype.clone() returns a new document copy.

5. Singleton – Ensures only one instance of a class exists globally.

○ Example: DatabaseConnection.getInstance() provides a single

connection object.

Structural Patterns (Class and Object Composition)

6. Adapter – Allows incompatible interfaces to work together by acting as a translator.

○ Example: TPVCalcAdaptor adapts a third-party calculator library to a

standard interface.
7. Bridge – Decouples abstraction from implementation to allow independent changes.

○ Example: Shape (Circle, Square) uses DrawingAPI (OpenGL,

DirectX) for rendering.
 8. Composite – Treats individual objects and compositions of objects uniformly.

○ Example: Folder contains both File and other Folder objects.

9. Decorator – Dynamically adds responsibilities to objects without modifying them.

○ Example: TextView decorated with BorderDecorator,

ScrollbarDecorator.
10. Facade – Provides a simplified interface to a complex subsystem.

● Example: HomeTheaterFacade manages TV, SoundSystem, Lights.

11. Flyweight – Reduces memory usage by sharing common object state.
● Example: CharacterFactory reuses existing Character objects for text
rendering.
12. Proxy – Controls access to another object by acting as an intermediary.
● Example: RowLockTableProxy ensures row-level locking in a database.

Behavioral Patterns (Communication Between Objects)

13. Chain of Responsibility – Passes a request along a chain of handlers until one
processes it.
● Example: Logger passes logs to ConsoleLogger, FileLogger, or
EmailLogger.
14. Command – Encapsulates a request as an object, allowing undoable operations.
● Example: RemoteControl executes LightOnCommand or FanOffCommand.
15. Interpreter – Defines a language grammar and interprets sentences in that language.
● Example: ExpressionParser evaluates mathematical expressions like 3 + 5 *
2.
16. Iterator – Provides sequential access to elements of a collection without exposing its
structure.
● Example: TreeSet<Integer>.iterator() iterates through elements.
17. Mediator – Centralizes communication between multiple objects to reduce
dependencies.
● Example: ChatRoom mediates messages between users.
18. Memento – Captures and restores an object's state for undo functionality.
● Example: Game.saveState() stores progress and Game.loadState() restores
it.
19. Observer – Defines a dependency between objects so that when one changes, all
dependents are notified.
● Example: StockObserver updates when StockPrice changes.
20. State – Allows an object to change behavior based on its internal state.
● Example: CeilingFan switches between Off, Low, Medium, High states.
21. Strategy – Defines a family of interchangeable algorithms encapsulated in separate
classes.
● Example: SortContext switches between BubbleSort and QuickSort.
22. Template Method – Defines a skeleton algorithm in a base class, allowing subclasses
to override specific steps.
● Example: DataProcessor defines load(), process(), save() while
subclasses implement process().
23. Visitor – Adds operations to objects without modifying their classes.
● Example: TaxCalculator visits Product to compute tax.