Unit 2

REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirement analysis and specification

Software requirement means requirement that is needed by software to increase quality

of software product. These requirements are generally a type of expectation of user from
software product that is important and need to be fulfilled by software. Analysis means to
examine something in an organized and specific manner to know complete details about it.
Therefore, Software requirement analysis simply means complete study, analyzing,
describing software requirements so that requirements that are genuine and needed can be
fulfilled to solve problem. There are several activities involved in analyzing Software
requirements. Some of them are given below :

1. Problem Recognition :
The main aim of requirement analysis is to fully understand main objective of requirement
that includes why it is needed, does it add value to product, will it be beneficial, does it
increase quality of the project, does it will have any other effect. All these points are fully
recognized in problem recognition so that requirements that are essential can be fulfilled to
solve business problems.

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not and synthesis
means to create or form something. Here are some tasks are given that is important in the
evaluation and synthesis of software requirement :
 To define all functions of software that necessary.
 To define all data objects that are present externally and are easily observable.
 To evaluate that flow of data is worth or not.
  To fully understand overall behavior of system that means overall working of system.
 To identify and discover constraints that are designed.
 To define and establish character of system interface to fully understand how system
interacts with two or more components or with one another.
3. Modeling :
After complete gathering of information from above tasks, functional and behavioral
models are established after checking function and behavior of system using a domain
model that also known as the conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the requirement
whether it is functional or non-functional should be developed.

5. Review :
After developing the SRS, it must be reviewed to check whether it can be improved or not
and must be refined to make it better and increase the quality.

Requirements gathering and analysis

Requirements gathering is a crucial phase in the software development life cycle (SDLC) and
project management. It involves collecting, documenting, and managing the requirements that
define the features and functionalities of a system or application. The success of a project often
depends on the accuracy and completeness of the gathered requirements in software.

Main Requirements Gathering Subprocesses:

Requirements gathering is a critical phase in the software development lifecycle, and it
involves several subprocesses to ensure a comprehensive understanding of the project's needs.
The main subprocesses include:

Stakeholder Identification:
 Objective: Identify all stakeholders who will be affected by the system, directly or
indirectly.
 Process: Conduct interviews, surveys, or workshops to determine the key individuals or
groups involved.
Stakeholder Analysis:
 Objective: Understand the needs, expectations, and influence of each stakeholder.
 Process: Analyze stakeholder inputs to prioritize requirements and manage conflicting
interests.
Problem Definition:
 Objective: Clearly define the problems or opportunities that the software system aims to
address.
 Process: Engage stakeholders in discussions to uncover and articulate the core problems or
opportunities.
Requirements Extraction:
 Objective: Gather detailed requirements by interacting with stakeholders.
 Process: Employ techniques such as interviews, surveys, observations, or brainstorming
sessions to extract requirements.
Requirements Documentation:
 Objective: Document gathered requirements in a structured format.
 Process: Create requirements documents, use cases, user stories, or prototypes to capture
and communicate requirements effectively.
Validation and Verification:
 Objective: Ensure that gathered requirements are accurate, complete, and consistent.
 Process: Conduct reviews, walkthroughs, or use validation tools to verify that the
requirements meet the defined criteria.

Processes of Requirements Gathering in Software Development:

There are 6 steps crucial for requirement gathering processes

Processes of
Requirements Gathering in Software Development

Step 1- Assigning roles:

 The first step is to identify and engage with all relevant stakeholders. Stakeholders can
include end-users, clients, project managers, subject matter experts, and anyone else who
has a vested interest in the software project. Understanding their perspectives is essential
for capturing diverse requirements.
Step 2- Define Project Scope:
 Clearly define the scope of the project by outlining its objectives, boundaries, and
limitations. This step helps in establishing a common understanding of what the software is
expected to achieve and what functionalities it should include.
Step 3- Conduct Stakeholder Interviews:
 Schedule interviews with key stakeholders to gather information about their needs,
preferences, and expectations. Through open-ended questions and discussions, aim to
uncover both explicit and implicit requirements. These interviews provide valuable insights
that contribute to a more holistic understanding of the project.
Step 4- Document Requirements:
 Systematically document the gathered requirements. This documentation can take various
forms, such as user stories, use cases, or formal specifications. Clearly articulate functional
requirements (what the system should do) and non-functional requirements (qualities the
system should have, such as performance or security).
Step 5- Verify and Validate Requirements:
 Once the requirements are documented, it's crucial to verify and validate them. Verification
ensures that the requirements align with the stakeholders' intentions, while validation
ensures that the documented requirements will meet the project's goals. This step often
involves feedback loops and discussions with stakeholders to refine and clarify
requirements.
Step 6- Prioritize Requirements:
 Prioritize the requirements based on their importance to the project goals and constraints.
This step helps in creating a roadmap for development, guiding the team on which features
to prioritize. Prioritization is essential, especially when resources and time are limited.

Requirement Gathering Techniques:
Effective requirement gathering is essential for the success of a software development project.
Various techniques are employed to collect, analyze, and document requirements.
Requirements Gathering Techniques

Here are some commonly used requirement gathering techniques:

1. Interviews:
 Conducting one-on-one or group interviews with stakeholders, including end-users,
clients, and subject matter experts. This allows for direct interaction to gather detailed
information about their needs, expectations, and concerns.
2. Surveys and Questionnaires:
 Distributing surveys and questionnaires to a broad audience to collect information on a
larger scale. This technique is useful for gathering feedback from a diverse set of
stakeholders and can be particularly effective in large projects.
3. Workshops:
 Organizing facilitated group sessions or workshops where stakeholders come together
to discuss and define requirements. Workshops encourage collaboration, idea
generation, and the resolution of conflicting viewpoints in a structured environment.
4. Observation:
 Directly observing end-users in their work environment to understand their workflows,
pain points, and preferences. Observational techniques help in uncovering implicit
requirements that users might not explicitly state.
5. Prototyping:
 Creating mockups or prototypes of the software to provide stakeholders with a tangible
representation of the proposed system. Prototyping allows for early visualization and
feedback, helping to refine requirements based on stakeholders' reactions.
6. Use Cases and Scenarios:
 Developing use cases and scenarios to describe how the system will be used in different
situations. This technique helps in understanding the interactions between users and the
system, making it easier to identify and document functional requirements.
7. Document Analysis:
 Reviewing existing documentation, such as business process manuals, reports, and
forms, to extract relevant information. This technique provides insights into the current
processes and helps identify areas for improvement.

Requirement gathering holds immense importance in software development for several critical
reasons:
1. Clarity of Project Objectives:
 Requirement gathering sets the stage by defining and clarifying the objectives of the
software project. It ensures that all stakeholders, including clients, users, and
development teams, have a shared understanding of what needs to be achieved.
2. Customer Satisfaction:
  Understanding and meeting customer needs is paramount for customer satisfaction.
Requirement gathering allows developers to comprehend the expectations of end-users
and clients, leading to the creation of a product that aligns with their desires and
requirements.
3. Scope Definition:
 Clearly defined requirements help in establishing the scope of the project. This
delineation is crucial for managing expectations, avoiding scope creep (uncontrolled
changes to project scope), and ensuring that the project stays on track.
4. Reduced Misunderstandings:
 Ambiguities and misunderstandings are common sources of project failures.
Requirement gathering facilitates clear communication between stakeholders, reducing
the risk of misinterpretations and ensuring that everyone involved is on the same page.
5. Risk Mitigation:
 Identifying and addressing potential issues at the requirements stage helps mitigate
risks early in the development process. This proactive approach minimizes the chances
of costly errors, rework, and delays later in the project life cycle.

Benefits of Requirements Gathering:

The benefits of effective requirements gathering in software development include:
 Cost Reduction: One of the primary benefits of effective requirements gathering is cost
reduction. When requirements are well-defined and thoroughly understood at the beginning
of a project, it minimizes the likelihood of costly changes and rework later in the
development process.
 Customer Satisfaction: Clear and accurate requirements gathering directly contributes to
customer satisfaction. When the end product aligns closely with the expectations and needs
of the stakeholders, it enhances user experience and meets customer demands. This
satisfaction is not only vital for the success of the current project but also contributes to
positive relationships between the development team and clients, fostering trust and
potential future collaborations.
 Improved Communication: Requirements gathering serves as a communication bridge
between various stakeholders involved in a project, including developers, clients, users,
and project managers. Miscommunication is a common source of project failures and
delays. By clearly documenting and understanding requirements, the development team
ensures that everyone involved has a shared vision of the project objectives, functionalities,
and constraints.
 Efficient Resource Utilization : Thorough requirements gathering enables the efficient
allocation and utilization of resources. Resources, including time, manpower, and
technology, are finite and valuable. When requirements are well-defined, project teams can
allocate resources more accurately, avoiding unnecessary expenditures or overcommitting
resources to certain aspects of the project.
 Enhanced Quality: Well-documented requirements serve as the foundation for quality
assurance throughout the development process. When the project team has a clear
understanding of what needs to be achieved, they can establish quality standards and
criteria from the outset. This clarity enables the implementation of effective testing
strategies, ensuring that each aspect of the system is thoroughly evaluated against the
specified requirements.
 Risk Management: Requirements gathering is a crucial component of effective risk
management. By identifying potential risks early in the project, stakeholders can
proactively address ambiguities, conflicting requirements, and other challenges that could
pose a threat to the project's success.
 Accurate Planning: Accurate project planning is dependent on a clear understanding of
project requirements. When requirements are well-documented, project managers can
create realistic schedules, milestones, and deliverables. This accurate planning is crucial for
setting expectations, managing stakeholder timelines, and ensuring that the project
progresses according to the established timeline.

Common Obstacles in Software Requirements Gathering:

Common obstacles in software requirements gathering include:

 Unclear Objectives: Lack of clear project objectives can hinder requirements gathering.
When stakeholders are unsure about what they want to achieve, it becomes challenging to
define and prioritize requirements effectively. This can lead to confusion, scope creep, and
difficulties in meeting project goals.
 Ambiguous Requirements: Ambiguities in requirements, such as vague language or
conflicting statements, can create misunderstandings among stakeholders and the
development team. Ambiguous requirements may result in deliverables that do not meet
expectations and may require extensive rework.
 Poor Stakeholder Involvement: Insufficient involvement or engagement of key
stakeholders can impede the requirements gathering process. When essential stakeholders
are not actively participating or providing input, there is a risk of missing critical
requirements or making decisions that do not align with the needs of the end-users.
 Changing Requirements: Requirements that undergo frequent changes during the
development process, often referred to as "scope creep," can lead to project delays,
increased costs, and challenges in maintaining project focus. It is essential to manage and
control changes to prevent unnecessary disruptions.
 Communication Barriers: Communication challenges, such as language barriers,
misinterpretations, or inadequate channels for information exchange, can hinder effective
requirements gathering. It is crucial to establish clear communication channels and ensure
that all stakeholders have a shared understanding of the terminology used in the project.
 Overreliance on Documentation: Depending solely on documentation without active
collaboration and communication can lead to misunderstandings. Written requirements may
 not capture the complete context or evolving needs, making it essential to complement
documentation with interactive processes like workshops and interviews.
 Lack of User Involvement: Users are often the ultimate beneficiaries of the system, and
their input is critical. Lack of user involvement or representation can result in systems that
do not effectively meet their needs. It is important to actively involve end-users in the
requirements gathering process to ensure the system's usability and acceptance.

How Requirements Gathering helps for Agile in Software Development:

Agile development emphasizes flexibility, collaboration, and continuous improvement. The

requirements gathering process in Agile is iterative and adaptive, allowing for changes and
adjustments throughout the development lifecycle. Here's a detailed explanation of the
requirements gathering process in Agile:
 User Stories: In Agile, requirements are often expressed as user stories. A user story is a
concise, informal description of a feature told from the end-user's perspective. It typically
follows the format: "As a [type of user], I want [an action] so that [benefit/value]." User
stories focus on the user and their goals, helping to capture the essence of the required
functionality.
 Backlog Refinement: The product backlog is a prioritized list of features, enhancements,
and fixes. Backlog refinement sessions, often known as backlog grooming, occur regularly
to review, clarify, and prioritize the items in the backlog. This process ensures that the most
valuable and highest-priority items are at the top of the list and ready for development in
upcoming sprints.
 Iterative Development: Agile development is iterative, with work organized into time-
boxed cycles called sprints. During each sprint, a cross-functional team works on a set of
prioritized user stories. The requirements for each user story are refined and clarified as the
team progresses, allowing for flexibility and adaptability to changing priorities or emerging
insights.
 Continuous Stakeholder Collaboration: Agile encourages ongoing collaboration with
stakeholders, including product owners, end-users, and business representatives. Regular
meetings, such as sprint reviews and sprint planning, provide opportunities for stakeholders
to provide feedback on completed work, discuss changes to priorities, and refine
requirements for upcoming sprints.
 Prototyping and Visual Aids: Agile teams often use prototyping and visual aids to
enhance requirements understanding. Prototypes, wireframes, and other visual
representations help stakeholders visualize the proposed features and provide early
feedback. This iterative approach ensures that the final product closely aligns with
stakeholder expectations.
 Daily Stand-ups: Daily stand-up meetings, or daily scrums, are a key Agile practice.
These brief, focused meetings provide team members with the opportunity to share
progress, discuss impediments, and ensure that everyone is aligned on the project's goals.
 While not specifically for requirements gathering, daily stand-ups facilitate ongoing
communication, allowing the team to quickly address any emerging requirements or
changes.
 Acceptance Criteria: Each user story in Agile is accompanied by acceptance criteria.
Acceptance criteria define the conditions that must be met for a user story to be considered
complete. They serve as a shared understanding between the development team and
stakeholders regarding the expectations for the functionality being delivered. Clear
acceptance criteria help prevent misunderstandings and ensure that the developed features
meet the desired outcomes.
 Retrospectives: Agile teams regularly conduct retrospectives at the end of each sprint to
reflect on what went well, what could be improved, and what changes might enhance the
development process. This feedback loop includes discussions about the effectiveness of
the requirements gathering process, allowing the team to adapt and refine their approach
for future sprints.

Challenges and Considerations in Agile Requirements Gathering:

 Changing Priorities: Agile embraces changes in requirements, but frequent changes can
pose challenges. It's crucial to strike a balance between flexibility and stability, ensuring
that changes are well-understood, prioritized, and communicated effectively to the
development team.
 Balancing Detail and Flexibility: Agile requires enough detail to guide development, but
also the flexibility to adapt as requirements evolve. Striking the right balance ensures that
the team can respond to changes while maintaining a clear understanding of the project's
direction.
 Effective Communication: Agile heavily relies on communication and collaboration.
Ensuring that all team members, including stakeholders, have open channels for
communication is essential to prevent misunderstandings and align everyone with the
project's goals.
 Overemphasis on Documentation: While Agile values working software over
comprehensive documentation, it's important to strike a balance. Minimal but effective
documentation, such as user stories and acceptance criteria, should be maintained to ensure
a shared understanding among team members and stakeholders.
 Ensuring Continuous Feedback: Agile places a strong emphasis on continuous feedback,
but ensuring active stakeholder involvement can be challenging. Efforts should be made to
encourage regular feedback through sprint reviews, demos, and other collaborative sessions
to avoid potential misunderstandings and to keep the development aligned with stakeholder
expectations.
By embracing these Agile practices and considering the associated challenges, teams can
effectively gather and adapt requirements throughout the development process, delivering
value to stakeholders in a dynamic and responsive manner.
Tools for Requirements Gathering in Software Development:
Requirements gathering tools play a crucial role in streamlining the process of collecting,
documenting, and managing project requirements. These tools are designed to enhance
collaboration, improve communication, and facilitate the organization of complex information.
Here are several types of requirements gathering tools and their roles:
 Collaboration Tools: Collaboration tools, such as project management platforms (e.g.,
Jira, Trello, Asana), facilitate teamwork and communication among project stakeholders.
These platforms often include features like task assignment, progress tracking, and
discussion forums, enabling teams to collaboratively gather, discuss, and manage
requirements in real-time.
 Document Management Tools: Document management tools (e.g., Confluence,
SharePoint) help organize and store project documentation. These tools provide a
centralized repository for requirements, ensuring easy access, version control, and
collaboration. Document management tools are particularly valuable for maintaining a
structured record of evolving project requirements.
 Survey and Form Builders: Tools like Google Forms, Typeform, or SurveyMonkey
enable the creation of online surveys and forms. These are useful for gathering structured
data from a large audience, such as feedback, preferences, or specific information required
for project requirements. The collected data can be easily analyzed and integrated into the
requirements gathering process.
 Prototyping Tools: Prototyping tools (e.g., Sketch, Balsamiq, Figma) allow the creation of
visual or interactive prototypes. These tools are valuable for translating requirements into
tangible representations that stakeholders can interact with, providing a clearer
understanding of the proposed features and functionalities.
 Mind Mapping Tools: Mind mapping tools (e.g., MindMeister, XMind) help visualize and
organize complex ideas and relationships. During requirements gathering, these tools can
be used to create visual representations of interconnected requirements, helping
stakeholders and the project team understand the relationships between different features
and functionalities.
 Version Control Systems: Version control systems (e.g., Git, SVN) are essential for
managing changes to project documentation. These tools track revisions, allowing teams to
review, revert, or merge changes seamlessly. This is particularly valuable in dynamic
projects where requirements may undergo frequent updates or refinements.
 Requirements Management Software: Specialized requirements management tools (e.g.,
IBM Engineering Requirements Management DOORS, Jama Connect) are designed
specifically for capturing, tracking, and managing requirements throughout the project
lifecycle. These tools often offer features such as traceability, impact analysis, and
integration with other project management tools.
 Visual Collaboration Tools: Visual collaboration tools (e.g., Miro, Lucidchart) facilitate
collaborative diagramming and visual representation of ideas. These tools can be used for
 creating flowcharts, diagrams, or visual models that help communicate complex
requirements in a more intuitive and accessible way.
Conclusion:
In conclusion, good requirements gathering is crucial for successful projects, ensuring the final
product meets everyone's needs and expectations in software development.

Software Requirement specification

What is Requirements Engineering?

A systematic and strict approach to the definition, creation, and verification of requirements for
a software system is known as requirements engineering. To guarantee the effective creation of
a software product, the requirements engineering process entails several tasks that help in
understanding, recording, and managing the demands of stakeholders.

Requirements Engineering Process

1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management
1. Feasibility Study
The feasibility study mainly concentrates on below five mentioned areas below. Among these
Economic Feasibility Study is the most important part of the feasibility analysis and the Legal
Feasibility Study is less considered feasibility analysis.
1. Technical Feasibility: In Technical Feasibility current resources both hardware software
along required technology are analyzed/assessed to develop the project. This technical
feasibility study reports whether there are correct required resources and technologies that
will be used for project development. Along with this, the feasibility study also analyzes
the technical skills and capabilities of the technical team, whether existing technology can
be used or not, whether maintenance and up-gradation are easy or not for the chosen
technology, etc.
2. Operational Feasibility: In Operational Feasibility degree of providing service to
requirements is analyzed along with how easy the product will be to operate and maintain
after deployment. Along with this other operational scopes are determining the usability of
the product, Determining suggested solution by the software development team is
acceptable or not, etc.
3. Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are
analyzed. This means under this feasibility study a detailed analysis is carried out will be
cost of the project for development which includes all required costs for final development
hardware and software resources required, design and development costs operational costs,
and so on. After that, it is analyzed whether the project will be beneficial in terms of
finance for the organization or not.

4. Legal Feasibility: In legal feasibility, the project is ensured to comply with all relevant
laws, regulations, and standards. It identifies any legal constraints that could impact the
project and reviews existing contracts and agreements to assess their effect on the project’s
execution. Additionally, legal feasibility considers issues related to intellectual property,
such as patents and copyrights, to safeguard the project’s innovation and originality.
5. Schedule Feasibility: In schedule feasibility, the project timeline is evaluated to determine
if it is realistic and achievable. Significant milestones are identified, and deadlines are
established to track progress effectively. Resource availability is assessed to ensure that the
necessary resources are accessible to meet the project schedule. Furthermore, any time
constraints that might affect project delivery are considered to ensure timely completion.
This focus on schedule feasibility is crucial for the successful planning and execution of a
project.
2. Requirements Elicitation
It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business manuals,
the existing software of the same type, standards, and other stakeholders of the project. The
techniques used for requirements elicitation include interviews, brainstorming, task analysis,
Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does not
produce formal models of the requirements understood. Instead, it widens the domain
knowledge of the analyst and thus helps in providing input to the next stage.
Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the requirements
engineering process and it is critical to the success of the software development project. The
goal of this step is to understand the problem that the software system is intended to solve and
the needs and expectations of the stakeholders who will use the system.
Several techniques can be used to elicit requirements, including:
 Interviews: These are one-on-one conversations with stakeholders to gather information
about their needs and expectations.
 Surveys: These are questionnaires that are distributed to stakeholders to gather information
about their needs and expectations.
 Focus Groups: These are small groups of stakeholders who are brought together to discuss
their needs and expectations for the software system.
 Observation: This technique involves observing the stakeholders in their work
environment to gather information about their needs and expectations.
 Prototyping: This technique involves creating a working model of the software system,
which can be used to gather feedback from stakeholders and to validate requirements.
It’s important to document, organize, and prioritize the requirements obtained from all these
techniques to ensure that they are complete, consistent, and accurate.

3. Requirements Specification
This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge about the problem
may be required which can again trigger the elicitation process. The models used at this stage
include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs),
data dictionaries, etc.
Requirements specification is the process of documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.
The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system. This document should be understandable by both the
development team and the stakeholders.

Several types of requirements are commonly specified in this step, including

1. Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.
2. Non-Functional Requirements : These describe how well the software system should do
it. They specify the quality attributes of the system, such as performance, reliability,
usability, and security.
3. Constraints: These describe any limitations or restrictions that must be considered when
developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.
To make the requirements specification clear, the requirements should be written in a natural
language and use simple terms, avoiding technical jargon, and using a consistent format
throughout the document. It is also important to use diagrams, models, and other visual aids to
help communicate the requirements effectively.
Once the requirements are specified, they must be reviewed and validated by the stakeholders
and development team to ensure that they are complete, consistent, and accurate.
4. Requirements Verification and Validation
Verification: It refers to the set of tasks that ensures that the software correctly implements a
specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built
is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:
1. The requirements should be consistent with all the other requirements i.e. no two
requirements should conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate and that they meet
the needs and expectations of the stakeholders. The goal of V&V is to ensure that the software
system being developed meets the requirements and that it is developed on time, within budget,
and to the required quality.
1. Verification is checking that the requirements are complete, consistent, and accurate. It
involves reviewing the requirements to ensure that they are clear, testable, and free of
errors and inconsistencies. This can include reviewing the requirements document, models,
and diagrams, and holding meetings and walkthroughs with stakeholders.
2. Validation is the process of checking that the requirements meet the needs and expectations
of the stakeholders. It involves testing the requirements to ensure that they are valid and
that the software system being developed will meet the needs of the stakeholders. This can
include testing the software system through simulation, testing with prototypes, and testing
with the final version of the software.
3. Verification and Validation is an iterative process that occurs throughout the software
development life cycle. It is important to involve stakeholders and the development team in
the V&V process to ensure that the requirements are thoroughly reviewed and tested.
It’s important to note that V&V is not a one-time process, but it should be integrated and
continue throughout the software development process and even in the maintenance stage.
5. Requirements Management
Requirement management is the process of analyzing, documenting, tracking, prioritizing, and
agreeing on the requirement and controlling the communication with relevant stakeholders.
This stage takes care of the changing nature of requirements. It should be ensured that the SRS
is as modifiable as possible to incorporate changes in requirements specified by the end users
at later stages too. Modifying the software as per requirements in a systematic and controlled
manner is an extremely important part of the requirements engineering process.
Requirements management is the process of managing the requirements throughout the
software development life cycle, including tracking and controlling changes, and ensuring that
the requirements are still valid and relevant. The goal of requirements management is to ensure
that the software system being developed meets the needs and expectations of the stakeholders
and that it is developed on time, within budget, and to the required quality.
Several key activities are involved in requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling changes to
the requirements throughout the development process, including identifying the source of
the change, assessing the impact of the change, and approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the requirements
document and other related artifacts.
3. Traceability: This involves linking the requirements to other elements of the development
process, such as design, testing, and validation.
4. Communication: This involves ensuring that the requirements are communicated
effectively to all stakeholders and that any changes or issues are addressed promptly.
5. Monitoring and reporting: This involves monitoring the progress of the development
process and reporting on the status of the requirements.
Requirements management is a critical step in the software development life cycle as it helps
to ensure that the software system being developed meets the needs and expectations of
stakeholders and that it is developed on time, within budget, and to the required quality. It also
helps to prevent scope creep and to ensure that the requirements are aligned with the project
goals.
Tools Involved in Requirement Engineering
 Observation report
 Questionnaire ( survey, poll )
 Use cases
 User stories
 Requirement workshop
 Mind mapping
 Roleplaying
 Prototyping
Advantages of Requirements Engineering Process
 Helps ensure that the software being developed meets the needs and expectations of the
stakeholders
 Can help identify potential issues or problems early in the development process, allowing
for adjustments to be made before significant
 Helps ensure that the software is developed in a cost-effective and efficient manner
 Can improve communication and collaboration between the development team and
stakeholders
 Helps to ensure that the software system meets the needs of all stakeholders.
 Provides an unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.
 Helps to identify potential conflicts and contradictions in the requirements, which can be
resolved before the software development process begins.
 Helps to ensure that the software system is delivered on time, within budget, and to the
required quality standards.
 Provides a solid foundation for the development process, which helps to reduce the risk of
failure.
Disadvantages of Requirements Engineering Process
 Can be time-consuming and costly, particularly if the requirements-gathering process is not
well-managed
 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into
account
 It Can be challenging to ensure that the requirements are clear, consistent, and complete
 Changes in requirements can lead to delays and increased costs in the development process.
 As a best practice, Requirements engineering should be flexible, adaptable, and should be
aligned with the overall project goals.
 It can be time-consuming and expensive, especially if the requirements are complex.
 It can be difficult to elicit requirements from stakeholders who have different needs and
priorities.
 Requirements may change over time, which can result in delays and additional costs.
 There may be conflicts between stakeholders, which can be difficult to resolve.
 It may be challenging to ensure that all stakeholders understand and agree on the
requirements.
Stages in Software Engineering Process
Requirements engineering is a critical process in software engineering that involves
identifying, analyzing, documenting, and managing the requirements of a software system. The
requirements engineering process consists of the following stages:
 Elicitation: In this stage, the requirements are gathered from various stakeholders such as
customers, users, and domain experts. The aim is to identify the features and functionalities
that the software system should provide.
 Analysis: In this stage, the requirements are analyzed to determine their feasibility,
consistency, and completeness. The aim is to identify any conflicts or contradictions in the
requirements and resolve them.
 Specification: In this stage, the requirements are documented in a clear, concise, and
unambiguous manner. The aim is to provide a detailed description of the requirements that
can be understood by all stakeholders.
 Validation: In this stage, the requirements are reviewed and validated to ensure that they
meet the needs of all stakeholders. The aim is to ensure that the requirements are accurate,
complete, and consistent.
 Management: In this stage, the requirements are managed throughout the software
development lifecycle. The aim is to ensure that any changes or updates to the requirements
are properly documented and communicated to all stakeholders.
 Effective requirements engineering is crucial to the success of software development
projects. It helps ensure that the software system meets the needs of all stakeholders and is
delivered on time, within budget, and to the required quality standards.
Petrinets

A Petri net, also known as a place/transition net (PT net), is one of

several mathematical modeling languages for the description of distributed systems. It is a class
of discrete event dynamic system. A Petri net is a directed bipartite graph that has two types of
elements: places and transitions. Place elements are depicted as white circles and transition
elements are depicted as rectangles. A place can contain any number of tokens, depicted as black
circles. A transition is enabled if all places connected to it as inputs contain at least one token.

A Petri net consists of places, transitions, and arcs. Arcs run from a place to a transition or vice
versa, never between places or between transitions. The places from which an arc runs to a
transition are called the input places of the transition; the places to which arcs run from a
transition are called the output places of the transition.

Graphically, places in a Petri net may contain a discrete number of marks called tokens. Any
distribution of tokens over the places will represent a configuration of the net called a marking.
In an abstract sense relating to a Petri net diagram, a transition of a Petri net may fire if it
is enabled, i.e. there are sufficient tokens in all of its input places; when the transition fires, it
consumes the required input tokens, and creates tokens in its output places. A firing is atomic,
i.e. a single non-interruptible step.

Unless an execution policy (e.g. a strict ordering of transitions, describing precedence) is defined,
the execution of Petri nets is nondeterministic: when multiple transitions are enabled at the same
time, they will fire in any order.

Since firing is nondeterministic, and multiple tokens may be present anywhere in the net (even in
the same place), Petri nets are well suited for modeling the concurrent behavior of distributed
systems.

Formal definition and basic terminology

Petri nets are state-transition systems that extend a class of nets called elementary nets.[2]

Definition 1. A net is a tuple where

1. P and T are disjoint finite sets of places and transitions, respectively.

2. is a set of (directed) arcs (or flow relations).

Definition 2. Given a net N = (P, T, F), a configuration is a set C so that C ⊆ P.
 A Petri net with an enabled transition.

The Petri net that follows after the transition fires (Initial Petri
net in the figure above).
Definition 3. An elementary net is a net of the form EN = (N, C) where

2. C is such that C ⊆ P is a configuration.

1. N = (P, T, F) is a net.

Definition 4. A Petri net is a net of the form PN = (N, M, W), which extends the elementary net
so that

1. N = (P, T, F) is a net.
2. M: P → Z is a place multiset, where Z is a countable set. M extends the concept
of configuration and is commonly described with reference to Petri net diagrams as
a marking.
3. W: F → Z is an arc multiset, so that the count (or weight) for each arc is a measure of the
arc multiplicity.

Object modelling using UML

Object diagrams are a visual representation in UML (Unified Modeling Language) that
illustrates the instances of classes and their relationships within a system at a specific point in
time. They display objects, their attributes, and the links between them, providing a snapshot
of the system’s structure during execution. Since object diagrams depict behavior when objects
have been instantiated, we can study the behavior of the system at a particular instant.

Important Topics for the Object Diagrams

 What are Object Diagrams?
 Object Diagram Notations
 Purpose of Object Diagrams
 Benefits of Object Diagrams
 How to draw an Object Diagram?
 Use Cases of Object Diagrams
1. What are Object Diagrams?
An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them.
 An object diagram in UML is useful because it provides a clear and visual representation of
specific instances of classes and their relationships at a particular point in time, aiding in
understanding and communicating the structure and interactions within a system.
 In other words, “An object diagram in the Unified Modeling Language (UML), is a
diagram that shows a complete or partial view of the structure of a modeled system at a
specific time.
Object diagrams in UML are depicted using a simple and intuitive notations to show a
snapshot of a system at a specific point in time, displaying instances of classes and their
relationships.
What is an Object?
An object refers to a specific instance of a class within a system. A class is a blueprint or
template that defines the common attributes and behaviors shared by a group of objects. An
object, on the other hand, is a concrete and individual occurrence of that class, possessing
unique values for its attributes.
What is a Classifier?
In UML a classifier refers to a group of elements that have some common features like
methods, attributes and operations. A classifier can be thought of as an abstract metaclass
which draws a boundary for a group of instances having common static and dynamic features.
For example:
we refer a class, an object, a component, or a deployment node as classifiers in UML since
they define a common set of properties. We are able to design object diagrams by instantiating
classifiers.
4. Object Diagram Notations
The object diagram in UML uses specific notations to represent instances of classes and their
relationships at a particular moment in time.
1. Objects or Instance specifications
When we instantiate a classifier in a system, the object we create represents an entity which
exists in the system. We can represent the changes in object over time by creating multiple
instance specifications. We use a rectangle to represent an object in an object diagram.

2. Attributes and Values

Inside the object box, attributes of the object are listed along with their specific values.

3. Link
We use a link to represent a relationship between two objects. We represent the number of
participants on the link for each, at the end of the link. The term link is used to specify a
relationship between two instance specifications or objects. We use a solid line to represent a
link between two objects.
For Example – In the figure below, an object of class Student is linked to an object of class
College

4. Dependency Relationships
We use a dependency relationship to show when one element depends on another element. A
dependency is used to depict the relationship between dependent and independent entities in
the system.
 Any change in the definition or structure of one element may cause changes to the other.
 This is a unidirectional kind of relationship between two objects.
 Dependency relationships are of various types specified with keywords like Abstraction,
Binding, Realization, Substitution and Usage are the types of dependency relationships
used in UML.

For example – In the figure below, an object of Player class is dependent (or uses) an object
of Bat class.
5. Association
Association is a reference relationship between two objects (or classes). An association line
connects two object boxes, representing a relationship between instances of two classes. We
use association when one object references members of the other object. Association can be
uni-directional or bi-directional. We use an arrow to represent association.

For example – The object of Order class is associated with an object of Customer class.

6. Aggregation
Aggregation represents a “has a” relationship. We use a hollow diamond on the containing
object with a line which joins it to the contained object.
 Aggregation is a specific form of association.
 It is a kind of parent-child relationship however it isn’t inheritance.
 Aggregation occurs when the lifecycle of the contained objects does not strongly depend on
the lifecycle of container objects.
For example – A library has an aggregation relationship with books. Library has books or
books are a part of library. The existence of books is independent of the existence of the
library.

7. Composition
Composition is a type of association where the child cannot exist independent of the other. We
use a filled diamond on the containing object with a line which joins it to the contained object.
Composition is also a special type of association. It is also a kind of parent child relationship
but it is not inheritance. So whenever independent existence of the child is not possible we use
a composition relationship.

Consider the example of a boy Gurkaran: Gurkaran is composed of legs and arms. Here
Gurkaran has a composition relationship with his legs and arms. Here legs and arms can’t
exist without the existence of their parent object.

5. Purpose of Object Diagrams

The main purpose of using object diagrams is:
 They offer a detailed view of how objects interact with each other in specific scenarios.
 Proper design and analysis of applications can be faster and efficient.
 Object diagrams are beneficial during the implementation phase of software development.
 Promoting a shared understanding of specific instances and their relationships, facilitating
collaboration among team members.
6. Benefits of Object Diagrams
 Detailed Insight into Relationships:
 o They offer a detailed view of relationships and collaborations between instances
of classes. This helps in understanding the specific interactions and
dependencies among objects.
 Implementation Guidance:
o During the system implementation phase, object diagrams assist developers in
building and testing the actual instances of classes. They provide guidance on
how to represent objects in code.
 Integration Testing Assistance:
o They are valuable for integration testing, allowing testers to evaluate how
different objects collaborate and exchange information. This ensures that
integrated components of the system work seamlessly.
 Validation of Code Implementation:
o Developers can use object diagrams to validate that the actual code aligns with
the intended relationships and interactions specified in the design. This helps
maintain consistency between the design and the implementation.
 Scenario Illustration:
o Object diagrams are useful for illustrating and documenting specific scenarios or
use cases, providing a clear visual representation of how objects behave in
different situations.
7. How to draw an Object Diagram?
1. Identify Classes: Determine the classes relevant to the scenario you want to depict.
Classes are the blueprints that define the attributes and behaviors shared by their instances.
2. Identify Objects: Identify specific instances or objects of each class that you want to
include in the diagram. These represent the actual things in your system.
3. Create Object Boxes: Draw rectangles to represent the specific instances or objects of
each class. Write the name of each object inside the box.
4. Add Attributes and Values: Inside each object box, list the attributes of that object along
with their specific values.
5. Draw Relationships: Connect the object boxes with lines to represent relationships or
associations between instances. Use arrows to indicate the direction of the association if
necessary.
6. Label Relationships: Label the relationships with multiplicity and role names if needed.
Label the association lines with a verb or phrase to describe the nature of the relationship.
7. Review and Refine: Review your Object diagram to ensure it accurately represents the
system’s structure and relationships. Refine the diagram as needed based on feedback and
requirements.
8. Use Tools for Digital Drawing: While you can draw class diagrams on paper, using digital
tools can provide more flexibility and ease of modification. UML modeling tools, drawing
software, or even specialized diagramming tools can be helpful.
8. Use Cases of Object Diagrams
Object diagrams in UML also play a crucial role in various phases of software development.
Here are some use cases for object diagrams:
 System Implementation:
o Object diagrams provide a practical representation of specific instances of
classes, aiding in the implementation phase. Object diagrams help developers
when they are building the actual software. These diagrams show real examples
of things (objects) in the system and how they work together.
 Communication and Collaboration:
o Similar to class diagrams, object diagrams serve as a communication tool among
stakeholders. They facilitate discussions about the relationships and interactions
between specific objects at a particular moment, promoting a shared
understanding among team members.
 Test Case Design:
o Testers use object diagrams to design test cases based on the relationships and
behaviors of specific instances. This helps ensure thorough testing of object
interactions in the system.
 Debugging and Troubleshooting:
o During the debugging process, object diagrams can be valuable for
understanding the state of specific objects at a particular point in time. This aids
developers in identifying and resolving issues related to object interactions.
 Training and Documentation:
o Object diagrams can be used for training purposes, helping new team members
understand the structure and behavior of specific instances in the system. They
also contribute to documentation by providing visual representations of object
relationships.
Use Case Diagram - Unified Modeling Language (UML)

A Use Case Diagram in Unified Modeling Language (UML) is a visual representation that
illustrates the interactions between users (actors) and a system. It captures the functional
requirements of a system, showing how different users engage with various use cases, or specific
functionalities, within the system. Use case diagrams provide a high-level overview of a
system’s behavior, making them useful for stakeholders, developers, and analysts to understand
how a system is intended to operate from the user’s perspective, and how different processes
relate to one another. They are crucial for defining system scope and requirements.

What is a Use Case Diagram in UML?

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that represents the
interaction between actors (users or external systems) and a system under consideration to
accomplish specific goals. It provides a high-level view of the system's functionality by
illustrating the various ways users can interact with it.
When to apply Use Case Diagram?
Use case diagrams are useful in several situations. Here’s when you should consider using them:
 When you need to gather and clarify user requirements, use case diagrams help visualize how
different users interact with the system.
 If you’re working with diverse groups, including non-technical stakeholders, these diagrams
provide a clear and simple way to convey system functionality.
 During the system design phase, use case diagrams help outline user interactions and plan
features, ensuring that the design aligns with user needs.
 When defining what is included in the system versus what is external, use case diagrams help
clarify these boundaries.
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and other
stakeholders to communicate and document system designs, architectures, and behaviors in a
consistent and understandable manner.
1. Actors
Actors are external entities that interact with the system. These can include users, other systems,
or hardware devices. In the context of a Use Case Diagram, actors initiate use cases and receive
the outcomes. Proper identification and understanding of actors are crucial for accurately
modeling system behavior.

2. Use Cases
Use cases are like scenes in the play. They represent specific things your system can do. In the
online shopping system, examples of use cases could be "Place Order," "Track Delivery," or
"Update Product Information". Use cases are represented by ovals.

3. System Boundary
The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that are
external to it. The system boundary is typically represented by a rectangular box that surrounds
all the use cases of the system.
The purpose of system boundary is to clearly outlines the boundaries of the system, indicating
which components are internal to the system and which are external actors or entities interacting
with the system.

Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions between
actors and use cases. These relationships provide a comprehensive view of the system's
functionality and its various scenarios. Let's delve into the key types of relationships and explore
examples to illustrate their usage.
1. Association Relationship
The Association Relationship represents a communication or interaction between an actor and a
use case. It is depicted by a line connecting the actor to the use case. This relationship signifies
that the actor is involved in the functionality described by the use case.
Example: Online Banking System
 Actor: Customer
 Use Case: Transfer Funds
 Association: A line connecting the "Customer" actor to the "Transfer Funds" use case,
indicating the customer's involvement in the funds transfer process.

2. Include Relationship
The Include Relationship indicates that a use case includes the functionality of another use case.
It is denoted by a dashed arrow pointing from the including use case to the included use case.
This relationship promotes modular and reusable design.
Example: Social Media Posting
 Use Cases: Compose Post, Add Image
 Include Relationship: The "Compose Post" use case includes the functionality of "Add
Image." Therefore, composing a post includes the action of adding an image.
3. Extend Relationship
The Extend Relationship illustrates that a use case can be extended by another use case under
specific conditions. It is represented by a dashed arrow with the keyword "extend." This
relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
 Use Cases: Book Flight, Select Seat
 Extend Relationship: The "Select Seat" use case may extend the "Book Flight" use case
when the user wants to choose a specific seat, but it is an optional step.

4. Generalization Relationship
The Generalization Relationship establishes an "is-a" connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an arrow
pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
 Use Cases: Rent Car, Rent Bike
 Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized versions of
the general use case "Rent Vehicle."

Generalization Relationship

How to draw a Use Case diagram in UML?

Below are the main steps to draw use case diagram in UML:
 Step 1: Identify Actors: Determine who or what interacts with the system. These are your
actors. They can be users, other systems, or external entities.
 Step 2: Identify Use Cases: Identify the main functionalities or actions the system must
perform. These are your use cases. Each use case should represent a specific piece of
functionality.
 Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors and the
use cases they are involved in. This represents the interactions between actors and the
system.
 Step 4: Add System Boundary: Draw a box around the actors and use cases to represent the
system boundary. This defines the scope of your system.
 Step 5: Define Relationships: If certain use cases are related or if one use case is an
extension of another, you can indicate these relationships with appropriate notations.
 Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately
represents the interactions and relationships in your system. Refine as needed.
 Step 7: Validate: Share your use case diagram with stakeholders and gather feedback.
Ensure that it aligns with their understanding of the system's functionality.
Use Case Diagram example(Online Shopping System)
Let's understand how to draw a Use Case diagram with the help of an Online Shopping System:
 Actors:
o Customer
o Admin
 Use Cases:
 o Browse Products
o Add to Cart
o Checkout
o Manage Inventory (Admin)
 Relations:
o The Customer can browse products, add to the cart, and complete the checkout.
o The Admin can manage the inventory.
Below is the use case diagram of an Online Shopping System:

What are common Use Case Diagram Tools and Platforms?

Several tools and platforms are available to create and design Use Case Diagrams. These tools
offer features that simplify the diagram creation process, facilitate collaboration among team
members, and enhance overall efficiency. Here are some popular Use Case Diagram tools and
platforms:
 Lucidchart:
o Cloud-based collaborative platform.

o Real-time collaboration and commenting.
o Templates for various diagram types.
 draw.io:
o Free, open-source diagramming tool.
o Works offline and can be integrated with Google Drive, Dropbox, and others.
o Offers a wide range of diagram types, including Use Case Diagrams.
 Microsoft Visio:
o Part of the Microsoft Office suite.
o Supports various diagram types, including Use Case Diagrams.

o Extensive shape libraries and templates.
 SmartDraw:
o User-friendly diagramming tool.
o Templates for different types of diagrams, including Use Case Diagrams.
o Integration with Microsoft Office and Google Workspace.
 PlantUML:
o Open-source tool for creating UML diagrams.
o Text-based syntax for diagram specification.
o Supports collaborative work using version control systems.
What are Common Mistakes while making Use Case Diagram?
Avoiding common mistakes ensures the accuracy and effectiveness of the Use Case Diagram.
Here are key points for each mistake:
 Adding too much detail can confuse people.
 Unclear connections lead to misunderstandings about system interactions.
 Different names for the same elements create confusion.
 Incorrectly using generalization can misrepresent relationships.
 Failing to define the system’s limits makes its scope unclear.
 Treating the diagram as static can make it outdated and inaccurate.
Best Practices for Use Case Diagram
Crafting clear and effective Use Case Diagrams is essential for conveying system functionality
and interactions. Here are some best practices to consider:
 Use Case Diagram focus on capturing the core functions of the system, avoiding extraneous
details.
 They uses a uniform naming scheme for use cases and actors throughout the diagram to
enhance clarity and prevent misunderstandings.
 They ensure uniformity in the appearance of elements such as ovals (for use cases), stick
figures (for actors), and connecting lines to create a polished presentation.
 They help in organizing use cases into coherent groups that represent distinct modules or
subsystems within the overall system.
 Use Case Diagrams adopt an iterative method, updating the diagram as the system changes or
as new information emerges.

What is the Purpose and Benefits of Use Case Diagrams?

The Use Case Diagram offers numerous benefits throughout the system development process.
Here are some key advantages of using Use Case Diagrams:
 Use Case Diagrams offer a clear visual representation of a system’s functions and its
interactions with external users. This representation helps stakeholders, including those
without technical expertise, in grasping the system’s overall behavior.
 They establish a shared language for articulating system requirements, ensuring that all team
members have a common understanding.
 Use Case Diagram illustrate the different ways users engage with the system, contributing to
a thorough comprehension of its functionalities.
 In the design phase, Use Case Diagrams help outline how users (actors) will interact with the
system. They support the planning of user interfaces and aid in structuring system
functionalities.

Class Diagram | Unified Modeling Language (UML)

A UML class diagram is a visual tool that represents the structure of a system by showing its
classes, attributes, methods, and the relationships between them. It helps everyone involved in
a project—like developers and designers—understand how the system is organized and how its
components interact.
What are class Diagrams?
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system i.e.
used to construct and visualize object-oriented systems.
In these diagrams, classes are depicted as boxes, each containing three compartments for the
class name, attributes, and methods. Lines connecting classes illustrate associations, showing
relationships such as one-to-one or one-to-many.
Class diagrams provide a high-level overview of a system’s design, helping to communicate
and document the structure of the software. They are a fundamental tool in object-oriented
design and play a crucial role in the software development lifecycle.

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

1. Class Name:
 The name of the class is typically written in the top compartment of the class box and is
centered and bold.
2. Attributes:
 Attributes, also known as properties or fields, represent the data members of the class.
They are listed in the second compartment of the class box and often include the
visibility (e.g., public, private) and the data type of each attribute.
3. Methods:
 Methods, also known as functions or operations, represent the behavior or functionality
of the class. They are listed in the third compartment of the class box and include the
visibility (e.g., public, private), return type, and parameters of each method.
4. Visibility Notation:
 Visibility notations indicate the access level of attributes and methods. Common
visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
 o ~ for package or default visibility (visible to classes in the same package)
Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an
input, an output, or both. This information is crucial for understanding how data is passed
between objects during method calls.

There are three main parameter directionality notations used in class diagrams:
 In (Input):
o An input parameter is a parameter passed from the calling object (client) to the
called object (server) during a method invocation.
o It is represented by an arrow pointing towards the receiving class (the class that
owns the method).
 Out (Output):
o An output parameter is a parameter passed from the called object (server) back
to the calling object (client) after the method execution.
o It is represented by an arrow pointing away from the receiving class.
 InOut (Input and Output):
o An InOut parameter serves as both input and output. It carries information from
the calling object to the called object and vice versa.
o It is represented by an arrow pointing towards and away from the receiving
class.
Relationships between classes
In class diagrams, relationships between classes describe how classes are connected or interact
with each other within a system. There are several types of relationships in object-oriented
modeling, each serving a specific purpose. Here are some common types of relationships in
class diagrams:
1. Association
An association represents a bi-directional relationship between two classes. It indicates that
instances of one class are connected to instances of another class. Associations are typically
depicted as a solid line connecting the classes, with optional arrows indicating the direction of
the relationship.
Let’s understand association using an example:
Let’s consider a simple system for managing a library. In this system, we have two main
entities: Book and Library. Each Library contains multiple Books, and each Book belongs to a
specific Library. This relationship between Library and Book represents an association.
The “Library” class can be considered the source class because it contains a reference to
multiple instances of the “Book” class. The “Book” class would be considered the target class
because it belongs to a specific library.

2. Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in a
specific way.
 In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the association to
the class that is being targeted or affected by the association.
 Directed associations are used when the association has a specific flow or directionality,
such as indicating which class is responsible for initiating the association or which class
has a dependency on another.
Consider a scenario where a “Teacher” class is associated with a “Course” class in a
university system. The directed association arrow may point from the “Teacher” class to the
“Course” class, indicating that a teacher is associated with or teaches a specific course.
 The source class is the “Teacher” class. The “Teacher” class initiates the association by
teaching a specific course.
 The target class is the “Course” class. The “Course” class is affected by the association as
it is being taught by a specific teacher.

3. Aggregation
Aggregation is a specialized form of association that represents a “whole-part” relationship. It
denotes a stronger relationship where one class (the whole) contains or is composed of another
class (the part). Aggregation is represented by a diamond shape on the side of the whole class.
In this kind of relationship, the child class can exist independently of its parent class.
Let’s understand aggregation using an example:
The company can be considered as the whole, while the employees are the parts. Employees
belong to the company, and the company can have multiple employees. However, if the
company ceases to exist, the employees can still exist independently.
4. Composition
Composition is a stronger form of aggregation, indicating a more significant ownership or
dependency relationship. In composition, the part class cannot exist independently of the whole
class. Composition is represented by a filled diamond shape on the side of the whole class.
Let’s understand Composition using an example:
Imagine a digital contact book application. The contact book is the whole, and each contact
entry is a part. Each contact entry is fully owned and managed by the contact book. If the
contact book is deleted or destroyed, all associated contact entries are also removed.
This illustrates composition because the existence of the contact entries depends entirely on the
presence of the contact book. Without the contact book, the individual contact entries lose their
meaning and cannot exist on their own.

5. Generalization(Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class (the subclass or
child) inherits the properties and behaviors of another class (the superclass or parent).
Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from the
subclass to the superclass.
In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.
The Bank Account class serves as the generalized representation of all types of bank accounts,
while the subclasses (Current Account, Savings Account, Credit Account) represent
specialized versions that inherit and extend the functionality of the base class.

6. Realization (Interface Implementation)

Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface. Realization is depicted by a
dashed line with an open arrowhead pointing from the implementing class to the interface.
Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner”
interface.
 Owner Interface: This interface now includes methods such as “acquire(property)” and
“dispose(property)” to represent actions related to acquiring and disposing of property.
 Person Class (Realization): The Person class implements the Owner interface, providing
concrete implementations for the “acquire(property)” and “dispose(property)” methods. For
instance, a person can acquire ownership of a house or dispose of a car.
 Corporation Class (Realization): Similarly, the Corporation class also implements the
Owner interface, offering specific implementations for the “acquire(property)” and
“dispose(property)” methods. For example, a corporation can acquire ownership of real
estate properties or dispose of company vehicles.
Both the Person and Corporation classes realize the Owner interface, meaning they provide
concrete implementations for the “acquire(property)” and “dispose(property)” methods
defined in the interface.

7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the relationship
is not as strong as association or inheritance. It represents a more loosely coupled connection
between classes. Dependencies are often depicted as a dashed arrow.
Let’s consider a scenario where a Person depends on a Book.
 Person Class: Represents an individual who reads a book. The Person class depends on the
Book class to access and read the content.
 Book Class: Represents a book that contains content to be read by a person. The Book
class is independent and can exist without the Person class.
The Person class depends on the Book class because it requires access to a book to read its
content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.

8. Usage(Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one class (the client)
utilizes or depends on another class (the supplier) to perform certain tasks or access certain
functionality. The client class relies on the services provided by the supplier class but does not
own or create instances of it.
 In UML class diagrams, usage dependencies are typically represented by a dashed arrowed
line pointing from the client class to the supplier class.
 The arrow indicates the direction of the dependency, showing that the client class depends
on the services provided by the supplier class.
Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.
 The “Car” class may need to access methods or attributes of the “FuelTank” class to check
the fuel level, refill fuel, or monitor fuel consumption.
 In this case, the “Car” class has a usage dependency on the “FuelTank” class because it
utilizes its services to perform certain tasks related to fuel management.

Purpose of Class Diagrams

The main purpose of using class diagrams is:
 This is the only UML that can appropriately depict various aspects of the OOPs concept.
 Proper design and analysis of applications can be faster and efficient.
 It is the base for deployment and component diagram.
 It incorporates forward and reverse engineering.
Benefits of Class Diagrams
Below are the benefits of class diagrams:
 Class diagrams represent the system’s classes, attributes, methods, and relationships,
providing a clear view of its architecture.
 They shows various relationships between classes, such as associations and inheritance,
helping stakeholders understand component connectivity.
 Class diagrams serve as a visual tool for communication among team members and
stakeholders, bridging gaps between technical and non-technical audiences.
 They guide developers in coding by illustrating the design, ensuring consistency between
the design and actual implementation.
 Many development tools allow for code generation from class diagrams, reducing manual
errors and saving time.
How to draw Class Diagrams
Drawing class diagrams involves visualizing the structure of a system, including classes, their
attributes, methods, and relationships. Here are the steps to draw class diagrams:
 Step 1: Identify Classes:
o Start by identifying the classes in your system. A class represents a blueprint for
objects and should encapsulate related attributes and methods.
 Step 2: List Attributes and Methods:
o For each class, list its attributes (properties, fields) and methods (functions,
operations). Include information such as data types and visibility (public,
private, protected).
 Step 3: Identify Relationships:
o Determine the relationships between classes. Common relationships include
associations, aggregations, compositions, inheritance, and dependencies.
Understand the nature and multiplicity of these relationships.
 Step 4: Create Class Boxes:
o Draw a rectangle (class box) for each class identified. Place the class name in
the top compartment of the box. Divide the box into compartments for attributes
and methods.
 Step 5: Add Attributes and Methods:
o Inside each class box, list the attributes and methods in their respective
compartments. Use visibility notations (+ for public, – for private, # for
protected, ~ for package/default).
 Step 6: Draw Relationships:
o Draw lines to represent relationships between classes. Use arrows to indicate the
direction of associations or dependencies. Different line types or notations may
be used for various relationships.
 Step 7: Label Relationships:
 o Label the relationships with multiplicity and role names if needed. Multiplicity
indicates the number of instances involved in the relationship, and role names
clarify the role of each class in the relationship.
 Step 8: Review and Refine:
o Review your class diagram to ensure it accurately represents the system’s
structure and relationships. Refine the diagram as needed based on feedback and
requirements.
Use cases of Class Diagrams
Below are the use cases of class diagrams:
 Class diagrams shows the static structure of a software system, showcasing classes,
attributes, methods, and relationships.
 They help visualize and organize the components of the system, serving as a blueprint for
implementation.
 They encourage discussions about the system’s design, promoting a shared understanding
among team members.
 Many development tools support code generation from class diagrams, enabling developers
to create code skeletons efficiently.
 This capability minimizes manual coding efforts and helps ensure that the implementation
aligns with the design.

Interaction Overview Diagrams | Unified Modeling Language (UML)

Interaction Overview Diagrams (IODs) in UML (Unified Modeling Language) provide a high-
level view of the interactions between various components or objects in a system. They are used
to visualize the flow of control and interactions within a system, showing how different parts of
the system communicate and collaborate to achieve a specific goal.

What are Interaction Overview Diagrams?

An Interaction Overview Diagram (IOD) is a type of UML (Unified Modeling Language)
diagram that illustrates the flow of interactions between various elements in a system or process.
It provides a high-level overview of how interactions occur, including the sequence of actions,
decisions, and interactions between different components or objects.
 Interaction diagrams give a general overview of system behavior that stakeholders can
understand without getting bogged down in specifics.
 They help with requirements analysis, documentation, communication, and system design.
Overall, they enable stakeholders to comprehend complicated systems and make educated
decisions.
Notations for Interaction Overview Diagram
Annotations and explanations from the Interaction Overview UML diagrams feature several
fundamental components that help to show control flow and system interactions. Here's a
detailed explanation of these notations:
1. Initial Node
Represents the starting point of the interaction. It is shown as a small solid circle with a single
outgoing control flow arrow.

2. Interaction Use
An Interaction Use is used to represent a reference to another interaction or sequence of
interactions defined in another diagram or part of the system.An Interaction Use is represented
by a rectangular box . Inside the box, you can include a label that specifies the name or reference
of the interaction being used.

3. Interaction Fragment
Interaction fragments are used to group and organize interactions within the diagram.

4. Object Lifeline
Represents the lifespan of an object during the interaction. It is a vertical dashed line that extends
from the top of the diagram to the Bottom, with the object's name or class at the top.

5. Message
Represents communication between objects or components in the system. Messages are shown
as arrows between lifelines, indicating the direction of communication.

6. Control Flow
Represents the flow of control or sequence of actions in the interaction. It is shown as a solid
arrow between elements in the diagram, indicating the order in which actions are performed.

7. Fork Node/Join Node

Represents a point in the interaction where multiple parallel actions can occur simultaneously. It
is shown as a solid rectangle with multiple outgoing control flow arrows in case of Fork Node
and ingoing control flow arrows in case of Join Node.

8. Decision Node
Represents a point in the interaction where a decision is made based on a condition. It is shown
as a small diamond shape with incoming and outgoing control flow arrows representing different
paths based on the decision.
9. Receive Signal Node
Represents the receipt of a signal or event during the interaction. It is shown as a small rectangle
with an incoming control flow arrow.

10. Final Node

Represents the ending point of the interaction. It is shown as a small solid circle with no
outgoing control flow arrows.

11. Note
Represents additional information or comments about the diagram. Notes are shown as a small
rectangle with a label indicating the content of the note.

Example of Interaction Overview Diagram

1. Online shopping interaction overview diagram
Let's understand interaction overview diagram using an example of online shopping system:
Think about an internet-based shopping platform. The flow of control between different
interactions, including logging in, viewing products, adding items to the basket, and checking
out, may be displayed in the interaction overview diagram. While fragments might depict
concurrent operations like managing inventory updates and creating invoices, decision nodes
could stand in for activities like selecting payment options.
 Purpose: The goal is to provide an online shopping UML interaction overview diagram
example.
 Summary: The consumer can explore or search the inventory, add or delete goods from their
cart, and complete the checkout process.

2. Student Admission Interaction Overview Diagram

Let's understand interaction overview diagram using Student Admission System :
The below example illustrates the admission process for a student who has been accepted into a
university. Initially, the student is required to either accept or decline the admission offer. Upon
acceptance, the student must proceed to register for classes and apply for housing. Once these
steps are completed, the student is then required to make payment to the registrar. Failure to
submit payment on time will result in the student being excluded by the registrar.
Benefits of Interaction Overview Diagram
 Clarity and Comprehension: By providing a clear visual representation of the control flow
of the system, these diagrams help stakeholders quickly grasp complicated systems.
 Simplification: Simplifying complicated systems by displaying interactions at a higher level
helps stakeholders understand them better and lessens their cognitive burden.
 Effective Communication: Overview of Interactions in Effective Communication Diagrams
improve collaboration and alignment among stakeholders by offering a comprehensive
understanding of system behavior.
 Analysis and Optimization: By allowing analysts to spot faults, inefficiencies, or
bottlenecks in the control flow, they can help stakeholders maximize the dependability and
performance of the system.
 Support for Design Decisions: By giving a high-level overview of system behavior and
dependencies, these diagrams help with well-informed design and architecture decisions.
 Change Management: Overview of Interaction Diagrams enhance effective change
management by assisting in anticipating the effects of changes to the system's control flow
and reducing risks during updates or revisions.
How to Draw Interaction Overview Diagram
Below are the steps to draw interaction overview diagram:
Step 1: Identify Interactions
Identify the interactions between different elements in your system or process that you want to
represent in the diagram. These interactions can include method calls, message exchanges, and
other types of communication.
Step 2: Identify Fragments
Determine the types of fragments you will need to use to represent the interactions. This includes
identifying loops, alternatives, options, and parallel sequences in the interactions.
Step 3: Create Lifelines
Draw vertical dashed lines (lifelines) for each object or component involved in the interactions.
Label each lifeline with the name or class of the object.
Step 4: Add Messages
Use arrows to represent messages between lifelines, indicating the flow of communication
between objects. Label the arrows with the type of message (synchronous, asynchronous, return).
Step 5: Add Fragments
Use rectangular boxes to represent fragments, such as combined fragments, interaction operands,
or interaction uses. Label each fragment with the type of fragment or the interaction being
referenced.
Step 6: Connect Fragments
Use control flow arrows to connect fragments and elements in the diagram, indicating the flow of
control between them. Use solid arrows for regular control flow and dashed arrows for exception
flow.
Step 7: Add Control Nodes
Use small circles to represent control nodes, such as decision nodes, fork nodes, initial nodes,
and final nodes. Place them at appropriate points in the diagram to indicate decisions, parallel
actions, and the start and end of the interaction.
Step 8: Review and Validate
Review the diagram to ensure that it accurately represents the interactions and behavior of the
system. Validate the diagram against the requirements and specifications of the system to ensure
correctness.
Step 9: Refine and Iterate
If necessary, refine the diagram based on feedback and further analysis. Iterate on the diagram
until you have a clear and accurate representation of the interactions in the system.
Use Cases of Interaction Overview Diagrams
 System Design:
o Overview of Interaction in System Design Diagrams give a thorough
understanding of the control flow, making them fundamental tools in system
design.
o They provide a clear understanding of how various components interact and
function inside the system, which helps designers conceptualize and architect
complex systems.
 Requirements Analysis:
o Analyzing and verifying system requirements is a critical function of these
diagrams in requirements analysis.
o Stakeholders may guarantee that system requirements are appropriately identified
and appropriately captured by providing an overview of interactions.
o This will help to create systems that satisfy user expectations and demands.
 Documentation:
o Overview of Interactions in Documentation Diagrams are very useful tools for
recording the architecture and behavior of systems.
o Developers, architects, and stakeholders can more easily comprehend and refer to
system behavior thanks to the visual representation of interactions and control
flow that they offer.
o This promotes more efficient communication and teamwork throughout the
project lifecycle.
 Testing:
o Interaction Overview Diagrams are essential for creating test cases and
comprehending system behavior during the testing stages.
o These diagrams can be used by testers to specify test scenarios, pinpoint crucial
interactions, and guarantee extensive test coverage, which will enhance system
reliability and result in more efficient and effective testing procedures.
Software/Applications to make Interaction Overview Diagrams
The following programs and software tools can be used to create Interaction Overview
Diagrams:
1. Enterprise Architect
2. Lucidchart
3. Visual Paradigm
4. Draw.io
5. Microsoft Visio
6. Creately
7. Gliffy
8. PlantUML
9. Edraw Max
10. SmartDraw
Conclusion
Interaction overview diagrams are crucial parts of the UML toolkit that provide a broad
perspective on system activities. Their proficiency in simplifying intricate relationships into a
broad overview renders them important in several facets of system conception, evaluation, and
record-keeping. These diagrams are essential for improving stakeholder understanding and
collaboration because they highlight complex relationships and allow for efficient
communication.

Activity Diagrams – Unified Modeling Language (UML)

Activity diagrams are an essential part of the Unified Modeling Language (UML) that help
visualize workflows, processes, or activities within a system. They depict how different actions
are connected and how a system moves from one state to another. By offering a clear picture of
both simple and complex workflows, activity diagrams make it easier for developers and
stakeholders to understand how various elements interact in a system.

What is an Activity Diagram?

Activity diagrams show the steps involved in how a system works, helping us understand the
flow of control. They display the order in which activities happen and whether they occur one
after the other (sequential) or at the same time (concurrent). These diagrams help explain what
triggers certain actions or events in a system.
 An activity diagram starts from an initial point and ends at a final point, showing different
decision paths along the way.
 They are often used in business and process modeling to show how a system behaves over
time.
When to use Activity Diagram?
Activity diagrams are useful in several scenarios, especially when you need to visually represent
the flow of processes or behaviors in a system. Here are key situations when you should use an
activity diagram:
1. Modeling Workflows or Processes: When you need to map out a business process,
workflow, or the steps involved in a use case, activity diagrams help visualize the flow of
activities.
2. Concurrent or Parallel Processing: If your system or process involves activities happening
simultaneously, an activity diagram can clearly show the parallel flow of tasks.
3. Understanding the Dynamic Behavior: When it’s essential to depict how a system changes
over time and moves between different states based on events or conditions, activity
diagrams are effective.
4. Clarifying Complex Logic: Use an activity diagram to simplify complex decision-making
processes with branching paths and different outcomes.
5. System Design and Analysis: During the design phase of a software system, activity
diagrams help developers and stakeholders understand how different parts of the system
interact dynamically.
6. Describing Use Cases: They are useful for illustrating the flow of control within a use case,
showing how various components of the system interact during its execution.
Activity Diagram Notations

In activity diagrams, the notations are like visual symbols that help represent different elements
and actions in a simple way.
1. Initial State
The starting state before an activity takes place is depicted using the initial state.
A process can have only one initial state unless we are depicting nested activities. We use a black
filled circle to depict the initial state of a system. For objects, this is the state when they are
instantiated. The Initial State from the UML Activity Diagram marks the entry point and the
initial Activity State.
For example:
Here the initial state of the system before the application is opened.

2. Action or Activity State

An activity represents execution of an action on objects or by objects. We represent an activity
using a rectangle with rounded corners. Basically any action or event that takes place is
represented using an activity.
 For example:
Consider the previous example of opening an application, opening the application is an activity
state in the activity diagram.

3. Action Flow or Control flows

Action flows or Control flows are also referred to as paths and edges. They are used to show the
transition from one activity state to another activity state.
An activity state can have multiple incoming and outgoing action flows. We use a line with an
arrow head to depict a Control Flow. If there is a constraint to be adhered to while making the
transition it is mentioned on the arrow.
For example:
Here both the states transit into one final state using action flow symbols i.e. arrows.

4. Decision node and Branching

When we need to make a decision before deciding the flow of control, we use the decision node.
The outgoing arrows from the decision node can be labelled with conditions or guard
expressions. It always includes two or more output arrows.
For example:
We apply the conditions on input number to display the result :
 If number is odd then display the number.
 If number if even then display the error.

5. Guard
A Guard refers to a statement written next to a decision node on an arrow sometimes within
square brackets.
The statement must be true for the control to shift along a particular direction. Guards help us
know the constraints and conditions which determine the flow of a process.
6. Fork
Fork nodes are used to support concurrent activities. When we use a fork node when both the
activities get executed concurrently i.e. no decision is made before splitting the activity into two
parts. Both parts need to be executed in case of a fork statement. We use a rounded solid
rectangular bar to represent a Fork notation with incoming arrow from the parent activity state
and outgoing arrows towards the newly created activities.

For example:
In the example below, the activity of making coffee can be split into two concurrent activities and
hence we use the fork notation.

7
. Join
Join nodes are used to support concurrent activities converging into one. For join notations we
have two or more incoming edges and one outgoing edge.

For example:
When both activities i.e. steaming the milk and adding coffee get completed, we converge them
into one final activity.

8. Merge or Merge Event

Scenarios arise when activities which are not being executed concurrently have to be merged.
We use the merge notation for such scenarios. We can merge two or more activities into one if
the control proceeds onto the next activity irrespective of the path chosen.
For example:
In the diagram below: we can’t have both sides executing concurrently, but they finally merge
into one. A number can’t be both odd and even at the same time.

9. Swimlanes
We use Swimlanes for grouping related activities in one column. Swimlanes group related
activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes are
used to add modularity to the activity diagram. It is not mandatory to use swimlanes. They
usually give more clarity to the activity diagram. It’s similar to creating a function in a program.
It’s not mandatory to do so, but, it is a recommended practice.
We use a rectangular column to represent a swimlane as shown in the figure above.
For example:
Here different set of activities are executed based on if the number is odd or even. These
activities are grouped into a swimlane.

10. Time Event

This refers to an event that stops the flow for a time; an hourglass depicts it. We can have a
scenario where an event takes some time to completed.
For example:
Let us assume that the processing of an image takes a lot of time. Then it can be represented as
shown below.

11. Final State or End State

The state which the system reaches when a particular process or activity ends is known as a Final
State or End State. We use a filled circle within a circle notation to represent the final state in a
state machine diagram. A system or a process can have multiple final states.

How to Draw an Activity Diagram in UML?

Below are the steps of how to draw the Activity Diagram in UML:
Step 1. Identify the Initial State and Final States:
 This is like setting the starting point and ending point of a journey.
 Identify where your process begins (initial state) and where it concludes (final states).
 For example, if you are modelling a process for making a cup of tea, the initial state could be
“No tea prepared,” and the final state could be “Tea ready.”
Step 2. Identify the Intermediate Activities Needed:
 Think of the steps or actions required to go from the starting point to the ending point.
 These are the activities or tasks that need to be performed.
 Continuing with the tea-making , intermediate activities could include “Boil water,” “Pour
tea into a cup”.
Step 3. Identify the Conditions or Constraints:
 Consider the conditions or circumstances that might influence the flow of your process.
 These are the factors that determine when you move from one activity to another.
 Using the tea-making scenario, a condition could be “Water is boiled,” which triggers the
transition to the next activity.
Step 4. Draw the Diagram with Appropriate Notations:
Now, represent the identified states, activities, and conditions visually using the appropriate
symbols and notations in an activity diagram. This diagram serves as a visual map of your
process, showing the flow from one state to another.
Activity Diagram Example
Here’s an example of an activity diagram that shows the process of making an online purchase:
Steps:
 Browse items on the website.
 Select products and add them to the cart.
 Proceed to checkout.
 Enter shipping details.
 Select payment method.
o If the payment is successful, the order is confirmed, and a receipt is generated.
o If the payment fails, the user is prompted to try again.
 End process.
What are the Differences between an Activity diagram and a Flowchart?
An activity diagram is very similar to a flowchart. So let us understand if activity diagrams or
flowcharts are any different.
What is a Flow Chart?
An algorithm is like a set of clear instructions to solve a problem, and a flowchart is a picture
that shows those instructions.
 When we’re writing computer programs, a flowchart helps us map out the steps of the
algorithm to solve the problem.
 Non programmers use Flow charts to model workflows.
 We can call a flowchart a primitive version of an activity diagram.
 Business processes where decision making is involved is expressed using a flow chart.
Example:
A manufacturer uses a flow chart to explain and illustrate how a particular product is
manufactured.
Aspect Activity Diagram Flowchart

Represents the flow of control in a Depicts the step-by-step flow of a

system or process, focusing on process or algorithm, focusing on
Purpose activities and conditions. operations.

Primarily used in software and Commonly used in various fields

systems modeling, especially in like programming, business, and
Used In UML (Unified Modeling Language). process mapping.

Can represent both simple and Typically used for simpler, linear
complex workflows, including processes, though can handle
Complexity concurrent processing. limited complexity.

Uses UML symbols like initial Uses basic symbols like rectangles
nodes, activity nodes, decisions, (process), diamonds (decisions),
Symbols swimlanes, etc. and arrows (flow).

Does not support parallel

Supports concurrent activities and
Concurrency processes explicitly; focuses on
parallel flows.
Representation sequential flow.

Do we need to use both the diagrams and the textual documentation?

Let’s understand this with the help of an example:
 Different individuals have different preferences in which they understand something.
 To understand a concept, some people might prefer a written tutorial with images while
others would prefer a video lecture.
 So we generally use both the diagram and the textual documentation to make our system
description as clear as possible.
tate Machine Diagrams | Unified Modeling Language (UML)

A State Machine Diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents the behavior using
finite state transitions. In this article, we will explain what is a state machine diagram, the
components, and the use cases of the state machine diagram.

What is a State Machine Diagram?

A state diagram is a uml diagram which is used to represent the condition of the system or part of
the system at finite instances of time. It’s a behavioral diagram and it represents the behavior
using finite state transitions.
 State Machine diagrams are also known as State Diagrams and State-Chart Diagrams. These
both terms can be used interchangeably.
 A state machine diagram is used to model the dynamic behavior of a class in response to time
and changing external stimuli( eventS that causes system to changes its state from one to
another).
 We can say that each and every class has a state but we don’t model every class using State
Machine diagrams.
Let’s understand State Machine Diagram with the help user verification example:
Example:

The State Machine Diagram above shows the different states in which the verification sub-system
or class exist for a particular system.
Basic components and notations of a State Machine diagram
Below are the basic components and their notations of a State Machine Diagram:
1. Initial state
We use a black filled circle represent the initial state of a System or a Class.

2. Transition
We use a solid arrow to represent the transition or change of control from one state to another.
The arrow is labelled with the event which causes the change in state.

3. State
We use a rounded rectangle to represent a state. A state represents the conditions or
circumstances of an object of a class at an instant of time.
4. Fork
We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from
the parent state and outgoing arrows towards the newly created states. We use the fork notation
to represent a state splitting into two or more concurrent states.

5. Join
We use a rounded solid rectangular bar to represent a Join notation with incoming arrows from
the joining states and outgoing arrow towards the common goal state. We use the join notation
when two or more states concurrently converge into one on the occurrence of an event or events.
6. Self transition
We use a solid arrow pointing back to the state itself to represent a self transition. There might be
scenarios when the state of the object does not change upon the occurrence of an event. We use
self transitions to represent such cases.

7. Composite state
We use a rounded rectangle to represent a composite state also. We represent a state with internal
activities using a composite state.
8. Final State
We use a filled circle within a circle notation to represent the final state in a state machine
diagram.

How to draw a State Machine diagram in UML?

Below are the steps of how to draw the State Machine Diagram in UML:
Step1. Identify the System:
 Understand what your diagram is representing.
 Whether it’s a machine, a process, or any object, know what different situations or conditions
it might go through.
Step2. Identify Initial and Final States:
 Figure out where your system starts (initial state) and where it ends (final state).
 These are like the beginning and the end points of your system’s journey.
Step3. Identify Possible States:
 Think about all the different situations your system can be in.
 These are like the various phases or conditions it experiences.
 Use boundary values to guide you in defining these states.
Step4. Label Triggering Events:
 Understand what causes your system to move from one state to another.
 These causes or conditions are the events.
 Label each transition with what makes it happen.
Step5. Draw the Diagram with appropriate notations:
 Now, take all this information and draw it out.
 Use rectangles for states, arrows for transitions, and circles or rounded rectangles for initial
and final states.
 Be sure to connect everything in a way that makes sense.
Let’s understand State Machine diagram with the help of an example, ie for an online order :

The UML diagrams we draw depend on the system we aim to represent. Here is just an example
of how an online ordering system might look like :
 On the event of an order being received, we transit from our initial state to Unprocessed
order state.
 The unprocessed order is then checked.
 If the order is rejected, we transit to the Rejected Order state.
 If the order is accepted and we have the items available we transit to the fulfilled order state.
 However if the items are not available we transit to the Pending Order state.
 After the order is fulfilled, we transit to the final state. In this example, we merge the two
states i.e. Fulfilled order and Rejected order into one final state.
Note: Here we could have also treated fulfilled order and rejected order as final states
separately.
Applications of State Machine Diagram
Below are the main use cases of state machine diagram:
 State Machine Diagrams are very useful for modeling and visualizing the dynamic behavior
of a system.
 They are also used in UI design where they help to illustrate how the interface changes in
response to user actions, helping designers to create a better use experience.
 In game design, state machine diagrams can help model the behavior of characters or objects,
detailing how they change states based on player interactions or game events
 In embedded systems, where hardware interacts with software to perform tasks, State
Machine Diagrams are valuable for representing the control logic and behavior of the system.
What are the Differences between a State Machine Diagram and a Flowchart?
Before understanding the differences between a state machine diagram and a flowchart, firstly
understand what is a flowchart:
What is a Flowchart?
An algorithm is like a set of clear instructions to solve a problem, and a flowchart is a picture
that shows those instructions.
 When we’re writing computer programs, a flowchart helps us map out the steps of the
algorithm to solve the problem.
 Non programmers use Flow charts to model workflows.
 We can call a flowchart a primitive version of an activity diagram.
 Business processes where decision making is involved is expressed using a flow chart.
Example:
A manufacturer uses a flow chart to explain and illustrate how a particular product is
manufactured.
State Machine Diagram vs. Flow Chart?
Below are the main differences between a state machine diagram and a flowchart:
State Machine Diagram Flow Chart

An State Machine Diagram is associated with A Flow Chart is associated with the
the UML(Unified Modelling Language) programming.

The basic purpose of a state machine diagram A flowchart on the other hand portrays the
is to portray various changes in state of the processes or commands that on execution
class and not the processes or commands change the state of class or an object of the
causing the changes. class.

Primarily used for systems, emphasizing their Often used for processes, procedures, or
states and transitions. algorithms involving actions and decisions.

Functional Modelling in object oriented analysis and design

Functional Modelling:
 A functional model of a system specifies how the output values are computed in the system
from the input values, without considering the control aspects of the computation.
 This represents the functional view of the system – the mapping from inputs to outputs and
the various steps involved in the mapping.
 The functional model of a system can be represented by a data flow diagram(DFD).
 As processes represent operations and in an object – oriented system, most of the processing
is done by operations on classes, all processes should show up as operations on classes.
provides the outline that what the system is supposed to do .It does not describes what is the need
of evaluation of data, when they are evaluated and how they are evaluated apart from all it only
represent origin of data values. It describes the function of internal processes with the help of
DFD.
DFD (Data Flow Diagram)
. Data Flow Diagrams: Function modelling is represented with the help of DFDs. DFD is the
graphically representation of data. It shows the input, output and processing of the system .When
we are trying to create our own business, website, system, project then there is need to find out
how information passes from one process to another so all are done by DFD. There are number
of levels in DFD but upto third level DFD is sufficient for understanding of any system. The
basic components of the DFD are:
1. External Entity : External entity is the entity that takes information and gives information to
the system. It is represented with rectangle.
2. Data Flow : The data passes from one place to another is shown by data flow. Data flow is
represented with arrow and some information written over it.
3. Process : It is also called function symbol .It is used to process all the information .If there
are calculations so all are done in the process part .It is represented with circle and name of
the process and level of DFD written inside it.
4. Data Store : It is used to store the information and retrieve the stored information .It is
represented with double parallel lines.
Some Guidelines for creating a DFD:
1. Every process must have meaningful name and number.
2. Level 0 DFD must have only one process.
3. Every data flow and arrow has given the name.
4. DFD should be logical consistent.
5. DFD should be organised in such a way that it is easy to understand.
6. There should be no loop in the DFD.
7. Each DFD should not have more than 6 processes.
8. The process can only connected with process, external entity and data store.
9. External entity cannot be directly connected with external entity.
10. The direction of DFD is left to right and top to bottom representation.

What is DFD(Data Flow Diagram)?

Data Flow Diagram (DFD) represents the flow of data within information systems. Data Flow
Diagrams (DFD) provide a graphical representation of the data flow of a system that can be
understood by both technical and non-technical users. The models enable software engineers,
customers, and users to work together effectively during the analysis and specification of
requirements.

What is Data Flow Diagram (DFD)?

DFD is the abbreviation for Data Flow Diagram. The flow of data in a system or
process is represented by a Data Flow Diagram (DFD). It also gives insight into the inputs and
outputs of each entity and the process itself. Data Flow Diagram (DFD) does not have a control
flow and no loops or decision rules are present. Specific operations, depending on the type of
data, can be explained by a flowchart. It is a graphical tool, useful for communicating with users,
managers and other personnel. it is useful for analyzing existing as well as proposed systems.
It should be pointed out that a DFD is not a flowchart. In drawing the DFD, the designer has to
specify the major transforms in the path of the data flowing from the input to the output. DFDs
can be hierarchically organized, which helps in progressively partitioning and analyzing large
systems.
It provides an overview of
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
Data Flow Diagram can be represented in several ways. The Data Flow Diagram (DFD) belongs
to structured-analysis modeling tools. Data Flow diagrams are very popular because they help us
to visualize the major steps and data involved in software-system processes.

Characteristics of Data Flow Diagram (DFD)

Below are some characteristics of Data Flow Diagram (DFD):
 Graphical Representation: Data Flow Diagram (DFD) use different symbols and notation
to represent data flow within system. That simplify the complex model.
 Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a system
and can be effectively used during analysis. Data Flow Diagram (DFDs) are quite general
and are not limited to problem analysis for software requirements specification.
 Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e. DFD
hides unnecessary implementation details and show only the flow of data and processes
within information system.
 Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level
diagram i.e. 0-level diagram provides an overview of entire system while lower-level
diagram like 1-level DFD and beyond provides a detailed data flow of individual process.
 Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the data flow
between external entity, processes and data store. Data Flow is represented by an arrow
Symbol.
 Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both
technical and non-technical stakeholders.
 Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks the
complex system into smaller module or processes. This provides easily analysis and design
of a system.
Types of Data Flow Diagram (DFD)
There are two types of Data Flow Diagram (DFD)
1. Logical Data Flow Diagram
2. Physical Data Flow Diagram
Logical Data Flow Diagram (DFD)
Logical data flow diagram mainly focuses on the system process. It illustrates how data flows in
the system. Logical Data Flow Diagram (DFD) mainly focuses on high level processes and data
flow without diving deep into technical implementation details. Logical DFD is used in various
organizations for the smooth running of system. Like in a Banking software system, it is used to
describe how data is moved from one entity to another.

Physical Data Flow Diagram

Physical data flow diagram shows how the data flow is actually implemented in the system. In
the Physical Data Flow Diagram (DFD), we include additional details such as data storage, data
transmission, and specific technology or system components. Physical DFD is more specific and
close to implementation.

Components of Data Flow Diagrams (DFD)

The Data Flow Diagram has 4 components:
 Process: Input to output transformation in a system takes place because of process function.
The symbols of a process are rectangular with rounded corners, oval, rectangle or a circle.
The process is named a short sentence, in one word or a phrase to express its essence
 Data Flow: Data flow describes the information transferring between different parts of the
systems. The arrow symbol is the symbol of data flow. A relatable name should be given to
the flow to determine the information which is being moved. Data flow also represents
material along with information that is being moved. Material shifts are modeled in systems
that are not merely informative. A given flow should only transfer a single type of
information. The direction of flow is represented by the arrow which can also be bi-
directional.
 Warehouse (Data Store) : The data is stored in the warehouse for later use. Two horizontal
lines represent the symbol of the store. The warehouse is simply not restricted to being a data
file rather it can be anything like a folder with documents, an optical disc, a filing cabinet.
The data warehouse can be viewed independent of its implementation. When the data flow
from the warehouse it is considered as data reading and when data flows to the warehouse it
is called data entry or data updating.
 Terminator (External Entity): The Terminator is an external entity that stands outside of
the system and communicates with the system. It can be, for example, organizations like
banks, groups of people like customers or different departments of the same organization,
which is not a part of the model system and is an external entity. Modeled systems also
communicate with terminator.

What symbols and notations are used to represent Components of DFD?

In Data-Flow Diagrams (DFDs), symbols and notations vary depending on the methodology
being used. Here’s a summary of symbols and notations commonly associated with each
methodology:
The different methodologies or approaches used for creating Data-Flow Diagrams (DFDs) are:
 Gane and Sarson
 Yourdon and De Marco
 SSADM
 UML
Each methodology provides its own set of guidelines, symbols, and notations for representing
system components and their interactions.

Levels of Data Flow Diagram (DFD)

Data Flow Diagram (DFD) uses hierarchy to maintain transparency thus multilevel Data Flow
Diagram (DFD’s) can be created. Levels of Data Flow Diagram (DFD) are as follows:

0-level DFD
It is also known as a context diagram. It’s designed to be an abstraction view, showing the
system as a single process with its relationship to external entities. It represents the entire system
as a single bubble with input and output data indicated by incoming/outgoing arrows.

1-Level DFD
This level provides a more detailed view of the system by breaking down the major processes
identified in the level 0 DFD into sub-processes. Each sub-process is depicted as a separate
process on the level 1 DFD. The data flows and data stores associated with each sub-process are
also shown. In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
In this level, we highlight the main functions of the system and breakdown the high-level process
of 0-level DFD into subprocesses.
2-level DFD
This level provides an even more detailed view of the system by breaking down the sub-
processes identified in the level 1 DFD into further sub-processes. Each sub-process is depicted
as a separate process on the level 2 DFD. The data flows and data stores associated with each
sub-process are also shown.
Rules for Data Flow Diagram (DFD)
Following are the rules of DFD:
 Data can flow from:
o Terminator or External Entity to Process
o Process to Terminator or External Entity
o Process to Data Store
o Data Store to Process
o Process to Process
 Data Cannot Flow From
o Terminator or External Entity to Terminator or External Entity
o Terminator or External Entity to Data Store
o Data Store to Terminator or External Entity
o Data Store to Data Store
Advantages of Data Flow Diagram (DFD)
 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical person because
they are very easy to understand.
Disadvantages of Data Flow Diagram (DFD)
 At times Data Flow Diagram (DFD) can confuse the programmers regarding the system.
 Data Flow Diagram takes long time to be generated, and many times due to this reasons
analysts are denied permission to work on it.
How to Draw Data Flow Diagram?
Following are the steps to Draw Data Flow Diagram
 Understand the System
 Identify External Entities
 Identify Processes
 Identify Data Stores
 Use Standard Symbols
 Create Level 0 Diagram
 Based on Complexity Draw Further Level Diagram like Level 1, 2 and so on.
 Identify Data Flows:
 Number Processes and Data Stores
 Review and Validate
Conclusion
Data Flow Diagram ( DFD) are visual maps that provides a clear understanding of how
information moves within a information system. Data Flow Diagrams (DFD) consist of four
component i.e. Processes that represent system’s functionality, External Entities that represent
the end users, data store that represent database or data ware house and data flow that represent
how data are flow among these three components. DFD help everyone, from computer experts to
regular users, as it provide a clear understanding of how a system works and how different parts
of it interact. By using DFDs, people can work together effectively to analyze, design, and
communicate about systems.
Frequently Asked Questions (FAQs) related to Data Flow Diagram (DFD)
What are the 4 components of DFD?
Four Components of DFD are:
 Process
 Data Flow
 Data Store
 External Entity

Computer Aided Software Engineering (CASE)

Computer-aided software engineering (CASE) is the implementation of computer-

facilitated tools and methods in software development. CASE is used to ensure high-quality and
defect-free software. CASE ensures a check-pointed and disciplined approach and helps
designers, developers, testers, managers, and others to see the project milestones during
development.
CASE can also help as a warehouse for documents related to projects, like business plans,
requirements, and design specifications. One of the major advantages of using CASE is the
delivery of the final product, which is more likely to meet real-world requirements as it ensures
that customers remain part of the process.
CASE illustrates a wide set of labor-saving tools that are used in software development. It
generates a framework for organizing projects and to be helpful in enhancing productivity. There
was more interest in the concept of CASE tools years ago, but less so today, as the tools have
morphed into different functions, often in reaction to software developer needs. The concept of
CASE also received a heavy dose of criticism after its release.
What is CASE Tools?
The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes. Throughout the 1990, CASE
tool became part of the software lexicon, and big companies like IBM were using these kinds of
tools to help create software.
Various tools are incorporated in CASE and are called CASE tools, which are used to support
different stages and milestones in a software development life cycle.
Types of CASE Tools:
1. Diagramming Tools: It helps in diagrammatic and graphical representations of the data and
system processes. It represents system elements, control flow and data flow among different
software components and system structures in a pictorial form. For example, Flow Chart
Maker tool for making state-of-the-art flowcharts.
2. Computer Display and Report Generators: These help in understanding the data
requirements and the relationships involved.
3. Analysis Tools: It focuses on inconsistent, incorrect specifications involved in the diagram
and data flow. It helps in collecting requirements, automatically check for any irregularity,
imprecision in the diagrams, data redundancies, or erroneous omissions.
For example:
 (i) Accept 360, Accompa, CaseComplete for requirement analysis.
  (ii) Visible Analyst for total analysis.

4. Central Repository: It provides a single point of storage for data diagrams, reports, and
documents related to project management.
5. Documentation Generators: It helps in generating user and technical documentation as per
standards. It creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators: It aids in the auto-generation of code, including definitions, with the help
of designs, documents, and diagrams.
7. Tools for Requirement Management: It makes gathering, evaluating, and managing
software needs easier.
8. Tools for Analysis and Design: It offers instruments for modelling system architecture and
behaviour, which helps throughout the analysis and design stages of software development.
9. Tools for Database Management: It facilitates database construction, design, and
administration.
10. Tools for Documentation: It makes the process of creating, organizing, and maintaining
project documentation easier.
Advantages of the CASE approach:
 Improved Documentation: Comprehensive documentation creation and maintenance is
made easier by CASE tools. Since automatically generated documentation is usually more
accurate and up to date, there are fewer opportunities for errors and misunderstandings
brought on by out-of-current material.
 Reusing Components: Reusable component creation and maintenance are frequently
facilitated by CASE tools. This encourages a development approach that is modular and
component-based, enabling teams to shorten development times and reuse tested solutions.
 Quicker Cycles of Development: Development cycles take less time when certain jobs,
such testing and code generation, are automated. This may result in software solutions being
delivered more quickly, meeting deadlines and keeping up with changing business
requirements.
 Improved Results: Code generation, documentation, and testing are just a few of the time-
consuming, repetitive operations that CASE tools perform. Due to this automation, engineers
are able to concentrate on more intricate and imaginative facets of software development,
which boosts output.
 Achieving uniformity and standardization: Coding conventions, documentation
formats and design patterns are just a few of the areas of software development where CASE
tools enforce uniformity and standards. This guarantees consistent and maintainable software
development.
Disadvantages of the CASE approach:
 Cost: Using a case tool is very costly. Most firms engaged in software development on a
small scale do not invest in CASE tools because they think that the benefit of CASE is
justifiable only in the development of large systems.
 Learning Curve: In most cases, programmers’ productivity may fall in the initial phase of
implementation, because users need time to learn the technology. Many consultants offer
training and on-site services that can be important to accelerate the learning curve and to the
development and use of the CASE tools.
 Tool Mix: It is important to build an appropriate selection tool mix to urge cost advantage
CASE integration and data integration across all platforms is extremely important.