SOFTWARE ENGINEERING

In the context of software development, there are • Modular and reusable: Objects can be
two orthogonal views: the traditional approach encapsulated into classes, and these
and the object-oriented approach. These views classes can be easily reused in different
represent different perspectives on how software parts of the system or in other projects.
is developed and organized. • Iterative and incremental: The
development process is iterative, with
1. Traditional Approach: The traditional
each iteration building upon the previous
approach to software development focuses
one. It allows for flexibility and
on functions or procedures. It considers
adaptability to changes during
software as a collection of procedures or
development.
functions that manipulate isolated data.
• Reduced complexity and redundancy: By
The main characteristics of the traditional
organizing software around objects, the
approach include:
object-oriented approach aims to reduce
• Emphasis on functions: The primary focus complexity and eliminate redundant code
is on breaking down the system into or functionality.
smaller functions or procedures that
SOFTWARE PROCESS
perform specific tasks.
• Sequential process: The development A software process refers to a set of activities
process follows a sequential order, moving that are followed to create a software product. It
from one phase to another (e.g., provides a structured approach to software
requirements gathering, design, development and helps ensure that the resulting
implementation, testing) in a linear product is of high quality. There are different
fashion. types of software processes, but they all involve
• Increased complexity: As the project four fundamental activities :-
progresses, the complexity of managing
and maintaining the software system tends 1. Software specification: This involves
to increase. defining the functionality and constraints
• Longer duration: Due to the sequential of the software. It is important to clearly
nature of the process and potential understand what the software needs to do
complexities, the duration of the project and how it should operate.
may be longer. 2. Software design and implementation: In
2. Object-Oriented Approach: The object- this activity, the software is designed and
oriented approach to software then implemented based on the
development centers on objects, which are specifications. It involves creating the
combinations of data and functionality. It actual code and programming the
focuses on organizing software around software.
objects, classes, and modules that can be 3. Software validation: The software is tested
easily replaced, modified, and reused. The to ensure that it meets the requirements
key characteristics of the object-oriented and functions as expected. This step is
approach include: crucial to identify any issues or bugs in
• Emphasis on objects: The primary focus is the software and ensure its correctness.
on identifying and modeling real-world 4. Software evolution: Over time, software
objects and their interactions within the needs may change or new features may
software system. be required. This activity involves making
 updates and modifications to the software systems if there are any, to find out what the
to meet changing customer needs. system needs to do. They try to understand what
problems the system should solve. Once they
These activities may have sub-activities and
have a good understanding of the problems, they
supporting process activities such as requirements
create a document called a "requirements
validation, documentation, and software
specification" that describes what the system
configuration management.
should do. This document is like a contract
In addition to activities, software processes may between the clients and the developers.
also include other elements such as products (the
In simple terms, requirement elicitation is like
outcomes of activities), roles (responsibilities of
when you and your friends want to build a cool
people involved), and pre- and post-conditions
toy, and you sit together to decide what the toy
(statements that are true before and after an
should be able to do. You talk about what
activity).
problems the toy should solve and what features
Software processes can be categorized as either it should have. Then, you write down all the
plan-driven or agile processes. Plan-driven things the toy needs to do in a special document
processes involve planning all activities in that everyone agrees on. That way, everyone
advance and measuring progress against the plan. knows what the toy will be like and what it
Agile processes, on the other hand, involve should be able to do.
incremental planning and are more adaptable to
When we talk about requirements specification
changing customer requirements. The choice
and analysis model, we are basically talking
between these approaches depends on the type of
about two different ways of describing and
software being developed.
understanding a computer system that we want to
In simpler terms, a software process is a roadmap create.
that guides the development of software. It
The requirements specification is like a document
includes steps like understanding what the
that uses normal words and sentences to explain
software should do, designing and building it,
what the system should do. It helps us talk and
testing it to make sure it works correctly, and
understand the system better with the people who
adapting it over time as needs change. The
want it, like the clients and the users. It's like
process provides stability, control, and
when you write a story or a description of
organization to ensure the production of quality
something using your own words.
software. It can be planned in advance or
adapted incrementally based on the project's On the other hand, the analysis model is a
needs. different way of representing the system. It uses
special symbols and diagrams to show how
CHAPTER TWO
different parts of the system fit together and how
REQUIREMENT ELICITATION they work. It's like drawing a picture or making
a map of the system using special signs and
Requirement elicitation is a process in software
shapes.
engineering where people who want to create a
computer system work together to figure out The important thing to know is that both the
what the system should do. The people who want requirements specification and the analysis model
the system (we call them clients) and the people are trying to show the same information about
who will build the system (we call them the system, but they use different languages and
developers) talk and discuss to understand the ways of expressing it. The requirements
purpose of the system. specification is more like a conversation, while
the analysis model is like a picture or a map.
During requirement elicitation, clients and
They are both helpful for different purposes. The
developers talk to each other and look at existing
requirements specification helps us talk to the So, actors are the different characters or things
people who want the system, while the analysis that interact with the system, and use cases are
model helps the developers understand and the fun and exciting things they can do together.
communicate with each other.
TYPES OR REQUIREMENTS
So, imagine you and your friends are planning a
When we talk about requirements for a computer
big event. You can write a list of things you
system, we have different types of requirements
want to happen in the event using words and
that help us understand what the system needs to
sentences. That's like the requirements
do.
specification. And then, you can also draw a map
or a diagram to show how different parts of the Functional requirements are like rules or
event will be organized, like where the stage will instructions that describe how the system should
be, where the food will be, and where the games interact with the things around it, like people,
will be. That's like the analysis model. Both the other devices, or the environment. They are
list and the map help you and your friends independent of how the system will be made or
understand and plan the event, but they use what its purpose is. For example, a functional
different ways of explaining things. requirement could be that a game operator
should be able to create a new game. It's like
When we're trying to understand a computer
saying that the person who runs the game should
system, we need to know who will use it and
have the ability to make a new game.
what they will do with it. We use two important
things to help us describe the system: actors and Nonfunctional requirements are about things that
use cases. are not directly related to how the system works
or what it does, but are still important for how
Actors are like the different people, machines, or
well the system performs. They are about aspects
things that interact with the system. They can be
like speed, reliability, or user experience. For
the people who will use the system, other
example, a nonfunctional requirement could be
computers that the system needs to talk to, or
that the system should respond within 1 second.
even the environment where the system will be
It's like saying that the system needs to react
used. It's like the different characters or players
quickly when someone interacts with it.
in a game.
Constraints or system requirements are
Use cases are like stories or scenarios that show
specifications or rules that are imposed by the
how these actors and the system will interact
client or the environment. These are specific
with each other. They describe the different
things that the system must have or follow in
actions or steps that can happen between an
order to work with certain hardware or software.
actor and the system for a specific part of the
For example, a constraint could be that the
system's functionality. It's like playing out
system must be built using the Java programming
different situations or adventures in a game.
language. It's like a special requirement that the
For example, imagine you have a game console, client or the environment wants the system to
and you want to know who will play with it and meet.
what they can do. The players who will use the
So, think of it like baking a cake. Functional
game console are the actors. They can be you,
requirements are like the instructions that tell
your friends, or even other devices like a
you how to mix the ingredients and put them in
controller or a special sensor. The use cases are
the oven. Nonfunctional requirements are like the
like the different game levels or challenges you
things you want the cake to be, like moist,
can play. Each use case describes what the player
delicious, and not too crumbly. Constraints or
and the game console will do together, like
system requirements are like special rules you
jumping, shooting, or solving puzzles.
have to follow, like using a specific type of oven or function to make them clear and
or a certain brand of chocolate. specific.

In summary, functional requirements tell us how 2. Be complete and accurate: Make sure each
the system should interact with its surroundings, requirement is fully described and
nonfunctional requirements focus on things like includes all the necessary details.
speed and reliability, and constraints or system
3. Include technical requirements: Consider
requirements are special rules or specifications
any technical specifications or constraints
that need to be followed.
that need to be met.
FUNCTIONAL REQUIREMENTS
4. Align with objectives and principles: Link
Functional requirements are like instructions that the requirements to the overall goals and
describe what a software system should do. They principles of successful software delivery.
explain how the system should interact with its
5. Document critical constraints: If there are
surroundings and what tasks it should perform.
any known limitations or restrictions that
Here are some important points about functional
significantly affect a requirement, they
requirements:
should be clearly mentioned.
1. Operations on screens: The requirements
Here are some examples of functional
should mention what actions can be
requirements:
performed on each screen of the software.
• The software should automatically validate
2. Data handling: The requirements should
customer information in the ABC Contact
explain how the system will manage and
Management System.
process data.
• The Sales system should allow users to
3. System reports and outputs: The record customers' sales.
requirements should describe the different • Only managerial-level employees should
types of reports or outputs that the have the right to view revenue data.
system should generate. • The software system should be integrated
with a banking API.
4. Workflows: The requirements should
• The system should allow users to edit
provide information about the different
their profile.
steps or processes that the system will
follow. When writing requirements, it's important to
avoid using confusing terms or phrases such as
5. User permissions: The requirements should
"support," "but not limited to," "etc.," and
specify who is allowed to create, modify,
"and/or." These terms can make the requirements
or delete data in the system.
unclear or ambiguous.
6. Regulatory and compliance needs: The
NON FUNCTIONAL REQUIREMENTS
requirements should include any
requirements related to following rules or Nonfunctional requirements are like special rules
regulations. or qualities that a software system should have,
but they are not about what the system actually
To create a good functional requirements
does. They focus on different aspects of the
document, it's important to follow some best
system that make it better or more enjoyable to
practices:
use. Here are some important points about
1. Keep requirements separate: Each nonfunctional requirements :-
requirement should focus on a single task
1. Not directly related to function:
Nonfunctional requirements are about
 things other than what the system does. performance, security, and more. They help
They are about how the system performs ensure that the system is not only functional but
or how it feels to use. also enjoyable and reliable to use.

2. Many different aspects: Nonfunctional 1) USABILITY

requirements cover a wide range of
Usability is all about how easy it is for someone
qualities that make the system better.
to learn, use, and understand a system or a part
They can be about usability, performance,
of it. It's like how simple and straightforward
security, and more.
something is to operate.
In software requirement engineering, some
Usability requirements are the rules or guidelines
common categories of nonfunctional requirements
that make sure the system is easy to use. For
include:
example, the requirements might say that the
• Usability: These requirements focus on system should follow certain design conventions,
making the system easy and enjoyable to like using specific colors, logos, and fonts. This
use. For example, the system should have helps make the system look and feel familiar and
a simple and intuitive user interface. consistent to the users.

• Performance: These requirements deal Usability requirements also include things like
with how fast and responsive the system how much help is available to the user while
is. For example, the system should they're using the system. This can include online
respond quickly within a certain time guides or manuals that explain how to use the
limit. system or how to do certain tasks.

• Security: These requirements ensure that So, imagine you have a new gadget or a game
the system protects information and console. Usability is about how easy it is for you
prevents unauthorized access. For to figure out how to use it without getting
example, the system should require a confused. The usability requirements might say
strong password for user authentication. that the buttons should be labeled clearly, the
menus should have pictures or icons to help you
• Reliability: These requirements are about
understand them, and there should be a user
how reliable and stable the system is. For
manual or online help available to answer your
example, the system should be able to
questions.
handle a large number of users without
crashing. In simpler terms, usability is about how user-
friendly something is and usability requirements
• Scalability: These requirements address the
are the rules that make sure things are easy to
system's ability to handle an increasing
understand and use.
number of users or data. For example, the
system should be able to support more 2) RELIABILITY
users as the business grows.
Reliability is about how well a system or a part
• Compatibility: These requirements ensure of it can do its job consistently and without any
that the system works well with different problems. It's like how trustworthy and
devices or software. For example, the dependable something is.
system should be compatible with various
Reliability requirements are the rules or
web browsers.
conditions that ensure the system works reliably.
So, nonfunctional requirements are like special They include things like how often the system
qualities or rules that make the system better. should have problems or fail, and how well it
They cover different aspects like usability, can handle certain faults or security attacks.
These requirements help make sure the system input or a command. It's like how fast the system
can be trusted to perform its functions when can start doing what you ask it to do.
needed.
Throughput is about how much work or tasks the
Sometimes, the term "dependability" is used system can handle and complete within a specific
instead of reliability. Dependability means that amount of time. It's like how many things the
you can rely on the system to provide the service system can do in a given period.
it's supposed to deliver. It includes not just
Availability is about how often the system is
reliability, but also other qualities like robustness
operational and accessible for use. It's like how
and safety.
frequently the system is ready and working when
Robustness is about how well the system can you need it.
handle difficult or challenging situations. For
Accuracy is about how precise and correct the
example, it's about how well a video game can
system's output or results are. It's like how well
continue running even if there are some errors or
the system can give you the right answers or
if the environment conditions are not perfect.
information.
Safety is about making sure the system doesn't
So, let's imagine you have a computer game.
cause any harmful or catastrophic consequences
Performance requirements are about how fast the
to the surroundings. It's like how a car should be
game reacts when you press a button or make a
designed to be safe and not cause accidents or
move. The response time requirement might say
harm people.
that the game should respond within a certain
So, imagine you have a computer or a number of milliseconds after you press a button.
smartphone. Reliability is about how often it
Throughput is about how many actions or tasks
works without crashing or having errors.
the game can handle at the same time. The
Reliability requirements might say that the system
throughput requirement might say that the game
should not fail more than a certain number of
should be able to process a certain number of
times within a specific period. Dependability is
moves or actions per second.
about being able to trust that the computer or
smartphone will work when you need it. It Availability is about how often the game is
includes not just reliability, but also how well it working and accessible. The availability
can handle difficult situations and how safe it is requirement might say that the game should be
to use. available to play at least 99% of the time,
meaning it can only be down or unavailable for a
In simpler terms, reliability is about how
very small percentage of the time.
trustworthy and consistent a system is, and
reliability requirements are the rules that make Accuracy is about how well the game provides
sure the system works well. Dependability accurate results or scores. The accuracy
includes reliability, robustness, and safety, and requirement might say that the game's scoring
it's about being able to rely on the system to do system should be precise and give the correct
its job effectively. points for each action or achievement.

3) PERFORMANCE In simpler terms, performance requirements are

about how fast, how much, how often, and how
Performance requirements are about how fast and
accurate a system can perform its tasks. They
efficient a system or a part of it can work. They
help ensure that the system works efficiently and
focus on measurable aspects that tell us how well
effectively.
the system performs certain tasks.
4) SUPPORTABILITY
Response time is about how quickly the system
reacts or responds when someone gives it an
Supportability requirements are about how easy it and portability, which are all about making the
is to make changes to a system after it has been system flexible, easy to fix, usable in different
deployed or put into use. They focus on making regions, and compatible with different devices.
the system adaptable, maintainable, and capable
REQUIREMENT ELICITATION ACTIVITIES
of working in different environments.
Requirements elicitation activities are a set of
Adaptability is about how easily the system can
steps or tasks that help us understand a problem
be changed or adjusted to handle new concepts
and define what a computer system needs to do.
or features related to the specific area it's being
These activities use a modeling technique called
used in. It's like how well the system can learn
UML (Unified Modeling Language) to visualize
or accommodate new things as needed.
and describe the system's specifications.
Maintainability is about how easy it is to make
The process begins by identifying the different
changes to the system to fix any problems or to
actors, which are the people, machines, or things
add new technology. It's like how simple it is to
that will interact with the system. Next, we
update or improve the system without breaking
identify various scenarios or situations where the
anything.
system will be used, considering the actions and
Internationalization is about how well the system interactions of the actors. Use cases are then
can be changed to work with different created, which represent specific tasks or
international conventions. This includes things functions that the actors and the system will
like different languages, units of measurement, perform together.
and number formats. It's like how the system can
To make the use cases more detailed, they are
be made compatible and useful for people in
refined by adding more information about the
different countries or regions.
steps, inputs, and outputs involved in each case.
Portability is about how easily the system can be Relationships among the actors and use cases are
transferred or moved from one hardware or identified to understand how they are connected
software environment to another. It's like how or related to each other.
well the system can work on different devices or
Additionally, nonfunctional requirements are
platforms without needing a lot of changes or
considered, which include aspects like system
adjustments.
performance, security, and usability. These
So, imagine you have a smartphone app. requirements are essential for ensuring the overall
Supportability requirements are about how easy it quality of the system.
is to update the app with new features or fix any
By following these elicitation activities, we can
issues. Adaptability means the app can handle
create a clear and comprehensive description of
new concepts or functionalities as the needs of
what the system should do and how it should
users change. Maintainability means the app can
behave. This helps in effectively planning and
be updated with new technology without causing
developing the computer system to meet the
problems. Internationalization means the app can
needs and expectations of the users and
work with different languages and number
stakeholders.
formats, making it useful for people around the
world. Portability means the app can work on Requirements elicitation activities help us
different types of phones or operating systems understand a problem and turn it into a set of
without needing major changes. specifications for a computer system. This is done
using a method called modeling with UML
In simpler terms, supportability requirements are
(Unified Modeling Language), which helps us
about how easy it is to make changes to the
visualize and describe the system.
system and keep it up-to-date. They include
adaptability, maintainability, internationalization,
Here are the steps involved in requirements requirements, and they are important for
elicitation activities: the overall quality of the system.

1. Identifying Actors: We figure out the So, imagine you and your friends are planning a
different people, machines, or things that board game. The requirements elicitation
will interact with the system. They are activities would involve figuring out who will
called actors. For example, in a shopping play the game (actors), thinking about different
app, actors could be the customers, the situations during the game (scenarios), describing
sellers, and the payment gateway. what each player will do (use cases), making the
use cases more detailed, understanding how
2. Identifying Scenarios: We think about
players and tasks are connected, and considering
different situations or scenarios where the
any additional requirements like the game's speed
system will be used. We consider what
or safety.
the actors will do and how they will
interact with the system. For example, a In simpler terms, requirements elicitation
scenario could be a customer searching activities are about understanding a problem and
for a product and making a purchase. creating a description of what the computer
system needs to do. We use different techniques,
3. Identifying Use Cases: Use cases are like
like identifying actors, scenarios, and use cases,
stories or descriptions of what the system
to map out the requirements. It's like making a
will do in each scenario. They represent
plan for how the system will work and what it
specific tasks or functions that the actors
will be able to do.
and the system will perform together. For
example, a use case could be "Customer IDENTIFYING ACTORS
places an order."
In the process of requirements elicitation, one of
4. Refining Use Cases: We take the initial the key steps is identifying the actors. Actors are
use cases and make them more detailed the different types of users and external systems
and specific. We add more information that interact with the computer system being
about the steps, inputs, and outputs developed. By understanding these actors, we can
involved in each use case. This helps us better determine the specific functionality and
understand exactly what needs to happen tasks that the system needs to support. This
in the system. involves asking questions about user groups, their
main functions, secondary functions, and any
5. Identifying Relationships Among Actors
external systems the system needs to interact
and Use Cases: We look at how the actors
with. Once the actors are identified, the next step
and use cases are connected or related to
is to define the functionality accessible to each
each other. This helps us understand the
actor through scenarios and use cases. This helps
flow of interactions in the system. For
create a clear understanding of how the system
example, a customer actor may be related
will be used and what it needs to accomplish for
to multiple use cases like searching,
different users and external entities.
adding items to the cart, and making
payments. Identifying actors involves figuring out the
different types of users and external systems that
6. Identifying Nonfunctional Requirements:
will interact with the computer system we're
Apart from the specific tasks, we also
building. We ask questions like:
consider other requirements like how fast
the system should respond, how secure it 1. Which user groups will use the system for
needs to be, or how easy it should be to their work?
use. These are called nonfunctional 2. Which user groups will perform the main
functions of the system?
 3. Which user groups will have secondary In simpler terms, identifying scenarios involves
functions like maintenance and creating detailed descriptions of specific situations
administration? or tasks that users will encounter when using the
4. Are there any external hardware or system. Developers observe users to understand
software systems that the system needs to their needs and then write scenarios that help
interact with? them better understand how the system should
function in real-life situations. These scenarios
By answering these questions, developers can
provide a clear picture of what the system needs
understand the various users that the system will
to do from the user's point of view.
support. Once the actors are identified, the next
step is to determine what each actor should be To identify scenarios, we can ask the following
able to do in the system. This is done by using questions :-
scenarios, which are like stories that describe
1. What tasks does the user want the system
specific situations, and formalizing them into use
to do? This helps us understand the
cases, which are detailed descriptions of tasks or
specific actions or functions the user
functions.
expects from the system.
In simpler terms, identifying actors means
2. What information does the user need to
figuring out the different types of users and
access? We explore what kind of data the
external systems that will be involved with the
user wants to see and interact with. We
computer system. We ask questions to understand
also determine who creates this data and
who will use the system and what they will do.
if it can be changed or removed, and by
This helps us determine the specific tasks or
whom.
functions that each user should be able to
perform. 3. Are there any external changes that the
user needs to inform the system about?
IDENTIFYING SCENARIOS
We consider if there are any updates or
In the process of requirements elicitation, another events outside the system that the user
important activity is identifying scenarios. needs to communicate to the system, and
Scenarios are detailed descriptions of specific how frequently this should be done.
situations or tasks that users will encounter when
4. Which events does the system need to
using the computer system or application. They
inform the user about, and how quickly
provide a narrative of what people do and
should this information be delivered? We
experience as they interact with the system.
determine if there are any important
During this activity, developers closely observe updates or notifications that the system
users and create a set of scenarios that outline needs to provide to the user, and how
the typical functionality the future system should fast this should happen.
provide. These scenarios serve as a means for
In simpler terms, when identifying scenarios, we
developers to communicate with users and gain a
ask questions to understand what tasks the user
deeper understanding of the application domain,
wants the system to do and what information
or the specific area or context in which the
they need. We also consider any external changes
system will be used.
or events that the user or the system should be
A scenario is a focused and informal description aware of. By answering these questions, we can
that highlights a single feature or task of the create detailed descriptions of specific situations
system, as seen from the perspective of a single or tasks that users will encounter when using the
user or actor. It provides a concrete example of system, providing a better understanding of how
how the system will be used and what actions or the system should function in different scenarios.
interactions are expected.
IDENTIFYING USE CASES distinguish the interactions between the
user and the system.
A scenario is like a specific example or situation
that shows how a particular function or task in 4. Use active voice for step descriptions: Use
the system can be used. It's like a real-life story case steps should be written in the active
that describes what happens step by step when voice to explicitly state who is
someone interacts with the system. accomplishing each step. This makes it
clear and easy to understand.
A use case, on the other hand, is like a
collection of all possible scenarios related to a 5. Clearly show the causal relationship
specific function or task. It's like a summary of between steps: The relationship between
different situations that can occur when using each step should be clear, showing the
that particular function or task in the system. cause and effect or the logical flow
between them.
When developers and users agree on a set of
scenarios, developers can create use cases based 6. Describe a complete user transaction: A
on those scenarios. The use cases help us use case should describe a complete
understand the overall scope or coverage of the sequence of interactions between the user
system and provide a complete flow of events and the system to achieve a specific goal
that happen when the use case is initiated or or task.
started.
7. Document exceptions separately: Any
In simpler terms, a scenario is an example that exceptional or error situations should be
shows how a specific function or task works in described separately from the main flow
the system. A use case is a summary that of events.
includes all the possible scenarios related to that
8. Avoid describing the user interface: A use
function or task. Use cases help us understand
case should focus on the user's actions
how different interactions and events flow
and the system's responses, rather than
through the system when using that function or
specific details of the user interface
task.
design.
SIMPLE USE CASE WRITING GUIDE
9. Keep use cases concise: Use cases should
When creating use cases, there are certain not be too long. Ideally, they should be
guidelines to follow: limited to two or three pages. If a use
case becomes lengthy, it can be
1. Use a verb phrase to name the use case:
decomposed into smaller use cases using
The name of the use case should indicate
relationships like "include" and "extend".
what the user is trying to accomplish. It
should be clear and descriptive. In simpler terms, when creating use cases, we
give them names that describe what the user
2. Name actors with noun phrases: Actors,
wants to accomplish. Actors are named based on
which are the users or external systems,
their roles. We clearly define which steps are
should be named using nouns that
done by the user and which are done by the
describe their roles or responsibilities in
system. Use case steps are described in a way
the system.
that shows who is doing each action. The
3. Clearly define the system boundary: It relationship between steps should be clear, and
should be clear which steps are performed the use case should describe a complete user
by the user (actor) and which steps are transaction. Any exceptions or errors are
performed by the system. This helps described separately. The focus should be on the
user's actions and the system's responses, not the
specific user interface. Use cases should be kept on how the system should perform, how it should
concise and, if needed, can be divided into be documented, the resources it should consume,
smaller parts. its security measures, and its overall quality.

REFINING USE CASES Let's break it down in simpler terms and go into
more detail:
Refining use cases is an activity where developers
add more details to the use cases to make sure 1. Performance: This refers to how well the
the requirements specification is complete. They system should perform in terms of speed,
describe each use case more thoroughly and responsiveness, and efficiency. It includes
consider how the system should behave in the requirements like response time (how
presence of errors or exceptional conditions. quickly the system should react),
throughput (how much work the system
In simpler terms, refining use cases means
can handle), and availability (how often
developers take the existing use cases and provide
the system should be accessible).
more information about them. They make sure all
the necessary details are included and think 2. Documentation: This involves requirements
about how the system should handle errors or related to providing clear and
unusual situations. This helps ensure that the comprehensive documentation for the
requirements for the system are fully described system. It ensures that users and
and well-defined developers have access to detailed
instructions, user manuals, guides, or any
IDENTIFYING RELATIONSHIPS AMONG USE
other necessary documentation.
CASES
3. Resources: These requirements focus on
Identifying relationships among use cases is an
how the system should utilize resources
activity where developers determine how different
such as memory, processing power,
use cases are related to each other. They look for
network bandwidth, or storage space. It
dependencies or connections between use cases
may include limitations or specifications
and consolidate the use case model by extracting
on resource usage to ensure the system
common functionalities. This ensures that the
operates efficiently.
requirements specification is consistent and well-
organized. 4. Security: This refers to requirements
related to protecting the system and its
In simpler terms, identifying relationships among
data from unauthorized access, breaches,
use cases means that developers look at how
or malicious activities. It involves
different tasks or functions in the system are
measures like user authentication, data
connected. They find out which use cases rely on
encryption, access control, and adherence
or depend on other use cases to be completed.
to relevant security standards.
They also identify common functionalities that are
shared by multiple use cases and separate them 5. Quality, Reliability, and Supportability:
to avoid repetition. This helps ensure that the These requirements encompass various
requirements for the system are clear, coherent, aspects related to the overall quality,
and don't have any conflicts or contradictions reliability, and supportability of the
system. It includes factors like robustness
IDENTIFYING NON-FUNCTIONAL REQUIREMENTS
(how well the system handles errors or
Identifying nonfunctional requirements is an unexpected situations), maintainability
activity where developers, users, and clients come (how easily the system can be maintained
together to agree on certain aspects of the system or modified), and support options
that are not directly related to its functionality. (availability of technical support or help
These aspects include constraints or specifications desk services).
 6. Interface: This involves requirements contradict itself. There should be no
concerning the user interface and how it conflicting or contradictory statements
should look, feel, and function. It includes within the document. It ensures that all
aspects like usability (how user-friendly requirements align and work together to
and intuitive the interface should be) and achieve the desired system behavior.
accessibility (ensuring the interface is
3. Clarity: Clarity refers to the unambiguous
usable for individuals with disabilities).
and clear expression of requirements.
7. Legal and Compliance: These requirements Each requirement should have only one
address legal and regulatory obligations interpretation and should be easily
that the system must adhere to. It may understandable by all stakeholders.
include data privacy regulations, industry- Ambiguous terms, words with multiple
specific standards, intellectual property meanings, should be avoided to prevent
rights, or any other legal considerations confusion and misunderstandings.
relevant to the system's domain.
4. Correctness: Correctness means that the
In summary, identifying nonfunctional requirements accurately represent the
requirements is about defining specifications system that the client needs and that the
beyond the system's functionality. It includes developers intend to build. The
aspects such as performance, documentation, requirements should describe the desired
resource usage, security, quality, interface, and features and behavior of the system and
legal compliance. These requirements ensure that its environment of interest, without
the system not only performs its tasks but also including unintended or unnecessary
meets certain standards of performance, usability, features.
security, and compliance with relevant
5. Ambiguous terms: Ambiguous terms are
regulations.
words that can be interpreted in different
REQUIREMENT VALIDATION (COMPLETENESS , ways and can lead to misunderstandings.
CONSISTENCY , CLARITY AND CORRECTNESS ) Examples of such terms include
"minimize," "maximize," "rapid," "easy,"
Requirement validation is an important step in
"sufficient," "adequate," and "quick." To
the development process where the client, users,
ensure clarity, it's important to provide
and developers continuously check and confirm
clear definitions or explanations for such
that the requirements specification is complete,
terms.
consistent, clear, and correct. It ensures that
everyone involved has a shared understanding of Requirement validation is crucial because it helps
what the system needs to do. ensure that everyone is on the same page and
that the requirements accurately capture what the
Let's break it down in simpler terms and provide
system should do. It prevents misunderstandings,
more detail:
inconsistencies, and misinterpretations that could
1. Completeness: The requirements lead to costly errors during development.
specification is considered complete if it
In summary, requirement validation is about
includes all possible scenarios and aspects
checking that the requirements specification is
of the system. It means that all the
complete, consistent, clear, and correct. It
different situations and behaviors the
confirms that all necessary scenarios and
system may encounter are described,
behaviors are described, there are no
including exceptional cases.
contradictions, the requirements are unambiguous,
2. Consistency: Consistency means that the and they accurately represent the desired system.
requirements specification does not This validation process is essential for successful
development and ensuring that the system meets 6. Use Case Approach: The use case
the client's needs and expectations. approach involves identifying actors,
scenarios, and use cases to describe the
interactions and functionality of the
REQUIREMENT-ELICITATION METHODS/ system. It helps in understanding user
TECHNIQUES requirements and specifying system
behavior.
During the process of requirements elicitation,
various methods can be used to gather The success of an elicitation technique depends
information and extract requirements from on factors such as the experience and skills of the
stakeholders. Here are some commonly used analysts, developers, users, and customers
methods: involved. The maturity of these individuals
influences their ability to effectively
1. Interviews: Interviews involve direct
communicate, understand needs, and extract
conversations between the analysts and
requirements using the chosen elicitation
stakeholders to gather information and
technique.
understand their perspectives. It allows for
in-depth discussions, clarifications, and In summary, requirements elicitation can involve
exploration of requirements. various methods such as interviews, document
analysis, brainstorming, FAST, QFD, and the use
2. Document analysis: This method involves
case approach. Each method offers a unique way
studying existing documents such as user
of gathering information and extracting
manuals, business processes, and technical
requirements from stakeholders. The effectiveness
specifications to extract relevant
of these methods depends on the skills and
information and requirements. It helps in
experience of the individuals involved in the
understanding the current system and its
process.
documentation.
1) INTERVIEWS
3. Brainstorming-sessions: Brainstorming
involves bringing together a group of The objective of conducting an interview is to
stakeholders to generate ideas, understand what the customer expects from the
suggestions, and requirements software. Since it's not possible to interview every
collaboratively. It encourages creative person involved, representatives from different
thinking, open discussion, and the groups are selected based on their knowledge and
exploration of different perspectives. credibility.

4. Facilitated Application Specification Interviews can be either open-ended or

Technique (FAST): FAST is a workshop- structured. In open-ended interviews, there is no
based technique that uses visual models fixed agenda, and the interviewer asks questions
and structured discussions to elicit to understand the problem or requirements. In
requirements. It involves stakeholders structured interviews, the interviewer has a set of
actively participating in creating models questions prepared in advance to guide the
and specifying requirements. discussion. Sometimes, a questionnaire is used to
ensure important points are covered during the
5. Quality Function Deployment (QFD): QFD
interview.
is a method that focuses on translating
customer needs into specific technical In simpler terms, an interview helps us learn
requirements. It uses matrices and what the customer wants from the software. We
customer-driven prioritization techniques can't talk to everyone, so we choose
to align requirements with customer knowledgeable people to represent different
expectations. groups. Interviews can be more flexible or follow
a structured approach with prepared questions or At the end of the session, a document is prepared
questionnaires. The goal is to gather information that lists all the requirements that were discussed.
and understand the customer's expectations. If possible, the requirements are prioritized to
identify the most important ones.
2) DOCUMENT ANALYSIS
In simpler terms, brainstorming sessions are
Document analysis is a process where we gather
group activities where people share their ideas
and review all the existing documents that are
and viewpoints. A facilitator helps guide the
relevant to our business goal or may contain
session and ensure everyone's ideas are heard. All
information related to a potential solution. These
ideas are written down, and at the end, a
documents can include various types of written
document is created listing the requirements and
materials such as business plans, market studies,
their priority, if possible. The aim is to generate
contracts, requests for proposal, statements of
a lot of new ideas and gather a wide range of
work, memos, guidelines, procedures, training
perspectives.
guides, and more.
4) FACILITATED APPLICATION SPECIFICATION
By analyzing these documents, we aim to extract
TECHNIQUE
valuable information and insights that can help
us understand the current situation, identify FAST, or Facilitated Application Specification
problems or opportunities, and gather Technique, is a requirements gathering method
requirements for a new solution. The documents that aims to bridge the gap between the
may also include feedback from customers, expectations of developers and customers. It is a
reports of issues or suggestions, and specifications team-oriented approach where participants
of existing systems or products. collaborate to gather and define requirements for
a software application or system.
In simpler terms, document analysis means going
through all the written materials that are In a FAST session, attendees are asked to
important for our project or problem. We look at individually create lists of three types of items:
things like plans, studies, contracts, reports,
1. Things that are part of the environment
guidelines, and more. By studying these
surrounding the system.
documents, we can gain valuable information that
2. Things that the system produces or
helps us understand the situation and gather
outputs.
requirements for a potential solution.
3. Things that the system uses or takes as
3) BRAIN STORMING SESSIONS inputs.

Brainstorming sessions are group activities where After creating their lists, the participants combine
people come together to generate a lot of new them and eliminate any duplicate entries. The
ideas and share their viewpoints. The main goal team then splits into smaller sub-teams, each
is to encourage creative thinking and gather a focusing on developing detailed specifications for
wide range of perspectives. different items from the consolidated list. By
working collaboratively, the sub-teams create
In these sessions, it's important to have a skilled
mini-specifications that capture the requirements
facilitator who can manage any biases or conflicts
for each item.
that may arise within the group. The facilitator
ensures that everyone's ideas are heard and Finally, all the inputs from the meeting, including
valued. the consolidated list and the sub-teams' mini-
specifications, are used to draft a comprehensive
During the brainstorming session, all ideas are
set of specifications for the system. This approach
documented so that everyone can see them. This
helps ensure that the expectations of both
helps in keeping track of all the suggestions and
ensures that no idea is overlooked.
developers and customers are considered and 2. List out all requirements from the
included in the requirements specification. customer: Gather all the things that the
customer wants the software to do.
In summary, FAST is a method that involves
collaborative teamwork to gather and define 3. Assign importance to each requirement:
requirements. Participants create lists of Give a value or rating to show how
environmental factors, system outputs, and system important each requirement is.
inputs. These lists are consolidated, and sub-
4. Categorize the final list of requirements:
teams develop detailed specifications for different
At the end, classify each requirement into
items. The outputs from the meeting are then
one of the following categories:
used to create a comprehensive set of
specifications for the system. • Possible to achieve: These are
requirements that can be
5) QUALITY FUNCTION DEPLOYMENT
implemented.
In this technique, the main focus is on making • Should be deferred and the reason
the customer happy, so it emphasizes for it: Some requirements may
requirements that are valuable to the customer. need to be postponed for later due
There are three types of requirements identified: to certain reasons.
• Impossible to achieve and should
1. Normal requirements: These are the basic
be dropped off: Some requirements
objectives and goals of the proposed
may not be possible to fulfill, so
software that are discussed with the
they should be removed from the
customer. For example, for a result
list.
management system, normal requirements
could include entering marks and In simpler terms, this technique focuses on
calculating results. making the customer happy by considering their
important requirements. There are three types of
2. Expected requirements: These
requirements: normal, expected, and exciting. The
requirements are so obvious that the
steps involve identifying stakeholders, listing
customer doesn't need to explicitly
customer requirements, assigning importance to
mention them. An example would be
each requirement, and categorizing them as
protecting the software from unauthorized
achievable, deferred, or impossible to achieve.
access.
6) USE CASE APPROACH
3. Exciting requirements: These are features
that go beyond the customer's This technique combines words and pictures to
expectations and provide great satisfaction help us understand the requirements better. A
when they are present. For instance, if scenario is an example of how a specific function
unauthorized access is detected, the or task is carried out in the system.
system should automatically create a
Use cases describe the "what" of a system, not
backup and shut down all processes.
the "how." They provide a functional view of the
Here are the major steps involved in this system by describing the interactions between
procedure: actors (external agents like people or machines)
and the system. Use cases show who does what
1. Identify all the stakeholders: This means
with the system. A complete set of use cases
listing out all the people involved in the
covers all the possible ways the system can be
project, such as users, developers, and
used.
customers.
The use case design has three main components:
 1. Actors: Actors are the external agents that own set of advantages and disadvantages , some
interact with the system. They can be of the most common SDLC models include :-
people, machines, or other entities. Actors
➢ Waterfall model
are represented as stick figures. There are
➢ Agile model
two types of actors: primary actors, who
➢ spiral model
need assistance from the system to ➢ v-model
achieve their goals, and secondary actors, ➢ incremental model
who provide assistance to the system. ➢ iterative model

2. Use cases: Use cases describe the sequence

of interactions between actors and the Waterfall model
system. They show what actions actors
take and how they interact with the The waterfall model is a sequential design process
system. Use cases capture different used in software development that follows a
functionalities or tasks the system can linear and a rigid approach. It consists of a series
perform. of phases that must be completed in a linear
sequence , with each phase dependent on the
3. Use case diagram: A use case diagram is previous one , before moving on to the next.
a graphical representation of what These phases typically include requirements
happens when an actor interacts with the gathering and analysis , design implementation ,
testing , and maintenance. Once a phase is
system. It shows the functional aspects of
completed , the process moves on to the next
the system by illustrating the relationships
and there is no turning back or overlapping of
between actors and use cases. phases. This model assumes that all the
requirements are known and fixed at the
In simpler terms, this technique uses beginning of the project , and changes are not
pictures and words to understand the expected or are very minimal. The waterfall
system's requirements. A scenario is an model is often criticized for its inflexibility and
lack of adaptability to changes in requirements.
example of how something is done in the
system. Use cases describe what the The term “waterfall” in the context of software
development refers to the sequential flow of the
system does and how actors interact with
development process , where each phase must be
it. Actors are the external agents, like completed before moving on to the next. The
people or machines, and they can be name comes from the analogy of a water fall ,
where the water flows downwards in a series of
primary or secondary. Use case diagrams steps or stages. Similarly , in the waterfall model
show the interactions between actors and , each phase or stage of the development process
the system in a visual way. flows down to the next phase and it is not
possible to move back up once a phase is
Software Development Life Cycle Models completed.

A software development life cycle (SDLC) model

is a framework that describes the stages involved
in the development of software , from its
conception to its deployment and maintenance. It
is a process that software development teams
used to guide their work and ensure that
software products are delivered on time , with in
budget and to the required level of quality.

There are several different SDLC models that have

been developed over the years , each with its
 ➔ Where the tools and technology used is
consistent and is not changing
➔ When resources are well prepared and are
available to use.

Advantages of Waterfall model

✔ This model is simple to implement also

the number of resources that are required
for it is minimal

✔ The requirements are simple and explicitly

declared; they remain unchanged during
The waterfall model is a software development the entire project
model that follows a sequential approach with
the following steps :- ✔ The start and end points for each phase is
fixed , which make it easy to cover
1) Requirements Gathering and Analysis :- In this progress
phase , the requirements for the software are
gathered and analyzed to determine what the ✔ The release date for the complete product
software needs to do and what features are , as well as its final cost , can be
needed. determined before development.

2) Design :- In this phase , the software ✔ It gives easy to control and clarity for the
architecture and design are created based on the customer due to a strict reporting system.
requirements gathered in the previous phase.
Disadvantages of waterfall model
3) Implementation :- This phase involves the
actual coding of the software based on the design
✔ In this model , the risk factor is higher ,
created in the previous phase.
so this model is not suitable for more
significant and complex projects
4) Testing :- In this phase , the software is tested
to ensure it meets the requirements and is free of
✔ This model can no accept the changes in
errors or bugs.
requirements during development.
5) Deployment :- Once the software has been
✔ It becomes tough to go back to the phase
tested and approved , it Is deployed to the
, for example , if the application has now
production environment.
shifted to the coding phase , and there is
a change in requirement , it becomes
6) Maintenance :- This phase involves ongoing
though to go back and change it.
maintenance and support of the software
including bug fixes , updates and enhancements.
✔ Since the testing done at a larger stage ,
it does not allow identifying the
When to use SDLC Waterfall model ? challenges and risks in the earlier phase ,
and there is a change in requirement , it
Some circumstances where the used of the becomes tough to go back and change it.
waterfall model is most suited are :-
✔ Since the testing done at a larger stage ,
➔ When the requirements are constant and it does not allow identifying the
not changed regularly challenges and risks in the earlier phase ,
➔ A project is short so the risk reduction strategy is difficult
➔ The situation is calm to prepare.
 ➔ When the software application is large
Iterative Model
➔ When there is a requirement of changes
in future.
The iterative model is a software development
model where software is developed in small
Advantages (PROS) of iterative model :-
chunks or iterations , each of which includes all
the phases of the software development life
➔ Testing and debugging during smaller
cycle , such as planning , design ,
iteration is easy
implementation and testing. In contrast to the
waterfall model , which is linear and sequential ,
➔ A parallel development can plan
the iterative model is cyclical and allows for
feedback and adjustments throughout the
➔ It is easily acceptable to ever changing
development process. Each iteration results in a
needs of the project
working software product that can be tested and
evaluated providing valuable insights that can
➔ Risks are identified and resolved during
inform the next iteration , this approach is often
iteration
used in Agile development methodologies.

Disadvantage (Cons) of iterative model

The point of having iterations in the iterative
model is to allow for continuous feedback and
✔ It is not suitable for smaller projects
improvement throughout the development process.
Each iteration involves a cycle of planning ,
✔ More resources may be required
designing , implementing , testing and evaluating.
By breaking down the project in to smaller
✔ Design can be changed again and again
parts , teams can focus on improving and refining
because of imperfect requirements
each iteration before moving on to the next one.

✔ Requirement changes can use over budget

This allows for more flexibility and adaptability
as changes can be made at each iteration based
✔ Project completion date not confirmed
on feedback and testing. Iterative development
because of changing requirements.
also helps to reduce risk as potential issues or
defects can be identified and addresses early on
in the process.
Incremental Model

The incremental model in software engineering is

a process model that breaks down the
development process in to small increments , or
modules , that are developed and tested
incrementally until the entire system is
completed.

In the incremental model , each module is

developed and tested separately , and then
integrated in to the larger system. This approach
allows for early testing and detection of errors or
issues and for adjustments to be made before the
entire system is completed.

When to use the iterative model ? The incremental model is beneficial for large
projects where it is difficult to predict all the
➔ When requirements are defined clearly requirements at the beginning of the development
and easy to understand process. It allows for flexibility in adapting to
changing requirements or needs and for
continuous feedback and improvement throughout
the development process.

Like the waterfall model , the incremental model

follows a linear sequential approach to software
development , where the requirements are
gathered , analyzed and defined at the beginning
of the project. However , unlike the waterfall
model , the development process is divided in to
smaller , more manageable modules or
increments.

Each increment delivers a portion of the Agile Model

functionality required by the complete system ,
allowing developers to test and evaluate the The Agile SDLC (Software Development Life
software at each stage of the development Cycle) is a methodology for developing software
process. Once an increment is completed , it is
that emphasizes flexibility, speed, and
integrated with the previous increments to form a
collaboration. An agile is the time-confined,
working system.
iterative approach to the software transmission
The difference between iterative and that develops software from the initiating of the
incremental models project to deliver it properly, up to the end.

Customer Collaboration: The customer, or end-

In the iterative model , each iteration involves a
complete cycle of requirement gathering , user, is involved throughout the development
design , development , testing and deployment. process and provides continuous feedback on the
The output of each iteration is a working product software being developed. This helps to ensure
that can be evaluated by the stakeholders. The that the software meets their needs and
process then repeats with the next iteration , expectations.
incorporating feedback and making improvements
along the way. Emphasis on Individuals and Interactions: The
Agile SDLC values people and communication
In contrast , the incremental model involves over processes and tools. Team members work
dividing the project in to smaller , self-contained together closely, collaborate frequently, and
pieces that can be developed and deployed
communicate openly to ensure that everyone is
independently. Each increment adds a new set of
features or capabilities to the product , building on the same page.
on the work of previous increments. Responding to Change: The Agile SDLC recognizes
that requirements and priorities can change over
The key difference between the two is that in the
the course of a project, and emphasizes the need
iterative model , each iteration involves a
complete cycle of development , where as in the to be able to adapt quickly and effectively.
incremental model , development is done In small
Agile is a way of creating software that focuses
increments that build on each other over time.
on teamwork, communication, and flexibility.
Instead of trying to create a big, complicated
program all at once, Agile breaks it down into
smaller parts called "user stories". Each user story
represents a small piece of functionality that the
software needs to have in order to be useful.

The team works together to decide which user

stories are the most important, and they prioritize
them based on how essential they are to the and show it to everyone. Then we ask if they
software. Then they work on each user story in like it and if they want any changes. We listen to
short periods of time called "iterations". During their ideas and make the changes right away.
each iteration, the team works to complete a few
Then we move on to the next part, like a gate or
user stories, and they test the software to make
a wall. Again, we build it quickly and show it to
sure it's working correctly.
everyone. We keep doing this, building small
parts and getting feedback, making changes as we
go along.

This way, we can see the castle taking shape

gradually, and we can make improvements based
on what we learn along the way. It's like
building the castle piece by piece, getting
feedback, and making it better as we go. It helps
us work together as a team and make sure we're
building something that everyone likes.

So, in the Agile model, we build software in

small pieces, get feedback, and make
improvements as we go along, just like building a
The team also communicates with each other and LEGO castle bit by bit and making changes based
with the customer throughout the development on what we learn.
process, to make sure everyone is on the same
Agile is a way of working in software
page and that the software is meeting the
development that focuses on flexibility and
customer's needs. They make adjustments as they
collaboration. It's like being part of a sports team
go, so that the software is always improving and
where everyone works together to score goals and
adapting to changing requirements.
win the game.
The Agile approach helps the team work more
In the Agile model, instead of trying to plan
efficiently, because they're not trying to do too
everything from the beginning and following a
much at once. It also helps them catch problems
fixed plan, we break the work into smaller parts
early, because they're testing the software as they
called "sprints." Each sprint is like a mini-project
go, instead of waiting until the end. And because
with a specific goal. It's similar to playing a
they're working closely with the customer
series of matches in a tournament.
throughout the development process, they can be
sure that they're creating software that will During each sprint, the team works together to
actually be useful and valuable. build a small piece of software, like a feature or
a module. They have regular meetings called
Let’s simplify the agile approach "stand-ups" where they discuss progress and any
challenges they're facing. It's like gathering in the
Imagine you want to build a big LEGO castle
locker room to discuss tactics and strategies for
with your friends. The traditional way would be
the next match.
to plan everything in advance, like how many
pieces you need, what the castle will look like, At the end of each sprint, the team reviews what
and then build it step by step following the plan. they have built and gets feedback from customers
or stakeholders. This feedback is important
But in the Agile model, we do things a little
because it helps the team understand if they're
differently. Instead of planning everything at the
heading in the right direction, just like analyzing
beginning, we start with a small part of the
castle, maybe just a tower. We build it quickly
the game after each match to see what worked the story. Again, you pause, review, and get
and what needs improvement. feedback to make further improvements. You
keep repeating this process until the story is
Based on the feedback, the team adjusts their
complete.
plans and decides what to work on in the next
sprint. They can change their strategies or adapt The Spiral model is like climbing a spiral
to new information. It's like adjusting their game staircase. With each step, you make progress and
plan for the next match based on what they get closer to your goal. But at each step, you
learned from the previous ones. also check your surroundings, see if there's a
better path, and adjust your course if needed. It's
This cycle of sprints, feedback, and adjustments
a continuous process of learning, improving, and
keeps repeating throughout the software
moving forward.
development process. It allows the team to be
flexible and respond quickly to changes or new So, in simple terms, the Spiral model is like
requirements, just like a sports team that adjusts writing a story chapter by chapter. You write a
its tactics during the tournament. part, get feedback, make improvements, and then
move on to the next part. It's a step-by-step
Agile emphasizes teamwork, communication, and
approach that allows you to learn and adjust
continuous improvement. It's like playing a sport
along the way, making the story better with each
where everyone has a role to play, and together,
cycle.
they strive to deliver the best software possible.
The Spiral model is a software development
So, in simple terms, Agile in software engineering
methodology that combines the iterative and
is about breaking work into smaller parts,
incremental approach of the Agile model with the
working together as a team, getting feedback
structured and systematic approach of the
regularly, and adjusting plans based on what is
Waterfall model. It's called the Spiral model
learned along the way. It's like being part of a
because it involves a series of cycles, or "spirals",
sports team where collaboration and adaptability
each of which represents a phase in the
are key to success.
development process.

Each spiral cycle involves four main steps:

Spiral Model planning, risk-analysis, engineering, and
evaluation. The planning phase involves defining
The Spiral model is a way of developing software
the project objectives and requirements, and
that focuses on learning and improving as you
creating a plan for how the software will be
go. It's like taking small steps forward while
developed. The risk analysis phase involves
constantly checking and adjusting your path.
identifying potential risks and uncertainties that
Imagine you have a big project, like writing a could affect the project, and creating strategies
story. Instead of writing the whole story at once, for dealing with them.
you break it into smaller chapters. Each chapter
The engineering phase involves developing the
is like a cycle in the Spiral model.
software, using the plan and strategies created in
In each cycle, you plan and write a part of the the earlier phases. The evaluation phase involves
story. Then, you pause to review what you've testing the software to make sure it works
written and get feedback from others. This correctly and meets the requirements.
feedback helps you make the story better and
The Spiral model is unique because it involves a
catch any mistakes or things that can be
continuous process of planning, risk analysis,
improved.
engineering, and evaluation, with each spiral
After getting feedback, you move on to the next building upon the previous one. This allows for
cycle, where you plan and write the next part of the software to be refined and improved over
time, and for potential risks to be identified and impact of any issues that do arise, and keeps the
addressed early on. development process on track.

Compared to other software development The Spiral model also allows for incremental
methodologies, the Spiral model is more flexible releases of the software, which means that the
and adaptable, because it allows for changes and team can release parts of the software as they're
adjustments to be made throughout the completed, instead of waiting until the entire
development process. It also places a greater project is finished. This helps to keep the
emphasis on risk management, which can help to customer informed of the progress of the project,
prevent problems and delays later on. and allows them to provide feedback and make
adjustments along the way.
Overall, the Spiral model is a flexible and
adaptable approach to software development that
emphasizes risk management and continuous Let’s Define them in simpler terms
improvement. It's a good choice for complex and
Imagine you want to bake a delicious cake, but
high-risk projects, where it's important to have a
you're not sure how it should turn out. The spiral
structured and systematic approach while also
model is like trying different recipes and making
allowing for flexibility and adaptation.
the cake better each time.

First, you start by mixing some basic ingredients

like flour, sugar, and eggs. This is the first step
of the spiral. You bake a simple cake and taste it
to see if it's good. If it's not perfect, that's okay
because it's just the beginning.

In the next step, you add more ingredients to

make the cake better. Maybe you add some
chocolate chips or vanilla extract to give it more
flavor. You bake the cake again and see if it's
better than before. If it's not quite right, you can
still make changes and try again.
The Spiral model takes the best parts of both of
With each step, you add new things and improve
these models and combines them into one. This
the cake. You might try different frosting or
model is called the Spiral model because it
decorations, like colorful sprinkles or fruit on top.
involves a continuous cycle of planning,
Each time you bake the cake, you learn what
development, and evaluation, with each cycle
works and what doesn't. You make adjustments
building upon the previous one in a spiral shape.
to the recipe, like changing the amount of sugar
During each cycle, the team works on a small or the baking time, based on what you learn.
part of the software, testing and refining it as
The spiral keeps going, with each round making
they go. They also analyze potential risks and
the cake better and better. You keep trying new
problems that could occur during the
things, making changes, and improving the cake
development process, and create plans for how to
until it becomes just the way you want it.
deal with them.
So, in the spiral model, software development is
The Spiral model is very focused on risk analysis,
like baking a cake. You start with a basic version
which means the team looks for potential issues
and keep adding new features and making
or problems that could occur during the
improvements with each iteration, just like
development process, and creates plans for how
adding ingredients and making adjustments to the
to deal with them. This helps to minimize the
cake until it tastes amazing. It's all about learning
from each step and making the final software as just like adding new features and making the tree
good as it can be. house better each time you work on it.

Another analogues definition V-Model

Imagine you have a big project to complete, like The V-Model is a software development
building a tree house. The Spiral model is like a methodology that is similar to the Waterfall
step-by-step process where you keep improving model. It involves a sequential, step-by-step
and adding new things to make the tree house approach to software development, with each step
better each time. building upon the previous one. However, the V-
Model also emphasizes the importance of testing
First, you start by planning and designing the
throughout the development process.
tree house. You think about how it should look,
what materials you need, and what features you The V-Model is called the V-Model because the
want to include, like a slide or a rope ladder. development process is shaped like the letter V.
This is the first step of the spiral. At the top of the V are the requirements
gathering and analysis stages, which involve
Next, you build a small part of the tree house
defining the project requirements and creating a
based on your design. It could be the foundation
plan for how the software will be developed.
or the base structure. Once you finish that part,
Then, the development process moves down the
you test it to see if it's strong and stable. If it's
left side of the V, with each step involving more
not quite right, you make adjustments and
detailed design and development work.
improvements.
At the bottom of the V is the testing phase,
Then, you move on to the next part, like adding
which involves testing the software to make sure
walls or a roof. Again, you build it, test it, and
it works correctly and meets the requirements.
make improvements if needed. Each time you add
Then, the development process moves up the
a new part, you check to make sure everything is
right side of the V, with each step involving
working well together.
more detailed testing and evaluation of the
As you keep building and testing, you learn from software.
your previous work and make the necessary
The V-Model is unique because it places a strong
changes. You might realize that you want to add
emphasis on testing throughout the development
more windows or make the tree house bigger.
process. This means that the software is tested at
With each step, you keep improving and refining
every step of the way, to ensure that it works
the design based on what you learn.
correctly and meets the requirements. This helps
The spiral keeps going, with each round making to catch any issues or problems early on, before
the tree house better and better. You add new they become bigger and more expensive to fix.
features, fix any problems, and make
Compared to other software development
improvements based on your testing and
methodologies, the V-Model is more structured
feedback.
and formal, with a clear plan and set of steps
So, the Spiral model in software engineering is that the team must follow. It's a good choice for
like building a tree house. You plan, build, test, projects where the requirements are well-defined
and improve in a continuous cycle. Each time and unlikely to change, and where there is a
you go around the spiral, you add new parts and strong emphasis on testing and quality control.
make adjustments based on what you learn. It's
all about continuously improving the software,
 something awesome while making sure everything
is just right along the way.

SOFTWARE DEVELOPMENT LIFE CYCLE

COMPARISON

There are different ways to develop software, and

each model has its own approach. Here are a few
models explained in simpler terms:

1. Waterfall Model: The Waterfall model is

like following a strict and straight path.
You complete one phase before moving
on to the next. However, this model
doesn't work well when you need to make
Define it in simpler terms
frequent changes because it doesn't allow
for flexibility.
Imagine you want to make a drawing of a cute
animal. The V-model is like following a specific 2. Spiral Model: The Spiral model combines
order to create your artwork step by step. elements of the Waterfall and Iterative
models. It focuses on managing risks
First, you start by drawing the outline of the
throughout the development process.
animal. This is the top part of the "V." It's like
While it offers some flexibility, it can be
drawing the basic shape of the animal, such as
complex and time-consuming, making it
its body and head.
less suitable for some projects.
Next, you move down to the middle part of the
3. V-Model: The V-Model is an extension of
"V." Here, you add more details to your drawing.
the Waterfall model. It emphasizes
You draw the eyes, nose, mouth, and other
validation and verification at each stage.
features that make the animal look cute and
However, like the Waterfall model, it
recognizable.
lacks flexibility and can be challenging to
Then, you go to the bottom part of the "V." This adapt to changes.
is where you color your drawing. You use
4. Iterative Model: The Iterative model
different colors to make the animal look vibrant
involves developing the system in small
and lively.
steps, allowing for flexibility and
Once you finish coloring, you move up the other adaptability. It's like taking small bites of
side of the "V." Here, you check your drawing a big sandwich. However, it may not
for any mistakes or things that need provide the same level of continuous
improvement. If you find something that doesn't collaboration and improvement found in
look right, you can make changes and fix it. Agile methodologies.
Finally, at the very top of the "V," you have 5. Incremental Model: The Incremental
your completed, beautiful drawing of a cute model breaks the project into smaller
animal! parts, with each part adding new features
So, in simpler terms, the V-model is like to the system. It offers more flexibility
following a specific order to create a drawing than the Waterfall model, but it still lacks
step by step. You start with the outline, add the continuous improvement and
details, color, check for mistakes, and then you collaboration aspects found in Agile.
have your finished artwork. It helps you create
So, in simpler terms, each software development
model has its own way of doing things. Some are ➔ Deployment Diagram
rigid and sequential, while others are more
flexible. Agile, which we haven't discussed yet, is
another model known for its adaptability, USE CASE DIAGRAM
collaboration, and continuous improvement.
In software engineering , a use case is a
description of the intended functionality of a
UNIFIED MODELING LANGUAGE software system from the perspective of a user or
a stake holder. A use case describes a sequence
UML (Unified Modeling Language) is a of interactions between the user and the system
standardized modeling language used in software that produces a result of value to one of the
engineering to design and visualize software stakeholders.
systems. It provides a graphical notation to
represent various aspects of a software system , Use cases can be represented visually using a use
including its structure , behavior , and case diagram , which is a type of UML diagram.
interactions between different components. A use case diagram is composed of actors , use
cases and the relationships between them. An
UML was developed by the Object Management actor is a user or an external system that
Group (OMG) as a means of standardizing the interacts with the system , while a use case
various notations used on object-oriented software represents a specific functionality of the system.
development. It is now widely used by software The relationships between actors and use cases
engineers , analysts , and developers to describe , are depicted using lines.
design , and communicate the architecture of
complex software systems. How to draw a use case diagram

UML provides various types of diagrams including

use case diagrams , class diagrams , sequence
diagrams , state diagrams , and activity diagrams
to represent different aspects of the software
system. These diagrams help developers and
stakeholders to understand the system’s
architecture and behavior , making it easier to
identify potential issues and communicate
requirements and design decisions.

UML DIAGRAMS

➔ Class diagrams

➔ Use case diagrams

➔ Sequence diagrams

A use case is a representation of the functionality

➔ Activity diagram
of a system , to create a use case diagram , it is
important to follow certain rules to ensure that
➔ State Machine Diagram the diagram accurately represents the system’s
functionality in a clear and concise way.
➔ Package Diagram
Firstly , each actor or use case should be given
an appropriate and meaningful name. This helps
➔ Component Diagram
to clearly identify and differentiate between the does no have an account , this steps for creating
different components of the system. an account will be included in the login process.

Secondly , the communication between the actors The include relationship is represented by a
and the use case must be defined in dashed arrow pointing from the base use case to
understandable way. This helps to ensure that the the included use case , with the label «include»
diagram accurately represents the interactions on the arrow. The base use case should reference
between the different components of the system. the included use case in its description and the
included use case should not reference the base
Thirdly , specified notations should be used as use case.
and when required. This helps to ensure that the
diagram follows a standard conventions and ways Extend :- The extend relationship in use case
for others to understand. diagrams is used to indicate optional behavior
that can be added to a base use case. The
Finally , the use cases should be enclosed with in optional behavior is represented by an “extension
a rectangle called the system boundary box , point” in the base use case. The extend use case
which indicates the scope of the system. All the is optional and not mandatory.
use cases inside the rectangle represent the
functionality that we intend to implement and For example , consider a use case “order
anything outside the rectangle is considered out Product” which involves selecting a product and
of scope for the system. addition it to the cart , and checking out.
However , the system may have an additional
By following these rules , the use case diagram feature where the user can apply a discount code
can be created in a structured and effective way , during check out. This is additional behavior can
ensuring that it accurately represents the system’s be represented as an extension of the “Order
functionality and is easy to understand for all Product” use case.
stake holders.
In this case , we would draw an “extend”
<< Include >> and << Extend >> relationship from the “Order product” use case
called “Apply Discounted code”. The “extend”
In UML use case diagrams , include and extend relationship is shown with a dashed arrow
are two relationships between use cases that pointing from the base use case to the extending
describe how they are related to each other. use case. The extension point in the base use
case would be labeled “Apply Discount Code”.
Include :- An include relationship is used when
one use case includes the functionality of another During the execution of the base use case , the
use case. It represents a common behavior that is system checks whether any extending use cases
reused in several use cases. The including use are applicable based on the extension point. If an
case adds additional behavior to the included use extension is applicable , it is executed in the
case. The included use case is mandatory and not addition to the base use case. If no extensions
optional. are applicable , the base use case is executed as
normal.
In the include relationship , one use case (called
the “base” use case) includes functionality of CLASS DIAGRAMS
another use case (called the “included” use case).
This means that the steps of the included use UML (Unified Modeling Language) class diagrams
case are inserted in to the base use case are a type of static structure diagram that depict
wherever the include relationship appears. the classes , interfaces and their relationships to
each other in a software system.
For example , suppose we have two use cases ,
“create account” and “login”. The “Login” use In a class diagram , a rectangle represents a class
case includes the “create account” use case , , with the class name appearing at the top. The
meaning that when a user attempts to log in but class attributes and methods are listed in separate
compartments inside the rectangle. The attributes
represent the properties or data associated with the behavior it performs. The parameters of the
the class , while the methods represent the method , if any , should be listed.
behaviors or actions the class can perform.
In addition to these three sections , the class
Relationships between classes are depicted by diagram also shows the relationships between
lines connecting the classes. There are several classes. The relationships can be of different types
types of relationships , including inheritance such as association , aggregation and inheritance.
(represented by a solid line with an arrow head These relationships help to define the behavior
pointing to the super class) , association and structure of the system being modeled.
(represented by a line connecting two classes) ,
and aggregation or composition (represented by a
diamond – shaped arrow head pointing to the
containing class)

The UML class diagram is a useful tool for

visualizing the structure of a software system ,
and can aid in the design , implementation , and
maintenance of a software applications.

The class diagram is a graphical representation of

a system that displays the classes , their
attributes and operations, along with the
relationships between them. It is a type of static
structure diagram that represents the static
structure of the system.

The upper section of the class diagram contains

the name of the class , which represents the type Relationships
of object that is being modeled. It is important to
give meaningful name to the class so that it can Dependency :- In UML Dependency is a
be easily identified and understood. The name of relationship between two elements , in which a
the class should be capitalized and placed in the change in one element affects the other element.
center of the upper section. It should be written It is represented as a dashed arrow with an
in bold format to distinguish it from other arrow head pointing towards the element on
elements in the diagram. which the other element depends.

The middle section of the class diagram contains Dependency relationship represents the concept of
the attributes of the class , which describe the using or depending on another element in the
quality of the class. Attributes are the properties system. It is a relationship in which one
of an object that define its state. They are element , called the client , uses or depends on
written along with their visibility factors , which another element , called the supplier for its
indicate whether they are public (+) , private implementation or operation. The supplier
(-) , protected (#) or package ( ~). A meaningful provides service , function or resource that is
name should be assigned to each attribute to needed by the client to operate.
explain it usage inside the class.
For example , a car engine is dependent on the
The lower section of the class diagram contains fuel system , which supplies fuel to the engine. If
the methods or operations of the class. Methods the fuel system fails , the engine will not operate
define the behavior of an object and describe properly. In this case , the engine represents the
how it interacts with data. Each method is client , and the fuel system represent the
represented in the form of a list , where each supplier.
method is written in a single line. The method’s
name should be descriptive , and clearly indicate
 this case , there is an association between the
customer class and the car rental class , as a
customer is associated with a specific car rental
transaction. The association can be represented as
Generalization follows :

In UML , generalization represents an inheritance

relationship between two classes where one class
is a more specific version of another class. The
more specific class is called the sub class or the
derived class and the more generalized class is
called the super class or the base class.

Generalization is represented by an arrow with a

hollow triangle at one end that points towards
the base class , and the derived class is
The above example shows a uni-directional from
conducted to the base class with this arrow. The
customer to car rental. The arrow head pointing
arrow indicates that the derived class inherits
to the car rental class indicates that the
properties , attributes and behaviors from the
association is navigable from the customer class
base class.
to the car rental class but not vice versa.
Generalization allows the reuse of code and
Association can also have multiplicity , which
eliminates redundancy by promoting the creation
defines the number of instances that can
of common attributes and behaviors in a super
participate in the association. Multiplicity can be
class that can be inherited by its sub class. It
expressed using a range or a specific number. For
also facilitates the modeling of complex systems
example , a customer can rent multiple car
by allowing for the abstraction of common
rentals , while a car rental can only be associated
features in to a more general class.
with one customer at a time.

In UML , multiplicity is used to specify how

many instances of one class are associated with
(connected to) the instance of another class. It is
represented as a range of numbers or specific
values that define the number of occurrences of a
class in a given association.

For example , a one to many relationship

between two classes can be represented as “1..*”
or “1 to many” in the multiplicity notation. This
means that each instance of the first class is
associated with one or more instances of the
second class.
Association
Similarly , a many to many relationship can be
In UML , association is a relationship between represented as “…” or “many to many”
two or more classes that describes a connection indicating that each instance of both classes can
or link between them. It shows that objects of be associated with many instances of other class.
one class are somehow related to objects of
another class. Association can be represented Multiplicity also includes minimum and maximum
using a solid line connecting the classes , with a values to specify constraints on the number of
possible arrow head indicating the direction of associations, for example , a range of “0 … 1”
the relationship. means that an instance of the class may or may
For example , consider a car rental system where not be associated with another instance of the
a customer rents a car for a rental agency. In class , while a range of “1..3” means that each
instance must be associated with at least one and aggregation relationship is indicated by a
up to three instances of another class. line with a hollow diamond at the whole
class's end.
AGGREGATION
Imagine you have a company with
In a class diagram, an aggregation relationship
employees. Aggregation is like understanding
represents a connection between classes where
how the company and its employees are
one class is considered as a "whole" and another
connected.
class is considered as a "part." It shows that the
whole class contains or is composed of instances In an aggregation relationship, the company
of the part class. is the "whole," and the employees are the
"parts." It's like the company is made up of
In simpler terms, an aggregation relationship
in a class diagram shows that one class is its employees, but the employees can still
exist independently even if they are not part
made up of or contains instances of another
class. It indicates a "part-of" or "has-a" of the company anymore.

relationship between the classes. For example, let's say you have a company

The aggregation relationship is represented called "ABC Corp" and several employees
working for it. The aggregation relationship
by a line with a hollow diamond at the
whole class's end, pointing towards the part shows that "ABC Corp" has a group of
employees, but each employee can have their
class. The hollow diamond signifies the
aggregation relationship. It shows that the own existence and identity outside of the
company. Even if one employee decides to
part class is a component or part of the
whole class. leave or resign, the company "ABC Corp"
will still continue to exist.
For example, let's consider a class diagram
for a car rental system. The system has two Think of it like a house and its rooms. The
house is the "whole," and the rooms are the
classes: "Car" and "RentalAgency." The
"RentalAgency" class has an aggregation "parts." Each room can exist on its own,
even if it's not part of that specific house
relationship with the "Car" class. This means
that the "RentalAgency" contains or has anymore. The house can still stand and
function even if a room is vacant or no
instances of the "Car" class as part of its
operations. longer part of it.

In an aggregation relationship, the parts are

The aggregation relationship indicates that
the "RentalAgency" class manages or has a connected to the whole, but they maintain
their independence. It's a way to represent
collection of cars. Each car instance is
considered a part of the rental agency's that something is made up of smaller
components, and those components can exist
overall system.
separately if needed.
In summary, an aggregation relationship in a
So, in simpler terms, aggregation is like
class diagram represents the connection
between classes where one class is considered understanding how a company and its
employees are connected. The company is
a whole and another class is considered a
part. It shows that the whole class contains made up of employees, but each employee
can still exist independently. It's similar to
or has instances of the part class. The
how a house is made up of rooms, and each
room can stand on its own. Aggregation In composition, there is a strong relationship
shows the relationship between the whole between a "whole" and its "parts." If you remove
and its parts while recognizing the the whole, the parts cannot exist on their own.
They are tightly connected.
independence of the parts.
For example, let's think about a contact book and
Imagine you have a collection of toys. its contacts. The contact book is the whole, and
Aggregation is like putting some toys together in the contacts are the parts. If you delete the
a special box. contact book, all the contacts inside it will be
lost because they only exist as part of that
In a class diagram, aggregation shows that one specific contact book.
class contains or holds another class as part of its
collection. It's like having a big toy box that can Think of it as building a toy car using Lego
hold different toys. blocks. The toy car is the whole, and the Lego
blocks are the parts. If you take apart the toy
For example, let's say you have a "ToyBox" class car, the Lego blocks can be used for other things.
and a "Toy" class. The "ToyBox" class can have But in composition, it's like using glue to
an aggregation relationship with the "Toy" class. permanently attach the Lego blocks to create the
This means that the "ToyBox" class can hold or toy car. If you break the toy car, you cannot
contain multiple instances of the "Toy" class. separate the blocks easily because they are now
Aggregation is shown in a class diagram using a part of the car.
line with a hollow diamond at one end pointing In simpler terms, composition is when you create
towards the class that contains the other class. It something by putting parts together, and those
shows that the class with the diamond (like the parts cannot exist independently. They are
"ToyBox" class) is the whole or container, and dependent on the whole. If you remove the
the class without the diamond (like the "Toy" whole, the parts are lost too. It's like building
class) is part of that whole. something with puzzle pieces that are
So, in simpler terms, aggregation is like putting permanently connected, and if you break it, the
different toys together in a special box. The box pieces cannot be separated.
(the whole) can contain many toys (the parts). It's So, composition represents a whole-part
a way to show that one class holds or contains relationship where the parts cannot exist without
instances of another class. the whole, and if the whole is removed, the parts
are lost.

Composition is like creating something by

combining different parts, where the parts are
essential to the existence and functioning of the
whole. It represents a strong relationship between
the whole and its parts.

Imagine you have a robot toy. The robot toy is

made up of various components like a body,
head, arms, and legs. In composition, these
components are put together to form the
COMPOSITION complete robot toy.
Imagine you have a puzzle set with different The important thing about composition is that the
pieces. Composition is like when you create parts are tightly connected and dependent on the
something using those puzzle pieces that cannot whole. If you were to take apart the robot toy,
be taken apart easily.
the individual parts wouldn't have much purpose 3) The attributes and methods of each class must
or meaning on their own. They are designed to be known.
work together as a cohesive unit.
4) A minimum number of desired properties
For example, let's consider a car and its wheels. should be specified as more number of unwanted
The car is the whole, and the wheels are the property will lead to a complex diagram.
parts. The wheels are an integral part of the car's
5) Notes can be used as and when required by
structure and functionality. If you were to remove
the developer to describe the aspects of the
the wheels, the car would not be able to move
diagram.
properly or function as intended.
6) The diagrams should be redrawn and reworked
Similarly, think of a house and its rooms. The
as many times to make it correct before
house is the whole, and the rooms are the parts.
producing its final version.
Each room is a crucial component of the house,
serving different purposes such as a bedroom, Usage of class diagrams
kitchen, or living room. If you were to remove a
room from the house, it would no longer be The class diagram is used to represent a static
complete or functional. view of the system. It plays an essential role in
the establishment of the component and
In simpler terms, composition is like putting deployment diagrams.
together different parts to create something
whole. The parts are interconnected and rely on It helps to construct an executable code to
perform forward and backward engineering for
each other for the overall functionality and
any system , or we can say it is mainly used for
purpose of the whole. If you were to remove the
construction , it represents the mapping with
whole, the parts wouldn't make much sense or object – oriented languages that are C++ , Java ,
serve their intended purpose individually. etc.
Composition represents a strong relationship
where the parts are tightly connected to the Let's explore the different types of relationships in
whole. a class diagram:

1. One-to-One (1:1) Relationship: In a one-

to-one relationship, one instance of a
class is associated with exactly one
instance of another class. It means that
for every object in Class A, there is only
one related object in Class B, and vice
versa. This relationship is represented by
a straight line between the two classes,
How to draw a class diagram
with a "1" on one end and a "1" on the
A collection of class diagrams as whole represents other end.
a system. Some key points to keep in mind while
For example, consider the relationship between a
drawing a class diagram are :-
Person and their Passport. Each person can have
1) To describe a complete aspect of the system , only one passport, and each passport is assigned
it is suggested to give meaningful name to the to only one person.
class diagrams.
2. One-to-Many (1:N) Relationship: In a one-
2) The objects and their relationships should be to-many relationship, one instance of a
acknowledged in advance. class is associated with multiple instances
of another class. It means that for every
object in Class A, there can be multiple
 related objects in Class B, but each object SEQUENCE DIAGRAMS
in Class B is related to only one object in
Class A. This relationship is represented Sequence diagrams are a type of UML diagram
used in software engineering to depict
by a straight line with an arrow pointing
interactions between objects or components of a
from the "1" end to the "N" end.
system. They are commonly used to visualize how
For example, consider the relationship between a different components of a system interact with
each other over time.
University and its Students. A university can have
many students, but each student can be
In sequence diagram , time flows from top to
associated with only one university. bottom , with different objects or components
depicted as vertical lines.
3. Many-to-One (N:1) Relationship: In a
many-to-one relationship, multiple
When we say that time flows from top to the
instances of a class are associated with bottom in a sequence diagram , it means that the
one instance of another class. It means diagram represents a chronological sequence of
that for every object in Class A, there is events in a system or process. Each vertical line
exactly one related object in Class B, but in the diagram represents an object or component
multiple objects in Class A can be in the system and the horizontal arrows between
the lines represent the messages or interactions
associated with the same object in Class
between them. The diagram is read from top to
B. This relationship is represented by a
bottom , with the events at the top occurring
straight line with an arrow pointing from before those at the bottom. This allows us to
the "N" end to the "1" end. understand the sequence of events and the order
in which messages are sent and received between
For example, consider the relationship between a
components. The sequence diagram is powerful
City and its Mayor. Many cities can have the tool in software engineering for understanding
same mayor, but each mayor is associated with complex systems and processes and designing
only one city. effective software solutions.

4. Many-to-Many (N:N) Relationship: In a Horizontal lines represent messages exchanged

many-to-many relationship, multiple between these objects or components. These
instances of a class are associated with message can include method calls , responses or
multiple instances of another class. It exceptions.
means that for every object in Class A,
The sequence diagram can also include various
there can be multiple related objects in
types of actors or stake holders , such as user or
Class B, and vice versa. This relationship
external systems. These actors are typically
is represented by a line with crow's feet depicted as stick figures. can be any person ,
or dots on both ends. system or organization that interacts with the
system or software. These actors may trigger
For example, consider the relationship between
certain events in the system or respond to events
Students and Courses. Many students can be generated by the system.
enrolled in multiple courses, and each course can
have multiple students enrolled. For example , in a banking system , a customer
may be an actor who initiates the process of
These different types of relationships in a class
transferring funds. Similarly , a bank employee
diagram help depict how objects or instances of can be an actor who processes the customer’s
classes are connected and associated with each request. An external system , such as a payment
other. They provide a visual representation of the gate way , can also be an actor who
associations and dependencies between classes, communicates with the banking system to
helping to understand the structure and behavior complete the transaction.
of a system.
The stick figures representing the actors are This includes identifying the methods or
usually positioned outside the system boundary functions that are called, as well as the
box to depict that they are external to the data that is passed between them.
system. The sequence diagram then show how
the messages or interactions flow between the 3. Determine the sequence of events: After
actors and the system. defining the messages and interactions,
you need to determine the sequence in
The interactions between actors and the system
which they occur. This involves
can be various types , such as sending a message
identifying the order in which messages
, receiving a message , calling a method , or
returning a value. These interactions are are sent and received, and the
represented as arrows in the sequence diagram , dependencies between different
with the arrows showing the direction of interactions.
communication. The messages or interactions can
be synchronous or asynchronous depending on 4. Draw the diagram: Once you have
weather they happen at the same time or not. identified the objects, actors, messages,
interactions, and sequence of events, you
In the sequence diagram , actors or stakeholders can start drawing the sequence diagram.
are represented as stick figures to show their The diagram should include boxes
interaction with the system or software being
representing the objects and actors, and
designed. Actors
arrows representing the messages and
One of the benefits of sequence diagrams is that interactions between them. The sequence
they allow developers to identify potential bottle of events should be represented by the
necks or performance issues in the system. By order of the arrows.
visualizing the sequence of events and
interactions , developers can identify areas where 5. Add details and annotations: Finally, you
the system may be slow or inefficient. can add details and annotations to the
diagram to clarify the interactions and
The sequence diagrams are powerful tool for explain any important details. This may
software engineers to visualize and design include labels for the objects and actors,
complex systems , as they allow for the clear
descriptions of the messages and
representation of interactions and dependencies
interactions, and notes on any important
between components.
decisions or conditions that affect the
How to draw a sequence diagram sequence of events.

Here are some of the symbols used in a sequence

1. Identify the objects and actors involved in diagram and their applications:
the scenario: The first step in drawing a
sequence diagram is to identify the 1. Objects: Objects are represented by
objects and actors involved in the rectangular boxes with the name of the
scenario you are trying to model. Objects object inside. Objects can represent
are the entities within the system that anything from a person or a device to a
interact with each other, while actors are software component or module.
external entities that interact with the 2. Lifelines: Lifelines are vertical dashed lines
system. that represent the lifespan of an object in
2. Define the messages and interactions the sequence diagram. They are drawn
between the objects and actors: Once you underneath the object box and indicate
have identified the objects and actors, you the period of time during which the
need to define the messages and object exists and can receive or send
interactions that occur between them. messages.
 3. Messages: Messages are represented by types of flows , activity diagrams include
arrows between objects or actors, and specialized symbols , such as forks and joins.
they indicate the communication between
Activity diagrams are particularly useful for
them. Messages can be synchronous
modeling complex systems or processes with
(represented by a solid arrowhead) or
multiple steps and decision points. By breaking
asynchronous (represented by an open down the workflow in to individual activities and
arrowhead). A message can also have a illustrating the relationships between them ,
return value, which is represented by a activity diagrams can help developers and stake
dashed arrow. holders better understand the behavior of the
system and identify areas where improvements
4. Activation Bars: Activation bars are thin can be made.
rectangles that show the time during
which an object is executing a method or An activity diagram is behavioral modeling
function. They are drawn on the lifeline diagram in unified modeling language (UML) to
illustrate the flow control with in a system. It
of the object and indicate the period of
shows the actions and states involved in a
time during which the object is busy
particular system , process or workflow. The
processing a message. activity diagram consists of various elements that
represent different types of actions such as initial
5. Self-Message: A self-message is a message
state , final state , decision box , and action box.
that an object sends to itself. It is
represented by an arrow that points back The initial state is represented as a circle with a
to the same object. black dot in the center , indicating the starting
point of the set of actions. The final state , on
6. Combined Fragment: A combined fragment
the other hands , is represented by a circle with
is a group of messages that are related a concentric black border , which represents the
and can be shown together. They are end of the actions.
represented by a box around the messages
and can be used to show loops, Decision boxes also known as diamond shapes ,
conditions, and other types of control allow a control flow or object to follow one of
the several paths based on certain conditions.
flow.
This element helps in modeling decisions that
occur in the workflow.
UML ACTIVITY DIAGRAM
Action boxes , represented as rounded
Activity diagrams are a type of diagram in UML rectangles , show the set of actions that are to be
that are used to model the flow of control with performed. These actions can be sequential or
in a system. Unlike other UML diagrams , such concurrent , depending on the requirement of the
as class diagrams or sequence diagrams , activity system. An action box may contain multiple
diagrams are not used to represent the activities or tasks and it may have dependence on
implementation of a system , but rather the another action boxes.
behavior of the system.
Why we use activity diagram , briefly explain ?
The primary purpose of an activity diagram is to
illustrate the workflow of a system or process ,
showing how different activities are related to
one another and how they are executed.
Activities are represented by nodes in the
diagram and the edges between the nodes
represent the flow of control from one activity to
another. The flow can be sequential , branched
or concurrent , and to deal with these different
 action box, swim lanes, branching, parallel flows,
join nodes, control nodes, and forks. These
notations allow for modeling of complex systems
and processes, supporting exception handling, and
enabling different types of flows and decision-
making processes.

To create an activity diagram, the activities are

first identified and analyzed to find out the
constraints applied to them. Each and every
activity, condition, and association must be
recognized and modeled in the diagram. This
An activity diagram is a modeling tool used to helps in understanding the flow of activities and
represent the behavior of a system in terms of identifying any issues that need to be addressed.
work flows and processes. It is a type of event
that encompasses a group of nodes and edges. Rules to be followed when drawing an activity
Activity diagrams can be attached to various diagram
modeling elements such as use cases , interfaces ,
components and collaborations to model their When drawing an activity diagram , it is
dynamic behavior. They allow for the important to follow certain rules to ensure that
visualization and understanding of how various the diagram is clear and understandable.
actions and tasks relate to each other and the
order in which they occur. Though similar to Firstly , each activity in the diagram should be
flow charts , activity diagrams are not exactly the given a meaningful name that accurately
same , but they share the purpose of depicting describes what the activity is doing. This helps to
the flow of activities between different nodes. ensure that the diagram Is easy to read and
They are useful for forward and reverse understand.
engineering of systems and processes.
Secondly , all constraints that apply to the
How to draw an activity diagram activities should be identified and included in the
diagram. Constraints can include things like time
An activity diagram is a graphical representation limits , resource availability , or dependencies on
of a business process or a system. It is a other activities. By including all of the constraints
flowchart-like diagram that represents the , the activity diagram can be used to help plan
and manage the activities more effectively.
workflow among various activities. The main
purpose of an activity diagram is to represent the Finally , all of the associations between the
sequence of activities, actions, and workflows activities should be acknowledged in the diagram.
within a system. Activity diagrams are similar to This means showing how the activities are
flowcharts, but they are more powerful and connected and how they relate one another. This
flexible. helps to provide a clear and complete picture of
the workflow and ensures that all activities are
Activity diagrams are used in various domains, properly accounted for.
including software engineering, business process
modeling, and project management. They help in When to use an Activity Diagram
identifying and analyzing the flow of activities
within a system or process. This allows for better An activity diagram can be used to portray
understanding of the system, identifying potential business processes and workflows. Also, it used
for modeling business as well as the software. An
problems or bottlenecks, and improving the
activity diagram is utilized for the followings:
system or process.
To graphically model the workflow in an easier
Activity diagrams consist of several notations, and understandable way.
including initial state, final state, decision box,
- To model the execution flow among several computer , another box for mobile phone and
activities. another box for a server.
- To model comprehensive information of a
function or an algorithm employed within the The boxes representing the devices or servers are
system. connected by lines that show how they
communicate with each other. For example , the
- To model the business process and its
desktop computer might connect to the server
workflow.
over the internet to send and retrieve data.
- To envision the dynamic aspect of a system.
- To generate the top-level flowcharts for Deployment diagrams are useful because they
representing the workflow of an application. help people understand how a program works in
the real world , and how it interacts with
- To represent a high-level view of a distributed
different devices and servers. They can be used to
or an object-oriented system
plan and test the deployment of a program , or
to communicate with other people about how a
program is used.

Package Diagram COMPONENT DIAGRAMS

In this diagram , the different parts of the A component diagram is like a visual map that
program are grouped in to “packages ” which
shows the different parts of a software or system
are like boxes that hold related parts of the
program. For example , there might be a package and how they work together. Think of it as a
for all the parts of the program that deal with picture that helps us understand how things are
the user interface , and another package for all organized and connected.
the parts of the program that deal with storing
In the diagram, each part is represented by a
and retrieving data.
shape, like a puzzle piece or a building block.
The packages are connected with arrows , which These parts are called "components." Each
show how they depend on each other. For component has a specific job or function, like
example , the user interface package might controlling a character in a game or handling the
depend on the data storage package because it score.
needs to access data from the storage package to
display to the user. To show how the components work together,
lines or arrows are drawn between them. These
Package diagram are useful because they help lines represent the connections or relationships
people understand how a program works and
between the components. It's like drawing paths
how the different parts of the program relate to
to show how one part interacts with another.
each other. They can be used to design and test
programs , or to communicate with other people The component diagram also helps us understand
about how a program works.
how the components depend on each other. Some
components need other components to work
Deployment Diagram
properly. For example, a scoring component
might need information from a player component
A deployment diagram is like a map that shows
how a computer program is installed and run on to keep track of points.
different devices or servers. It is a picture that
Overall, the component diagram helps us see the
helps people understand how the program is
bigger picture of how all the different parts fit
deployed and used in the real world.
together and collaborate to make the software or
In the diagram , the program is shown as a set system function correctly. It's like a map that
of boxes and the devices or servers where it is guides us in understanding the structure and
installed and run are show as other boxes. For interactions of the different components.
example , there might be a box for a desktop
FUNCTIONAL AND NON-FUNCTIONAL performance, security, usability, and
REQUIREMENTS maintainability. Non-functional requirements
answer the question, "How should the software
In software engineering, requirements are perform?" Here are some key points about non-
statements that describe what a software system functional requirements :-
should do or how it should behave. They provide
1. Quality attributes: Non-functional
a foundation for designing and developing the
requirements focus on the qualities or
software. Requirements can be categorized into
attributes that the software should
two main types: functional requirements and non-
possess. These attributes include
functional requirements.
performance, reliability, security,
Functional Requirements: Functional requirements usability, scalability, maintainability, and
define the specific functionalities or features that more.
the software system must possess. They describe
2. Constraints and limitations: Non-functional
the tasks, actions, or behaviors that the software
requirements also include constraints or
should be able to perform. Functional
limitations that the software must adhere
requirements answer the question, "What should
to. For example, constraints may involve
the software do?" Here are some key points
compatibility with specific hardware or
about functional requirements:
software platforms or compliance with
1. Describing specific actions: Functional legal or regulatory standards.
requirements outline the specific actions
3. User experience: Non-functional
or operations that the software should be
requirements address aspects related to
able to perform. For example, in a
the user experience, such as usability,
banking application, functional
accessibility, and responsiveness. They
requirements may include actions such as
ensure that the software is user-friendly
"Allow customers to create new accounts"
and provides a satisfactory experience to
or "Enable users to transfer money
its users.
between accounts."
In summary, functional requirements specify what
2. Identifying inputs and outputs: Functional
the software system should do, describing the
requirements specify the inputs that the
specific actions, inputs, and outputs. Non-
software system should accept and the
functional requirements, on the other hand,
outputs it should produce. For example, a
define the qualities and constraints that the
requirement may state that the software
software should possess, addressing aspects such
should take a customer's order as input
as performance, reliability, security, and user
and generate an invoice as output.
experience. Both types of requirements are crucial
3. Defining system behaviors: Functional for designing and developing software systems
requirements describe the expected that meet user needs and expectations.
behavior of the software in response to
different inputs. They outline how the
software should respond or behave in
various scenarios or use cases.

Non-Functional Requirements: Non-functional

requirements specify the quality attributes or
constraints that the software system should meet.
They define how the system should perform or
behave in terms of qualities like reliability,
 CHAPTER FIVE specific services it provides. It's like
dividing a big task into smaller tasks to
SYSTEM DESIGN make it easier to handle.

1. Subsystem Interface: The subsystem

OVERVIEW A SYSTEM DESIGN
interface is like the door through which
System design is the process of transforming the the subsystem communicates with the rest
analysis model into a design model. In analysis, of the system. We define the operations
we focus on understanding what the user wants or functions that the subsystem provides,
and needs. In design, we focus on figuring out like buttons on a remote control.
how to build the system to meet those needs.
2. Properties of Subsystems: Subsystems have
During system design, the developers set goals for two important properties: coupling and
the project and break down the system into cohesion. Coupling refers to how much
smaller parts called subsystems. Each team can one subsystem depends on or is connected
then work on building their assigned subsystem. to another subsystem. Cohesion refers to
Developers also make decisions on how to build how well the parts of a subsystem fit
the system, such as choosing the right hardware together and work towards a common
and software, managing the data that the system goal.
uses, controlling who can access the system, and
3. Techniques of Decomposition: There are
planning how different parts of the system will
two common techniques to break down a
work together.
system into subsystems: layering and
The result of system design is a model that shows partitioning. Layering is like building a
how the system is divided into subsystems, the cake with different layers, where each
goals that the design wants to achieve, and a layer performs a specific function.
clear description of the strategies chosen to build Partitioning is like dividing a puzzle into
the system. pieces that fit together to form the
complete picture.
In simpler terms, system design is like creating a
plan to build something. We figure out what the 4. Architectural Style: Architectural style
users want, and then we decide how to make it refers to the overall design approach or
happen. We break the big project into smaller pattern we use to build the system. It's
pieces, and different teams work on building their like choosing a particular style for
part. We also make choices about the tools and designing a house, such as modern,
methods we'll use. The end result is a plan that traditional, or futuristic. The architectural
shows how everything fits together and what we style guides how we structure and
want to achieve. organize the subsystems.

SYSTEM DESIGN CONCEPTS In simpler terms, system design is like planning

how to build a system based on what people
System design is a phase where we plan how to
need. We break the system into smaller parts
build a system based on what the users need. In
called subsystems and define what each part
this phase, we focus on breaking down the
does. We also decide how the parts will work
system into smaller parts called subsystems and
together and how they communicate with each
figuring out how they will work together.
other. Subsystems have properties like how
1) Subsystem Decomposition :- Subsystem connected they are and how well their parts fit
decomposition means dividing the system together. We use techniques like layering or
into smaller parts called subsystems. We partitioning to divide the system into subsystems.
define each subsystem based on the And just like choosing a style for a house, we
choose an architectural style to guide the overall ambulances, the MapManagement subsystem for
design of the system. displaying maps and locations, and the
Notification subsystem for managing notifications.
SUBSYSTEMS
In simpler terms, when designing a system, we
When designing a system, we break it down into
break it into smaller parts called subsystems.
smaller parts to make it easier to understand and
Each subsystem has its own specific job and is
manage. These smaller parts are called
made up of related classes. Subsystems have clear
"subsystems." Subsystems are like separate pieces
ways of interacting with other parts of the system
or modules within the system, and they have
and keep all the relevant information together.
their own specific jobs to do.
Subsystems are manageable by individual
To organize the application domain, we identify developers or teams. For example, an accident
smaller parts called "classes" and group them into management system can be divided into different
packages. This helps us manage the complexity of subsystems, each responsible for a specific part of
the system by organizing related classes together. the system, like the user interface, incident
management, resource tracking, maps, and
To manage the complexity of the solution
notifications.
domain, we decompose the system into
subsystems. Each subsystem is made up of a In system design, we use a visual representation
collection of classes, associations, operations, called UML (Unified Modeling Language) to show
events, and constraints that work closely together. how the subsystems fit together. UML uses
components to represent these subsystems.
Subsystems have well-defined interfaces, which
means they have clear ways of interacting with Components in UML are shown as rectangles with
other parts of the system. They encapsulate the a special icon in the upper right corner. They
state and behavior of the classes they contain, represent the different parts or modules of the
which means they keep everything related to system. Think of them as puzzle pieces that come
those classes together in one place. together to form the complete system.

In UML (Unified Modeling Language), subsystems Dependencies among components, which

are represented using component diagrams. These show how they rely on each other, are depicted
diagrams show how the subsystems fit together with dashed stick arrows. These arrows help us
and interact with each other. understand how the different parts of the system
Each subsystem is designed to be manageable by are connected.
a single developer or development team. This In UML, components can represent both logical
means that each subsystem represents a portion and physical components. A logical component is
of the system that can be worked on like a subsystem that doesn't have a physical
independently. form at runtime. It represents individual parts of
For example, let's consider an accident the system's business logic that are combined
management system. It can be decomposed into together to form the complete system. It's like
different subsystems, such as the having different building blocks that make up the
DispatcherInterface subsystem that handles the overall structure.
user interface for the dispatcher, the On the other hand, a physical component
FieldOfficerInterface subsystem that handles the corresponds to a subsystem that has a physical
user interface for field officers, the form at runtime. It represents something like a
IncidentManagement subsystem responsible for database server or another tangible part of the
creating and managing incidents, the system. It's like a specific piece of equipment that
ResourceManagement subsystem for tracking is essential for the system to work.
available resources like fire trucks and
In simpler terms, when we use UML to show Cohesion, on the other hand, refers to how
how different parts of the system fit together, we closely related and focused the objects are within
represent them as components. Components are a subsystem. If a subsystem has high cohesion, it
like puzzle pieces that show the different means that the objects inside it are closely
subsystems or modules of the system. We use related and perform similar tasks. If a subsystem
special shapes and icons to represent them. The has low cohesion, it means that the objects inside
connections or dependencies between the it are unrelated and perform different tasks. It's
components are shown with dashed stick arrows. better to have subsystems with high cohesion
Components can represent either logical parts that because it means that the objects within the
are combined together or physical parts that have subsystem work well together towards a common
a specific form in the system, like a database goal.
server.
When designing subsystems, there is a trade-off
Properties of a subsystem : coupling and cohesion between cohesion and coupling. Breaking the
system into smaller subsystems can increase
Coupling and cohesion are important concepts
cohesion, but it can also increase the number of
when we design subsystems in a system.
interfaces and dependencies, leading to higher
Coupling refers to the level of dependency coupling. It's important to find a balance where
between two subsystems. If two subsystems are we have subsystems with high cohesion and as
loosely coupled, they are more independent from low coupling as possible.
each other. This means that making changes to
In simpler terms, coupling is like how much
one subsystem will have minimal impact on the
subsystems rely on each other. If they are loosely
other. On the other hand, if two subsystems are
coupled, they are more independent, and changes
strongly coupled, changes in one subsystem can
in one subsystem don't affect the others much.
affect the other. It's better to have subsystems
Cohesion is about how well the objects within a
that are loosely coupled because it reduces the
subsystem work together. If they have high
impact that errors or future changes in one
cohesion, it means they are closely related and
subsystem have on the others.
focused on similar tasks. It's good to have
For example, let's consider the subsystems that are loosely coupled and have
IncidentManagement subsystem that interacts with high cohesion because it helps make the system
a Database subsystem to store and retrieve more manageable and less prone to problems.
incident records. In this case, there is high
TECHNIQUES OF SUBSYSTEM : LAYERS AND
coupling between the Database subsystem and the
PARTITIONS
three client subsystems (IncidentManagement,
ResourceManagement, and MapManagement). If When designing a system, we can organize it into
we make changes in the way data is stored in different layers and partitions to manage its
the database, we would need to make changes in complexity.
all these client subsystems. To reduce this
Layers are like different levels or tiers of the
coupling, we can introduce a new subsystem
system. Each layer groups together subsystems
called Storage. This new subsystem will act as a
that provide related services. Think of layers as
shield between the Database subsystem and the
stacked on top of each other, with each layer
client subsystems. The client subsystems will use
depending on the services provided by the layer
the services provided by the Storage subsystem,
below it. Layers help organize the system and
which will be responsible for issuing database
create a hierarchy.
queries. This reduces the direct dependency
between the client subsystems and the Database A closed architecture means that a layer can only
subsystem. access the layer immediately below it. It can't
access higher layers. This keeps the dependencies different layers. Each layer groups together
between layers in a specific order. similar pieces that go together. You start with the
bottom layer and add more layers on top. Each
An open architecture allows a layer to access
layer only uses the pieces from the layer below
layers at deeper levels, not just the immediate
it.
layer below it. This provides more flexibility in
how the layers interact with each other. Now, each layer can also have different parts
called partitions. Think of these partitions as
Within a layer, we can further divide it
smaller groups of puzzle pieces within a layer.
horizontally into partitions. Partitions are like
They work together and help each other within
smaller groups of subsystems within a layer. They
the same layer. This makes it easier to handle
provide services to other partitions within the
and organize the puzzle.
same layer. This helps in organizing and
managing the subsystems within a layer. Sometimes, you can also divide the puzzle into
different sections. Each section has its own
Another approach to managing complexity is to
special set of pieces to work on. This way,
divide the system into peer subsystems. Each
different parts of the puzzle can be solved by
subsystem is responsible for a different class of
different people, and everyone can focus on their
services. This allows different parts of the system
own tasks.
to focus on specific tasks.
When we design a system, it's like solving a big
In general, when designing a system, we use a
puzzle. We use layers and partitions to make it
combination of layering and partitioning. We start
easier to understand and manage. Each layer has
by dividing the system into top-level subsystems,
its own pieces, and they depend on the pieces
each responsible for specific functionality or
from the layer below. We can also divide each
running on a specific hardware node. If the
layer into smaller sections that work together.
system is complex, we continue breaking down
This helps us solve the puzzle step by step and
the subsystems into lower-level layers and
make sure everything fits together nicely.
partitions until they become simple enough for a
single developer to handle. What are these layers and partitions

In simpler terms, when we design a system, we Layers and partitions are ways to organize and
divide it into different layers, which are like divide a system into manageable parts. Here are
different levels of the system. Each layer groups some examples of layers and partitions that can
together related parts of the system. Layers have exist in a system:
a specific order, and each layer depends on the
Layers:
services provided by the layer below it. We can
also divide each layer horizontally into smaller 1. Presentation Layer: This layer deals with
groups called partitions. These partitions provide the user interface of the system, how it
services to other partitions within the same layer. looks and how users interact with it.
Another way to manage complexity is to divide 2. Business Logic Layer: This layer contains
the system into peer subsystems, where each the rules and logic that govern the
subsystem handles a specific set of tasks. This operations and functionality of the system.
helps make the system more organized and easier 3. Data Access Layer: This layer is
to work with. responsible for interacting with the
database or data storage system to
Let’s simplify it
retrieve and manipulate data.
Imagine you have a big puzzle to solve, but it 4. Infrastructure Layer: This layer handles
has too many pieces and is very complicated. To the underlying technical aspects of the
make it easier, you can divide the puzzle into
 system, such as networking, security, and the system. Think of it like a blueprint or plan
system configuration. for building a house.

Partitions within Layers: Software architecture is when we apply a specific

architectural style to a real system. It's like
1. User Management Partition: This partition
actually building the house based on the
handles user authentication, registration,
blueprint. We implement the design and create
and management.
the different subsystems according to the chosen
2. Reporting Partition: This partition focuses
architectural style.
on generating reports and analyzing data.
3. Payment Processing Partition: This There are many different types of architectural
partition handles payment transactions styles, and each one has its own characteristics
and integrates with payment gateways. and rules. Examples include client-server
4. Inventory Management Partition: This architecture, where one part of the system acts as
partition deals with managing and a server providing services to clients, and layered
tracking inventory levels and stock architecture, where the system is divided into
information. different layers with specific responsibilities.
These architectural styles help us make the
These are just examples, and the actual layers
system organized, efficient, and easier to develop
and partitions in a system can vary depending on
and maintain.
the specific requirements and architecture. The
purpose of these divisions is to organize the In simpler terms, when we have a big and
system into logical components, making it easier complicated system, we need to plan how to
to understand, develop, and maintain. break it down into smaller parts. We choose a
design style, like a blueprint, that tells us how to
ARCHITECTURAL STYLES
divide the system and how the different parts
When we are dealing with complex systems, it is should work together. Then, we actually build
important to plan how we divide the system into the system based on this design. There are
smaller parts. This division is called system different styles to choose from, like building a
decomposition. Once we start building the house in different architectural styles. Each style
system, it becomes difficult to change the division has its own rules and ways of organizing the
later, as it would require many changes to the system. This helps us make sure the system
different parts of the system. works well and is easier to manage.

In system decomposition, we identify the different TYPES OF ARCHITECTURAL STYLE

subsystems, which are like mini-systems within
Repository Architectural Style: In this style,
the bigger system. Each subsystem has specific
subsystems interact with a central data structure
tasks or services that it provides, and these
called the repository. Each subsystem can access
subsystems are connected to each other in
and modify the repository, and they communicate
different ways. Sometimes, the connection is
with each other only through the repository. This
hierarchical, which means one subsystem is on
style allows for the easy addition of new services
top and controls the others underneath. Other
by adding more subsystems. However, the main
times, the subsystems are equal and work
drawback is that the repository can become a
together like a team.
bottleneck in terms of performance and making
An architectural style is like a pattern or changes to the repository can affect all
template for how we organize the subsystems. It subsystems.
provides guidelines for how the subsystems
Model-View-Controller(MVC) Architectural Style:
should be structured and interact with each
In MVC, subsystems are divided into three types:
other. It helps us create a consistent design for
Model, View, and Controller. The Model
subsystem maintains the domain knowledge and shared forms processed in the Presentation Server
implements the central data structure. The View layer.
subsystem is responsible for displaying
These architectural styles help organize and
information to the user, while the Controller
structure subsystems within a system, making it
subsystem manages the interactions with the user
easier to manage and maintain. Each style has its
and notifies views of changes in the model. The
own characteristics and considerations, and the
model subsystems are designed to be independent
choice depends on the specific requirements and
of views and controllers.
goals of the system.
Client/Server Architectural Style: In this style,
subsystems are divided into clients and servers.
Clients interact with the user and request services CHAPTER 7
from servers. The request is usually done through
remote procedure calls or object brokers. Control
SOFTWARE QUALITY ASSURANCE
flow in clients and servers is independent, except
for synchronization purposes. An example is an When we create software, we want to make sure
information system with a central database where it works correctly and doesn't have any problems.
clients handle user inputs and initiate database Software testing is like checking the software to
transactions, while servers perform the find and fix any issues.
transactions and ensure data integrity.
There are different types of software testing that
Peer-to-Peer Architectural Style: In this style, we can use during the software development
subsystems can act as both clients and servers, process. These tests help us make sure our
meaning they can request and provide services to software is stable and free from bugs.
other subsystems. Each subsystem's control flow is
independent, except for synchronization when Think of it like making a cake. When we bake a
making requests. Peer-to-peer systems are more cake, we want to make sure it tastes good and
complex than client/server systems and can doesn't have any problems. So, we do different
introduce complications like deadlocks. things to check the cake and make it perfect.

Three-Tier Architectural Style: This style organizes Similarly, in software testing, we do different
subsystems into three layers. The interface layer tests to check the software's functionality and
includes objects that interact with the user, such make it bug-free. It's like checking each part of
as windows or web pages. The application logic the cake to make sure it's cooked well and tastes
layer contains control and entity objects that delicious.
handle the processing, rule checking, and For example, one type of testing is called
notifications. The storage layer deals with storing, "functional testing." It's like tasting the cake to
retrieving, and querying persistent data. see if it has the right flavors and ingredients.
Four-Tier Architectural Style: This is an extension Another type is called "performance testing." It's
of the three-tier architecture with an additional like checking if the cake is moist and fluffy.
layer. The interface layer is split into a There are many other types of testing, like
Presentation Client layer (on user machines) and "security testing" to make sure the software is
a Presentation Server layer (on servers). This safe, "user interface testing" to check if it's easy
allows for different presentation clients to be used to use, and "compatibility testing" to see if it
while sharing some presentation objects across works well on different devices.
clients, reducing redundancy. For example, a
By performing these different types of testing, we
banking system can have a web interface, an
can find and fix any problems in our software
ATM interface, and an application client, with
and make it stable and bug-free. It's like making
sure our cake is perfect and delicious before verifying the system's behavior. They may
serving it to others. input data, interact with the user
interface, and manually validate the
So, in simpler terms, the various types of
expected outputs.
software testing are like different ways of
checking our software to make sure it works 3. Defect Reporting: If any defects or issues
correctly and doesn't have any issues. It's like are discovered during testing, testers
making sure our cake tastes good and doesn't report them to the development team for
have any problems before we enjoy it. resolution. They provide detailed
information about the defect, including
steps to reproduce it and any supporting
documents or logs.

4. Test Documentation: Testers document the

test results, including observed behaviors,
issues, and any additional notes or
feedback. This documentation helps in
tracking the testing progress and
providing a reference for future testing
cycles.

Automation Testing: Automation testing involves

using specialized tools and scripts to automate
the execution of test cases, reducing manual
MANUAL TESTING AND AUTOMATED
effort and enhancing efficiency. Automation
TESTING
testing is suitable for repetitive tasks, regression
Software testing is a crucial process in software testing, and large-scale projects. It involves the
development that involves verifying and following steps:
validating a software system to ensure that it 1. Test Script Development: Testers write
meets the intended requirements and functions as scripts or use testing frameworks to
expected. It involves executing tests, identifying automate test cases. These scripts define
defects or bugs, and providing feedback to the steps, interactions, and expected
improve the quality and reliability of the outcomes for each test.
software.
2. Test Execution: The automated testing tool
Manual Testing: Manual testing refers to the executes the test scripts, interacts with
process of executing tests and validating the the software system, and compares the
software system manually, without the use of actual outcomes with the expected results.
automated tools. In manual testing, a human
3. Defect Reporting: If any defects are
tester performs various test cases, interacts with
identified during automation testing,
the software's user interface, and evaluates its
testers report them to the development
behavior against expected results. Manual testing
team for resolution, similar to manual
involves the following steps:
testing.
1. Test Planning: Testers analyze the
4. Test Maintenance: Test scripts may require
software requirements, define test
periodic updates to accommodate changes
objectives, and develop test plans and test
in the software system. Testers maintain
cases.
and update the scripts to ensure they
2. Test Execution: Testers execute the test
cases, following specific steps and
 remain effective and aligned with the Imagine you are fixing a toy by opening it up
evolving software requirements. and seeing how the gears and circuits work. In
white box testing, the tester can review the
Automation testing offers benefits like faster
software's internal code, algorithms, and system
execution, repeatability, and wider coverage.
architecture. This allows them to create test cases
However, it requires initial setup and continuous
specifically targeting those internal components
maintenance of test scripts.
and ensure they function correctly.
Both manual testing and automation testing have
their advantages and limitations. The choice
between them depends on factors like project
requirements, budget, complexity, and time
constraints. Often, a combination of manual and
automation testing is used to achieve
comprehensive test coverage and maximize
efficiency in software testing processes.

CLASSIFICATION OF MANUAL TESTING

3. Grey Box Testing :- Grey box testing is
Let's explain the classification of manual testing like having a partially open box. In grey
as black box, white box, and grey box testing in box testing, the tester has limited
simpler terms. knowledge of the internal workings of the
software but not the full understanding
like in white box testing.

Think of it as peeking into the box and getting a

glimpse of its internal structure without complete
access. In grey box testing, the tester may have
some knowledge of the internal code or database
1. Black Box Testing :- Black box testing is structure. This partial understanding allows them
like examining a closed box without to design test cases that cover specific areas of
knowing what's inside. In black box interest or potential vulnerabilities.
testing, the tester focuses solely on the
In summary, the classification of manual testing
software's external behavior and
into black box, white box, and grey box helps
functionality, without knowing its internal
describe the level of knowledge and access a
structure or code.
tester has to the internal workings of the
Think of it as using a remote control for a TV. software. Black box testing focuses on the
You don't need to know how the TV works software's external behavior, white box testing
inside; you just press buttons and see how it examines the internal structure and code, while
responds. Similarly, in black box testing, the grey box testing falls somewhere in between with
tester interacts with the software's user interface limited knowledge of the internals.
and tests its inputs, outputs, and overall
TYPES OF BLACK BOX TESTING
functionality without looking at the internal code.

2. White Box Testing :- White box testing is Let's explain the types of black box testing,
like having access to the inside of the box including functional and non-functional testing, in
and examining its components. In white simpler terms.
box testing, the tester has knowledge of
Black box testing is like examining a closed box
the internal structure, logic, and code of
without knowing what's inside. It focuses on the
the software being tested.
software's external behavior and functionality, For example, consider checking if the toy car is
without considering the internal code or durable, has good battery life, or is easy to use.
structure. Similarly, in non-functional testing, the tester
evaluates aspects like performance, security,
usability, reliability, and compatibility of the
software.

Here are a few examples of non-functional

testing:

• Performance Testing: Checking if the

software performs well under expected
1. Functional Testing (Black Box): Functional workloads and responds quickly.
testing is like checking if the box does • Security Testing: Evaluating the software's
what it's supposed to do. In functional resistance to unauthorized access, data
testing, the tester verifies that the breaches, or other security vulnerabilities.
software functions correctly according to • Usability Testing: Assessing the software's
the specified requirements or functional user-friendliness and ease of use.
specifications. • Reliability Testing: Verifying the software's
ability to function consistently and
Think of it as checking if a toy car moves
reliably over a period of time.
forward and backward as expected. Similarly, in
• Compatibility Testing: Ensuring that the
functional testing, the tester interacts with the
software works properly across different
software's user interface, provides inputs, and
devices, browsers, or operating systems.
checks if it produces the expected outputs. It
ensures that the software performs the intended In summary, black box testing involves examining
functions correctly. the software's external behavior. Functional
testing focuses on verifying if the software
2. Non-Functional Testing (Black Box): Non-
functions correctly as per the requirements. Non-
functional testing is like examining aspects
functional testing evaluates the software's qualities
of the box other than its primary
beyond its basic functionality, such as
function. It focuses on the software's
performance, security, usability, reliability, and
qualities or characteristics beyond its
compatibility.
functional behavior.
TYPES OF FUNCTIONAL TESTING

Let's explain the types of functional testing,

including unit testing, integration testing, and
system testing, in a brief detail:
 1. Unit Testing: Unit testing is like checking and reliability of the software system from end to
each part of the box individually. In unit end.
testing, individual components or units of
System testing involves testing the system's
the software are tested in isolation to
interactions with external components, verifying
ensure they work correctly on their own.
the software's compliance with the specified
Think of it as testing each puzzle piece to make requirements, and assessing its behavior in
sure it fits and functions properly before putting different scenarios. It aims to ensure that the
the whole puzzle together. In unit testing, the software system meets the desired functionality
focus is on testing small, independent units of and performs as expected in real-world usage.
code, such as functions or methods, to verify
In summary, the types of functional testing
their expected behavior.
include unit testing, which checks individual
Unit testing helps identify any defects or issues components; integration testing, which verifies the
within individual components early in the interaction between components; and system
development process. It promotes modular and testing, which evaluates the complete software
isolated testing of code segments and allows for system's behavior. These types of testing ensure
easier debugging and maintenance. that the software functions correctly at different
levels of granularity, from individual units to the
2. Integration Testing: Integration testing is
entire system.
like checking if the different parts of the
box fit and work together. In integration
testing, the individual components or
units tested in unit testing are combined
and tested together as a group.

Imagine assembling the puzzle by connecting

different puzzle pieces. In integration testing, the
objective is to verify that the interactions and
communication between the integrated
components or units work as expected.

Integration testing ensures that the combined

software components function correctly, exchange
data properly, and maintain compatibility with
each other. It helps identify any issues that may
arise when multiple components interact, such as
interface problems, data inconsistencies, or
functional gaps.

3. System Testing: System testing is like

checking the fully assembled box to
ensure it works as a whole. In system
testing, the complete software system is
tested as a whole to validate its behavior
against the specified requirements.

Think of it as checking the puzzle once it's fully

assembled to ensure it forms the complete picture
correctly. In system testing, the objective is to
evaluate the overall functionality, performance,
 CHAPTER FOUR Analysis is a crucial phase in software
engineering that focuses on understanding the
ANALYSIS requirements and needs of the users or
stakeholders. It involves analyzing, documenting,
When we want to build something like a house and modeling the system to ensure that the
or a toy, we first need to understand what it software solution meets the desired objectives.
should look like and how it should work. The
1. Producing the Analysis Model: The
analysis phase in software engineering is just like
analysis phase aims to produce an
that.
analysis model, which is a representation
During the analysis phase, we talk to the people of the system being developed. This
who will use the software and ask them lots of model should be correct, complete,
questions to understand what they want the consistent, and verifiable. It serves as a
software to do. It's like asking a friend what kind blueprint that captures the essential
of toy they want and how they want it to play. aspects of the system, including its
functionalities, behavior, and
Once we understand what the software should
relationships.
do, we make a plan, or a model, of how it will
work. It's like making a drawing or a blueprint of The analysis model typically consists of various
the toy we want to build. This plan helps us diagrams, documents, and artifacts that provide a
make sure we don't forget anything important comprehensive understanding of the system.
and that the software will work correctly. These may include use case diagrams, activity
diagrams, class diagrams, sequence diagrams, and
We also write down all the things the software
more. The model helps stakeholders visualize and
needs to have, like buttons, colors, or sounds. It's
communicate the requirements and desired system
like making a list of the features the toy should
behavior effectively.
have, such as wheels, lights, or sounds.
2. Structuring and Formalizing Requirements:
In the analysis phase, we focus on understanding
During analysis, developers work closely
what the software needs to be and how it should
with stakeholders to elicit and understand
behave. It's like figuring out what a toy needs to
the system requirements. This involves
be and how it should play. We talk to people,
gathering information, conducting
make a plan, and write down all the important
interviews, holding discussions, and
things.
analyzing existing documentation. The aim
By doing this analysis, we make sure that is to gather a clear understanding of what
everyone understands what the software should the system should do and how it should
do, and we can start building it in the best way behave.
possible. It's like making sure we know exactly
Once the requirements are gathered, the analysis
what kind of toy to build before we start putting
phase involves structuring and formalizing them.
all the pieces together.
Developers document the requirements in a
So, in simpler terms, the analysis phase in systematic manner, ensuring they are clear,
software engineering is like talking to people, unambiguous, and comprehensive. This
making a plan, and writing down all the documentation serves as a reference for the
important things so that we understand what the subsequent phases of software development and
software should do and how it should work. It helps in managing scope, expectations, and
helps us build the software in the best way changes.
possible, just like making sure we know what
3. Object-Oriented Analysis: In object-
kind of toy to build before we start building it.
oriented analysis, developers use the
 principles and concepts of object-oriented For example, a scenario for the shopping
programming to build a model that app use case could be "User selects an
describes the application domain. They item, adds it to the cart, and sees the
identify and define objects, their updated cart total."
attributes, relationships, and behaviors.
The functional model helps the development team
The focus is on understanding the real-
understand the software's functionality and how it
world entities and their interactions, and
should meet the users' needs.
then mapping them to software objects
and classes. 2) Analysis Object Model: The analysis object
model helps us understand the different objects or
The object-oriented analysis model helps in
things that the software will use and how they
visualizing and representing the system in a way
are related. It is represented by class and object
that aligns with the concepts of object-oriented
diagrams.
programming. It allows for modular design,
encapsulation, and re-usability, enhancing the • Class diagrams: Class diagrams show
overall efficiency and maintainability of the different classes or types of objects in the
software solution. software and how they are connected. It's
like making a family tree, where each
In summary, the analysis phase in software
class represents a different type of object,
engineering involves producing an analysis model
and the connections show their
that captures the system requirements, structuring
relationships.
and formalizing the gathered requirements, and,
in object-oriented analysis, building a model • Object diagrams: Object diagrams show
describing the application domain. This phase sets specific instances of objects and how they
the foundation for the subsequent phases of interact. It's like taking a snapshot of a
software development, ensuring a clear particular moment, showing the objects
understanding of the system's objectives and and their relationships at that point.
requirements.
The analysis object model helps the development
TYPES OF ANALYSIS MODEL team understand the structure and relationships
of objects in the software.
Let's define the three individual models in the
3) Dynamic Model: The dynamic model helps us
analysis phase of software engineering:
understand how the software behaves over time
1) Functional Model: The functional model helps and in different situations. It is represented by
us understand what the software should do and state machine and sequence diagrams.
how it should behave. It is represented by use
• State machine diagrams: State machine
cases and scenarios.
diagrams show the different states or
• Use cases: Use cases are like stories that conditions that an object can be in and
describe how people will interact with the how it transitions between those states.
software. They show different actions or It's like showing the different moods or
tasks that users can perform and what the emotions a person can have and how they
software should do in response. For change.
example, in a shopping app, a use case
• Sequence diagrams: Sequence diagrams
could be "Adding items to the cart."
show the order of actions and interactions
• Scenarios: Scenarios are like detailed between objects in a particular scenario.
examples of how the software should It's like drawing a timeline that shows
work in specific situations. They show who does what and when.
step-by-step actions and expected results.
The dynamic model helps the development team understand how things change over time in the
understand how objects change and interact with game.
each other during the software's execution.
So, in simpler terms, the analysis model is like a
In summary, the analysis model consists of three collection of different models that help the
individual models. The functional model shows developers understand how the software should
what the software should do, the analysis object work. The functional model shows what the
model shows the objects and their relationships, software needs to do, the analysis object model
and the dynamic model shows how objects shows the different objects in the software, and
behave and interact over time. These models help the dynamic model shows how things happen
the development team understand and design the over time. It's like having a map, a family photo
software effectively. album, and a storyboard to guide the developers
in creating the software.

In Simpler Terms Let's simplify the explanation of working with the

analysis object model and the dynamic model in
Functional Model: The functional model is like a software engineering:
map that shows us how the software should
When we work with the analysis object model or
work. It's like a list of things the software needs
the dynamic model, it's important to remember
to do to make it useful and fun for people to
that these models represent concepts that are
use.
easy for users to understand, not the actual
For example, let's think of a video game. The technical details of the software.
functional model would describe all the different
For example, when we talk about the analysis
actions and tasks the game should have, like
object model, we focus on objects that make
jumping, running, or collecting points. It helps
sense to users, like "User," "Product," or
the developers know what features to include in
"Shopping Cart." We don't include technical
the game.
concepts like "Database," "Subsystem," or
Analysis Object Model: The analysis object model "Network" because users don't need to know
is like a family photo album that shows different about them.
members of a family and how they are related.
Similarly, when we talk about the dynamic
In this case, the "family" refers to the different
model, we focus on how objects behave and
objects or things the software will use.
interact in ways that users can relate to. We
In our video game example, the analysis object don't need to show the technical details like how
model would show all the different characters or data is stored in a database or how different
objects in the game, like the player, enemies, or components work together.
power-ups. It helps the developers understand
It's important to note that the analysis models are
what objects are needed and how they interact
simplified versions of the actual software. The
with each other.
analysis object model may have classes that
Dynamic Model: The dynamic model is like a represent objects in the software, but they are
storyboard or comic strip that shows the different more abstract and simplified compared to the
actions and events that happen in the software. actual software classes. The software classes have
It's like a series of pictures that tells a story. more details, like additional attributes and
associations.
In the video game example, the dynamic model
would show how the player moves, how enemies So, in simpler terms, when we work with the
appear, and how the game progresses. It helps analysis object model and the dynamic model, we
the developers see the sequence of events and focus on concepts that users can easily
understand. We don't include technical details 3. Control Objects: Control objects are like
that users don't need to know. The analysis the helpers that make things happen in
models provide a high-level overview, and later the system. They represent the tasks that
in the development process, the software will be the user wants to perform and that the
implemented with more detailed classes and system supports. For example, in the
components. watch example, the control object could
be something like a "ChangeDateControl,"
ENTITY , BOUNDARY AND CONTROL OBJECTS
which represents the activity of changing
Let's simplify the explanation of the analysis the date by pressing combinations of
object model and its different types of objects: buttons. These objects are responsible for
carrying out specific actions or
1. Entity Objects :- Entity objects are like
functionalities in the system.
the important information that the system
keeps track of. They represent things that Control objects are like helpers that make
are stored or persisted in the system. For things happen in the system. They are
example, in the context of a watch, the like the instructions or rules that tell the
entity objects could be things like the system what to do. For example, in a
year, month, and day. These objects hold watch, there could be a control object
important data that the system needs to called "ChangeDateControl" that helps us
remember. change the date by following specific
steps. It's like having a special helper who
Entity objects are like important things
tells the watch how to change the date.
that the system needs to remember. They
are like puzzle pieces that hold important To help distinguish between the different types of
information. For example, in a watch, the objects, we can use special labels called
entity objects could be the year, month, "stereotypes" in a modeling language called UML.
and day. These objects help the watch For example, boundary objects may have the
remember the current date label "<<boundary>>" attached to their name,
control objects may have the label
2. Boundary Objects: Boundary objects are
"<<Control>>" attached to their name, and
like the bridges between the system and
entity objects usually don't have any special label
the people using it. They represent the
appended to their name, but sometimes they may
interactions or connections between the
have the label "<<entity>>."
users (actors) and the system. For
example, in the watch example, the In simpler terms, in the analysis object model,
boundary objects could be things like we have different types of objects. Entity objects
buttons and the LCD display. These hold important information, boundary objects
objects allow the users to interact with connect the system with the users, and control
the watch and see the information objects represent the tasks that users want to do.
displayed. For example, in a watch, the entity objects could
be the date, month, and year; the boundary
Boundary objects are like the parts that
objects could be the buttons and the display; and
let us interact with the system. They are
the control object could be the one that handles
like buttons and screens that we can
changing the date when we press the buttons in
touch and press. For example, in a watch,
a specific way. These different types of objects
the boundary objects could be the buttons
help us understand and represent the system in a
we press to change settings or the screen
clear and organized way.
that shows us the time.
 In UML modeling, specialization is when we
identify more specific concepts or categories that
inherit traits from a higher-level or more general
concept. It's like saying that dogs have certain
traits that are specific to them, but they also
inherit traits from the general mammal category.

So, in simpler terms, generalization is like putting

similar things into groups based on common
traits, while specialization is focusing on the
unique traits that set something apart within a
group. In UML modeling, generalization helps us
organize concepts into hierarchies, with a general
GENERALIZATION AND SPECIALIZATION
concept at the top and more specialized concepts
Let's simplify the definition of generalization and at the bottom. It helps us see common traits and
specialization in UML modeling: relationships between concepts. Specialization, on
the other hand, helps us identify more specific
1. Generalization: Generalization is like concepts within the hierarchy and understand
organizing things into groups or their unique traits.
categories. It helps us see the big picture
and find common traits among different
things.

Think of it as grouping animals into categories

like mammals, birds, or reptiles. We know that
mammals have certain common characteristics
like giving birth to live young and having hair or
fur. Generalization helps us identify these
common traits and group similar things together.

In UML modeling, generalization is when we

identify a general concept or category at the top
of a hierarchy, and we see that other concepts
are more specific versions of that general
concept. It's like saying that all mammals share
common traits, but some mammals are more ANALYSIS ACTIVITIES :- From Use cases
specific, like dogs or cats. to Objects
2. Specialization: Specialization is like
Let's simplify the explanation of the analysis
zooming in and focusing on the details. It
activities in software engineering:
helps us identify specific traits or
characteristics that set something apart 1. Identifying Entity, Boundary, and Control
from others in the same group. Objects: In this activity, we figure out the
important things (entity objects) that the
Using the animal example, we can specialize
software needs to remember, the parts
within the mammal category to identify more
that let us interact with the software
specific animals like dogs, cats, or bears. Each of
(boundary objects), and the helpers that
these animals has unique traits that differentiate
make things happen in the software
them from other mammals. Specialization helps
(control objects). It's like deciding what
us understand these unique characteristics.
pieces are important, what buttons we
 can press, and who helps us make things (like "animals") and others are more
work. specific (like "dogs" or "cats").

2. Mapping Use Cases to Objects with 7. Reviewing the Analysis Model: In this
Sequence Diagrams: In this activity, we activity, we carefully check and review
connect the actions or tasks that users the analysis model we created. We make
want to do (use cases) with the objects in sure that everything makes sense and that
the software. We create diagrams we haven't missed any important details.
(sequence diagrams) that show the order It's like double-checking our work and
of actions and interactions between making sure the story we've created is
objects. It's like drawing a storyboard to complete and accurate.
see how different objects work together to
In simpler terms, the analysis activities involve
make the software do what users want.
figuring out important things, connecting user
3. Modeling Interactions among Objects with tasks with software objects, understanding how
CRC Cards and Identifying Associations: In objects interact, recognizing groups of closely
this activity, we create cards (CRC cards) related objects, identifying specific details of
for each object and write down their objects, understanding the hierarchy of objects,
responsibilities and interactions. It's like and reviewing our work to ensure it's correct. It's
making character cards for a story and like creating a story where we decide who the
describing what each character does. We characters are, how they interact, and what
also figure out how different objects are special abilities or qualities they have, and then
related or connected to each other making sure everything fits together nicely.
(associations). It's like understanding how
characters in a story interact or work
IDENTIFYING ENTITY OBJECTS
together.

4. Identifying Aggregates: In this activity, we When we want to build something like a toy or a
game, we need to understand what it should do
find groups of objects that work closely
and how it should work. Requirements elicitation
together or are strongly related. It's like
is like the first step in figuring out what our
recognizing a team of characters who software should be like.
always work together in a story. We call
these groups aggregates. It helps us Let's simplify the explanation of the requirements
understand how different objects are elicitation process and the heuristics used to
organized and connected. identify objects, attributes, and associations:

5. Identifying Attributes: In this activity, we 1. Requirements Elicitation: Requirements

identify the specific details or elicitation is like gathering all the
characteristics of objects (attributes) that important information we need to
are important for the software. It's like understand what the software should do.
noting down the special features or It involves looking at each task or action
qualities of the characters in a story. that users want to perform (use cases) and
finding the important things (objects) that
6. Modeling Inheritance Relationships: In this
are involved in those tasks.
activity, we identify the hierarchy or
levels of objects where some objects are 2. Natural Language Analysis: Natural
more general, and others are more language analysis is like carefully reading
specific. It's like understanding how and understanding the words and
different characters in a story are related, sentences in a document that describes
where some characters are more general the software requirements. It helps us
 identify the important parts and extract understanding how they fit together in the
useful information from the text. software.

3. Heuristics for Identifying Objects, EXAMPLE :- Let's simplify the explanation of the
Attributes, and Associations: Heuristics are use case and its related entity objects:
like helpful rules or guidelines that help
Use Case: ReportEmergency This use case is about
us make decisions. In this case, we use
a task called "Report Emergency" that involves
heuristics to identify objects, attributes,
two people, the FieldOfficer (a police or fire
and associations from the requirements
officer on duty) and the Dispatcher (a police
document.
officer who manages incidents). The FieldOfficer
Here are some heuristics we can use: initiates the task, and it requires communication
with the Dispatcher.
• Terms that need clarification: We look for
words or phrases that are not clear or Flow of Events:
need more explanation. It's like finding
1. The FieldOfficer starts the "Report
parts of the requirements that we need to
Emergency" task on her device.
ask questions about to understand better.
2. The software presents a special form to
• Recurring nouns: We look for words that the FieldOfficer, like a digital paper with
appear frequently in the requirements. It's fields to fill in.
like noticing names or things that are 3. The FieldOfficer fills in the form by
mentioned multiple times. selecting the emergency level, type,
location, and giving a brief description of
• Real-world entities: We look for names of
the situation. She also describes possible
things in the real world that the software
responses to the emergency situation.
needs to keep track of. It could be
4. Once the FieldOfficer completes the form,
people, places, or things. It's like
she submits it.
recognizing important characters or
5. The software receives the form and
objects in a story.
notifies the Dispatcher, like sending a
• Real-world activities: We look for actions message to get the Dispatcher's attention.
or tasks that the software needs to track. 6. The Dispatcher reviews the information in
It's like identifying important actions or the form and creates an "Incident" entry
events in a story. in the system's database using a special
function called "OpenIncident." The
• Data sources or sinks: We look for things
Dispatcher selects a response to the
that the software needs to interact with,
reported emergency and acknowledges the
like getting data from a printer or sending
report.
data to another system. It's like
7. The software shows the acknowledgment
recognizing objects that the software
and the selected response to the
needs to connect with.
FieldOfficer, like displaying a message on
In simpler terms, during requirements elicitation, her device.
we carefully read and understand the information
Entity Objects: In this use case, there are specific
provided to identify important things and make
things or concepts that play important roles. We
sense of what the software should do. We use
call these things entity objects.
helpful rules like looking for recurring words,
important entities, activities, and things that the • Dispatcher: This is like a police officer
software needs to interact with. It's like finding who manages incidents. They receive
characters, objects, and actions in a story and reports and make decisions on how to
respond to emergencies.
 • EmergencyReport: This is like the initial guide us in recognizing what things are boundary
report about an incident made by the objects.
FieldOfficer to inform the Dispatcher. It
Here are some heuristics we use:
includes details about the emergency
situation. • User Interface Controls: We look for
buttons or controls that people need to
• FieldOfficer: This is like a police or fire
use to start a task. For example, a
officer who is on duty and reports
"Report Emergency" button is a control
emergencies to the Dispatcher.
that people can press to start reporting an
• Incident: This is like a situation that emergency.
requires attention from a FieldOfficer. It
• Data Entry Forms: We look for places
could be something like a crime or an
where people need to enter information
accident.
into the software. For example, an
In simpler terms, the use case "ReportEmergency" "Emergency Report Form" is a place
is a task where a FieldOfficer on duty reports an where people can fill in details about an
emergency to a Dispatcher. The FieldOfficer fills emergency.
in a form with details about the emergency, and
• System Notices and Messages: We look for
the software notifies the Dispatcher. The
messages or notices that the software
Dispatcher reviews the information, takes action,
shows to people in response to their
and acknowledges the report. During this process,
actions. For example, an
there are important things involved, like the
"Acknowledgment Notice" is a message
people (FieldOfficer and Dispatcher), the report
that the software displays to let people
itself (EmergencyReport), and the incident that
know that their action has been received.
needs attention.
• Actor Terminals: When multiple people
IDENTIFYING BOUNDARY OBJECTS
are involved in a task, we use special
Let's simplify the explanation of boundary objects names for the parts of the interface that
and the heuristics used to identify them: each person interacts with. For example,
a "Dispatcher Station" is the part of the
Boundary objects are like the parts of the interface that the dispatcher uses.
software that help us interact with the people
using it. They are like the bridges between the It's important to always use words that the
system and the actors (the people using the people using the software will understand. We
software). should not use technical words or terms that are
only used by the people building the software.
In each task or action that people want to do We want to make sure everyone can understand
(use case), they interact with at least one how to interact with the software.
boundary object. The boundary object collects the
information from the person and translates it into In simpler terms, boundary objects are like the
a form that the software can understand and use. parts of the software that help us interact with it.
They are like buttons and forms that we use to
For example, think of a button on a screen or a communicate with the software. To find these
form where we enter information. These are boundary objects, we look for buttons, forms,
examples of boundary objects. They help us messages, and special names for different people's
communicate with the software by pressing parts of the interface. It's important to use words
buttons or filling in information. that everyone can understand.
To help us identify boundary objects, we have
some helpful rules called heuristics. These rules
EXAMPLE :- Let's simplify the explanation of the • DispatcherStation: This is like a computer
use case and its related boundary objects: used by the Dispatcher to review and
Use Case: ReportEmergency This is a task that handle the reported emergencies.
involves two people, the FieldOfficer and the
Dispatcher. The FieldOfficer initiates the "Report In simpler terms, the use case "ReportEmergency"
Emergency" function using her device, and it is a task involving a FieldOfficer and a
involves communication with the Dispatcher. Dispatcher. The FieldOfficer starts by pressing a
special button and filling in a form about an
Flow of Events: emergency. The software then notifies the
1. The FieldOfficer activates the "Report Dispatcher, who reviews the information and
Emergency" function on her device. takes appropriate action. During this process,
2. The software presents a form to the there are special objects like buttons, notices,
FieldOfficer, like a special page with forms, and computers that help with the
fields to fill in. interaction between the people and the software.
3. The FieldOfficer fills in the form by
IDENTIFYING CONTROL OBJECTS
selecting the emergency level, type,
location, and giving a brief description of Let's simplify the explanation of control objects
the situation. Once done, she submits the and the heuristics used to identify them:
form.
Control objects are like the coordinators or
4. The software receives the form and
managers in a use case. They are responsible for
notifies the Dispatcher.
making sure things happen in the right order and
5. The Dispatcher reviews the information in
coordinating the actions of other objects. Control
the form and creates an incident in the
objects are usually created at the beginning of a
system's database using the
use case and stop existing once the use case is
"OpenIncident" function. The Dispatcher
finished.
selects a response and acknowledges the
report. To help us identify control objects, we have some
6. The software displays the acknowledgment helpful rules called heuristics. These rules guide
and the selected response to the us in recognizing what things are control objects.
FieldOfficer.
Here are some heuristics we use :-
Boundary Objects: In this use case, there are
• One Control Object per Use Case: We
certain parts of the software that help in the
have one control object that oversees the
interaction between the FieldOfficer and the
entire use case. It's like having one person
system. These parts are called boundary objects.
in charge of making sure everything goes
• ReportEmergencyButton: This is like a smoothly.
special button that the FieldOfficer presses
• One Control Object per Actor: If multiple
to start the "Report Emergency" task.
people are involved in a use case, we
• AcknowledgmentNotice: This is like a
have one control object for each person.
notice or message that shows the
Each control object is responsible for
Dispatcher's acknowledgment to the
coordinating the actions of that particular
FieldOfficer.
person.
• EmergencyReportForm: This is like a
special form that appears on the • Lifespan of a Control Object: The control
FieldOfficer's device when she selects the object should exist throughout the whole
"Report Emergency" function. It has fields use case or for as long as the person is
where she can enter information about interacting with the software. It's like the
the emergency.
 control object is active as long as the MAPPING USE CASES TO OBJECTS
person is using the software. WITH SEQUENCE DIAGRAMS
Now, let's see how these control objects work in
Let's simplify the explanation of sequence
the "ReportEmergency" use case:
diagrams and the heuristics used to draw them:
• ReportEmergencyControl: This control
Sequence diagrams are like visual representations
object manages the reporting function for
of how different objects interact with each other
the FieldOfficer. It is created when the
in a use case. They show the behavior and
FieldOfficer selects the "Report
communication between objects over time.
Emergency" button. It presents a form
(EmergencyReportForm) to the FieldOfficer In a sequence diagram:
and collects the information from the
• Columns represent the objects that are
form. It creates an EmergencyReport and
involved in the use case. The leftmost
sends it to the Dispatcher. It waits for an
column is usually the person who starts
acknowledgment from the Dispatcher and,
the use case (the actor).
upon receiving it, creates an
• Horizontal arrows represent messages or
AcknowledgmentNotice and shows it to
signals being sent from one object to
the FieldOfficer.
another.
• ManageEmergencyControl: This control • When an object receives a message, it
object manages the reporting function for triggers an action called an operation.
the Dispatcher. It is created when an • The activation of an operation is shown
EmergencyReport is received. It displays a as a vertical rectangle that represents the
form (IncidentForm) to the Dispatcher. time the operation is active.
Once the Dispatcher creates an Incident,
Sequence diagrams also help us understand the
allocates resources, and submits an
lifetime of objects involved:
acknowledgment, the
ManageEmergencyControl forwards the • A dashed line between an object's
acknowledgment to the FieldOfficer. rectangle and the bottom of the diagram
represents the time span when the object
In simpler terms, control objects are like
exists.
managers or coordinators in a use case. They
• Objects that already exist before the
make sure things happen in the right order and
sequence diagram starts are shown at the
coordinate the actions of other objects. For the
top.
"ReportEmergency" use case, we have control
• Objects created during the interaction are
objects for the FieldOfficer and the Dispatcher.
represented by a "create" message
The FieldOfficer's control object oversees the
pointing to the object.
reporting process, while the Dispatcher's control
• Objects that are no longer needed are
object manages the handling of the report. They
shown with a cross, indicating when they
ensure that the right forms are displayed,
cease to exist.
information is collected, and acknowledgments
are exchanged. To draw sequence diagrams, we follow some
helpful rules called heuristics:

• The first column should represent the

actor who initiated the use case.
• The second column should be a boundary
object, like a button or control, that the
actor used to start the use case.
 • The third column should be the control interactions among objects, but they serve the
object that manages the rest of the use same purpose.
case.
Sequence diagrams are like pictures that show
• Control objects are created by boundary
how objects communicate and pass messages to
objects when they initiate use cases.
each other over time. They are useful for a single
• Boundary objects are created by control
person or modeler to understand and visualize
objects.
the flow of actions in a use case or scenario.
In simpler terms, sequence diagrams are like
On the other hand, CRC cards are physical index
pictures that show how objects talk to each other
cards that can be used by a group of developers.
in a use case. The columns represent the objects
Each developer can have their own set of CRC
involved, and the arrows show the messages they
cards, and they can use them to discuss and
send. The length of the rectangles shows how
collaborate on understanding the responsibilities
long an action takes. We can also see when
and collaborations between classes. It helps the
objects exist, when they are created, and when
group have a shared understanding and organize
they are no longer needed. To draw these
their work.
diagrams, we start with the actor, then show the
boundary object they use, and finally the control In simpler terms, CRC cards are like special cards
object that manages everything else. Control that describe classes in a software system. They
objects create boundary objects, and boundary have the class name, responsibilities (what the
objects create control objects. class does), and the names of other classes they
work with. CRC cards are useful for a group of
developers to understand and work together on a
MODELING INTERACTIONS AMONG OBJECTS
WITH CRC CARDS project. Sequence diagrams are like pictures that
show how classes communicate, and they are
Let's simplify the explanation of CRC (Class, useful for a single person to understand the flow
Responsibilities, and Collaborators) cards and of actions in a use case. Both CRC cards and
their relationship with sequence diagrams: sequence diagrams help us understand how
different classes interact in a software system.
CRC cards are a way to understand and organize
the interactions among objects in a software IDENTIFYING ASSOCIATIONS AND ATTRIBUTES
system. Each class is represented on an index
card, called a CRC card. The card contains Let's simplify the explanation of associations and
important information about the class, such as its the heuristics used to identify them:
name, responsibilities, and the names of other Associations show relationships between different
classes it collaborates with. classes in a software system. For example, one
The CRC card has three sections :- class called FieldOfficer is associated with another
class called EmergencyReport because the
• The top section shows the name of the FieldOfficer writes the report.
class.
• The left column lists the responsibilities of Identifying associations has two advantages :-
the class, which are the things it needs to 1. It makes the relationships between objects
do or take care of. clear in the analysis model. For example,
• The right column lists the names of other it explicitly shows that an
classes that the class works together with EmergencyReport can be created by either
to accomplish its responsibilities. a FieldOfficer or a Dispatcher.
CRC cards and sequence diagrams are two 2. It helps the developer discover special
different ways to represent and understand cases or exceptions related to the
associations. These special cases are called
 boundary cases and need to be clarified determining the number of instances
in the model. For example, should the involved.
system allow multiple FieldOfficers to • Avoid too many associations: Having too
write one EmergencyReport? Should it many associations can make the model
allow anonymous EmergencyReports? hard to understand.
These questions should be discussed with
In simpler terms, associations show relationships
clients or end users during the analysis
between different classes in a software system.
phase.
They help us understand how classes are
Associations have several properties: connected and work together. Associations have
names, roles, and multiplicity to describe the
• Name: Each association has a name that
relationship and the number of instances
describes the relationship between the
involved. To identify associations, we look for
classes. For example, the name "Writes"
specific words or phrases that describe the
could be used to describe the association
relationship. It's important to name associations
between FieldOfficer and
and roles clearly, use qualifiers when needed,
EmergencyReport.
and avoid having too many associations in the
• Role: Each class in the association has a
model.
role that describes its function with
respect to the association. For example,
the FieldOfficer plays the role of the ATTRIBUTES
author in the "Writes" association.
• Multiplicity: Each end of the association Let's simplify the explanation of attributes and
has a multiplicity that describes the the heuristics used to identify them:
possible number of instances. For Attributes are like properties or characteristics of
example, the "*" symbol indicates that a individual objects in a software system. They
FieldOfficer can write zero or more represent specific information that is relevant to
EmergencyReports, while the "1" symbol the system. For example, a FieldOfficer object
indicates that each EmergencyReport has may have attributes like badge number, name,
exactly one FieldOfficer as the author. and rank.
To identify associations, we can use Abbott's When identifying attributes, we consider only the
heuristics :- ones that are important for the system to
• Examine verb phrases: Look for phrases function properly. For example, a FieldOfficer's
like "has," "is part of," "manages," social security number may not be relevant to the
"reports to," "is triggered by," "is emergency information system, so we don't
contained in," "talks to," or "includes" to include it as an attribute. Instead, we focus on
identify associations. attributes like badge number, which helps
• Name associations and roles precisely: identify the FieldOfficer within the system.
Give associations and roles clear and Attributes have two main properties:
descriptive names.
• Use qualifiers: Use qualifiers to identify 1. Name: Each attribute has a name that
specific namespaces or key attributes identifies it within an object. For
related to the associations. example, the attribute "badgeNumber"
• Eliminate redundant associations: Remove represents the badge number of a
any association that can be derived or FieldOfficer.
understood from other associations. 2. Type: Each attribute has a type that
• Don't worry about multiplicity at first: describes the legal values it can take. For
Focus on identifying associations before example, the badge number attribute may
 have a type of "integer" because it should In an analysis model, aggregations are
only accept whole numbers. represented as associations with a diamond-
shaped symbol on the side of the whole (like the
To identify attributes, we can use some helpful
FireStation or State). This symbol indicates that
rules called heuristics:
there is a part-whole relationship between the
• Examine possessive phrases: Look for objects involved.
phrases like "belonging to" or "of" to
In simpler terms, aggregations show how smaller
identify attributes. For example, in the
things are connected to form a bigger thing. It's
phrase "badge number of a FieldOfficer,"
like putting puzzle pieces together to create a
"badge number" is an attribute.
complete picture. In the example of a FireStation,
• Represent stored state as an attribute:
there are different components like FireFighters
Consider attributes that represent the
and FireEngines that come together to make up
stored information or state of an object.
the FireStation. The same idea applies to a State
• Describe each attribute: Provide a clear
composed of Counties and Townships.
description for each attribute, indicating
Aggregations help us understand the relationships
what information it represents.
between these parts and the whole.
In simpler terms, attributes are like properties or
characteristics of objects in a software system.
MODELING STATE DEPARTMENT BEHAVIOR OF
They represent specific information that is INDIVIDUAL OBJECTS
important for the system to work correctly.
Attributes have names and types. To identify Let's simplify the explanation of sequence
attributes, we look for phrases that indicate diagrams and state machine diagrams:
possession or ownership, and we consider
Sequence diagrams show the behavior of the
attributes that store important information. It's
important to describe each attribute clearly to system from the perspective of a single use
understand what it represents. case. They help us understand the flow of
actions and messages between different objects
involved in that use case. It's like watching a
IDENTIFYING AGGREGATES
step-by-step movie of how things happen in a

Let's simplify the explanation of aggregations and

specific situation.
their part-whole relationship: On the other hand, state machine diagrams
Aggregations represent a special type of represent the behavior of a single object. They
association that shows a relationship between a focus on showing how an object changes its
whole and its parts. It's like a way to understand state based on different events or actions. It's
how smaller things come together to form a like looking at a map that guides us through
larger thing. the different states an object can be in and the
transitions between those states.
For example, imagine a FireStation. It consists of
several components, such as FireFighters, By looking at the transitions in a state machine
FireEngines, Ambulances, and a LeadCar. Each of diagram, developers can discover new
these components is part of the FireStation and behaviors or actions that an object can
contributes to its functioning. perform. It helps us understand how an object
Similarly, in a State, you can have Counties, and reacts or changes based on specific events or
each County is composed of smaller units called triggers.
Townships. These relationships help us understand
It's important to note that we don't need to
how things are organized and connected.
create state machines for every class in the
system. Usually, state machines are more
relevant for control objects that manage the
flow of actions, less often for entity objects
that represent real-world concepts, and almost
never for boundary objects that interact with
the users.

For example, let's take an Incident object in a

system called FRIEND. This object can exist in
different states: Active, Inactive, Closed, and
Archived. Each state represents a specific
situation related to an incident:

• Active Incident: It means there is an

ongoing situation that requires a
response, like a fire or a traffic
accident.
• Inactive Incident: It means the situation
has been handled, but there are still
some reports or follow-up tasks to be
completed, like finalizing damage
estimates after a fire has been put out.
• Closed Incident: It means the situation
has been handled and properly
documented.
• Archived Incident: It's a closed incident
whose documentation has been moved
to a separate storage location.

In simpler terms, sequence diagrams show the

step-by-step actions and messages between
objects in a use case, while state machine
diagrams show how a single object changes its
state based on different events or actions. They
help us understand the behavior of the system
and individual objects. State machine diagrams
are especially useful for understanding how
objects transition between different states and
react to specific triggers.