CHENNAI INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND BUSINESS SYSTEMS

CB3405 -SOFTWARE ENGINEERING
UNIT II - REQUIREMENTS ANALYSIS AND SPECIFICATION
Requirement Analysis and Specification – Requirements Gathering and Analysis – Functional
and Non Functional Requirements – Software Requirement Specification (SRS) – Formal
System Specification: Finite State Machines, Petri Nets – Modern Requirement Modelling
Techniques – Introduction to UML: Use Case Model, Class Diagrams – Agile Requirements
Techniques: User Stories, Epics, Acceptance Criteria.

REQUIREMENT ANALYSIS AND SPECIFICATION

When we build software, the first and most important step is to understand what the software
should do. This step is called Requirement Analysis and Specification. Think of it like planning a
house—you need to know what rooms are needed, how big they should be, and any special
features before construction begins. Requirement Analysis and Specification is a critical phase in
the Software Development Life Cycle (SDLC). It involves understanding the needs of
stakeholders, analyzing these needs, and documenting them in a structured manner to guide the
development process.
 In software development, it is critical to clearly understand what the customer wants
before starting the development process. This is achieved through Requirements Analysis
and Specification.
Why is this important?
1. Development without clear requirements leads to:
2. Repeated changes in later phases.
3. Increased development time and costs.
4. A clear and well-documented requirements specification:
5. Provides a shared understanding of the system.
6. Acts as a foundation for subsequent phases like design, coding, and testing.
 All plan-driven life cycle models prescribe that before starting to develop a software, the
exact requirements of the customer must be understood and documented.
 Starting development work without properly understanding and documenting the
requirements increases the number of iterative changes in the later life cycle phases, and
thereby alarmingly pushes up the development costs.
 A good requirements document not only helps to form a clear understanding of various
features required from the software, but also serves as the basis for various activities
carried out during later life cycle phases.
Overview of requirements analysis and specification:
 The requirements analysis and specification phase starts after the feasibility study stage is
complete and the project has been found to be nancially viable and technically feasible.

1
  The requirements analysis and specification phase ends when the requirements
specification document has been developed and reviewed.
 The requirements specification document is usually called the software requirements
specification (SRS) document.
 The goal of the requirements analysis and specification phase is to clearly understand the
customer requirements and to systematically organize the requirements into a document
called the Software Requirements Specification (SRS) document.
 Who performs requirements analysis
 Requirements analysis and specification activity is usually carried out by a few experienced
members of the development team.
 It normally requires them to spend some time at the customer site.
 The engineers who gather and analyze customer requirements and then write the
requirements specification document are known as system analysts.
Requirements analysis and specification phase mainly involves carrying out the following two
important activities:
1. Requirements gathering and analysis.
2. Requirements specification.
REQUIREMENTS GATHERING AND ANALYSIS.
Requirements gathering and analysis is the first step in understanding the needs of stakeholders
and documenting them systematically. This phase ensures that the development team has a clear
understanding of what the software must achieve
What is Requirements Gathering?
 Also known as requirements elicitation, it involves collecting information about the desired
features and functionalities of the software.
 The primary goal is to capture all relevant requirements from stakeholders.
 The complete set of requirements are almost never available in the form of a single
document from the customer.
 Complete requirements are rarely obtainable from any single customer representative.
 We can conceptually divide the requirements gathering and analysis activity into two
separate tasks: Requirements gathering and Requirements Analysis
REQUIREMENTS GATHERING.
 Requirements gathering is also popularly known as requirements elicitation.
 The primary objective of the requirements gathering task is to collect the requirements
from the stakeholders.
 A stakeholder is a source of the requirements and is usually a person, or a group of persons
who either directly or indirectly are concerned with the software.
 It is very dicult to gather all the necessary information from a large number of stakeholders
and from information scattered across several pieces of documents.
 Gathering requirements turns out to be especially challenging if there is no working model
of the software being developed.

2
Challenges in Requirements Gathering
 Scattered Information:
o Requirements are rarely consolidated in one document or with one stakeholder.
 Ambiguity:
o Stakeholders may use vague terms, making it hard to define clear requirements.
 Incomplete Requirements:
o Certain needs may be overlooked during initial discussions.
 Conflicting Stakeholder Needs:
o Different stakeholders may have contradictory expectations.
Important ways in which an experienced analyst gathers requirements:
1. Studying existing documentation:
 The analyst usually studies all the available documents regarding the system to be
developed before visiting the customer site.
 Customers usually provide a statement of purpose (SoP) document to the
developers.
2. Interview:
 Typically, there are many different categories of users of a software.
 Each category of users typically requires a different set of features from the
software.
 Therefore, it is important for the analyst to first identify the different categories of
users and then determine the requirements of each.
3. Task analysis:
 The users usually have a black-box view of a software and consider the software as
something that provides a set of services (functionalities).
 A service supported by software is also called a task.
 The analyst tries to identify and understand the different tasks to be performed by
the software.
 For each identified task, the analyst tries to formulate the different steps necessary
to realize the required functionality in consultation with the users.
4. Scenario analysis:
 A task can have many scenarios of operation.
 The different scenarios of a task may take place when the task is invoked under
different situations.
 For different types of scenarios of a task, the behavior of the software can be
different.
5. Form analysis:
 Form analysis is an important and effective requirements gathering activity that is
undertaken by the analyst, when the project involves automating an existing manual
system.

3
  In form analysis the existing forms and the formats of the notifications produced are
analyzed to determine the data input to the system and the data that are output from
the system.
REQUIREMENTS ANALYSIS:
 After requirements gathering is complete, the analyst analyses the gathered requirements to
form a clear understanding of the exact customer requirements and to weed out any
problems in the gathered requirements.
 During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:
1. Anomaly:
 An anomaly is an ambiguity in a requirement. When a requirement is anomalous, several
interpretations of that requirement are possible.
 Example: While gathering the requirements for a process control application, the following
requirement was expressed by a certain stakeholder: “When the temperature becomes high,
the heater should be switched off”. Please note that words such as “high”, “low”, “good”,
“bad” etc. are indications of ambiguous requirements as these lack quantification and can
be subjectively interpreted.
2. Inconsistency:
 Two requirements are said to be inconsistent, if one of the requirements contradicts the
other.
 Example: Consider the following two requirements that were collected from two different
stakeholders in a process control application development project.
 The furnace should be switched-off when the temperature of the furnace rises above 500℃.
 When the temperature of the furnace rises above 500℃, the water shower should be
switched-on and the furnace should remain on.
3. Incompleteness:
 An incomplete set of requirements is one in which some requirements have been
overlooked. The lack of these features would be felt by the customer much later, possibly
while using the software.
 Example: In a chemical plant automation software, suppose one of the requirements is that
if the internal temperature of the reactor exceeds 200℃ then an alarm bell must be
sounded. However, on an examination of all requirements, it was found that there is no
provision for resetting the alarm bell after the temperature has been brought down in any of
the requirements. This is clearly an incomplete requirement.
STEPS IN REQUIREMENTS ANALYSIS
Requirements analysis involves systematically organizing, validating, prioritizing, and
documenting the requirements gathered from stakeholders.
1. Organizing Requirements
Organizing requirements involves grouping them into logical categories to ensure clarity and
easy reference.

4
Steps to Organize Requirements:
1. Classify Requirements:
o Functional Requirements: Define what the system should do.
 Example: "The system must allow users to log in using their credentials."
o Non-Functional Requirements: Define how the system performs its functions.
 Example: "The system should handle 1000 concurrent users with less than
2 seconds of response time."
2. Group by Modules or Features:
o Divide the requirements into related modules or features.
 Example: For an e-commerce system:
 User Management: Login, Registration, Profile Management.
 Order Management: Add to Cart, Checkout, Payment Processing.
3. Create a Traceability Matrix:
o Map each requirement to its source (stakeholder, document, etc.) and related
system components.
o Purpose: Ensure all requirements are traceable and accounted for.
2. Validating Requirements
Validation ensures that the requirements are feasible, complete, and testable, preventing costly
changes later in the development process.
Steps to Validate Requirements:
1. Check Feasibility:
o Ensure the requirements are achievable within the project's technical, financial,
and time constraints.
 Example: If a requirement demands real-time data processing, confirm
that the infrastructure can support it.
2. Ensure Completeness:
o Verify that all aspects of the requirements are covered, including edge cases and
scenarios.
 Example: If a requirement specifies generating reports, ensure details like
report format, frequency, and data sources are included.
3. Resolve Ambiguities:
o Replace vague terms with precise, measurable criteria.
 Example: Instead of "The system should be fast," specify "The system
should respond within 2 seconds."
4. Testability Check:
o Confirm that each requirement can be tested.
 Example: "The system should encrypt passwords using SHA-256" is
testable, while "The system should be secure" is not.
3. Prioritizing Requirements

5
Prioritization helps focus on the most critical requirements first, ensuring that the system delivers
maximum value early in the development process.
Steps to Prioritize Requirements:
1. Categorize Requirements:
o Use categories like Must-Have, Should-Have, Could-Have, and Won’t-Have
(MoSCoW Method).
 Example:
 Must-Have: User authentication.
 Should-Have: Multi-language support.
 Could-Have: Dark mode.
 Won’t-Have: Augmented reality integration.
2. Assess Stakeholder Value:
o Identify requirements that are critical to stakeholders' objectives.
 Example: For a banking application, stakeholders may prioritize security
features over aesthetics.
3. Consider Dependencies:
o Address requirements that serve as prerequisites for others.
 Example: Implementing user registration before implementing a profile
management system.
4. Rank by Risk and Effort:
o High-risk or high-effort requirements may be scheduled later to allow more time
for analysis.
4. Documenting Requirements
The final step is to document the requirements systematically in the Software Requirements
Specification (SRS) document.
Steps to Document Requirements:
1. Follow a Standard Template:
o Use a predefined format to ensure consistency and completeness.
 Example: IEEE Standard 830-1998 for SRS documents.
2. Include Essential Sections:
o Introduction:
 Overview of the project, purpose, and scope.
o Functional Requirements:
 Detailed description of system functionalities.
o Non-Functional Requirements:
 Performance, security, and usability requirements.
o Constraints:
 Limitations like hardware or software dependencies.
o Glossary:
 Define technical terms to avoid misunderstandings.

6
 3. Use Clear and Concise Language:
o Avoid jargon and write requirements in simple, unambiguous terms.
 Example: Instead of "The system should handle heavy loads," specify
"The system should support 5000 concurrent users with a response time of
less than 2 seconds."
4. Review and Approve:
o Share the SRS document with stakeholders for feedback.
o Incorporate changes and obtain formal approval.
FUNCTIONAL AND NON FUNCTIONL REQUIREMENTS
In software development, requirements are the foundation upon which a system is built.
These requirements are broadly categorized into functional requirements and non-functional
requirements, both of which are essential to the success of the software. Understanding these
requirements ensures that the software meets user needs, performs efficiently, and operates
securely.
1. Functional Requirements
Functional requirements define the specific features or functionalities that the system must
provide. They describe what the system should do to fulfill the business objectives and user
needs. These requirements are often directly tied to the user’s actions or the system's behavior
during interactions.
Examples:
 In an e-commerce system, functional requirements might include:
o Users should be able to create an account and log in.
o The system should allow users to search for products by category, price, or brand.
o Users should be able to add products to the shopping cart and proceed to
checkout.
 In a banking system, functional requirements might include:
o Customers should be able to check their account balance.
o The system should allow users to transfer funds between accounts.
o The system should generate transaction history reports.
Functional requirements are often defined through discussions with stakeholders and serve as the
basis for system development and testing. They are generally easier to validate because they are
directly related to user actions and system behavior.
2. Non-Functional Requirements
Non-functional requirements define the quality attributes or performance characteristics of
the system. They describe how the system should perform rather than what it should do. These
requirements focus on aspects such as performance, security, usability, and scalability, ensuring
that the system operates efficiently, reliably, and securely.
Examples:
 Performance: The system should handle 1,000 concurrent users with a response time of
less than 2 seconds.

7
  Security: All sensitive data should be encrypted using AES-256 encryption.
 Usability: The user interface should be intuitive and easy to navigate for both beginners
and experienced users.
 Scalability: The system should be able to scale up to handle 10,000 users without
performance degradation.
Non-functional requirements are harder to quantify than functional requirements but are crucial
for ensuring that the system provides a positive user experience and meets operational needs.
These requirements often influence the system’s architecture and design choices.
Comparison between Functional and Non-Functional Requirements
Aspect Functional Requirements Non-Functional Requirements
Definition Describes what the system should Describes how the system should perform
do (features, actions). (quality, constraints).
Focus System behavior and user Performance, security, scalability, and other
interactions. operational aspects.
Examples User login, product search, Response time, security measures, system
transaction processing. uptime.
Testing Verified through functional testing. Verified through non-functional testing (e.g.,
load testing, security testing).
Impact Directly tied to business goals and Ensures reliability, performance, and user
user needs. satisfaction.
Both functional and non-functional requirements are essential for developing a successful
software system. Functional requirements ensure that the system delivers the necessary
features and functionality to meet user and business needs. Non-functional requirements, on
the other hand, ensure that the system operates efficiently, securely, and reliably. A well-
balanced focus on both types of requirements results in a software product that is not only
functional but also performs well, scales effectively, and provides a seamless user experience.
SOFTWARE REQUIREMENT SPECIFICATION (SRS)
 A Software Requirement Specification (SRS) is a comprehensive document that
captures all the requirements of a software system. It serves as a blueprint for both the
development team and stakeholders, ensuring a clear understanding of what the system
should do and how it should behave.
 A well-structured SRS reduces ambiguity, facilitates better communication, and lays the
foundation for a successful software project.
 The SRS document usually contains all the user requirements in a structured though an
informal form. SRS document is probably the most important document and is the
toughest to write.
 One reason for this difficulty is that the SRS document is expected to cater to the needs
of a wide variety of audience.
 A well-formulated SRS document finds a variety of usage:
 Forms an agreement between the customers and the developers.

8
  Reduces future reworks.
 Provides a basis for estimating costs and schedules
 Provides a baseline for validation and verification
 Facilitates future extensions
Objectives of SRS
 To clearly define what the software should do (functional requirements).
 To specify how the software should perform (non-functional requirements).
 To serve as a reference for all stakeholders, including developers, testers, and clients.
 To ensure consistency and reduce misunderstandings during development.
 To act as a baseline for validating the final product.
Characteristics of a Good SRS
A good SRS document should have the following characteristics:
1. Correctness: Accurately reflects the user’s needs.
2. Unambiguous: Free of unclear or vague statements.
3. Completeness: Covers all functional and non-functional requirements.
4. Consistency: Does not contain conflicting requirements.
5. Modifiability: Easy to update when requirements change.
6. Verifiability: Requirements are testable and measurable.
Components of an SRS Document
A Software Requirement Specification (SRS) document is essential for defining the
requirements of a software system. It ensures clarity, consistency, and completeness for all
stakeholders involved in the software development lifecycle. Below is a detailed explanation of
the typical components of an SRS document:
1. Introduction
The introduction provides a high-level overview of the project and sets the context for the
document. It ensures that all readers understand the purpose and scope of the system.
1. Purpose
o Explains why the software is being developed and what the document aims to
achieve.
o Example: "The purpose of this document is to define the functional and non-
functional requirements of an online shopping platform that enables users to
browse and purchase products conveniently."
2. Scope
o Defines the boundaries of the software system, including its goals and objectives.
o Example: "This system will allow users to search for products, add them to a
shopping cart, make payments securely, and track orders."
3. Definitions, Acronyms, and Abbreviations
o Provides explanations for technical terms and abbreviations used in the document.
o Example: "AES: Advanced Encryption Standard."
4. References

9
 o Lists external documents, standards, or guidelines that are relevant to the system.
o Example: "ISO/IEC 27001: Information Security Management Standards."
2. Overall Description
This section gives a broader understanding of the system, its environment, and its users.
1. Product Perspective
o Describes how the system fits into the larger environment or ecosystem.
o Example: "The online shopping platform will integrate with third-party payment
gateways and logistics services."
2. Product Functions
o Summarizes the key features and capabilities of the system.
o Example:
 Users can browse products by category or price.
 Admins can manage product inventory and generate sales reports.
3. User Characteristics
o Identifies the intended users of the system, including their technical expertise and
expectations.
o Example: "Users include general customers with basic internet skills and
administrators with advanced knowledge of inventory management."
4. Constraints
o Lists the limitations that may affect the system's design or implementation.
o Example: "The system must support at least 10,000 concurrent users."
5. Assumptions and Dependencies
o States any assumptions made during the requirements gathering process and
dependencies on external systems.
o Example: "It is assumed that all users will have access to a stable internet
connection."
3. Specific Requirements
This is the most critical section of the SRS document, providing detailed requirements.
1. Functional Requirements
o Describes the specific functionalities the system must perform.
o Example:
 Users must be able to register, log in, and reset passwords.
 Admins can add, update, or delete products from the inventory.
2. Non-Functional Requirements
o Defines the quality attributes of the system, such as performance, security, and
usability.
o Example:
 The website must load within 3 seconds for 90% of users.
 All user data must be encrypted using AES-256 encryption.
3. External Interface Requirements

10
 o Specifies how the system interacts with external systems, hardware, or users.
o Example:
 The system must integrate with PayPal for payment processing.
 The system must provide an API for logistics partners to track orders.
4. System Models (Optional)
 Provides a visual representation of the system's behavior and structure using diagrams
such as:
o Use Case Diagrams: Illustrates interactions between users and the system.
o Data Flow Diagrams (DFD): Shows the flow of data within the system.
o UML Diagrams: Represents the system's components and relationships.
5. Appendices
 Includes additional information such as a glossary of terms, detailed calculations, or
references to supplementary documents.
Example of an SRS for an Online Shopping Application
1. Introduction
 Purpose:
To develop an online shopping platform for users to browse and purchase products easily.
 Scope:
The system will include features like product search, shopping cart, secure payment
gateway, and order tracking.
2. Overall Description
 Product Functions:
o Users can search for products by category, price, or name.
o Admins can manage product inventory and generate reports.
 Constraints:
o The system must support mobile and desktop platforms.
o Must handle up to 10,000 concurrent users.
3. Specific Requirements
 Functional Requirements:
o Users must be able to register, log in, and update their profiles.
o The system must send email notifications for order confirmations.
 Non-Functional Requirements:
o The website must load within 2 seconds for users with broadband internet.
o All sensitive data must be encrypted using industry-standard encryption.
4. System Models
 Use Case Diagram: Depicts how users interact with the shopping cart and payment
gateway.
 DFD: Shows the flow of product data from the database to the user interface.
5. Appendices
 Glossary of terms:

11
 o SRS: Software Requirement Specification.
o SoP: Statement of Purpose.
Benefits of SRS
 Improved Communication: Ensures that all stakeholders have a shared understanding of
the system requirements.
 Reduced Development Costs: Minimizes the need for changes during later stages of
development.
 Better Quality Assurance: Provides a clear baseline for testing and validation.
 Easier Maintenance: Acts as a reference for future updates or modifications.
The Software Requirement Specification (SRS) ensures that the development team has a clear
understanding of what needs to be built and how the system should behave. A well-prepared SRS
reduces risks, improves communication, and sets the stage for a successful project. By adhering
to the principles of clarity, completeness, and consistency, the SRS becomes a powerful tool for
both developers and stakeholders.

FORMAL SYSTEM SPECIFICATION

Formal system specification in software engineering refers to the process of precisely describing
the behavior, properties, and requirements of a software system using formal methods and
mathematical notations. It aims to eliminate ambiguity, clarify system requirements, and enable
formal analysis and verification of system properties.
Purpose of Formal Specification
1. Clarity: Provides an unambiguous description of system behavior.
2. Validation: Ensures that the requirements meet the needs of stakeholders.
3. Verification: Allows for checking correctness, consistency, and completeness of the
specifications.
4. Automation: Enables automatic analysis, such as model checking and theorem proving.
Key Aspects of Formal System Specification
1. Mathematical Foundation:
 Formal methods are rooted in mathematical principles, enabling rigorous and logical
reasoning about system behavior.
 Common mathematical tools include predicate logic, set theory, algebraic
expressions, and temporal logic.
2. Formal Specification Languages:
 Languages like Z notation, B method, and Specification and Description Language
(SDL) provide constructs for defining system properties.
 These languages use precise syntax and semantics to represent data types, predicates,
invariants, and schema definitions.
Steps in Formal Specification
1. Requirements Capture
 Translating informal requirements into formal expressions.

12
  Identifying and resolving inconsistencies, ambiguities, and gaps in requirements.
2. Specification
 Developing a precise model of the system using formal languages.
 Describing functional and non-functional requirements explicitly.
3. Verification and Validation
 Formal methods enable automated tools to verify consistency, correctness, and
completeness.
 Validation ensures that the system adheres to its intended behavior and satisfies user
needs.
4. Refinement
 Gradually refining high-level specifications into detailed designs.
 Ensuring the final implementation aligns with initial requirements.
5. Documentation
 Formal specifications serve as detailed, unambiguous documentation.
 Provides a reliable reference for maintenance and future enhancements.
Advantages of Formal System Specification
 Precision: Eliminates ambiguities in system descriptions.
 Early Detection of Errors: Identifies flaws in the requirements phase, reducing costly
revisions later.
 Automated Analysis: Leverages tools for validation, simulation, and theorem proving.
 Improved Communication: Provides a common understanding of system behavior among
stakeholders.
 Enhanced Reliability: Results in robust and dependable software designs.
Challenges of Formal Specification
 Complexity: Requires expertise in mathematics and formal languages.
 Time-Consuming: Demands additional time during initial development phases.
 Cost: Involves investment in tools and training.
 Scalability: Difficult to manage for very large or complex systems.
Formal system specification employs mathematical models to describe and analyze the behavior
of systems. Two prominent techniques are Finite State Machines (FSMs) and Petri Nets, which
provide structured and rigorous approaches to modeling system behaviors.
I. FINITE STATE MACHINES (FSMS)
A Finite State Machine (FSM) is a mathematical model used to describe a system's behavior
in terms of states and transitions. It is widely used for modeling sequential systems where the
behavior depends on the current state and inputs. FSMs are simple yet powerful tools for
designing and analyzing systems with predictable behaviors.
Key Components of FSMs
1. States
 Definition: States represent the various conditions or configurations that a system can be
in at any given time. Each state defines specific behaviors or actions of the system.
 Example: A washing machine has distinct states such as:

13
  Idle: The machine is not running and waiting for user input.
 Washing: The machine is actively washing clothes.
 Rinsing: The machine is rinsing clothes with clean water.
 Spinning: The machine is spinning clothes to remove excess water.
 States are fundamental to defining the behavior of the system under different conditions.
2. Transitions
 Definition: Transitions define the movement from one state to another based on specific
inputs or events. They are the links between states that dictate how the system reacts to
changes.
 Example: In a traffic light system:
 From the Green state, the system transitions to the Yellow state when a timer expires.
 From the Yellow state, it transitions to the Red state after another timer event.
 Transitions are typically labeled with the triggering event or condition that causes the
change.
3. Inputs
 Definition: Inputs are external signals, events, or user actions that trigger state transitions
in the FSM.
 Example:
 A vending machine receives a button press as input to transition from "Idle" to
"Processing Selection."
 In an elevator system, pressing a floor button serves as an input to move from "Idle"
to "Moving."
 Inputs are crucial for dynamic system interaction and behavior changes.
4. Outputs
 Definition: Outputs are the actions or responses generated by the system either during
state transitions or while in a specific state.
 Example:
 A printer outputs the message "Printing Document" while in the "Printing" state.
 A microwave beeps when it transitions from "Cooking" to "Completed."
 Outputs ensure the system communicates its status or actions to users or other systems.
5. Initial State
 Definition: The initial state is the starting point of the system when it begins operation. It
defines the system's behavior before any inputs or transitions occur.
 Example:
 In a vending machine, the initial state is Idle, waiting for user input.
 In a mobile phone, the initial state could be Locked or Home Screen depending on the
context.
 The initial state provides a baseline for the system's functionality.
6. Final State (Optional)
 Definition: The final state is an optional state where the system halts operations or
completes its tasks. Not all FSMs require a final state.
 Example:
 In an ATM system, the state Transaction Complete is a final state indicating the end
of a user session.
 In a video game, the state Game Over represents the final state of the game.
 Final states are useful in systems with defined endpoints or completion criteria.

14
Types of FSMs
1. Deterministic FSM (DFSM)
 Definition: In a deterministic FSM, for every state and input, there is exactly one defined
transition. This ensures predictable behavior.
 Characteristics:
o No ambiguity in transitions.
o Easy to design and analyze.
 Example:
o A Turnstile System:
 State: Locked
 Input: Insert coin → Transition to Unlocked
 Input: Push arm → Transition back to Locked
o The turnstile always transitions to a specific state based on the input, ensuring
determinism.
2. Non-Deterministic FSM (NDFSM)
1. Definition: In a non-deterministic FSM, for a given state and input, multiple transitions
may be possible. This allows for flexibility in system behavior.
2. Characteristics:
o Ambiguity in transitions.
o Requires additional logic to resolve multiple possible outcomes.
3. Example:
o A Chatbot System:
 State: Greeting
 Input: "Hello" → Possible transitions:
1. Respond with "Hi! How can I help you?"
2. Respond with "Hello! What do you need today?"
 The chatbot can choose from multiple responses based on additional
factors like user history or context.
Example of an FSM
Traffic Light Controller
1. States:
o Green
o Yellow
o Red
2. Transitions:
o Green → Yellow (Timer expires)
o Yellow → Red (Timer expires)
o Red → Green (Timer expires)
3. Inputs:
o Timer events
4. Outputs:
o Lights change color
Advantages of FSMs
1. Simplicity:
o Easy to understand and implement.
2. Predictability:

15
 o Clearly defines system behavior for all possible states and inputs.
3. Analysis:
o Facilitates verification and testing of system logic.
4. Automation:
o Supports the use of tools to generate code or test cases.
Applications of FSMs
1. Embedded Systems:
o Control systems like washing machines, elevators, and microwaves.
2. Communication Protocols:
o TCP/IP state transitions, handshake protocols.
3. Game Development:
o AI behavior modeling for game characters.
4. User Interfaces:
o Navigation in menus or state-dependent interactions.
Limitations of FSMs
1. State Explosion:
o For complex systems, the number of states can grow exponentially, making the
FSM hard to manage.
2. Concurrency:
o FSMs are not well-suited for modeling systems with concurrent behaviors.
3. Scalability:
o Difficult to scale for large and highly dynamic systems.
By defining states, transitions, inputs, and outputs, FSMs provide clarity in system design
and facilitate testing and analysis. Whether deterministic or non-deterministic, FSMs are
widely applicable in fields like embedded systems, communication protocols, user interfaces,
and more.
II. PETRI NETS
Petri Nets are a mathematical modeling tool used for describing and analyzing the flow of
information and control in systems. They are particularly effective for systems with
concurrent, asynchronous, distributed, or parallel processes. Petri Nets provide a graphical
representation and a formal basis for reasoning about system behavior.
Key Components of Petri Nets
1. Places
o Represent conditions or states in the system.
o Depicted as circles in the graphical representation.
o Example: In a manufacturing system, places could represent "Raw Material
Available" or "Product Assembled."
2. Transitions
o Represent events or actions that cause changes in the system.
o Depicted as rectangles or bars.
o Example: A "Start Assembly" action in a factory is a transition between "Raw
Material Available" and "Assembly in Progress."
3. Tokens

16
 o Represent the presence of a condition or the availability of a resource.
o Tokens are placed inside places (circles) to indicate their state.
o Example: A token in "Raw Material Available" indicates that raw materials are
ready for processing.
4. Arcs
o Represent the flow or relationship between places and transitions.
o Directed arrows connect places to transitions (input arcs) or transitions to places
(output arcs).
o Example: An arc connects "Raw Material Available" (place) to "Start Assembly"
(transition) to indicate dependency.
5. Marking
o The current state of the system is represented by the distribution of tokens across
places.
o Example: If a token is in "Raw Material Available," it signifies that raw materials
are ready.
Working of Petri Nets
1. Enabling a Transition
o A transition is enabled if all its input places have the required number of tokens.
o Example: For the transition "Start Assembly" to fire, "Raw Material Available"
must have a token.
2. Firing a Transition
o When a transition fires:
 Tokens are removed from input places.
 Tokens are added to output places.
o Example: When "Start Assembly" fires:
 A token is removed from "Raw Material Available."
 A token is added to "Assembly in Progress."
3. Concurrent Transitions
o Petri Nets naturally support concurrency. Multiple transitions can fire
simultaneously if they do not share input places.
o Example: In a factory, "Start Assembly" and "Start Packaging" can occur
concurrently if resources are available.
Advantages of Petri Nets
1. Graphical Representation
o Provides an intuitive way to visualize system behavior.
o Suitable for both designers and stakeholders.
2. Formal Analysis
o Supports mathematical analysis of system properties such as liveness,
reachability, and deadlock.
3. Concurrency Modeling

17
 o Ideal for systems with concurrent processes, such as multi-threaded programs or
distributed systems.
4. Validation and Verification
o Helps in verifying system correctness and identifying potential bottlenecks or
deadlocks.
Applications of Petri Nets
1. Workflow Management
o Modeling business processes and identifying inefficiencies.
o Example: Order processing systems.
2. Distributed Systems
o Analyzing communication protocols and resource sharing.
o Example: Network packet routing.
3. Embedded Systems
o Modeling real-time systems with strict timing constraints.
o Example: Automotive control systems.
4. Manufacturing Systems
o Modeling assembly lines and detecting bottlenecks.
o Example: Robotics in production lines.
Example of a Petri Net
Consider an online shopping system:
1. Places:
o "Item Selected"
o "Payment Processed"
o "Order Confirmed"
2. Transitions:
o "Add to Cart"
o "Make Payment"
o "Confirm Order"
3. Tokens:
o A token in "Item Selected" represents an item added to the cart.
o A token in "Payment Processed" indicates payment is completed.
4. Flow:
o Transition "Make Payment" fires when a token is in "Item Selected," moving the
token to "Payment Processed."
o Transition "Confirm Order" fires when a token is in "Payment Processed,"
moving the token to "Order Confirmed."
By combining graphical representation with formal mathematical analysis, Petri Nets help in
understanding, designing, and verifying system behavior, making them indispensable in various
domains like software engineering, manufacturing, and workflow management.

18
MODERN REQUIREMENT MODELING TECHNIQUES
Modern requirement modeling techniques are approaches that help in the systematic
identification, representation, and analysis of software system requirements. These techniques
allow stakeholders to clearly define the desired system functionality, constraints, and user
expectations. They also support the verification and validation of requirements, ensuring that the
final product meets customer needs. Some modern techniques include:
1. Unified Modeling Language (UML)
Overview: UML is a widely used modeling language for specifying, visualizing, and
documenting software system architecture and design. It provides a standardized way to model
both functional and non-functional aspects of a system.
Key Diagrams in UML:
 Use Case Diagrams: Represent the interactions between users (actors) and the system,
showing the system's functionalities from the user's perspective.
 Class Diagrams: Show the static structure of the system by modeling its classes,
attributes, operations, and relationships.
 Activity Diagrams: Model the flow of control or data within the system, focusing on the
sequence of activities.
 Sequence Diagrams: Depict the interactions between system components or objects over
time.
 State Diagrams: Illustrate the states of an object and the transitions between them based
on events or conditions.
Advantages:
 Provides a comprehensive view of the system.
 Widely adopted and understood in the industry.
 Helps in bridging the gap between requirements and design.
2. Business Process Model and Notation (BPMN)
Overview: BPMN is a graphical representation for specifying business processes in a workflow.
It helps in modeling the flow of activities within a business process and provides a way to
visualize complex workflows.
Key Components:
 Flow Objects: Includes events, activities, and gateways that control the flow of the
process.
 Connecting Objects: Arrows (sequence flows), associations, and message flows.
 Swimlanes: Represent different participants or organizational units in the process.
 Artifacts: Provide additional information about the process, such as data objects or
annotations.
Advantages:
 Helps in visualizing business processes and interactions.
 Suitable for process-driven applications.
 Allows easy collaboration between technical and non-technical stakeholders.

19
3. Entity-Relationship (ER) Diagrams
Overview: ER diagrams are used to model the data and relationships in a system. They provide a
clear structure for understanding how different entities (objects) interact with each other in a
database.
Key Components:
 Entities: Represent objects or concepts in the system (e.g., Customer, Product).
 Attributes: Characteristics of entities (e.g., Customer Name, Product Price).
 Relationships: Connections between entities (e.g., a Customer can place an Order).
Advantages:
 Helps in designing the database schema.
 Provides a clear view of the system’s data structure.
 Supports the identification of data-related requirements early in the development process.
4. User Stories and Agile Modeling
Overview: User stories are short, simple descriptions of system features from the perspective of
the user. They are used primarily in Agile methodologies to capture functional requirements in a
concise format.
Key Components:
 User Story: Describes what the user wants to do (e.g., "As a customer, I want to be able
to search for products").
 Acceptance Criteria: Conditions that must be met for the user story to be considered
complete.
 Story Points: A measure of the complexity or effort required to implement the user story.
Advantages:
 Encourages collaboration between stakeholders and developers.
 Flexible and easy to adapt to changes.
 Focuses on delivering incremental value to the customer.
5. Model-Driven Engineering (MDE)
Overview: MDE is a methodology that focuses on creating and exploiting domain models, which
are abstract representations of system requirements, design, and implementation. It emphasizes
the use of models throughout the software development lifecycle.
Key Concepts:
 Platform-Independent Models (PIM): Representations of the system that are independent
of any specific technology or platform.
 Platform-Specific Models (PSM): Models that are tailored to a specific technology or
platform (e.g., Java, .NET).
 Model Transformations: The process of converting one model to another, such as from
PIM to PSM.
Advantages:
 Improves productivity by automating code generation from models.
 Ensures consistency between different stages of development.

20
  Helps in maintaining high-level abstraction during development.
6. Goal-Oriented Requirements Engineering (GORE)
Overview: GORE focuses on identifying the goals that the system must achieve and using these
goals to drive the system design. It involves modeling both functional and non-functional goals
and determining how to achieve them.
Key Techniques:
 i Framework*: A goal-oriented approach that focuses on modeling actors, goals, and
dependencies between them.
 KAOS: A formal method for specifying and reasoning about system goals and
requirements.
Advantages:
 Helps in aligning the system with business objectives.
 Focuses on understanding the "why" behind requirements.
 Supports traceability from high-level goals to system specifications.
7. Contextual Design
Overview: Contextual design is a user-centered design methodology that focuses on gathering
and analyzing user data to create system requirements. It involves observing users in their natural
environment to understand their needs and behaviors.
Key Techniques:
 Flow Models: Represent how information or tasks flow through a system.
 Cultural Models: Represent the social context of users.
 Sequence Models: Capture the sequence of actions performed by users.
 Affinity Diagrams: Group related user needs and observations.
Advantages:
 Provides deep insights into user needs.
 Helps in designing systems that are highly user-friendly.
 Encourages iterative development based on user feedback.

INTRODUCTION TO UML: USE CASE MODEL, CLASS DIAGRAMS

The Unified Modeling Language (UML) is a standardized modeling language used to visualize,
specify, construct, and document the artifacts of a software system. UML provides a set of
graphic notation techniques to create abstract models of software systems, offering a
comprehensive view of the system's architecture, components, and interactions.
What is UML?
Unified Modeling Language (UML) is a standardized visual modeling language that is a
versatile, flexible, and user-friendly method for visualizing a system’s design. Software system
artifacts can be specified, visualized, built, and documented with the use of UML.
Why do we need UML?

21
We need UML (Unified Modeling Language) to visually represent and communicate complex
system designs, facilitating better understanding and collaboration among stakeholders. Below is
Why we need UML:
 Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with non-
programmers about essential requirements, functionalities, and processes of the system.
 A lot of time is saved down the line when teams can visualize processes, user interactions,
and the static structure of the system.
Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:

1. STRUCTURAL DIAGRAMS
Structural UML diagrams are visual representations that depict the static aspects of a system,
including its classes, objects, components, and their relationships, providing a clear view of the
system’s architecture.
1.1 CLASS DIAGRAM
 The most widely use UML diagram is the class diagram. It is the building block of all
object oriented software systems.
 We use class diagrams to depict the static structure of a system by showing system’s
classes, their methods and attributes. Class diagrams also help us identify relationship
between different classes or objects.
 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

22
 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, al so 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:
+ for public (visible to all classes)
- for private (visible only within the class)
# for protected (visible to subclasses)
~ for package or default visibility (visible to classes in the same 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.

There are three main parameter directionality notations used in class diagrams:

23
In (Input): An input parameter is a parameter passed from the calling object (client) to the called
object (server) during a method invocation. It is represented by an arrow pointing towards the
receiving class (the class that owns the method).
Out (Output): An output parameter is a parameter passed from the called object (server) back to
the calling object (client) after the method execution. It is represented by an arrow pointing away
from the receiving class.
InOut (Input and Output): An InOut parameter serves as both input and output. It carries
information from the calling object to the called object and vice versa. 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.
Example: 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.

24
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.
Example: 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.
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.

25
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.
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.
Example: In case of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.

26
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.
Example: 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.
27
  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.
Example: 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.
Example: Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.

28
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

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.
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.

2. BEHAVIOUR DIAGRAMS
 Behavioral UML diagrams are visual representations that depict the dynamic aspects of a
system, illustrating how objects interact and behave over time in response to events.
 Behavioral UML diagrams focus on illustrating the dynamic aspects of a software system,
showcasing how it behaves, responds to stimuli, and undergoes state changes during runtime.

29
 2.1 USE CASE DIAGRAM
 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.
Use case diagrams are useful in several situations. Here’s when you should consider using them:
1. When you need to gather and clarify user requirements, use case diagrams help visualize
how different users interact with the system.
2. If you’re working with diverse groups, including non-technical stakeholders, these
diagrams provide a clear and simple way to convey system functionality.
3. During the system design phase, use case diagrams help outline user interactions and plan
features, ensuring that the design aligns with user needs.
4. 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.

30
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. The key types of relationships are:
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.

31
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."

32
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:
Customer
Admin
 Use Cases:
Browse Products
Add to Cart
Checkout
Manage Inventory (Admin)
 Relations:
The Customer can browse products, add to the cart, and complete the checkout.
The Admin can manage the inventory.

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.

33
  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.

AGILE REQUIREMENTS TECHNIQUES:

 Agile methodologies emphasize collaboration, flexibility, and delivering value to customers
through iterative development.
 To manage and capture requirements effectively in an Agile environment, teams use
lightweight, flexible techniques that allow for frequent adjustments based on feedback.
 The most widely used techniques in Agile requirements gathering include User Stories,
Epics, Acceptance Criteria, Backlogs, and Sprint Planning.
 These techniques help ensure that the product meets user needs while maintaining
flexibility throughout the development process.
 Agile requirement techniques are specific practices or approaches used to gather,
document, and manage requirements within Agile projects. These techniques focus on
ensuring that the requirements are flexible, prioritized, and easily adaptable to changes
during the development process.
 Some common Agile requirement techniques include:
 User Stories: Short, simple descriptions of a feature from the perspective of the user.
They help define what a user needs and why.
 Epics: Large user stories that can be broken down into smaller, more manageable
user stories.
 Acceptance Criteria: Conditions that must be met for a user story to be considered
complete.
 Backlog Grooming: The process of reviewing and prioritizing the product backlog
(list of requirements).
 Story Mapping: A visual technique to organize and prioritize user stories, helping
teams understand the user's journey through the system.
These techniques are used within Agile methodologies to capture and manage requirements in a
way that aligns with Agile values such as flexibility, collaboration, and continuous feedback.
1. USER STORIES
In Agile Requirement Techniques, User Stories are a key tool used to capture and define
the features or functionalities required by the users. These stories serve as a bridge
between the development team and the stakeholders, ensuring that the system being built
aligns with the user’s needs. They are written in simple, understandable language,
focusing on the user's perspective, and are typically part of the Product Backlog.

34
Purpose of User Stories in Agile
User stories in Agile methodologies help to:
1. Capture User Needs: They focus on what the user wants to achieve, making sure the
development team understands the problem from the user's perspective.
2. Promote Communication: They encourage conversations between the development
team, product owner, and other stakeholders, ensuring clarity in requirements.
3. Prioritize Features: They help the team prioritize work based on business value,
ensuring the most important features are developed first.
4. Iterative Development: User stories are often broken down into smaller tasks that
can be completed in a single sprint, enabling incremental progress and quick
feedback.
Structure of User Stories in Agile
The structure of user stories in Agile is designed to be simple and user-centric, ensuring that
the development team clearly understands the functionality from the perspective of the end-
user. The typical format is:
"As a [user], I want [feature], so that [benefit]"
This format is broken down into three key components:
1. Who the feature is for (the user):
This part defines the user or role who will benefit from the feature. It answers the question,
"Who is this feature intended for?"
Example:
"As a customer"
This tells us that the feature is intended for a customer using the system.
2. What the user wants (the functionality):
This part describes the feature or functionality that the user needs. It answers the question,
"What does the user want to do?"
Example:
"I want to view my order history"
This explains the functionality the user is requesting: the ability to see past orders.
3. Why the user wants it (the benefit or value):
This part explains the reason or benefit behind the user's request. It answers the question,
"Why does the user want this feature?" This helps to understand the value that the feature
provides to the user and ensures that the team delivers functionality that is truly useful.
Example:
"So that I can track my previous purchases"
This part clarifies the benefit: the user wants to be able to track what they have bought in the
past.
Complete Example of a User Story:
 As a customer,
 I want to view my order history,
 So that I can track my previous purchases.
Why This Structure is Effective:

35
 Clarity: The format is straightforward and keeps the focus on the user and their needs.
 Collaboration: It encourages conversations between stakeholders, product owners, and
developers to ensure everyone is aligned.
 Flexibility: It allows for easy modifications as the project evolves. New user stories can
be created, refined, or adjusted based on feedback.
This format helps ensure that the team remains focused on delivering value to the user while
keeping the development process flexible and adaptable.
2. EPICS
 In Agile development, Epics are large, high-level user stories that describe a
significant piece of functionality or a feature of the system.
 They are too broad to be completed in a single iteration or sprint and need to be
broken down into smaller, more manageable user stories.
 Epics are often used in the early stages of Agile projects to capture big-picture
requirements and provide a roadmap for the development process.
 Over time, as the project progresses, these epics are refined and decomposed into
smaller, more detailed user stories that can be worked on in individual sprints.
Key Characteristics of Epics
1. Large Scope:
o Epics represent substantial pieces of functionality that span multiple iterations
or sprints. They often cover a large user need or business goal that cannot be
completed in a single sprint.
2. High-Level Overview:
o Epics are generally written at a high level and may not contain specific details
about the implementation. They focus more on what needs to be done rather
than how it will be done.
3. Decomposable:
o Epics can be broken down into smaller, more manageable user stories. This
decomposition process helps Agile teams plan and prioritize the work more
effectively.
4. Flexible and Iterative:
o Since Epics are high-level, they are flexible and can evolve over time. As the
project progresses, the understanding of the epic may change, and new
requirements may emerge.
5. Longer Timeframe:
o Due to their size, epics are typically completed over several sprints. The work
required to complete an epic is often spread out across multiple iterations,
making it easier for teams to plan and track progress.
Structure of an Epic
An epic typically includes the following components:
1. Title/Name:

36
 o A brief, descriptive title that captures the essence of the epic.
2. Description:
o A high-level overview of the functionality or feature. This is often written
from the perspective of the user or the customer.
3. Acceptance Criteria:
o General conditions that must be met for the epic to be considered complete.
While epics are high-level, acceptance criteria may still be defined to outline
the general expectations for success.
4. Business Value:
o The importance or value of the epic to the business or end-users. This helps in
prioritizing the epic relative to other features or functionalities.
5. Dependencies:
o Any dependencies the epic has on other epics or stories, systems, or external
factors. Understanding these dependencies helps in planning and sequencing
the work.
Example of an Epic
For an e-commerce application, an example of an epic might be:
 Title: Implement User Account Management
 Description: As a user, I want to be able to create, update, and delete my account so
that I can manage my personal information and preferences.
 Acceptance Criteria:
o Users can create an account using their email and password.
o Users can update their personal details.
o Users can delete their account.
 Business Value: This epic is critical as it enables users to manage their personal
information, which is essential for personalized experiences.
 Dependencies: Dependent on the user authentication system being implemented.
Decomposing Epics into User Stories
Epics, due to their large size, are broken down into smaller user stories that can be
implemented within a sprint. This process is known as story mapping or epic breakdown.
For example, the "Implement User Account Management" epic can be decomposed into
smaller user stories like:
1. User Story 1: As a user, I want to create an account using my email and password so
that I can register on the platform.
2. User Story 2: As a user, I want to update my account information so that I can keep
my details up to date.
3. User Story 3: As a user, I want to delete my account so that I can remove my
information from the platform.
By breaking down the epic into these smaller user stories, the development team can estimate
effort, prioritize work, and deliver functionality incrementally.

37
Benefits of Using Epics in Agile
1. Better Planning and Roadmapping:
o Epics help Agile teams plan large features over multiple sprints. They give a
clear picture of what needs to be done in the long run, helping with product
roadmaps and release planning.
2. Facilitates Prioritization:
o Since epics are large and high-level, they help product owners and
stakeholders prioritize the most important features for the product. They
provide clarity on the business value of each feature.
3. Improved Flexibility:
o Epics are flexible and can evolve as the project progresses. Agile teams can
revisit epics as new requirements emerge or as more is learned about the
system.
4. Encourages Incremental Delivery:
o By breaking down epics into smaller user stories, Agile teams can deliver
features incrementally. This ensures that value is delivered to the customer
frequently, reducing the time to market.
5. Enhanced Collaboration:
o Epics encourage collaboration among cross-functional teams. The large scope
of an epic often requires input from multiple stakeholders, including
developers, designers, testers, and business analysts.
Challenges in Using Epics
1. Vague Scope:
o Since epics are high-level, they can sometimes be too vague, leading to
confusion about the exact requirements. This is why it's important to break
them down into user stories as soon as possible.
2. Difficulty in Estimation:
o Estimating the effort required for an epic can be challenging due to its large
scope. Teams may need to break the epic into smaller stories before they can
accurately estimate the work.
3. Overloading the Product Backlog:
o If too many epics are added to the product backlog without being broken
down into smaller stories, the backlog can become unwieldy and difficult to
manage.
Epics provide a way to capture large features or functionalities in the early stages of
development and allow teams to break down these large pieces of work into smaller,
more manageable user stories. By decomposing epics into user stories, teams can deliver
value incrementally, prioritize work based on business value, and maintain flexibility
throughout the development process. Epics play a crucial role in planning, prioritization,

38
 and collaboration, ensuring that Agile projects can evolve and adapt to changing
requirements over time.
3. ACCEPTANCE CRITERIA
 In Agile development, Acceptance Criteria are the conditions that a product or
feature must meet to be considered complete and acceptable to the customer or end-
user.
 They are essential for defining the boundaries of a user story or feature and ensuring
that it delivers the intended value.
 Acceptance criteria provide clear and testable requirements that help Agile teams
understand what is expected for a given user story or feature.
 Acceptance criteria are typically written from the perspective of the user and focus on
the functionality, behavior, and outcomes expected from the system.
 They also help in determining the scope of work and are crucial for verifying and
validating the system's functionality during testing.
Key Characteristics of Acceptance Criteria
1. Clear and Unambiguous:
o Acceptance criteria must be written in clear, concise, and unambiguous
language to avoid confusion. They should be specific and easy to
understand by both the development team and the stakeholders.
2. Testable:
o Acceptance criteria should be defined in a way that they can be tested.
This ensures that once the feature is developed, it can be verified against
the criteria to check if it meets the requirements.
3. Outcome-Oriented:
o The criteria focus on the outcome or behavior of the system, not the
implementation details. They describe the expected results or behavior
when the system is used in a specific way.
4. User-Centric:
o Acceptance criteria are often written from the perspective of the user or
customer, ensuring that the system delivers value to them. They reflect the
needs and expectations of the end-user.
5. Specific to the User Story:
o Each user story should have its own set of acceptance criteria, detailing
what must be true for the story to be considered complete.
Structure of Acceptance Criteria
Acceptance criteria can be structured in different formats, but the most common formats
include:
1. Given-When-Then Format (Behavior-Driven Development - BDD):
o This format is widely used for writing acceptance criteria and is based on
the Given-When-Then structure. It provides a scenario-based approach to
define how the system should behave under specific conditions.
o Given: The initial condition or context.
o When: The action or event that triggers the behavior.
o Then: The expected outcome or result of the action.
Example:
o Given: The user is logged into their account.

39
 o When: The user clicks on the "Change Password" button.
o Then: The system prompts the user to enter their current password and
new password.
2. Checklist Format:
o Acceptance criteria can also be written as a list of specific conditions that
must be met for the user story to be considered complete.
Example:
o User must be able to log in using their username and password.
o System must display an error message for incorrect login credentials.
o User must be redirected to the dashboard after successful login.
Importance of Acceptance Criteria
1. Clarity of Requirements:
o Acceptance criteria provide clear and detailed expectations for the
development team. They ensure that both the customer and the
development team have the same understanding of what is required for the
feature to be complete.
2. Testability:
o Acceptance criteria define specific conditions that can be tested. This
makes it easier for the quality assurance (QA) team to verify that the
feature works as expected. It also helps in automating tests for regression
testing in future sprints.
3. Scope Management:
o Acceptance criteria help define the scope of the user story. They ensure
that the team focuses on delivering the agreed-upon functionality and
prevents scope creep by clearly outlining what is included and what is not.
4. Quality Assurance:
o QA teams use acceptance criteria to create test cases and verify that the
feature behaves as expected. The criteria provide a basis for both manual
and automated testing.
5. Customer Validation:
o Acceptance criteria ensure that the final product meets the customer's
needs and expectations. They act as a form of contract between the
development team and the customer, helping to ensure that the product
delivers the desired outcomes.
Example of Acceptance Criteria
For an online shopping application, a user story might be:
User Story: "As a customer, I want to add items to my shopping cart so that I can
proceed to checkout."
Acceptance Criteria:
1. Given: The user is logged into their account.
o When: The user clicks the "Add to Cart" button for a product.
o Then: The product is added to the shopping cart, and the cart icon is
updated to show the number of items in the cart.
2. Given: The user has items in their shopping cart.
o When: The user clicks on the "View Cart" button.

40
 o Then: The user is redirected to the cart page, where they can view all
items in the cart, including the quantity and price.
3. Given: The user is viewing their cart.
o When: The user clicks on the "Remove" button for an item.
o Then: The item is removed from the cart, and the cart icon is updated
accordingly.
Benefits of Acceptance Criteria
1. Ensures Alignment with Business Goals:
o Acceptance criteria ensure that the functionality being developed aligns
with the business goals and user needs. They help the team focus on
delivering value to the customer.
2. Improves Communication:
o By clearly defining what is expected, acceptance criteria improve
communication between the development team, QA team, and
stakeholders. They ensure everyone is on the same page regarding the
feature's requirements.
3. Reduces Ambiguity:
o Acceptance criteria reduce ambiguity by providing a clear definition of
"done." They eliminate the possibility of different interpretations of the
user story, ensuring that the team knows exactly what needs to be done.
4. Supports Continuous Improvement:
o With well-defined acceptance criteria, teams can easily track progress and
identify areas for improvement. If a feature does not meet the acceptance
criteria, it can be refined or adjusted in future iterations.
Challenges with Acceptance Criteria
1. Overly Complex Criteria:
o Acceptance criteria should be simple and focused. If they are too complex
or detailed, they can become difficult to implement and test. It's important
to keep them concise and to the point.
2. Ambiguous Criteria:
o Ambiguity in acceptance criteria can lead to confusion and
misinterpretation. It is essential to ensure that the criteria are clear and
unambiguous to avoid misunderstandings.
3. Changing Requirements:
o In Agile projects, requirements can evolve over time. Acceptance criteria
may need to be updated or refined as new information becomes available.
Keeping acceptance criteria up-to-date with changing requirements is
crucial for maintaining project success.
Acceptance criteria provide clear, testable, and outcome-oriented conditions that define
when a user story or feature is complete. By ensuring that all stakeholders have a shared
understanding of the feature's requirements, acceptance criteria help improve
communication, reduce ambiguity, and ensure that the system delivers value to the
customer. Well-written acceptance criteria also support testing, quality assurance, and
continuous improvement, making them an essential tool in Agile development.

41