Software Engineering

1
Page 5
• Software Types: System Software, Application Software, Embedded & Cloud
Software, AI & ML Software, Security Software, Game Software
Page 7
• Software Characteristics: Functionality, Reliability, Usability, Efficiency, etc.
Page 9
• Software Engineering Overview: Definition, Approach, Cost, Team, Lifecycle
Page 10
• Objectives: Quality, Cost, Timeliness, Satisfaction, etc.
Page 12
• Generic View: Process, Methods, Tools, Paradigms, Quality, Management
Page 14
• Layered Technology: Foundation, Process, Methods, Tools, Quality
Page 17
• Software Process Models: Importance, Guidance, Quality Control
Page 18
• Process Models: Waterfall, Prototype, Incremental, Spiral
Page 21
• Introduction: Complexity, Planning, Communication, Management
Page 23
• Managing Complexity: Design Goals, Modularity, Incremental Development
Page 24
• Role of Engineers: Programming-in-the-Small/Large, Communication, Modeling,
Teamwork
Page 25
• Key Points: Definition, Design Goals, Techniques, Examples
Page 27
• UML & Class Diagrams: Understanding UML, Class Components, Object-Oriented
Modeling
Page 29

2
 • UML Structure: Building Blocks, Class Diagram Concepts
Page 34
• UML & Object-Oriented Modeling: Overview, Levels, Class Diagrams
Page 37
• UML Example: Bank Accounts
Page 38
• UML Relationships: Associations, Aggregation, Composition
Page 41
• Key Points & Problems: Model Corrections, Diagram Components
Page 43
• UML Components: Classes, Attributes, Relationships
Page 44
• UML Detailed: Structure, Generalization, Inheritance
Page 47
• Constraints: Definition, Placement, Types
Page 48
• Constraints in UML Diagrams
o Basic Concept
o Types and Examples
Page 49
• Modeling Software Systems Using UML
o Summary: Class Name, Attributes, Operations, Associations
Page 51
• System Requirements Capture
o Overview, Types, Challenges, Activities
Page 53
• System Requirements Specification (SRS)
o Purpose, Writing, Best Practices, Domain Modeling

3
Page 56

• Eliminating Irrelevant Associations and Refining the Domain Model

o Rules and Examples

Page 59

• Building a Use-Case Model

o Overview, Use Cases, Actors, Diagram Creation

Page 63

• Specifying Use Cases

o Definition, Scenarios, Documentation

Page 66

• ASU Use-Case Model Specification

o Functionalities, Actors, Use-Case Diagram

Page 70

• Writing a Use Case Specification

o Structure: Name, Description, Actors, Preconditions, etc.

Page 74

• Specifying Extension Points and Alternative Flows

o Extension Points, Alternative Flows, Examples

Page 77

• Incorporating Subflows in Use Case Specifications

o Definition, Guidelines, Examples

Page 80

• Capturing Nonfunctional Requirements

o Types, Analysis, Examples

Page 83

• Validating System Requirements

o Key Aspects, Validation Process, Examples

Page 85

• .
Iterative Refinement Continuous Improvement, Iterative Process

Page 86

• What is class? Classs diagram ,Case study

4
 • Software and its types

software refers to a set of instructions, data, or programs used to operate computers and
execute specific tasks. It's the intangible counterpart to computer hardware.
Types of software can be broadly categorized as follows:
1. System Software:
o Operating Systems (e.g., Windows, macOS, Linux)
o Device drivers
o Firmware
o Utilities
2. Application Software:
o Desktop applications (e.g., word processors, web browsers)
o Mobile apps
o Web applications
o Enterprise software (e.g., ERP, CRM systems)
3. Programming Software:
o Compilers
o Interpreters
o Integrated Development Environments (IDEs)
o Debuggers
4. Middleware:
o Application servers
o Web servers
o Database management systems
5. Embedded Software:
o Software for embedded systems in devices and appliances
6. Cloud Software:
o Software-as-a-Service (SaaS)
o Platform-as-a-Service (PaaS)

5
 o Infrastructure-as-a-Service (IaaS)
7. Artificial Intelligence and Machine Learning Software:
o Neural network frameworks
o Machine learning libraries
8. Security Software:
o Antivirus programs
o Firewalls
o Encryption tools
9. Game Software:
o Video games
o Game engines
10. Simulation Software:
o Scientific simulations
o Training simulators
Each type of software serves different purposes and may require different development
approaches and technologies. Understanding these categories is crucial for software
engineers to specialize and develop expertise in specific areas.

6
Software Characteristics
software characteristics are essential attributes that define the quality and nature of a
software system. These characteristics help in evaluating, comparing, and designing
software. Here are the key software characteristics:
1. Functionality:
o The ability of the software to perform its intended functions and meet
specified requirements.
o Includes features, capabilities, and the overall purpose of the software.
2. Reliability:
o The consistency and dependability of the software's performance over time.
o Includes fault tolerance, recoverability, and maturity.
3. Usability:
o How easy it is for users to learn, operate, and interact with the software.
o Involves user interface design, documentation, and overall user experience.
4. Efficiency:
o The software's ability to perform tasks with minimal resource consumption.
o Includes time behavior (response time) and resource utilization.
5. Maintainability:
o The ease with which the software can be modified, updated, or enhanced.
o Involves aspects like modularity, reusability, and code readability.
6. Portability:
o The ability of the software to function across different environments or
platforms.
o Includes adaptability, installability, and replaceability.
7. Security:
o The software's capability to protect data and prevent unauthorized access.
o Involves confidentiality, integrity, and availability of information.

7
8. Scalability:
o The ability of the software to handle increased load or growing amounts of
data.
o Important for systems expected to grow over time.
9. Interoperability:
o The capability of the software to interact and exchange information with
other systems.
o Crucial for integration in complex environments.
10. Testability:
o How easily the software can be tested to verify its functionality and
performance.
o Affects the quality assurance process and overall reliability.
11. Flexibility:
o The ease with which the software can be adapted to changes in requirements
or environment.
o Related to maintainability but focused on future changes.
12. Reusability:
o The extent to which parts of the software can be used in other applications.
o Promotes efficiency in development across projects.

8
Software engineering
Software engineering is the systematic application of engineering principles, methods, and
tools to the design, development, maintenance, testing, and evaluation of software systems.
Here's a more detailed definition:
Software engineering is:
1. A disciplined approach: It involves applying structured methodologies and proven
practices to software development.
2. Engineering-focused: It emphasizes engineering principles like systematic planning,
design, and problem-solving.
3. Concerned with all aspects of software production: This includes not just coding, but
also requirements gathering, design, testing, deployment, and maintenance.
4. Aimed at creating high-quality software: The goal is to produce reliable, efficient, and
maintainable software that meets user needs.
5. Cost-effective: It aims to develop software within time and budget constraints.
6. Team-oriented: It often involves coordinating the efforts of multiple developers and
stakeholders.
7. Scalable: It provides methods for developing both small and large-scale software
systems.
8. Lifecycle-focused: It considers the entire software lifecycle, from inception to
retirement.
9. Process-driven: It employs defined processes and methodologies to guide
development.
10. Continuously evolving: The field adapts to new technologies, tools, and best
practices.
Software engineering addresses the challenges of creating complex software systems by
providing:
• Structured approaches to software development (like Agile, Waterfall, etc.)
• Tools and techniques for managing software projects
• Methods for ensuring software quality and reliability
• Strategies for handling the complexity of large software systems
• Practices for maintaining and evolving software over time

9
The objectives of software engineering
1. Deliver High-Quality Software:
o Produce reliable, efficient, and error-free software that meets user
requirements.
o Ensure the software is maintainable, scalable, and performs well under
various conditions.
2. Cost-Effectiveness:
o Develop software within budget constraints.
o Optimize resource utilization throughout the development process.
3. Timely Delivery:
o Complete projects within specified timelines.
o Manage development cycles efficiently to meet deadlines.
4. Customer Satisfaction:
o Create software that fulfills user needs and expectations.
o Ensure the end product is user-friendly and solves the intended problem
effectively.
5. Systematic Approach:
o Implement structured methodologies for software development.
o Apply engineering principles to bring discipline to the software creation
process.
6. Maintainability and Evolvability:
o Design software that can be easily maintained and updated over time.
o Ensure the system can evolve to meet changing requirements and
technologies.
7. Reusability:
o Develop components and systems that can be reused in other projects.
o Promote code reuse to increase efficiency and reduce development time.
8. Scalability:
o Create software architectures that can handle growth in data, users, or
functionality.

10
 o Ensure the system can be scaled up without major redesigns.
9. Reliability and Robustness:
o Develop software that operates consistently under various conditions.
o Build systems that can handle errors gracefully and recover from failures.
10. Security and Data Protection:
o Implement robust security measures to protect against vulnerabilities and
threats.
o Ensure data integrity and user privacy.
11. Interoperability:
o Create software that can effectively communicate and work with other
systems.
o Adhere to standards that promote integration with diverse technologies.
12. Efficiency:
o Optimize software performance and resource utilization.
o Develop solutions that make effective use of hardware resources.
13. Traceability:
o Maintain clear links between requirements, design, code, and tests.
o Ensure changes can be tracked and their impacts understood.
14. Continuous Improvement:
o Foster a culture of learning and adaptation to new technologies and
methodologies.
o Continuously refine processes based on feedback and experience.
These objectives collectively aim to produce software that not only works but does so
efficiently, reliably, and in a way that provides long-term value to users and stakeholders.
They guide software engineers in making decisions throughout the development process,
from initial planning to final deployment and maintenance.

11
The generic view of software engineering

provides a high-level, abstract perspective of the software development process. This view
helps in understanding the overall structure and flow of software engineering activities,
regardless of specific methodologies or project types. Here's an explanation of the generic
view:
1. Software Process: The software process is the foundation of the generic view. It
consists of a series of activities that lead to the production of a software product. The
main phases typically include: a) Requirements Engineering b) Design c)
Implementation (Coding) d) Testing e) Deployment f) Maintenance
2. Methods: These are systematic approaches to software development. They provide
guidelines for carrying out the activities in the software process. Examples include:
o Object-Oriented Analysis and Design
o Structured Programming
o Agile Methodologies (Scrum, XP, etc.)
o Model-Driven Development
3. Tools: Software tools support the methods and processes. They automate or semi-
automate various tasks in software development. Examples include:
o Integrated Development Environments (IDEs)
o Version Control Systems
o Testing Tools
o Project Management Software
4. Paradigms: These are overarching approaches or philosophies to software
development. Common paradigms include:
o Waterfall Model
o Iterative Development
o Incremental Development
o Spiral Model
5. Quality Focus: Quality assurance and control activities are integrated throughout the
process to ensure the software meets specified standards and requirements.
6. Project Management: This involves planning, monitoring, and controlling the
software project to ensure it's completed on time, within budget, and to the required
quality standards.

12
 7. People: The human aspect is crucial. This includes roles like developers, testers,
project managers, and stakeholders, as well as team dynamics and communication.
8. Product: The end result of the software engineering process - the software system
itself, along with associated documentation.
9. Technology: The underlying hardware, networks, and supporting software systems
that the developed software will run on or interact with.
This generic view emphasizes that software engineering is not just about coding, but a
comprehensive approach that considers various interrelated aspects. It provides a
framework for understanding how different elements of software development fit together,
regardless of the specific techniques or technologies used in a particular project.
The generic view helps software engineers to:
• Understand the overall structure of the development process
• Plan and organize projects effectively
• Identify and apply appropriate methods and tools
• Ensure all crucial aspects of software development are addressed
By providing this high-level perspective, the generic view of software engineering aids in
managing the complexity of software development and ensures a holistic approach to
creating software systems.

13
software engineering - a layered technology
Software engineering as a layered technology is a conceptual model that illustrates how
different aspects of software development build upon each other. This model, often
represented as a pyramid or a stack, helps to understand the interdependencies and
hierarchical nature of software engineering practices. Let's break down this layered
approach:
1. Foundation Layer: Quality Focus
o At the base of the pyramid is a commitment to quality.
o This layer emphasizes the importance of quality in all aspects of software
development.
o It includes quality assurance practices, standards, and continuous
improvement processes.
2. Process Layer
o Built on top of the quality foundation, this layer defines the framework for
software development.
o It includes the overall software development lifecycle and methodologies (like
Agile, Waterfall, etc.).
o This layer provides structure and organization to the development effort.
3. Methods Layer
o This layer consists of technical methods for building software.
o It includes practices for requirements analysis, design modeling, program
construction, testing, and maintenance.
o Examples: Object-oriented methods, structured programming, test-driven
development.
4. Tools Layer
o The tools layer provides support for the process and methods.
o It includes software tools and integrated environments that automate or
semi-automate process activities.
o Examples: IDEs, version control systems, testing tools, project management
software.
5. Top Layer: A Quality Focus
o The pyramid is capped with another quality layer, reinforcing that quality is
both the foundation and the goal.

14
 o This top layer represents the continuous assessment and improvement of the
software engineering approach.
Key Aspects of This Layered Approach:
1. Interdependence:
o Each layer depends on the layer below it.
o Tools support methods, methods are defined for processes, and processes are
grounded in the quality focus.
2. Integration:
o The layers are not isolated; they integrate and interact with each other.
o For example, tools often embody methods, and processes will dictate which
methods and tools are used.
3. Customization:
o Organizations can adapt this model to fit their specific needs and context.
o The exact composition of each layer may vary based on project requirements
and organizational culture.
4. Continuous Improvement:
o The model supports the idea of continuously refining and improving each
layer.
o Feedback from upper layers can lead to improvements in lower layers.
5. Holistic View:
o This layered approach provides a comprehensive view of software
engineering.
o It emphasizes that successful software engineering is more than just coding or
using tools.
6. Scalability:
o The model can be applied to projects of various sizes and complexities.
o It provides a framework that can be scaled up or down as needed.
Understanding software engineering as a layered technology helps professionals and
organizations to:
• Organize their approach to software development
• Ensure all crucial aspects are considered
• Identify areas for improvement

15
 • Align tools and methods with processes and quality objectives
This layered view underscores that effective software engineering is a multifaceted discipline
that requires attention to various interconnected aspects, all contributing to the ultimate
goal of producing high-quality software.

16
Software process models
Introduction to Software Process Models
What is a Software Process Model?
A software process model is a structured approach to planning, organizing, and managing
software development projects. It provides a framework for defining and managing the
phases and activities involved in software development, aiming to improve efficiency,
quality, and predictability.
Importance of Software Process Models
• Guidance: Provides a clear structure and guidelines for managing software projects.
• Consistency: Ensures uniformity in project practices and deliverables.
• Quality Control: Helps in maintaining high-quality standards through defined
processes.
• Risk Management: Identifies and mitigates risks early in the development lifecycle.
• Predictability: Enhances the ability to predict project outcomes and timelines.

17
Waterfall , prototype , incremental and spiral
1. Waterfall Model
Description:
The Waterfall Model is a traditional, linear approach to software development. It is one of
the earliest models and follows a straightforward, sequential process where each phase
must be completed before the next begins.
Phases:
1. Requirements Analysis: Gathering and documenting what the system should do.
2. System Design: Creating the architecture and design specifications.
3. Implementation: Coding the system based on the design.
4. Integration and Testing: Combining components and testing the system as a whole.
5. Deployment: Delivering the final product to users.
6. Maintenance: Addressing issues and making updates as necessary.
Characteristics:
• Sequential: Each phase is completed before the next one starts.
• Documentation-Heavy: Extensive documentation is created at each phase.
• Predictable: Clear structure and milestones.
• Challenges: Inflexible to changes once requirements are defined; late testing phase
may result in late discovery of defects.

2. Prototype Model
Description:
The Prototype Model focuses on creating a working model (prototype) of the software to
visualize and refine requirements through iterative feedback from users. It is useful for
projects with unclear or evolving requirements.
Phases:
1. Requirements Gathering: Initial requirements are collected.
2. Prototype Development: A preliminary version of the system is built.
3. User Feedback: Users interact with the prototype and provide feedback.
4. Refinement: The prototype is refined based on feedback and requirements are
updated.

18
 5. Final Development: The final system is developed using the refined requirements.
Characteristics:
• Iterative: Prototype is developed and refined through multiple iterations.
• User Involvement: Direct feedback from users helps in refining requirements.
• Flexibility: Accommodates changes more readily.
• Challenges: Prototypes may lead to scope creep; may not always represent the final
product accurately.

3. Incremental Model
Description:
The Incremental Model divides the system into smaller, manageable pieces or increments.
Each increment adds functionality to the previous one, and the system is developed and
delivered in parts.
Phases:
1. Requirements Analysis: Initial requirements are gathered.
2. System Design: Design is created for the first increment.
3. Implementation: The first increment is developed and delivered.
4. Evaluation: Feedback is gathered and used to plan the next increment.
5. Subsequent Increments: Additional increments are designed, implemented, and
evaluated until the system is complete.
Characteristics:
• Modular: System is built and delivered in increments.
• Feedback: Each increment allows for user feedback and adjustments.
• Flexibility: Changes can be accommodated in future increments.
• Challenges: Integration of increments may be complex; overall project management
requires careful planning.

4. Spiral Model
Description:
The Spiral Model combines iterative development with systematic risk management. It is
designed to handle large, complex, and high-risk projects by emphasizing repetitive
refinement and user feedback.

19
Phases:
1. Planning: Define objectives, constraints, and risks.
2. Risk Analysis: Identify and analyze risks; develop strategies for risk management.
3. Engineering: Develop and test prototypes or iterations of the system.
4. Evaluation: Review progress and obtain user feedback.
5. Iteration: Refine and repeat the cycle as needed until the final system is developed.
Characteristics:
• Iterative: Repeats through multiple cycles or spirals.
• Risk-Driven: Focuses on identifying and mitigating risks early.
• User Feedback: Frequent interaction with users to refine requirements.
• Challenges: Can be complex to manage; requires careful planning and risk
assessment.

Comparison Summary
• Waterfall: Best for projects with well-defined requirements; lacks flexibility.
• Prototype: Useful for projects with uncertain or evolving requirements; can lead to
scope creep.
• Incremental: Delivers functionality in stages; allows for user feedback and flexibility.
• Spiral: Ideal for large, complex projects with significant risk; emphasizes risk
management and iterative refinement.
Each model has its advantages and is suited to different types of projects. Choosing the right
model depends on factors such as project requirements, complexity, risk, and the need for
flexibility.

20
Lecture Introduction to Software Engineering: Key Points
Learning Objectives:
1. Appreciate the Complexity of Large Software Systems:
o Understand why developing large software systems is a complicated process.
o Recognize the sources of complexity in software development.
2. Techniques for Managing Complexity:
o Learn strategies and techniques to handle the complexity in software
development.
3. Importance of Software Engineering:
o Understand what software engineering is and why it is crucial in developing
software systems.
Key Concepts:
1. Software Complexity:
o Lines of Code: Large systems have millions of lines of code. For instance:
▪ Boeing 787: 14 million lines

▪ Windows 7: 14 million lines

▪ Windows 10: 15 million lines

o Planning: Implementation requires extensive planning, not just bottom-up

coding.
2. Sources of Complexity:
o Application Domain:
▪ Problems can be inherently complicated.

▪ Developers often lack expertise in the specific application domain (e.g.,

hospital management software).
o Stakeholder Communication:
▪ Different terminologies and background knowledge among stakeholders.

▪ Ambiguities in human language can lead to misunderstandings.

o Project Management:
▪ Coordination among multiple parts and people is necessary.

▪ The project needs to be divided into manageable pieces and then

reassembled.

21
 o Coding Challenges:
▪ The engineering process to create useful software is inherently
complicated.
3. Impact of Complexity on Software Quality:
o Reliability Issues:
▪ Example: Ariane 5 rocket failure due to a software bug.

o Safety Risks:
▪ Example: London Ambulance Service failure leading to fatalities.

o Project Abandonment:
▪ Example: London Stock Exchange System abandoned after five years due
to unreliability.
o Inflexibility:
▪ Systems that are hard to change and maintain.

4. Impact on Software Development:

o Over Schedule: Projects often take longer than planned.
o Over Budget: Costs frequently exceed estimates.
o Failure to Meet Requirements: Systems may not fulfill user needs.
o Measuring Progress: Difficult to track development progress effectively.
o Large Project Challenges:
▪ 17% face company-threatening issues.

▪ 45% go over budget.

▪ 7% are delayed.

▪ 56% deliver less value than expected.

22
Key Points for Studying Software Engineering Complexity
Managing Complexity through Design Goals
1. Setting Clear Design Goals:
o Importance: Establishing clear, prioritized design goals early in the project is
essential.
o Client Requirements: Understand and align with the client’s design goals.
o Conflicting Goals: Acknowledge that achieving all goals simultaneously is
often impossible due to time and budget constraints.
o Prioritization: Choose and focus on the most critical goals (e.g., efficiency,
reliability).
2. Modularity and Incremental Development:
o Divide and Conquer: Break down the large system into smaller, manageable
modules.
o Modular Definition: A module is a part of the system that can be considered
separately but interacts with other modules.
o Incremental Development: Build and integrate smaller modules one at a
time.
3. Information Hiding:
o Interfaces: Interact with modules through interfaces, achieving abstraction
and encapsulation.
o Abstraction: Skip details of the module’s internal implementation, focusing
only on how to use the interface.
o Encapsulation: Modify a module internally without affecting other modules.
4. Benefits of Modularity and Interfaces:
o Easier Understanding: Reduces the complexity of understanding the system.
o Maintainability: Simplifies system maintenance by isolating changes to
specific modules.
o Team Productivity: Enhances team productivity by allowing different teams to
focus on individual modules.
o Fewer Bugs: Leads to fewer bugs and more maintainable, reusable software.
o Predictability: Results in more predictable cost and time estimates.

23
Role of Software Engineers
1. Programming-in-the-Small:
o Coding: Focus on writing code and implementing individual functionalities.
2. Programming-in-the-Large:
o Beyond Coding: Involves activities beyond coding, such as:
▪ Communication: Engage with clients and users to understand and clarify
requirements.
▪ Modeling: Build system models at different abstraction levels for better
communication with stakeholders.
▪ Processes: Apply and use various software development processes.

▪ Design: Make appropriate design choices and trade-offs.

▪ Teamwork: Collaborate effectively as part of a development team.

Examples and Case Studies

1. Large Systems:
o Boeing 787: 14 million lines of code.
o Windows 7: 14 million lines of code.
o Windows 10: 15 million lines of code.
2. Complexity Impacts:
o Ariane 5 Rocket Failure: Demonstrates the critical impact of software bugs.
o London Ambulance Service: Failure led to fatalities due to software issues.
o London Stock Exchange System: Abandoned after five years due to
unreliability.

24
Key Points on Software Engineering
Definition and Scope of Software Engineering
1. Definition:
o Software engineering is a disciplined development method aimed at creating
quality software products that solve real user problems in specific application
domains.
o It involves team effort and multi-version management to handle various
versions of the software throughout its lifecycle.
2. Modeling Activity:
o Requirements Model: Captures all user and client requirements.
o Solution Model: The actual model used for implementation.
o These models must be aligned to ensure the final product meets user needs.
3. Problem-Solving Activity:
o Software engineering is systematic, not purely algorithmic, focusing on
finding appropriate solutions in the face of change.
o It involves continuous learning and sometimes unlearning incorrect
approaches, requiring flexibility and adaptability.
4. Rationale Management Activity:
o Documentation is crucial to track decisions, assumptions, and solutions,
ensuring clarity and rationale for choices made throughout the project.
o Revisiting and revising decisions as new information or changes occur is
essential.
Importance of Design Goals
1. Choosing Design Goals:
o Establish clear, prioritized design goals early in the project.
o Align with client requirements and focus on a few critical goals due to time
and budget constraints.
o Recognize and manage conflicting goals.
2. Effective Techniques:
o Modularity and Incremental Development: Break down large systems into
manageable modules and develop them incrementally.

25
 o Information Hiding: Use interfaces to interact with modules, achieving
abstraction and encapsulation.
▪ Abstraction: Users interact with the interface without needing to
understand internal implementation.
▪ Encapsulation: Modifications are confined to specific modules without
affecting others.
Role of Software Engineers
1. Programming-in-the-Small:
o Focus on coding and implementing individual functionalities.
2. Programming-in-the-Large:
o Encompasses broader activities beyond coding, such as:
▪ Communication: Engage with clients, users, and stakeholders to
understand and clarify requirements.
▪ Modeling: Create system models at different abstraction levels for
effective communication.
▪ Process Application: Apply various software development processes.

▪ Design: Make informed design choices and trade-offs.

▪ Team Collaboration: Work effectively within a team.

3. Real-World Examples:
o Boeing 747: 4 million lines of code.
o Modern Games: Around 6 million lines of code.
o Amazon Outage: A 90-minute outage caused by a software upgrade led to a
$2.8 million loss, highlighting the financial impact of software failures.
Summary
• Software engineering reduces complexity through disciplined methods, modularity,
incremental development, and effective communication.
• It encompasses both technical and non-technical activities, focusing on creating
maintainable, high-quality software systems that meet user needs.
• Continuous learning, adaptability, and thorough documentation are vital for
successful software engineering projects.

26
Key Points on UML and Class Diagrams in Software Engineering
Understanding UML
1. What is UML?:
o UML (Unified Modeling Language) is a general-purpose visual modeling
language used to represent systems.
o It incorporates best practices in object-oriented (OO) modeling techniques.
o UML is methodology-neutral, meaning it is not tied to any specific software
development process.
2. Purpose of UML:
o To build models representing the system to be developed.
o To capture important objects and their relationships within the software
system.
o To provide a common language for stakeholders to communicate and
understand the system's structure and behavior.
3. Components of UML:
o Building Blocks: Key elements used to construct the model.
o Relationships: Connections between different elements.
o Diagrams: Visual representations used to model different aspects of the
system.
o Common Mechanisms: Additional textual descriptions, adornments, and
definitions that enhance the model.
o Extensibility Mechanisms: Tools to extend the model's capabilities.
Class Diagrams in UML
1. Overview:
o A class diagram is used to capture all the data requirements within a software
system.
o It represents a collection of objects and their relationships.
o It is suitable for both OO and non-OO systems.
2. Basic Components of Class Diagrams:
o Classes: Represent the objects within the system.
o Associations: Relationships between classes.

27
 o Generalizations: Hierarchical relationships showing inheritance.
o Association Classes: Associations that also have attributes.
3. Applying Constraints:
o Additional constraints can be applied to class diagrams to specify more
detailed rules and behaviors.
Importance of Building Models
1. Communication:
o Models facilitate clear communication among stakeholders, ensuring
everyone has the same understanding of the system.
o They provide a visual representation that helps to align different perspectives
and ideas.
2. Abstraction:
o Models allow abstraction, focusing on the essential details and skipping the
non-essential complexities.
o This helps in managing the complexity of the system and understanding the
big picture.
3. Dealing with Complexity:
o By representing the system as a collection of objects, models help in
managing the complexity of software development.
o This approach leads to better design, more maintainable systems, and a
clearer understanding of requirements.
Object-Oriented Modeling
1. Natural Representation:
o OO modeling represents things using objects, making it a natural way to map
real-world entities to the system.
o Objects can represent organizations, people, cars, etc., and their
relationships.
2. Reducing the Gap:
o OO modeling reduces the gap between the application domain and the
model.
o It mirrors how people naturally think about and interact with the world,
making it easier to understand and communicate.
3. Types of Models:

28
 o Requirement Model: Captures all important objects and their relationships
within the application domain.
o Solution Model: Used for implementation, representing how the system will
be constructed.
4. Focus of the Course:
o The course focuses on two types of models:
▪ Requirement Model: To capture data requirements and important
objects.
▪ Solution Model: To design the implementation of the system.

5. Distinguishing Models:
o The requirement model is not concerned with implementation details. It
focuses purely on capturing what exists in the application domain.
o The solution model is concerned with how the system will be implemented
and includes more detailed design and implementation information.

29
Drawing a Class Diagram: Key Concepts
In this segment, we will delve into drawing a class diagram using key UML elements such as
classes, associations, association classes, and generalization. We will also discuss the
significance of these elements in representing a system, specifically focusing on a banking
system example.
1. Understanding Classes
• Definition: A class describes a collection of objects sharing common attributes,
operations, and relationships.
• Example: In a banking system, different bank accounts (Fred's account, Sam's
account, Eva's account) share attributes (account number, balance) and operations
(check balance, deposit money, withdraw money, pay interest).
• Key Elements of a Class:
o Class Name: Represents the general concept (e.g., Account).
o Attributes: Properties of the class (e.g., accountNumber, balance).
o Operations: Functions or methods the class can perform (e.g.,
checkBalance(), deposit(amount), withdraw(amount)).
• Classification:
o By identifying common attributes and operations, we classify various
instances into a single class.
o Example: Instead of referring to individual accounts, we refer to the class
Account.
• Good Class Design:
o A class should capture one and only one abstraction.
o Use appropriate vocabulary from the application domain for clarity and
traceability.
• Attributes in UML:
o Name and Type: Mandatory elements.
o Optional Elements: Visibility, initial value, multiplicity (whether multiple
values are allowed), changeability.
• Operations in UML:
o Signature: Includes the operation name and parameters.
o Return Type: Specifies what the operation returns.

30
 o Visibility: Indicates the accessibility of the operation (public, private,
protected, package).
2. Implementing a Class in a Bank System
• Class Example: Account
o Attributes: accountNumber: int, balance: float
o Operations:
▪ checkBalance(): float

▪ deposit(amount: float): void

▪ withdraw(amount: float): void

▪ payInterest(rate: float): void

• Instance vs. Class:

o Instance: A specific object (e.g., Fred's account).
o Class: The general concept used to create instances.
3. Associations
• Definition: Associations represent relationships between classes.
• Example: A Customer class may be associated with multiple Account classes.
• Multiplicity: Indicates how many instances of a class can be associated with
instances of another class.
o Example: A Customer can have multiple Accounts, but an Account is typically
associated with one Customer.
4. Association Classes
• Definition: An association class is used when an association itself has attributes or
operations.
• Example: If the association between Customer and Account needs additional
information (e.g., ownershipType), an association class can be created.
5. Generalization
• Definition: Generalization represents inheritance relationships where a subclass
inherits attributes and operations from a superclass.
• Example: SavingsAccount and CheckingAccount classes can inherit from a general
Account class.
• Generalization Example:
o Superclass: Account

31
 o Subclasses: SavingsAccount, CheckingAccount

Benefits of Using Classes and Objects

1. Natural Representation:
o Mapping real-world entities to objects reduces the gap between the
application domain and the model.
o Example: Representing bank accounts, customers, and transactions as
objects.
2. Modularity:
o Breaking down the system into manageable, cohesive classes promotes
modularity.
o Modular design aids in understanding, developing, and maintaining the
system.
3. Abstraction:
o Focus on essential details while omitting irrelevant complexities.
o Example: Capturing key attributes and operations of Account without delving
into implementation specifics.
4. Enhanced Communication:

32
 o Using a common modeling language like UML facilitates better
communication among stakeholders.
o Visual diagrams make it easier to convey and align understanding.
Conclusion
In summary, drawing class diagrams involves identifying and representing the key classes in a
system, their attributes, operations, and relationships. By employing UML effectively, you
can build a clear and concise model that captures the essential details of the system,
promotes modularity, and enhances communication among stakeholders.

33
Software Engineering: Modeling Software Systems using UML
Learning Objectives
1. Understand UML:
o Understand what UML (Unified Modeling Language) is.
o Learn how UML can be used to model software systems.
2. Modeling Language vs. Methodology:
o Recognize that UML is a modeling language and not a software
development methodology.
3. Basic Components of UML Class Diagrams:
o Learn the basic modeling components of UML class diagrams, such as class,
association, and generalization.
UML and Object-Oriented Modeling
Overview of UML
• General-purpose visual modeling language:
o Used for systems modeling.
o Incorporates best practices in object-oriented (OO) modeling techniques.
o Neutral in terms of software development methodology/process.
o Standard OO modeling language for modeling systems (also usable for non-
OO systems).
Basic Premise of UML
• Modeling a software system:
o A software system can be modeled as a collection of collaborating objects.
UML Structure
Building Blocks
• Things: Fundamental modeling elements.
• Relationships: Connections between things.
• Diagrams: Visual representations of a part of the system.
Common Mechanisms
• Specifications: Details about things and relationships.
• Adornments: Visual notations added to elements.

34
 • Common Divisions: Separation of concerns in models.
• Extensibility Mechanisms: Customization of UML.
Architecture
• Use-case view: Represents the functionality of the system.
• Logical view: Represents the structure of the system.
• Implementation view: Represents the organization of the system's components.
• Process view: Represents the dynamic aspects of the system.
• Deployment view: Represents the physical deployment of the system.
Why Build Models?
• Abstraction of Reality:
o Models describe reality succinctly by showing essential details and filtering
out non-essential ones.
• Focus on the "Big Picture":
o Helps in managing the complexity of software development.
o Facilitates a better understanding of requirements, cleaner designs, and
more maintainable systems.
Why Object-Oriented Modeling?
• Application Domain Representation:
o Models the application domain as a collection of objects.
o Reduces the "semantic gap" between the application domain and the
model.
o Better represents how people think about reality.
Levels of Abstraction in OO Modeling
• Requirements Level:
o Focus on identifying objects (concepts) in the application domain without
considering implementation aspects.
• Analysis & Design Level:
o Focus on how objects interact in the solution.
o Consideration of object interfaces but not internal aspects.
• Implementation Level:
o Focus on coding objects.

35
 o Consideration of all details of objects (both external and internal).
UML Class Diagrams
Class
• Class Definition:
o A class describes a collection of objects having common semantics,
attributes, operations, and relationships.
• Class Components:
o Attributes: Data values held by objects in a class.
o Operations: Functions or transformations that may be applied to or by
objects in a class.
• Naming Classes:
o Should use the vocabulary of the application domain.
o Class names must be unique and meaningful.
Association
• Association Definition:
o Describes a collection of links with common semantics between objects.
• Multiplicity:
o Specifies the number of objects in one class that may be related to an object
in another class.
• Aggregation and Composition:
o Special types of associations where there is a "part-of" relationship
between one class and another.
Association Class
• Combines an association with a class, allowing the association itself to have
attributes and operations.
Generalization
• Inheritance:
o Mechanism by which a class (subclass) inherits attributes and operations
from another class (superclass).
• Coverage:
o Describes how thoroughly the generalization relationship covers the
subclass.

36
Example: UML Class Diagram for Bank Accounts
• Class "Account":
o Attributes: account#, amount
o Operations: balance(), deposit(amount), withdraw(amount), payInterest()
• Class "Customer":
o Attributes: name, customerID
• Association "Holds" between "Customer" and "Account":
o Multiplicity: A customer can hold multiple accounts (1..*), an account can
be held by exactly one customer (1..1).
• Aggregation Example:
o Class "Bank" has a "Has" relationship with "Account", indicating that
accounts are part of a bank.
Modeling Software Systems Using UML
Key Points
• Model Reality:
o Use UML to abstract and model the reality of the system being developed.
• Focus on Essential Details:
o Concentrate on the essential details and filter out the non-essential ones to
manage complexity.
• Direct Representation:
o Use object-oriented modeling to directly represent "things" in the
application domain, making the model more intuitive and closer to how
people think about reality.

37
1. Associations
Associations are used to represent the relationships between different classes in a UML class
diagram. Here's how to effectively model them:
• Bidirectional Associations: These indicate that both classes are aware of each other
and can interact. For example, a Customer class and an Account class might have a
bidirectional association if customers hold accounts and accounts are held by
customers.
• Unidirectional Associations: Represented with an arrowhead, indicating that one
class depends on another. For instance, an Order might point to a Product, meaning
an order knows which products it includes.
• Multiplicity: Specifies how many instances of one class can be associated with
instances of another class:
o 1..*: One to many (e.g., one bank can have many accounts).
o 0..*: Zero to many (e.g., a customer might have no accounts or many
accounts).
o 1..1: Exactly one (e.g., an account is associated with exactly one customer).
2. Multiplicity Details
Multiplicity defines the range of valid links between classes:
• Lower Bound: The minimum number of instances.
• Upper Bound: The maximum number of instances.
• Special Notations:
o 1..1 can be simplified to 1.
o 0..* can be simplified to *.
3. Role Names
Role names clarify the nature of the association on either end, especially useful in
unidirectional or unary associations:
• Unary Association: This involves a single class. For example, Person may have a unary
association with itself to denote "manages" or "married to".
• Role Names in Unary Associations: Necessary to distinguish roles within the same
class (e.g., boss and worker).
4. Aggregation and Composition
These are specialized forms of associations that denote whole-part relationships:

38
 • Aggregation (hollow diamond): Represents a whole-part relationship where the part
can exist independently of the whole. Example: A Department (whole) and an
Employee (part) – an employee can exist without a department.
• Composition (filled diamond): A stronger form of aggregation where the part cannot
exist without the whole. Example: A House (whole) and a Room (part) – a room
cannot exist independently of a house.
Practical Example for Bank System:
Here's how we might represent some of these relationships in a class diagram for a banking
system:
Classes and Associations:
• Customer: Attributes: customerID, name, address
• Account: Attributes: accountNumber, balance
o Operations: checkBalance(), deposit(amount), withdraw(amount),
payInterest()
• Bank: Attributes: bankID, bankName
Associations:
• Customer-Account:
o Association: holds
o Multiplicity: 1..* (A customer can hold multiple accounts)
o Role Names: accountHolder, customerAccount
• Account-Bank:
o Association: belongs to
o Multiplicity: 1..1 (An account belongs to exactly one bank)
Aggregation/Composition:
• Bank-Branch (Aggregation):
o Association: has
o Multiplicity: 1..* (A bank has multiple branches)
• Branch-Employee (Composition):
o Association: employs
o Multiplicity: 1..* (A branch employs multiple employees)

39
40
Key Points and Problems Identified:
1. Initial Incorrect Models:
o Grade as an attribute of Student: This is not feasible as we cannot determine
how many grade attributes are needed for each student.
o Multi-valued attribute for Grade: This approach does not indicate which
grade corresponds to which course.
2. Correcting the Model with an Association Class:
o The initial attempt was to use an association class EnrollsIn between Student
and Course to store grades. However, this model does not allow for tracking
multiple enrollments of the same student in the same course.
3. Final Correct Model:
o Introducing the concept of Offering, which represents a specific instance of a
course offered in a particular semester.
o Students enroll in different offerings of courses, which allows tracking
multiple enrollments and the grades associated with each specific offering.
UML Class Diagram Components:
1. Classes:
o Student
o Course
o Offering
2. Attributes and Relationships:
o Student has attributes such as studentID, name, etc.
o Course has attributes such as courseID, courseName, etc.
o Offering has attributes such as offeringID, semester, and year.
o Association between Student and Offering with an attribute grade.

41
Diagram Details:
1. Student Class:
o Attributes: studentID (unique identifier), name (student's name), and possibly
other attributes like age, major, etc.
2. Course Class:
o Attributes: courseID (unique identifier), courseName (name of the course),
and possibly other attributes like credits, department, etc.
3. Offering Class:
o Attributes: offeringID (unique identifier), semester (semester offered), year
(year offered), and possibly other attributes like instructor, location, etc.
4. Associations:
o Student to Offering: A student enrolls in an offering of a course, and this
relationship includes an attribute grade.
o Course to Offering: A course can have multiple offerings over different
semesters and years.

42
 The correct UML class diagram for the given scenario uses the Offering class to represent
different instances of courses being offered in various semesters. This allows the system to
keep track of multiple enrollments and grades for the same student in the same course
across different semesters.
An association class EnrollsIn is used to capture the grade attribute, providing a clear
mapping between a student, a specific course offering, and the grade received.

43
1. UML and Object-Oriented Modeling
• Overview of UML: UML is a standardized modeling language used to specify,
visualize, construct, and document the artifacts of a software system.
• Object-Oriented Modeling: This involves modeling a system using objects that
interact with each other. It emphasizes modeling real-world entities and their
interactions.
2. Class
• Attributes: Characteristics or properties of a class. For example, a Student class might
have attributes like name, studentID, and grade.
• Operations: Functions or methods defined in a class. For example, a Student class
might have operations like enrollInCourse() or updateGrade().
3. Association
• Multiplicity: Indicates how many instances of a class are related to instances of
another class. For example, one Student can be enrolled in multiple Courses, but a
Course can have multiple Students.
• Aggregation and Composition: Aggregation represents a "whole-part" relationship
where the part can exist independently of the whole, while composition implies a
stronger lifecycle dependency where the part cannot exist without the whole.
• Association Class: Used when an association itself has attributes. For example, in the
EnrollsIn association between Student and Course, the grade achieved in a course
could be represented as an attribute of the association.
4. Generalization
• Inheritance: A mechanism to define a new class based on an existing class, inheriting
its attributes and operations. For example, Savings and Checking accounts might
inherit from a general Account class.
• Coverage: Describes whether all possible instances of a superclass are covered by
subclasses (complete vs. incomplete) and whether instances can belong to more
than one subclass (overlapping vs. disjoint).
5. Constraints
• Constraints: Conditions or rules applied to model elements that must be satisfied.
For instance, a PreferredSavings account must always have a balance greater than
$100,000.
• Object Constraint Language (OCL): A formal language used to describe rules and
constraints in UML models.

44
6. Modeling Software Systems
• Static Modeling: Focuses on the structure of the system. Examples include class
diagrams and object diagrams.
• Dynamic Modeling: Focuses on the behavior and interactions over time. Examples
include sequence diagrams and state diagrams.
7. Example Scenarios
1. Grade in a Course:
o Use an association class if grades are associated with the combination of
Student and Course. This allows you to manage grades as attributes of the
association.
2. Generalization Examples:
o Bank Accounts: Account can be a superclass with Checking and Savings as
subclasses.
o Payment Types: Cash, CreditCard, and DebitCard could be subclasses of a
Payment superclass.
3. Constraints in Models:
o Use constraints to enforce rules such as "An account must be associated with
either a person or a company, but not both."

45
Generalization and Inheritance
1. Definition:
o Generalization: A relationship between classes where one class (the
superclass) is a general form, and the other classes (subclasses) are more
specific forms of the superclass.
2. Top-Down Specialization:
o Start with a broad class and specialize it into more specific classes.
o Example: Start with a general Account class. Specialize it into
CheckingAccount and SavingsAccount, adding specific attributes and
operations to each subtype.
3. Bottom-Up Generalization:
o Identify similarities between classes and generalize them into a common
superclass.
o Example: Combine CheckingAccount and CreditCardAccount into a more
general Account class, with common attributes and operations, and then
specialize it back into the more specific types.
4. Benefits:
o Reduces Redundancy: Common attributes and operations are defined only
once in the superclass.
o Promotes Reusability: Subclasses inherit and reuse the common functionality
from the superclass.
o Simplifies Modifications: Changes to shared attributes or operations only
need to be made in the superclass.
5. Overriding:
o Subclasses can provide their own implementation of operations defined in
the superclass. This is known as overriding.
o Example: If a Withdraw operation is defined in both the Account superclass
and the CheckingAccount subclass, the CheckingAccount subclass will use its
own Withdraw method.
6. Levels of Inheritance:
o Single Inheritance: One level of inheritance from a superclass to a subclass.
o Multi-Level Inheritance: Subclasses inherit from other subclasses, creating a
chain of inheritance.

46
 o Recommendation: Limit inheritance to 3-4 levels to maintain clarity in the
class diagram.
7. Abstract Classes:
o Definition: A class that cannot have instances on its own. It is used to define
common attributes and operations for its subclasses.
o Example: An abstract Account class that defines common attributes and
operations for CheckingAccount and SavingsAccount.
8. Coverage Types:
o Disjoint: Instances of the superclass belong to only one subclass.
o Overlapping: Instances of the superclass can belong to more than one
subclass simultaneously.
o Complete: All instances of the superclass are covered by its subclasses.
o Incomplete: Some instances of the superclass may not be covered by any
subclass.
9. Examples of Coverage:
o Overlapping and Complete: Payment methods like cash, credit card, and
debit card, where multiple methods can be used together.
o Disjoint and Complete: Personal and Business accounts, where an account is
strictly one or the other.
Practical Advice
• Use abstract classes to define common attributes and operations that will be shared
among multiple subclasses.
• Avoid excessive levels of inheritance to ensure the class diagram remains
understandable and maintainable.
• Specify coverage constraints to clarify the relationships and ensure the model
accurately represents the real-world domain.

47
Constraints in UML Diagrams
1. Basic Concept of Constraints:
o Definition: A constraint is a statement that can be tested to be either true or
false. It ensures that certain conditions are met within the system.
o Example: For a PreferredSavings account, a constraint might be that the
balance must always be greater than or equal to $100,000.
2. Placement of Constraints:
o On Operations: Constraints can be specified next to operations to describe
conditions that must be true when the operation is performed. For example,
a checkBalance operation might have a constraint that the balance must be
greater than or equal to $100,000.
o On Classes: Constraints can be applied directly to classes to indicate rules that
apply to instances of that class. For example, the PreferredSavings class might
have a constraint that its balance attribute must meet certain criteria.
o Using Notes: Constraints can be documented using notes in UML diagrams. A
note provides additional information about the constraints and can be
attached to classes or associations. For instance, you might use a note to state
that "For PreferredSavings accounts, balance must be greater than or equal to
$100,000."
3. Types of Constraints:
o Ordering: Specifies the order of elements in a collection. For example, a
waitlist for courses might need to be managed in a FIFO (First-In-First-Out)
order.
o Subset: Indicates that a set of elements is a subset of another set. For
example, a Chair of a committee is a subset of Members of that committee.
o Exclusive OR (XOR): Defines that only one of the possible conditions is true at
any given time. For example, an Account can be held by either a Person or a
Company, but not both simultaneously.
4. Implementation of Constraints:
o Enforcement: Constraints should be enforced in the system’s implementation.
For example, the system must ensure that the balance of a PreferredSavings
account is always checked against the constraint during transactions or
balance updates.
o Documentation: Constraints can be documented in UML diagrams and should
be communicated clearly to ensure they are understood and implemented
correctly.

48
 5. Examples:
o Balance Constraint: In a PreferredSavings account, the constraint {balance ≥
100000} ensures that the balance cannot fall below $100,000.
o Waitlist Ordering: {ordered, FIFO} indicates that students on a waitlist are
processed in the order they were added.
o Exclusive OR: {xor} constraint on Account indicates that it is either held by a
Person or a Company, but not both.
6. Modeling Data Requirements:
o Class Diagrams: Used to model data requirements within an application
domain. For example, classes like Item, Order, Invoice, Account, and VIP might
be used to capture and organize data requirements.
7. Modeling Programs:
o Class Diagrams: Also used to model programs, showing how different
components like Clients, EventHandlers, and GUIHandlers interact within the
system.
Conclusion
Constraints play a crucial role in UML diagrams by defining rules and conditions that must be
met within the system. They ensure that the system adheres to specific requirements and
business rules, and they can be applied at various levels including operations, classes, and
associations. Proper documentation and enforcement of these constraints are essential for
maintaining the integrity and correctness of the system.

49
50
System Requirements Capture
Overview: System requirements capture is a crucial phase in the software development
process that focuses on understanding and documenting what the system must achieve. This
involves gathering requirements from clients and other stakeholders to ensure that the final
product meets their needs and expectations. Here's a concise summary of the key points
from the lecture:
Learning Objectives:
1. Understand what requirements capture is and its role in software development.
2. Recognize the importance and challenges of requirements capture.
3. Learn the major activities involved in requirements capture.
4. Use UML to model data and functional requirements with class diagrams and use
case diagrams.
5. Understand the importance of validating system requirements.
What is Requirements Capture?
• Definition: A requirement is a feature or constraint that the system must satisfy to be
accepted by the client. Requirements range from high-level statements to detailed
specifications.
Types of Requirements:
1. User Requirements: Written in natural language, often accompanied by diagrams,
describing the system's features and constraints from a user's perspective.
2. System Requirements: Detailed descriptions of system functionalities and
constraints, serving as a contract between the client and the developer.
Purpose of Requirements Capture:
• Specifies the system's behavior and ensures that all requirements are understood
before moving to the design and implementation phases.
• Helps in project planning by defining what needs to be done, which in turn aids in
scheduling and resource allocation.
Challenges in Requirements Capture:
• Client Uncertainty: Clients may not always know what they want. It's the software
engineer's role to translate vague requirements into precise specifications.
• Stakeholder Collaboration: Capturing requirements involves coordinating with
multiple stakeholders, each with different backgrounds and expectations.

51
Activities in Requirements Capture:
1. Understand the Application Domain: Gain insight into the context and constraints of
the application.
2. Identify User Needs: Determine what users expect from the system.
3. Assess Risks: Identify potential issues in developing the system.
4. Capture System Requirements: Use domain models (class diagrams) for data
requirements and use case models for functional requirements.
5. Validate Requirements: Ensure that captured requirements are both correct and
complete.
Modeling Tools:
• Class Diagrams: Used for modeling data requirements and capturing entities and
their relationships.
• Use Case Diagrams: Represent functional requirements and interactions between
users and the system.
Importance of Documentation:
• System Requirements Specification (SRS): An official document that outlines user
and system requirements. It is not a design document but serves as a basis for design
and implementation.
• Documentation Helps Reduce Errors: Capturing and documenting requirements
helps prevent issues that arise from incomplete or misunderstood requirements.
Conclusion:
• Even with Agile Methods: While agile methods like Scrum emphasize flexibility,
capturing requirements in a product backlog remains essential.
• Documentation Methods: Requirements can be documented using natural language,
structured templates, graphical notations, or design description languages. For this
course, the focus is on graphical notations and templates.
Summary: Requirements capture is a foundational activity in software development. It
involves understanding, documenting, and validating what the system should do before
diving into design and implementation. Using UML diagrams and proper documentation
helps ensure that all requirements are accurately captured and addressed.

52
System Requirements Specification (SRS)
Overview: The System Requirements Specification (SRS) is a crucial document that outlines
what is required from a software system. It serves as the official record of the system's
requirements and is essential for guiding both the development and validation phases.
Key Points:
1. Purpose of the SRS:
o Documents Requirements: Defines what the system should do and the
constraints it must operate under.
o Not a Design Document: It specifies WHAT the system should achieve, but
not HOW it should achieve it. Design details are reserved for later stages.
2. Writing an SRS:
o Natural Language: Describes requirements using sentences, supplemented by
diagrams and tables.
o Structured Natural Language: Uses a restricted language or template to
standardize the description of requirements.
o Graphical Notations: Employs diagrams (e.g., UML) along with text
annotations to represent requirements.
o Design Description Languages: Uses specialized languages akin to
programming languages for specifying requirements.
o Mathematical Specifications: Utilizes mathematical notations to describe
requirements in a precise and formal manner.
System Requirements Capture Outline:
1. System Requirements Capture Overview:
o Life-cycle Role: Details the role of requirements capture in the software
development life cycle.
o Importance: Highlights why capturing requirements accurately is vital for the
success of a project.
o Challenges: Discusses why requirements capture can be challenging, such as
dealing with vague requirements and diverse stakeholder needs.
2. System Requirements Capture Activities:
o Capture Data Requirements (Domain Modeling): Identifies and models the
data entities and their relationships.
o Capture Functional Requirements (Use-Case Modeling): Defines the
functions the system must perform and the interactions with users.

53
 o Capture Nonfunctional Requirements: Includes performance, security, and
other quality attributes.
o Validate System Requirements: Ensures that the requirements are correct,
complete, and feasible.
Domain Modeling
Purpose: Domain modeling captures the essential classes and their associations within a
system based on user requirements. It helps in understanding the data that needs to be
stored and the relationships between different data entities.
Identifying Classes and Associations:
• Classes: Represent business objects, real-world objects, concepts, or events. These
are typically nouns or noun phrases found in user requirements.
• Associations: Represent the relationships between classes, often described using
verbs or verb phrases.
Best Practices:
• Relevance: Include only those classes and associations that are essential and stable.
Exclude transient or irrelevant elements.
• Stability: Aim for a stable system by focusing on persistent data rather than transient
aspects.
• Specificity: Ensure classes are well-defined and specific to avoid vagueness.
Evaluating Classes:
• Irrelevance: Remove classes that do not contribute to the domain model.
• Vagueness: Clarify or eliminate vague classes.
• Redundancy: Keep the most descriptive classes if duplicates are found.
• Attributes vs. Classes: Decide if concepts should be represented as classes or
attributes based on their dependency.
Evaluating Associations:
• Irrelevance: Remove associations that do not add value to the model.
• Operations: Ensure associations describe structural properties rather than
operations.
• Simplicity: Decompose complex ternary associations into simpler binary ones where
possible.
• Redundancy: Avoid derived associations that introduce redundancy.
Attributes:

54
 • Identification: Attributes should be closely related to their class and represent data
specific to the class.
• Classes vs. Attributes: Determine if some attributes should be classes themselves.
• Association Classes: Use them for attributes dependent on the existence of an
association.
• Object Identifiers: Do not include object identifiers as attributes in the domain
model.
Domain Modeling: Detail
For each class:
• Attributes: Specify the name, type (e.g., string, integer), and multiplicity.
• Associations: Define the name, role names (if needed), multiplicity, and association
class (if necessary).

55
Eliminating Irrelevant Associations and Refining the Domain Model
In domain modeling, it's important to keep the class diagram clear and meaningful. Here are
some rules and considerations for refining your model by eliminating irrelevant associations
and attributes:
Rules for Eliminating Associations
1. Irrelevant Associations:
o Remove associations that do not contribute to understanding the domain or
are not essential for capturing the core relationships between classes.
2. Operational Associations:
o If an association represents an operation or action rather than a structural
relationship, eliminate it. Associations should describe structural properties,
not operations.
3. Ternary Associations:
o Ternary associations (involving three classes) can make diagrams complex and
hard to read. If possible, decompose ternary associations into multiple binary
associations to simplify the diagram.
4. Derived Associations:
o If an association can be derived from other existing associations, consider
removing the redundant association. For example, if you can traverse from A
to B via C, and you have a direct association from A to B, you might eliminate
one of the associations. However, be careful to retain associations that
provide unique or essential information.
Example Scenario
Consider a class diagram tracking transactions for accounts and customers. In this example,
you might encounter:
• Cycle in Diagram: A cycle indicates interdependencies that might complicate the
diagram. Removing associations to break the cycle should be done with care,
ensuring that the essential information is preserved.
• Information Loss: If removing an association results in loss of information, such as
identifying which customer initiated a transaction, it is essential to retain that
association. For instance, the association Makes may be necessary to determine the
transaction initiator.

56
Evaluating Attributes
1. Relevance:
o Ensure attributes are closely related to their respective classes. Attributes
should directly describe the properties of a class and should be removed if
irrelevant.
2. Classes vs. Attributes:
o Evaluate if certain attributes should be represented as classes instead. For
instance, if an attribute represents a distinct concept that warrants its own
class, create a class for it.
3. Association Classes:
o If an attribute depends on the existence of a relationship between two
classes, place it in an association class rather than directly in the related
classes.
4. Object Identifiers:
o Object identifiers (IDs) are artificial constructs used for tracking instances but
do not reflect the real properties of objects. Exclude IDs from the domain
model as they do not convey meaningful domain information.
Example Exercise
In an exercise involving IDs as attributes:
• Remove IDs: IDs are typically not part of the domain model but are used for
database or implementation purposes. Focus on the real properties and relationships
relevant to the domain.
Detailing the Model
1. For Classes:
o Specify attributes including their name, type, and multiplicity.
2. For Associations:
o Provide names for the associations. If they are unary associations
(associations involving only one class), include role names and multiplicity as
necessary. Also, consider if an association class is needed to capture
additional details.
Summary
• Simplify the Diagram: Eliminate redundant or irrelevant associations to make the
diagram more readable and meaningful.

57
 • Evaluate and Refine Attributes: Ensure attributes are directly related to their classes,
and consider whether they should be represented as classes or association classes.
• Focus on Essential Information: Retain associations and attributes that provide
unique and crucial information about the domain.
By adhering to these guidelines, you ensure that your class diagram remains an effective tool
for representing the system’s data requirements, while avoiding unnecessary complexity.

58
Building a Use-Case Model for System Requirements Capture
Use-case modeling is an essential technique for capturing and specifying functional
requirements in software systems. It helps in understanding the system's behavior from the
user's perspective and guides the development and validation processes.
Overview of Use-Case Modeling
1. Purpose:
o Capture System Behavior: Describes how the system functions from the
user's viewpoint.
o Incremental Development: Developed alongside the domain model, refining
system functionality.
o Functional Requirements: Specifies what functionalities the system must
provide.
o Planning and Validation: Assists in planning development iterations and
validating the system against user needs.
2. Use Cases:
o Definition: A use case represents a specific functionality or behavior of the
system initiated by an actor.
o Role in Development: Use cases outline required functionalities and guide
the development process.
Identifying Actors
1. Definition:
o Actors: Entities outside the system that interact with it. Actors can be people,
other systems, or external devices that provide input or receive output from
the system.
o Notation: Depicted using stick figures or icons in UML diagrams.
2. Types of Actors:
o Person: An individual who interacts with the system.
o System: Another system interfacing with the software.
o Roles: A user may have multiple roles, and multiple users can fulfill the same
role.
3. Questions to Identify Actors:
o Who or what will use the system?

59
 o What roles do these entities play in the system's interaction?
o Who provides and receives information from the system?
o Are there external systems interacting with the system?
o Who handles installation, maintenance, etc.?
4. Actors vs. Domain Classes:
o Domain Class: Represents entities in the system’s domain (e.g., Student in a
class diagram).
o Actor: Represents users or external systems interacting with the software
(e.g., Student as an actor in a use-case diagram).
5. Note:
o Input/Output Devices: Devices like keyboards, mice, or printers are not
considered actors; they are external hardware, not entities interacting with
the system’s functionality.
Creating Use-Case Diagrams
1. Components:
o Actors: Represented outside the system boundary.
o System Boundary: Depicted as a rectangle that encloses all the use cases.
o Use Cases: Represented as ovals within the system boundary, showing
functionalities.
2. Example: ASU Course Registration System
o Actors Identified:
▪ Student: Registers for courses.
▪ Instructor: Teaches courses.
▪ Billing System: External system for billing students.
o Actor Descriptions:
▪ Student: Person who registers for courses at ASU.
▪ Instructor: Member of the teaching staff at ASU.
▪ Billing System: External system responsible for billing students.
3. Drawing the Diagram:
o System Box: Draw a rectangle to represent the ASU course registration
system.

60
 o Use Cases: Inside the rectangle, draw ovals to represent functionalities like
"Register for Courses," "Assign Grades," etc.
o Actors: Place stick figures outside the rectangle for Student, Instructor, and
Billing System.
o Connections: Draw lines connecting actors to use cases to show interactions.
Use Cases and Scenarios
1. Definition:
o Use Case: Describes a complete sequence of interactions between an actor
and the system to achieve a specific goal.
o Scenario: A specific instance or sequence of events in the use case.
2. Types of Scenarios:
o Normal Sequence: The standard flow of events.
o Alternative Scenarios: Other possible paths or exceptions.
3. Modeling Techniques:
o Top-Down: Start with use cases and refine with scenarios.
o Bottom-Up: Begin with scenarios and abstract to use cases.
Generalization in Use-Case Modeling
• Generalization: Represents a design decision where a more general use case or actor
is refined into more specific ones.
• Note: Avoid using generalization unless necessary as it can complicate the model.
Example Use-Case Model for ASU Course Registration System
1. Actors and Use Cases:
o Student:
▪ "Request Course Catalogue": Allows students to view course
offerings.
▪ "Select Course Offering": Enables students to choose courses for
registration.
▪ "Change Course Offering": Lets students add or drop courses within a
specified period.
o Instructor:
▪ "Select Courses to Teach": Allows instructors to choose which courses
they will teach.

61
 ▪ "Request Enrollment List": Provides the list of students enrolled in
their courses.
o Billing System:
▪ "Receive Billing Information": Processes billing information after
student registration.
2. Initial Use-Case Specification:
o "Register for Courses":
▪ Purpose: Allows students to register for courses, including adding and
dropping courses.
▪ Steps:
1. Add course offering.
2. Drop course offering.
3. Send billing information.
By following these guidelines, you can build a comprehensive use-case model that captures
all necessary functionalities and interactions for your system, guiding the development and
ensuring alignment with user requirements.

62
Specifying Use Cases in Use-Case Modeling
In use-case modeling, specifying use cases is crucial for defining the functionalities provided
by the system and how users (actors) interact with it. Here's a detailed guide on how to
specify use cases effectively:
Understanding Use Cases
1. Definition:
o Use Case: A specific way of using the system that represents a function or
service provided by the system. It is depicted as an oval in UML diagrams.
o Purpose: Describes the interaction between an actor and the system,
outlining what the system must do from the actor's perspective.
o Sequence of Events: A use case describes a complete sequence of actions and
events initiated by an actor.
2. Normal vs. Alternative Scenarios:
o Normal Sequence: Initially, focus on the primary, normal flow of events and
actions in the use case diagram.
o Alternative Scenarios: These are not included in the use case diagram but
should be detailed in the use case specification.
3. Scenario:
o Definition: A concrete, focused description of a single use of the system from
the viewpoint of a single actor. It represents an attempt to carry out a use
case.
o Viewpoints:
▪ Top-Down: Start with general use cases and refine them into specific
scenarios.
▪ Bottom-Up: Begin with specific scenarios and abstract them into
general use cases.
o Stereotype: A use case is a stereotype of a UML class, where the scenario is
an instance of this class.
Identifying Use Cases and Scenarios
1. Key Questions:
o Tasks: What tasks does an actor want to perform using the system?
o Information Access: What information does the actor access or manipulate in
the system?

63
 o External Changes: Which external changes does the actor need to
communicate to the system?
o Events: What events does the actor need to be informed about by the
system?
o Support and Maintenance: How will the system be supported and
maintained?
2. Steps to Identify Use Cases:
o Brainstorm: Gather all possible functionalities the system must support from
the actor’s perspective.
o Analyze Interactions: Determine how actors interact with the system to
achieve their goals.
o Define Functionalities: Specify what each use case should achieve.
Documenting Use Cases
1. Use Case Name:
o Format: Use a present-tense, verb phrase in active voice for clarity (e.g.,
"Register for Course").
o Perspective: Name the use case from the perspective of the actor performing
the action.
2. Description:
o Purpose: Provide a brief summary of what the use case accomplishes and its
role in the system.
o Functionality: Outline the specific functionalities and steps involved in the
use case.
3. Application Domain Vocabulary:
o Terminology: Use terms and concepts from the application's domain to
ensure clarity and relevance.
Example: Use Case Specification
Use Case Name: Register for Course
• Description:
o Purpose: Allows a student to register for a course offering for the upcoming
term.
o Functionality:
1. The student selects a course from the course catalogue.

64
 2. The student indicates alternative course choices.
3. The system checks course availability and adds the course to the
student’s schedule.
4. If a course is full, the system suggests alternative choices.
5. Once registration is complete, the system sends billing information to
the billing system.
Use Case Name: Request Course Catalogue
• Description:
o Purpose: Enables a student to view a list of available course offerings for the
upcoming term.
o Functionality:
1. The student requests the course catalogue.
2. The system retrieves and displays the catalogue, including course
details such as instructor, department, and prerequisites.
Use Case Name: Select Courses to Teach
• Description:
o Purpose: Allows an instructor to choose which courses they will be teaching
for the upcoming term.
o Functionality:
1. The instructor logs into the system.
2. The system presents a list of available courses.
3. The instructor selects courses to teach.
4. The system updates the course schedule accordingly.

65
ASU Use-Case Model Specification
To build a comprehensive and readable use-case model for the ASU Course Registration
System, we’ll follow these steps based on the prompt statement:
1. Identifying Functionalities from the Prompt Statement
1. Initial Functionalities Identified:
o Request Course Catalog: Students need to browse course offerings.
o Prepare Course Offerings: Someone (possibly a registrar) will prepare and
update course offerings.
o Select Course Offering: Students select courses they wish to register for.
o Select Alternative Course Offerings: Students indicate alternative courses if
their initial choice is unavailable.
o Cancel Course Offering: Someone cancels course offerings.
o Receive Billing Information: The billing system receives billing details after
registration.
o Select Courses to Teach: Instructors choose which courses they will teach.
o Request Enrollment List: Instructors request the list of students enrolled in
their courses.
o Change Course Offerings: Students add or drop courses to/from their
schedule.
2. Group Functionalities into Comprehensive Use Cases:
o Register for Courses:
▪ Includes: Request Course Catalog, Select Course Offering, Select
Alternative Course Offerings, Add Course Offering, Drop Course
Offering, Change Course Offerings.
o Maintain Course Information:
▪ Includes: Prepare Course Offerings, Cancel Course Offering.
o Manage Instructor Assignments:
▪ Includes: Select Courses to Teach, Request Enrollment List.
3. Actor Identification and Grouping:
o Students:
▪ Use Case: Register for Courses.
o Registrar:

66
 ▪ Use Case: Maintain Course Information.
o Instructor:
▪ Use Case: Manage Instructor Assignments.
o Billing System:
▪ Interaction: Receives Billing Information as part of the Register for
Courses use case.
2. Creating the Use-Case Diagram
Actors:
• Student
• Registrar
• Instructor
• Billing System
Use Cases:
• Register for Courses
o Actors Involved: Student
o Description: Students can browse the course catalog, select courses, choose
alternatives, and add or drop courses.
• Maintain Course Information
o Actors Involved: Registrar
o Description: Preparation and cancellation of course offerings.
• Manage Instructor Assignments
o Actors Involved: Instructor
o Description: Instructors select courses to teach and request enrollment lists.
Connections:
• Student to Register for Courses:
o Arrow: Indicates that students initiate this use case.
• Registrar to Maintain Course Information:
o Arrow: Indicates that the registrar performs this use case.
• Instructor to Manage Instructor Assignments:
o Arrow: Indicates that instructors perform this use case.

67
 • Register for Courses to Billing System:
o Line: Indicates communication, where the billing system receives billing
information as part of the Register for Courses process.
3. Drawing the Diagram
• Actors: Represented outside the system boundary.
• System Boundary: A rectangle representing the ASU Course Registration System.
• Use Cases:
o Inside the System Boundary: Ovals for "Register for Courses," "Maintain
Course Information," and "Manage Instructor Assignments."
• Connections:
o Arrow from Student to Register for Courses.
o Arrow from Registrar to Maintain Course Information.
o Arrow from Instructor to Manage Instructor Assignments.
o Line between Register for Courses and Billing System.
4. Generalization and Simplification
• Generalization (Avoid if Possible):
o Use generalization to simplify models only if it enhances clarity without
overcomplicating the diagram. For instance, avoid generalizing use cases if it
makes the model less intuitive.
o Use generalization on actors (e.g., different types of users) if it improves
understanding.
5. Example Use-Case Diagram
Here's a simplified description of what the diagram might look like:
• Actors:
o Student
o Registrar
o Instructor
o Billing System
• Use Cases:
o Register for Courses
▪ Initiated by: Student

68
 ▪ Communicates with: Billing System
o Maintain Course Information
▪ Performed by: Registrar
o Manage Instructor Assignments
▪ Performed by: Instructor
• Connections:
o Student → Register for Courses (Arrow)
o Registrar → Maintain Course Information (Arrow)
o Instructor → Manage Instructor Assignments (Arrow)
o Register for Courses ↔ Billing System (Line)

69
Writing a Use Case Specification
A use case specification provides a detailed description of a use case, including the steps
required to perform the functionality, the conditions before and after the use case, and any
variations from the typical flow. Here's a structured approach to writing a use case
specification:
1. Use Case Name
• Purpose: Clearly identify the functionality provided by the system.
• Example: Select Courses to Teach
2. Brief Description
• Purpose: Provide a high-level overview of what the use case does.
• Example: This use case describes how an instructor selects courses to teach for a
specific term within the ASU Course Registration System.
3. Participating Actors
• Purpose: Identify who interacts with the system to perform the use case.
• Example:
o Primary Actor: Instructor
o Secondary Actors: None (if no other actors interact directly with this use
case)
4. Preconditions
• Purpose: Define the state of the system and/or actor before the use case can be
executed.
• Example:
o The instructor must be logged into the system.
o The term for course selection must be open for registration.
5. Postconditions
• Purpose: Describe the state of the system after the use case has been completed.
• Example:
o The selected courses are saved in the instructor's profile for the specified
term.
o The system updates the course availability status accordingly.
6. Flow of Events
Basic Flow:

70
 • Purpose: Describe the typical sequence of actions for the use case.
• Example:
1. The instructor logs into the ASU Course Registration System.
2. The instructor selects the "Select Courses to Teach" option from the main
menu.
3. The system displays the interface for selecting courses to teach.
4. The instructor specifies the term for which they wish to select courses.
5. The system retrieves and displays available courses for the specified term.
6. The instructor selects the courses they wish to teach.
7. The system saves the instructor's selections and confirms the updates.
Alternative Flows:
• Purpose: Describe any variations from the basic flow, including exceptional or
optional scenarios.
• Example:
o Alternative Flow 1 (No Available Courses):
1. If no courses are available for the specified term, the system displays a
message indicating that there are no available courses.
2. The instructor may choose a different term or exit the process.
o Alternative Flow 2 (Term Closed for Registration):
1. If the term is closed for registration, the system displays a message
indicating that the term is not open for course selection.
2. The instructor is prompted to choose an open term.
7. Nonfunctional Requirements
• Purpose: Specify any performance or quality attributes required for the use case.
• Example:
o The course selection process should be completed within 5 seconds.
o The system must be able to handle up to 100 simultaneous instructors
performing course selection.
Example Use Case Specification: "Select Courses to Teach"
1. Use Case Name: Select Courses to Teach

71
 2. Brief Description: This use case describes how an instructor selects courses to teach
for a specific term within the ASU Course Registration System.
3. Participating Actors:
o Primary Actor: Instructor
4. Preconditions:
o The instructor must be logged into the system.
o The term for course selection must be open for registration.
5. Postconditions:
o The selected courses are saved in the instructor's profile for the specified
term.
o The system updates the course availability status accordingly.
6. Flow of Events:
Basic Flow:
1. The instructor logs into the ASU Course Registration System.
2. The instructor selects the "Select Courses to Teach" option from the main menu.
3. The system displays the interface for selecting courses to teach.
4. The instructor specifies the term for which they wish to select courses.
5. The system retrieves and displays available courses for the specified term.
6. The instructor selects the courses they wish to teach.
7. The system saves the instructor's selections and confirms the updates.
Alternative Flows:
o Alternative Flow 1 (No Available Courses):
1. If no courses are available for the specified term, the system displays a
message indicating that there are no available courses.
2. The instructor may choose a different term or exit the process.
o Alternative Flow 2 (Term Closed for Registration):
1. If the term is closed for registration, the system displays a message
indicating that the term is not open for course selection.
2. The instructor is prompted to choose an open term.
7. Nonfunctional Requirements:
o The course selection process should be completed within 5 seconds.

72
o The system must be able to handle up to 100 simultaneous instructors
performing course selection.

73
Specifying Extension Points and Alternative Flows in Use Case Specifications
When detailing a use case specification, extension points and alternative flows provide a way
to handle different scenarios or variations in the flow of events. Here’s how you can
incorporate these elements into your use case specifications:
Extension Points
Extension points are specific locations within the flow of events where additional behavior
can be inserted. These can be used to handle exceptional cases, optional features, or
variations in the process. There are three types of extension points:
1. Single Location Extension Point
o Definition: An extension point that occurs only once within the use case
specification.
o Example: If a use case involves a payment process and there is a single point
where additional validation can be applied, you might have an extension
point like "Validate Payment Method".
2. Discrete Locations Extension Point
o Definition: An extension point that can occur at multiple, discrete locations
within the use case.
o Example: A use case for order processing might have extension points for
"Verify Inventory" that occur at different stages (e.g., before placing an order
and before shipping).
3. Region Extension Point
o Definition: An extension point that covers a range or region of the flow of
events, from a specific starting point to an ending point.
o Example: In a use case for user registration, you might define a region from
"Begin User Registration" to "Confirm User Registration", covering the entire
process of registration.
Alternative Flows
Alternative flows describe optional, exceptional, or variant behavior that diverges from the
basic flow of events. They help manage scenarios that are not the primary path but still need
to be addressed. Alternative flows should be numbered (e.g., A1, A2) and categorized into
three types:
1. Specific Alternative Flow
o Definition: Starts at a specific extension point or location in the flow of
events.

74
 o Example: If during course selection, an extension point is reached where the
system needs to handle "Course Already Enrolled" exceptions:
▪ At: Course Selection
▪ If: The instructor tries to enroll in a course already taken
▪ Then: The system will display a warning and prompt the instructor to
select another course.
2. Bounded Alternative Flow
o Definition: Occurs between two defined extension points within the use case.
o Example: In a course registration use case, you might have a bounded flow
between "Select Course" and "Confirm Registration":
▪ Between: Select Course and Confirm Registration
▪ If: The selected course is full
▪ Then: The system will offer alternative courses to the instructor.
3. General Alternative Flow
o Definition: Can start at any point within the use case.
o Example: For handling any type of error during course selection:
▪ At: Any point in the course selection process
▪ If: An unexpected error occurs
▪ Then: The system displays a general error message and logs the
incident for support.
Example of Alternative Flows
1. Exceptional Flow
o Scenario: The instructor enters an invalid term or year during course
selection.
▪ At: Select Activity
▪ If: The entered term or year is invalid
▪ Then: The system informs the instructor of the error and prompts
them to re-enter the correct term or year.
▪ Exit Point: Resume at "Enter Term" to re-enter valid data.
2. Variant Flow
o Scenario: The instructor attempts to create a schedule that already exists.

75
▪ At: Begin Creating Schedule
▪ If: A schedule with the same term and courses already exists
▪ Then: The system shows a pop-up indicating the conflict and provides
options to either overwrite the existing schedule or choose a different
term.
▪ Exit Point: Resume at "Select Activity" to adjust the schedule details.

76
Incorporating Subflows in Use Case Specifications
Understanding Subflows
A subflow in a use case specification is a segment of events with a clear purpose that can be
extracted from the main flow to enhance readability and organization. Here’s a breakdown
of how and when to use subflows effectively:
What is a Subflow?
• Definition: A subflow is a specific part of a use case that represents a sequence of
actions or events with a distinct purpose. It is a subset of the overall use case but
focuses on a specific task or process.
• Purpose: By extracting these segments into subflows, you simplify the main flow of
events, making the use case specification easier to understand.
Guidelines for Using Subflows
1. Identification:
o Determine segments within the main use case flow that are repetitive,
complex, or have a distinct purpose.
o Ensure that each subflow has a clear function and can be described
independently from the main flow.
2. Numbering and Naming:
o Number subflows sequentially as S1, S2, up to Sn.
o Give each subflow a descriptive name that reflects its purpose, such as
"Create Schedule" or "Modify Schedule."
3. Integration:
o Refer to subflows within the main flow by mentioning the subflow number
and name.
o Ensure the main flow description remains concise, with references to
subflows for detailed steps.
4. Avoid Excessive Nesting:
o Limit the nesting of subflows to prevent complexity. Avoid putting one
subflow within another multiple levels deep.
Example Use Case Specification with Subflows
Here’s an example of how you might use subflows in a use case specification for a course
registration system:
Use Case: Register for Courses

77
 • Description: This use case describes the process through which a student registers
for courses in a given term.
• Actors: Student
• Preconditions: The student must be logged into the system and have a valid list of
course offerings.
• Basic Flow:
1. The student selects the option to register for courses.
2. The system displays available course offerings.
3. The student chooses courses and adds them to their schedule.
4. The student reviews their selections.
5. The student confirms the registration.
Subflow S1: Create Schedule
o Description: Handles the process of creating a new schedule.
o Flow of Events:
1. The student selects "Create New Schedule."
2. The system prompts the student to enter the term and year.
3. The system saves the new schedule.
Subflow S2: Modify Schedule
o Description: Manages modifications to an existing schedule.
o Flow of Events:
1. The student selects "Modify Existing Schedule."
2. The system displays the current schedule.
3. The student makes changes to course selections.
4. The system updates the schedule with the changes.
• Postconditions: The student's course registration is successfully updated in the
system.
• Alternative Flows:
o A1: If the student tries to register for a course that is already full, the system
will display an error message and suggest alternative courses.
o A2: If the student inputs invalid data (e.g., incorrect term or year), the system
will prompt for correct information.

78
When to Use Subflows
• Complexity Reduction: Use subflows when a segment of the use case has multiple
steps or branches that would make the main flow too complex.
• Reusability: If a segment of events can be reused across different use cases, consider
defining it as a subflow.
• Clarity: Improve the readability of the use case specification by isolating complex
processes into subflows.
When Not to Use Subflows
• Over-Nesting: Avoid excessive nesting of subflows, which can make the use case
specification difficult to follow.
• Minor Details: Don’t create subflows for trivial or straightforward tasks that don’t
warrant separation from the main flow.

79
Capturing Nonfunctional Requirements
Nonfunctional requirements place constraints on a system’s performance, design, and other
aspects not related to specific functionalities. They are crucial for ensuring the system meets
certain quality standards and operational criteria. Here’s a breakdown of how to identify and
specify nonfunctional requirements:
Types of Nonfunctional Requirements
1. Design Quality:
o Reliability: The system should perform consistently without failure.
o Maintainability: The system should be easy to maintain and update.
o Supportability: The system should support upgrades and fixes.
2. Documentation:
o Requirements: What documentation is needed and for whom (e.g., user
manuals, technical documentation).
3. Hardware:
o Implementation Platform: Specifications for the hardware, including memory
size and storage capacity.
4. Implementation:
o Standards: Programming languages, development standards, and error
handling practices.
5. Interface:
o User Interface: Requirements for how users interact with the system.
o External Systems: How the system interfaces with other systems.
6. Management:
o System Backup: Requirements for backing up and restoring the system.
o Installation and Maintenance: Processes for system installation and ongoing
maintenance.
7. Performance:
o Speed: Response time and processing speed.
o Accuracy: Precision of data and operations.
8. Physical Environment:
o Abnormal Conditions: How the system should operate under unusual or
extreme conditions.

80
 o Distributed Operation: Requirements for distributed systems.
9. Security:
o System Access: How access to the system is controlled.
o Data Access: Security measures for data protection.
o Physical Access: Security for physical components of the system.
Example Analysis of Nonfunctional Requirements
Let's analyze a set of nonfunctional requirements for a satellite watch:
1. User Usability:
o Statement: “Any user who knows how to read a digital watch and understand
international time should be able to use the satellite watch.”
o Type: Interface and Usability. This requirement ensures the system is user-
friendly for its target audience.
2. Reliability:
o Statement: “The satellite watch should not require resetting due to software
faults.”
o Type: Design Quality, Reliability. This requirement emphasizes the need for
the system to be fault-tolerant.
3. Supportability:
o Statement: “The satellite watch should accept upgrades to its onboard
processor via USB interface.”
o Type: Design Quality, Supportability. This specifies the system's ability to
support hardware upgrades.
4. Response Time:
o Statement: “The satellite watch should display the correct time within five
minutes of the end of a GPS blackout period.”
o Type: Performance, Response Time. This requirement addresses how quickly
the system should recover from disruptions.
5. Accuracy:
o Statement: “The satellite watch should measure time within one hundredth
of a second over five years.”
o Type: Accuracy. This specifies the precision required for time measurement.
6. Performance:

81
 o Statement: “The satellite watch should display time correctly in all 24 time
zones.”
o Type: Performance. This ensures the system handles multiple time zones
effectively.
7. Implementation:
o Statement: “All software associated with the satellite watch will be written
using Java.”
o Type: Implementation. This specifies the programming language to be used.
8. Interface Compliance:
o Statement: “The satellite watch complies with the physical, electrical, and
software interfaces defined by the Web API 2.0.”
o Type: Interface. This ensures compatibility with specified standards.
Specifying Nonfunctional Requirements
Nonfunctional requirements can be specified in two main ways:
1. Supplementary Requirements:
o Add these requirements to the use cases or system specifications to address
constraints beyond functional requirements.
2. Administration Use Cases:
o Define administrative use cases for system operations and maintenance, such
as system startup, shutdown, and backup. These use cases deal with
nonfunctional requirements related to security and system management.

82
Validating System Requirements
Validation of system requirements ensures that the requirements are complete, consistent,
clear, correct, and realistic. This process helps to verify that the system being developed
meets the needs of the stakeholders and functions as intended.
Key Aspects of Requirements Validation
1. Completeness:
o Ensure that all necessary requirements are captured and none are missing.
o Example: For the satellite watch (SatWatch), make sure all boundary
behaviors are defined, such as how it handles users standing between time
zones.
2. Consistency:
o Verify that requirements do not contradict each other.
o Example: If one requirement states that the SatWatch software should not
require upgrades, and another says it should be easily upgradeable via USB,
these are inconsistent. Resolve this by revising one of the conflicting
requirements.
3. Clarity:
o Requirements should be understandable to all stakeholders.
o Example: If it’s unclear whether the SatWatch needs to handle daylight saving
time, refine the requirement to explicitly state that it must.
4. Correctness:
o Ensure that requirements accurately reflect what is needed and are
technically feasible.
o Example: If the SatWatch specification incorrectly limits support to 24 time
zones, revise it to support all time zones.
5. Realism:
o Requirements should be feasible and achievable within the constraints of the
project.
o Example: Ensure that performance requirements for response time and
accuracy are realistic given the technology and resources available.
Examples of Requirement Validation Issues
1. Incomplete Requirement:
o Issue: The SatWatch specification lacks details on handling GPS accuracy
limitations near time zone boundaries.

83
 o Solution: Add a requirement specifying that the time zone on the SatWatch
should not change more frequently than every five minutes.
2. Inconsistent Requirements:
o Issue: One requirement says the SatWatch should not need software
upgrades, while another says it should support upgrades via USB.
o Solution: Resolve the inconsistency by deciding whether or not the SatWatch
will support upgrades and revise the requirements accordingly.
3. Unclear Requirement:
o Issue: It’s not clear if the SatWatch should handle daylight saving time.
o Solution: Refine the requirement to specify that the SatWatch must account
for daylight saving time changes.
4. Incorrect Requirement:
o Issue: The SatWatch is stated to support only 24 time zones, but there are
more than 24 time zones in reality.
o Solution: Update the requirement to support all time zones.
Requirements Validation Process
1. Domain Model:
o Capture all data requirements and important objects within the system. This
is typically represented as a class diagram.
2. Use Case Model:
o Define functional requirements through use case diagrams and specifications.
Describe how users will interact with the system and the flow of events for
each use case.
3. Nonfunctional Requirements:
o Specify additional constraints related to design quality, hardware,
implementation, performance, security, etc.
4. Continuous Validation:
o Regularly validate requirements with clients or users to ensure they remain
relevant and accurate throughout the development process.
5. Acceptance Testing:
o Validate that the system meets all requirements through acceptance tests
conducted with the client or user. This ensures that the implemented system
satisfies all captured requirements.

84
6. Iterative Refinement:
o In subsequent iterations or phases, refine and detail the requirements
further, align them with the analysis and design models, and prepare for
implementation.

85
What are class Diagrams?
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system
i.e. used to construct and visualize object-oriented systems.
In these diagrams, classes are depicted as boxes, each containing three compartments for
the class name, attributes, and methods. Lines connecting classes illustrate associations,
showing relationships such as one-to-one or one-to-many.
Class diagrams provide a high-level overview of a system’s design, helping to communicate
and document the structure of the software. They are a fundamental tool in object-oriented
design and play a crucial role in the software development lifecycle.

86
What is a class?
In object-oriented programming (OOP), a class is a blueprint or template for creating objects.
Objects are instances of classes, and each class defines a set of attributes (data members)
and methods (functions or procedures) that the objects created from that class will possess.
The attributes represent the characteristics or properties of the object, while the methods
define the behaviors or actions that the object can perform.
UML Class Notation
class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.

1. Class Name:
• The name of the class is typically written in the top compartment of the class
box and is centered and bold.
2. Attributes:
• Attributes, also known as properties or fields, represent the data members of
the class. They are listed in the second compartment of the class box and
often include the visibility (e.g., public, private) and the data type of each
attribute.
3. Methods:
• Methods, also known as functions or operations, represent the behavior or
functionality of the class. They are listed in the third compartment of the class
box and include the visibility (e.g., public, private), return type, and
parameters of each method.

87
 4. Visibility Notation:
• Visibility notations indicate the access level of attributes and methods.
Common visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
o ~ for package or default visibility (visible to classes in the same
package)
Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an
input, an output, or both. This information is crucial for understanding how data is passed
between objects during method calls.

88
There are three main parameter directionality notations used in class diagrams:
• In (Input):
o An input parameter is a parameter passed from the calling object (client) to
the called object (server) during a method invocation.
o It is represented by an arrow pointing towards the receiving class (the class
that owns the method).
• Out (Output):
o An output parameter is a parameter passed from the called object (server)
back to the calling object (client) after the method execution.
o It is represented by an arrow pointing away from the receiving class.
• InOut (Input and Output):
o An InOut parameter serves as both input and output. It carries information
from the calling object to the called object and vice versa.
o It is represented by an arrow pointing towards and away from the receiving
class.

89
Steps to Create a Class Diagram
1. Identify the Requirements:
o Understand the system or problem domain.
o List the main entities (classes) involved.
2. Determine the Classes:
o Identify the classes that are necessary for the system.
o Each class should represent a significant concept or object in the system.
3. Define the Attributes:
o For each class, list the attributes (properties) that describe the class.
o Include details like data type and visibility (public, private, protected).
4. Define the Methods:
o Identify the functions or methods that each class should have.
o Include the return type, parameters, and visibility.
5. Identify Relationships:
o Determine how the classes interact with each other.
o Common relationships include inheritance (generalization), association,
aggregation, and composition.
6. Define Multiplicity:
o For each relationship, define the multiplicity (one-to-one, one-to-many,
many-to-many).
7. Add Access Specifiers:
o Specify the visibility of each attribute and method (public +, private -,
protected #).
8. Use Diagramming Tool:
o Use a diagramming tool like UMLet, Lucidchart, or draw.io to create the class
diagram.
o Arrange the classes and draw the relationships.
Example
Let's create a class diagram for a simple Library Management System. The main classes
might be Library, Book, Member, and Librarian.
1. Identify Requirements

90
 • The system manages books and members.
• Members can borrow books.
• Librarians manage the library operations.
2. Determine the Classes
• Library
• Book
• Member
• Librarian
3. Define Attributes and Methods
• Library
o Attributes: name: String, location: String
o Methods: addBook(), removeBook(), registerMember()
• Book
o Attributes: title: String, author: String, isbn: String, available: Boolean
o Methods: borrowBook(), returnBook()
• Member
o Attributes: name: String, memberId: String, membershipDate: Date
o Methods: borrowBook(), returnBook()
• Librarian
o Attributes: name: String, employeeId: String
o Methods: manageBooks(), assistMembers()
4. Identify Relationships
• A Library has many Books.
• A Member can borrow many Books.
• A Library employs Librarians.
5. Define Multiplicity
• Library to Book: One-to-Many
• Member to Book: Many-to-Many
• Library to Librarian: One-to-Many

91
Class Diagram
Here's how the class diagram might look:

92
93
In this diagram:
• The Library class has a one-to-many relationship with the Book and Librarian classes.
• The Member class has a many-to-many relationship with the Book class.
• Attributes and methods are clearly defined for each class.
• Access specifiers are indicated (assumed to be public for methods and private for
attributes).
By following these steps and using this example as a guide, you can create a class diagram
for any system.

94
Class diagram case study :
Case Study: E-Commerce System
Let's create a class diagram for an E-Commerce System. This system includes various
functionalities like user management, product catalog, order processing, and payment
processing.
Step-by-Step Process
1. Identify the Requirements:
o Users can browse products, add products to the cart, and place orders.
o Admins can manage products, users, and orders.
o The system processes payments and manages order status.
2. Determine the Classes:
o User
o Admin
o Customer
o Product
o Cart
o Order
o Payment
3. Define the Attributes and Methods:
• User
o Attributes: userId: String, name: String, email: String, password: String
o Methods: login(), logout()
• Admin (inherits from User)
o Methods: manageProduct(), manageUser(), manageOrder()
• Customer (inherits from User)
o Attributes: address: String
o Methods: addToCart(), placeOrder()
• Product

95
 o Attributes: productId: String, name: String, description: String, price: Double,
stock: Int
o Methods: updateStock()
• Cart
o Attributes: cartId: String, products: List<Product>, totalAmount: Double
o Methods: addProduct(), removeProduct(), calculateTotal()
• Order
o Attributes: orderId: String, orderDate: Date, orderStatus: String, products:
List<Product>, totalAmount: Double
o Methods: updateStatus()
• Payment
o Attributes: paymentId: String, paymentDate: Date, amount: Double,
paymentStatus: String
o Methods: processPayment()
4. Identify Relationships:
o A Customer can have one Cart.
o A Customer can place multiple Orders.
o An Order contains multiple Products.
o An Order has one Payment.
5. Define Multiplicity:
o Customer to Cart: One-to-One
o Customer to Order: One-to-Many
o Order to Product: Many-to-Many
o Order to Payment: One-to-One
Class Diagram
Here's how the class diagram might look:

96
97
98
99