BA Learning Material

BA HELPL!
NE
Business Analysis Learning Material For Beginners
Note:- This is free material shared on LinkedIn

and not for sale. Created By – Diwakar Singh
Founder & Mentor
What is Business Analysis?
As per BABOK(Business Analysis Body of Knowledge) Version 3, it is

the practice of enabling change in an enterprise by defining needs
and recommending solutions that deliver value to stakeholders. It
helps an organization to express the background and need of an
idea and the reason/logic for change, and to design and
recommend solution that deliver value to the business.
Who is Business Analyst?
A business analyst is anyone who performs business analysis

irrespective of their job title or the role in an organization. They are
responsible for discovering, synthesizing(combining the ideas and
findings), and analyzing information from various sources within or
external to enterprise by using tools, processes, techniques,
documentation and stakeholders.
Activities that a Business Analyst is
involved in:
• Understanding the business needs/requirements by eliciting and
collaboration
• Analyzing the business requirements and defining designs
• Managing and Maintaining the requirements through documentation
• Evaluating the solution and proposing it to business stakeholders
• Monitoring and Managing the business requirements by providing
regular status updates to business stakeholders
Business Analysis Core Concept
Model
As per BABOK V3, it is a conceptual framework for business analysis that encompasses what business analysis is and what it means to those who
perform business analysis task regardless of perspective, industry, methodology, or level in the organization.
1. Change – The act of transformation in response to a need. As a BA you should ask, what are the types of changes we are doing?
2. Need – A problem that is required to be addressed. As a BA you should ask, What are the needs we are trying to satisfy?
3. Solution – A specific way of satisfying one or more business needs in a context. As a BA you should ask, what are the solution we are
proposing or trying to create?.
4. Stakeholder – A group or individual who will be affected by the change, need or the solution. As a BA you should ask, who are the
stakeholders involved?
5. Value – The importance or usefulness of solution to the stakeholder within the context. As a BA you should ask, What value I am delivering to
stakeholder?
6. Contexts – It is everything relevant to the change that is within the environment like attitudes, beliefs, competitors, goals, behavior, domain,
culture, technology, etc., As a BA you should ask, what are the contexts that we and the solution are in.
Software/System Development Life
Cycle
A software/system development lifecycle is the framework which software industry uses to design, develop, test and deploy high
quality software/system. There are 7 stages in SDLC as described below:
1. Planning - To understand and define the scope of the business problem/software/system that needs to be solved/developed.
2. Analysis – To gather the business requirements and all other details which will help the project to prepare a prototype or in
designing the solution.
3. Design – In this stage prototypes/Mockups/UI/system interfaces are designed.
4. Development – In this stage actual development works start where developers write code and build application/software.
5. Testing – In this stage the application/software is tested and any bugs issue found is resolved( i.e., it goes back to step no 4)
6. Implementation and Deployment – In this stage the software/application/system is launched or deployed in production.
7. Maintenance – Any issues or problems encountered after making the product live will be handled and corrected(Again, it starts
from step 1)
SDLC Methodologies
• Waterfall
• Spiral
• Big Bang
• Iterative
• V-Model
• Agile
• RAD
Waterfall vs Agile Methodology
Waterfall: Agile:
1. Linear sequential Life cycle model. 1. Continuous iteration of development.
2. Structured software development 2. Flexible methodology.
methodology. 3. Follows Incremental approach.
3. Based on sequential design approach. 4. Here testing is done concurrently in
4. Here testing of product is done only each sprint.
after build phase. 5. Customers are continuously involved in
5. Customers are not involved in the each every stage.
stage and is only involved when 6. It allows changes in project
completed product is built and tested. development requirements.
6. No scope of changes in requirement
when development starts.
What is Requirement?
A requirement is a physical or functional need that a particular design,

product or process aims to achieve.
Types of Requirements
• Business Requirement – It describes the goals, objectives and outcome
that a business is trying to achieve.
• Stakeholder Requirement – It describes the needs of stakeholders in
order to achieve the business requirement.
• Solution Requirement – It describes the quality of solution that meets
the stakeholders requirements. It is categorized in two types: Functional
and non-functional requirements.
• Transition Requirement – It describes the capabilities that a solution
must have in order to move from the current state to proposed state.
An example of this is data migration and business training.
Functional Requirements vs Non-Functional
Requirements
Functional Requirements Non-Functional Requirements

• It defines what the system should do • It specifies how the system should do
and what it should not do. it.
• They are product features and hence • They are product properties and
focus on end user requirements. hence focus on user expectations.
• Example – An application needs a log • Example – Portability, Security,
in page. Maintainability, Reliability, Scalability,
Performance, Reusability, Flexibility.
Requirement Life Cycle
It refers to the process of identifying, validating, documenting and
managing requirements. There are four stages in requirement life cycle:
1. Definition – The process of eliciting requirements.
2. Validation – The process of validating the requirements gathered by
creating prototypes and process flow models.
3. Documentation – The process of documenting requirements once
validated and signed off.
4. Management – The process of monitoring and managing the
requirements through tools like Jira and confluence.
Who are Stakeholders?
A stakeholder is anyone who has a stake in the project i.e., a group or individual who
is either interested in the project or affected by the project. Below are the
stakeholders in a project:
• Business Analyst
• Customer
• SME(domain and implementation)
• End User
• Operational Support team
• Project Manager
• Business Sponsor
• Supplier
• Tester
Stakeholder Analysis and Mapping
Stakeholder analysis is a process of identifying stakeholders, assess their
interest and influence level, and understand how they are connected to the
project deliverables.
Stakeholder Mapping is the technique to map the identified stakeholder

according to their level of influence.
Stakeholder Mapping - RACI Matrix
RACI matrix is a responsibility assignment chart that maps out every task, milestones involved in completing the
project and assigns which roles are responsible for each action item, who is accountable and who should be
consulted or informed. It stands for Responsible, Accountable, Consulted and Informed.
Understanding each attribute in detail:

1. Responsible – Stakeholders who do the job like Business Analyst. There can be more than one person
responsible.
2. Accountable – Stakeholder who is the owner of work and are involved in sign off or approving the requirements
or other project related artefacts. These are the Business Sponsor or Project Sponsors. It is advised to have one
person accountable to avoid conflicts.
3. Consulted- Stakeholders who need to give input before the work can be done or signed off and should be kept
in loop. This can be the business analyst, solution architects, etc.
4. Informed – Stakeholders who need to be informed about the project status and hence they need to be kept in
picture. They are neither consulted nor they contribute directly to the task or decision. This can be the project
manager.
How to create RACI matrix?
• Identify the key tasks involved in completing the project.
• Identify all the stakeholders involved in the project.
• Identify who is responsible, accountable, consulted or informed for each
task.
• Ensure each task should have at least one stakeholder responsible.
• Ensure that there should be not more than one stakeholder accountable for
a task.
• Once the RACI matrix is completed, share it with all the stakeholders and
discuss to avoid any conflicts and confusion at later stage. A business
analyst can sit with the project manager to prepare the RACI matrix.
Project Initiation – BOSCARD Technique
It is a strategic planning tool used to write terms of reference before a project begins. It is an agreement between
stakeholders made before project kicks off. It stands for Background, Objectives, Scope, Constraints, Assumptions, Risk
and Deliverables.
1. Background – Provide background information that includes the reasons for creating the project and mentions the
key stakeholders who will benefit from the project result.
2. Objectives - Describe the project goals and link each of them with related, SMART project objectives.
3. Scope - Provide a high-level description of the features and functions that characterize the product, service, or
result the project is meant to deliver.
4. Constraints - Identify the specific constraints or restrictions that limit or place conditions on the project, especially
those associated with project scope.
5. Assumptions - Specify all factors that are, for planning purposes considered to be true. During the planning
process, these assumptions will be validated.
6. Risk - Outline the risks identified at the start of the project. Include a quick assessment of the significance of each
risk and how to deal with them.
7. Deliverables - Define the key deliverables the project is required to produce to achieve the stated objectives.
Requirement Elicitation
It is the practice of researching, identifying and gathering the requirements of a business/system from users,
customers or stakeholders. Below are the requirement elicitation techniques used by a Business Analyst:
Stages in requirement elicitation:
• Pre Elicitation – In this stage it is very important to choose the right elicitation technique, informing
stakeholders, sharing the agenda of elicitation, selecting the place/mode/tool for elicitation.
• During Elicitation – Start the elicitation by introducing yourself, address the agenda for elicitation, drive
elicitation and gather the information.
• Post Elicitation – Once you have gathered all the information, validate the requirements elicited by
sending MOM and scheduling walkthrough sessions with the stakeholders who have attended.
Requirement Elicitation Techniques
1. Stakeholder Analysis
2. Interviews
3. Joint Application Development
4. Workshops
5. Focus Groups
6. Surveys
7. Brainstorming
8. Prototyping
9. Document Analysis
10.Observation
11. Data Dictionary and Glossary
12. Interface Analysis
Interviews
This is the most widely used technique and it can be done one on one or with multiple stakeholders.
Interviews conducted are of two types:
• Structured – If as a business analyst you have predefined set of questions then it is a structured
interview.
• Unstructured – If you are not having any particular format or any specific questions then it is an
unstructured interview.
Questions are of two types: Open Ended and Closed.
1. Open Ended – These are the questions asked with the intention of getting detailed information and
it cannot be answered in one word.
2. Closed – These are questions asked to get confirmation on answers provided and it can be
answered in Yes/No form.
Joint Application Development
It is a structured, process oriented, facilitated workshops that brings heterogeneous
stakeholders together to define, clarify and complete requirements. JAD sessions are
divided basically into two categories:
• Formal Workshops – These are highly structured workshops with group of

stakeholders to define, create, refine, and reach closure on business requirements.
• Process Improvement Workshops – These are less formal as compared to formal

workshops where existing business processes are analyzed and process improvements
are identified.
Workshops
It is a structured and facilitated event for getting selected group of stakeholders together to discover,
refine, prioritize, validate and discuss requirements.
What is done in Workshops?

• The topic of the workshop is declared at the beginning. This is to ensure that stakeholders do not
divert from the topic.
• Business Analyst start workshop by discussing the topic and asking questions related to agenda.
• Participant can express their views thoughts and can answer the questions.
• Workshops can also be used for prioritizing requirements, brainstorming, validating requirements,
and for reviewing requirements.
• Business Analyst should ensure that all the required information is gathered within the allotted
timeframe.
Focus Groups
It is an elicitation technique used to gather subjective information and is
a useful technique to understand the stakeholder’s attitudes, feelings,
and beliefs about the requirement. Focus group is a homogeneous group
which has stakeholders with similar characteristics and background i.e.
Subject Matter Experts whereas brainstorming and workshops has
heterogeneous stakeholders i.e. individuals with different characteristic
and background.
Surveys
It is an elicitation technique where set of questions is given to
stakeholders to quantify their thoughts. Response is then collected,
analysed, and modelled. It is very important to keep in mind that the
questions should be direct and unambiguous.
Questions in the survey are again of two types:

1. Open Ended – Participants are given the freedom to answer in their own
words rather that selecting answer from the pre-defined options.
2. Close Ended – It has predefined options and stakeholders has to choose
the answer among them.
Brainstorming
It is a creative process that is used to generate ideas and find a solution for a specific issue. The best part
of brainstorming sessions is that each participant gets an equal opportunity to generate ideas or express
their views and thoughts.
When to use brainstorming technique:

• To get answer for specific question
• To resolve an issue
• To understand what are the factors that is holding a group or organization from moving ahead
• To understand the cause of delay in development process
• To generate new ideas to solve a problem
Brainstorming is most effective when it is carried out in group and when focus is kept on one specific
topic.
Facilitating Brainstorming Session
1. Select your facilitator, idea recorder, and participants, and reserve
your place and time.
2. Set out the expectation about the format and objective.
3. Set a time limit and request participant to brainstorm ideas in that
time limit.
4. Keep everyone on the topic.
5. No restriction on number of ideas to be generated.
6. Once the brainstorming is done, collect all ideas, refine and start
prioritizing the ideas generated.
Prototyping
It is an elicitation technique used to identify missing or unspecified
requirements. In this technique prototypes are created and demo is given
to stakeholders to get an idea how the product will look like.
Prototype vs Wireframe vs Mockup
Prototype – They are high-fidelity representation that demonstrate how a user will
interact with the new product or feature. The main purpose of prototype is to collect
the feedback by user testing the real experience.
Mockups – They are static yet realistic renderings of what a product or feature will
look like and how it will be used. The main purpose is to facilitate more detailed
critiques of visual elements and functionality so that changes can be made.
Wireframes – They are basic, black and white renderings that focus on what the new
product or feature will do. The main purpose is to gain consensus and collect internal
feedback on how new functionality will work.
Prototype vs Wireframe vs Mockup - Image
Document Analysis
It is a technique of studying relevant business, system and project documentation with
the objective of understanding the business, the project background and identifying
requirements or opportunities for improvement.
There are 3 stages in document analysis:

• Prepare – Business Analyst identify which materials are suitable and relevant for
analysis.
• Review – In this stage business analyst study the material, makes notes and list down
all questions that needs to be asked to the stakeholders.
• Wrap up – In this stage BA walkthrough the notes with stakeholders, and get the
answers for the questions prepared.
Observation
It is a technique used by business analysts to understand how a user does
their job by conducting an assessment of their work environment. This
technique can be used to verify requirements and deliver instant
requirements worthy of consideration.
Data Dictionary and Glossary
Glossaries allow you to document any key business terms along with
their definitions. It is a best practice to start your business glossary
immediately during that project’s controlled start and to keep it
updated throughout the project life cycle. Much of the information
that goes into the glossary will be a result of your business, stakeholder,
solution and transition requirements development efforts.
Data dictionaries are a bit more technical in nature. A data dictionary

defines data elements, their meanings and their allowable values.
Building a data dictionary for your project may not begin until the
project requirements are complete and the technical design effort is
underway. There are two types of data elements found in a data
dictionary: primitive data elements and composite data elements.
Data Dictionary Example
Business Glossary Example
Interface Analysis
Interface Analysis is a business analysis elicitation technique that helps to identify
interfaces between solutions/applications to determine the requirements for ensuring
that the components interact with one another effectively. It helps in discovering the
requirements needed to integrate software into its new environment. It also helps
in determining requirements for interoperability and exposing interfacing stakeholders
early on in the project.
It is done by reviewing the existing system and building a context diagram which displays
at a glance, the entities that send data to and receive data from it at a high level.
Assessment
Requirement Analysis – Organizing and Modelling Requirements
It is the process of breaking, organizing, modelling and prioritizing

requirements to get the better understanding of it.
Overview:
• Analyse the requirements gathered in order to define the requirement
capabilities of a potential solution that will satisfy the stakeholders needs.
• Organize the requirements by prioritizing the requirements.
• Modelling the requirements by developing several models for the current
state and understanding what is needed to achieve the proposed state.
• Validating the solution scope with stakeholders(business and technical).
Requirement Prioritization Technique
It is a process of prioritizing requirements when there are multiple requirements,
budgetary constraints, and tight deadlines. It becomes necessary to prioritize
requirements so that requirements which are very important(MVP) can be implemented
first and one which are less important can be delayed for some time.
Techniques used to prioritize requirements:
1. MoSCoW
2. Ranking Method
3. 100 dollar method
4. Bubble Sort Technique
5. Planning Poker
Aspects of Prioritization
Requirements can be prioritized taking many different aspects into account. An aspect
is a property or attribute of a project and its requirements that can be used to prioritize
requirements.
• Importance
• Penalty
• Cost
• Time
• Volatility
MoSCoW Technique
It stands for Must have, Should have, Could have and Would have.
• Must have – These are non-negotiable requirement/product needs that

are mandatory for the team.
• Should have – These are important initiatives that are not vital but add
significant value.
• Could have – These initiatives are good to add but if left out will have
small impact.
• Would have – These are initiatives that are not in priority for a specific
time period.
Ranking Method Technique
When you rank requirements on an ordinal scale, you give each one a
different numerical value based on its importance. For example, the number
1 can mean that the requirement is the most important and the
number n can be assigned to the least important requirement, n being the
total number of requirements. This method works best when you are dealing
with a single stakeholder as it can be difficult to align different stakeholders’
perspectives on what the priority of a requirement should be; taking an
average can however, address this problem to some extent.
100 dollar method
This simple method is useful anywhere multiple stakeholders need to democratically vote
on which requirements are the most important. All stakeholders get a conceptual 100
dollars, which they can distribute among the requirements. As such, the stakeholder may
choose to give all 100 dollars to a single requirement, or the person may distribute the
points more evenly. The higher the amount allocated to each requirement, the higher the
priority of the requirement. At the end, the total is counted and the requirements are
sorted based on the number of points received.
This technique should only be used when you have a small group of requirements to
prioritize and when you have the same set of requirements to prevent respondents from
influencing their results by assigning more dollars to their favorite requirement.
Bubble Sort Technique
To prioritize requirements using bubble sort, you take two requirements and
compare them with each other. If you find out that one requirement should
have greater priority over the other, you swap them accordingly. You then
continue in this fashion until the very last requirement is properly sorted.
The result is a list of requirements that are ranked.
Planning Poker- User Story Estimation
Planning poker (also known as Scrum poker) is a consensus-based, gamified technique for estimating, mostly used
to estimate effort or relative size of development goals in software development.
Steps to perform planning poker:

• To start a poker planning session, the product owner or customer reads an agile user story or describes a
feature to the estimators.
• Team members of the group make estimates by playing numbered cards face-down to the table without
revealing their estimate (Fibonacci values: 1,2,3,5,8,13,21,44)
• Cards are simultaneously displayed and estimates are then discussed and high and low estimates are explained
• Repeat as needed until estimates converge
How to assign Fibonacci numbers:

1. 0- Task is already completed.
2. 1,2,3 – Task is small in size.
3. 5,8,13 – Task is of medium sized.
4. 21,44 – Task is of large size.
5. >44 – They are used for very large task
6. No number allotted – Not sure how much time it will take so unable to estimate.
Requirement Modelling
It is a process of ensuring/validating that the requirement has been gathered correctly
and is communicated to business stakeholders in the form of business modelling and to
technical stakeholders in the form of UML(Unified Modelling Language)
Importance of requirement modelling:

• To achieve fast, consistent, and continuous delivery of the requirements.
• It helps in gaining a deeper understanding of the requirements and the processes
involved in it.
• To identify and address any changes that are necessary to meet their exact
requirements and specifications.
• By taking the feedback from stakeholders at an early stage helps the project to avoid
any conflicts and obstacles at later stage of the project.
Requirement Modelling Techniques
Business Requirement Modelling Techniques:
1. BPMN(Business Process Model And Notation)
2. Flowcharts
3. Cross Functional Flowcharts
Unified Modelling Language:

• Structural Diagrams – Class Diagram, Context Diagram and Component Diagram
• Behavior Diagrams – Use Case Diagram, State Diagram and Activity Diagram.
Data Flow Diagram
Role Activity Diagram

Business Process Model And Notation
BPMN 2.0 is an open standard notation system based on a flowcharting technique that
is used to model business processes. The standard is widely used in business process
management since it is easily understood by business users while also providing
technical users with the ability to represent and implement complex processes.
History of BPMN2.0:
BPMN was originally developed by the Business Process Management Initiative (BPMI)
in 2004. In 2005 BPMI merged with the Object Management Group (OMG). One year
later BPMN was formally adopted as a standard by OMG. BPMN 2.0 was developed in
2010 but was not released until 2013.
Benefits of BPMN2.0:
1. It helps stakeholders gain a better understanding of a process through a universally

understood language.
2. It helps to close the gap between the various stages of business process
BPMN2.0 – High Level Overview
Business Process
Business Process Examples
BPMN 2.0 tools
Below are the tools that can be used to make BPMN2.0 diagrams:
• Aris
• Draw.io
• Visio
• Lucid Chart
Questions to ask before making BPMN2.0 diagram
Before making BPMN2.0 diagrams you should ask your stakeholders below
questions:
• What level of BPMN2.0 diagram is needed? There are 4 levels of BPMN2.0
diagram – L0, L1, L2, L3.
• Are there any assumptions to be made?
Tokens in BPMN2.0
It is a theoretical concept that is used as an aid to define the behavior of a Process that is being performed.
Token is born when a Start Event is triggered (e.g. by receiving a Message, when some condition becomes
true or for a plain Start Event simply when some employee starts the process).
Token then follows the Sequence Flow (it cannot use Message Flows or other arrows) and flows through a
process (passing through elements such as Gateways or Tasks/Sub-processes) right till the End Event where
it is consumed.
Important thing about token is that it helps figure out what can happen in a process.
In the beginning all Activities in a process are Inactive. When a Token arrives Activity becomes Ready.
Understanding Token in detail
BPMN2.0 Elements and Symbols
There are 4 primary elements of BPMN: Flow Objects, Connecting Objects, Swimlanes
and Artifacts.
• Flow objects. These are the core elements of BPMN. It form the overall workflow. The
three main flow objects are called events, activities, and gateways. Events are triggers
that start, alter, or complete a process. Activities are tasks performed by individuals or
technology. Gateways are not decision points, it just helps to direct the flow of the
process.
• Swimlanes. A pool includes the participants in a process. Swimlanes show the
activities for each participant.
• Connecting objects. Illustrate how the elements of a process relate to one another.
There are three types of connecting objects: sequence flows, message flows,
and associations. Sequence flows show the order that activities will be performed.
Message flows show communications between departments. Associations shows the
relationship between an artifact to an event, activity, or gateway.
• Artifacts. Artifacts are used to provide additional information about a process. There
BPMN2.0 Flow Objects - Events
Events represents an event in a business process.
Start event symbol – It signals the first step of a business process
Intermediate event symbol – It represents any event that occurs between a start and end event.
End event symbol – It signals the final step in a process

BPMN2.0 – Event Symbols(Message Start)
A message start event can be used to start a process instance using a named message. Points to keep in
mind while using message start event.
• The name of the message start event must be unique across a given process definition, i.e., a process
definition must not have multiple message start events with the same name.
• The name of the message start event must be unique across all deployed process definitions. The
engine throws an exception upon deployment of a process definition in case one or more message
start events reference a message with the same name as a message start event already deployed by a
different process definition.
BPMN2.0 Message Start Example
Intermediate Catch Event
An Intermediate Catch Event indicates that something is happening between the start and end of a process.
Intermediate Events affect the flow of a process, but do not start or directly terminate the process.
Intermediate Catch Event is used to:

•Show where messages are expected or sent within a process.
•Show delays that are expected within a process.
•Interrupt normal flow through exception handling.
Types of Intermediate Catch Events are the following:
• Message Catching Intermediate Event

• Timer Catching Intermediate Event
• Conditional Catching Intermediate Event
BPMN2.0 – Event Symbols(Message Intermediate Catching)
A Message Catching Intermediate Event is used to receive a message. When a token arrives at the message
intermediate catching event it will wait there until a message with the proper name arrives.
BPMN2.0-Event Symbols(Message Boundary Event)
Interrupting Non-Interrupting
Boundary events are catching events that are attached to an activity. This means that while
the activity is running, the message boundary event is listening for named message. When
this is caught, two things might happen, depending on the configuration of the boundary
event:
•Interrupting boundary event: The activity is interrupted and the sequence flow going out
of the event is followed.
•Non-interrupting boundary event: One token stays in the activity and an additional token
is created which follows the sequence flow going out of the event.
Message Boundary Interrupting Event Example
Message Boundary Event Non-Interrupting Example
BPMN2.0-Event Symbols(Message Intermediate Throwing event)
A Message Intermediate Throwing event sends a message to an external service.

BPMN2.0-Event Symbols(Message End Event)
When process execution arrives at a Message End Event, the current path of execution is ended and a message is sent.
BPMN2.0 – Event Symbols(Timer)
Timer events are events which are triggered by a defined timer. They can be used as start event, intermediate
event or boundary event. Boundary events can be interrupting or not.
Timer start – A timer start event is used to create process instance at a given time. It
can be used both for processes which should start only once and for processes that
should start in specific time intervals.
Timer Intermediate catching – A timer intermediate event acts as a stopwatch. When an execution arrives
in catching event activity, a timer is started. When the timer fires (e.g., after a specified interval), the
sequence flow going out of the timer intermediate event is followed.
A timer boundary event acts as a stopwatch and as an alarm clock. When an execution arrives in the activity to which the
boundary event is attached, a timer is started. When the timer fires (e.g., after a specified interval), the activity is
interrupted and the sequence flow going out of the timer boundary event are followed.
There is the difference between an interrupting and a non interrupting timer event. The interrupting event is the default.
The non-interrupting event leads to the original activity not being interrupted, the activity stays there.
BPMN2.0 Timer Event Example
BPMN2.0-Event Symbols(Conditional Start)
The conditional event defines an event which is triggered if a given condition is evaluated to true.
A conditional start event can be used to start a process by evaluating some condition. One process can have one or
more conditional start events.
If more than one conditions are fulfilled the respective number of processes will be triggered.
When deploying a process definition with conditional start events, the following considerations apply:
•The condition of the conditional start event must be unique across a given process definition, i.e., a process
definition must not have multiple conditional start events with the same condition. The engine throws an exception
upon deployment of a process definition in case two or more conditional start events contain the same condition.
•Process versioning: Upon deployment of a new version of a process definition, the conditional subscriptions of the
previous version are cancelled. This is also the case for conditional events that are not present in the new version.
BPMN2.0 – Event Symbols(Conditional Intermediate Event)
A conditional intermediate event is an intermediate event with a Boolean condition as
its trigger. The event trigger further workflow execution when the condition evaluates
to true and its outgoing flow is taken.
The event must define the expression property. When a conditional intermediate
event is placed in the process workflow, it has one incoming flow, one outgoing flow
and the execution starts when the incoming flow transfers to the event.
When a conditional intermediate event is placed on an activity boundary, the

execution is triggered at the same time as the activity execution. If the event is non
interrupting, the event triggers continuously while the condition is true.
Conditional Event Example
BPMN2.0 Gateways
Gateways are used to control how Sequence Flows interact as
they converge and diverge within a Process. It is used to control the flow of the
process so it must not be confused with decisions. They do not make the
decisions, they only direct the flow according to the decisions previously made.
Types of Gateways in BPMN2.0:
• Exclusive Gateway
• Inclusive Gateway
• Parallel Gateway
• Complex Gateway
• Event Gateway
• Exclusive Start Gateway
• Parallel Start Gateway
BPMN2.0 – Exclusive Gateway
It is represented by either a diamond with an X, or without the X. It is used to create alternative paths within
a Process flow. For a given instance of the Process, only one of the paths can be taken.
When the execution of a workflow arrives at this gateway, all outgoing sequence flows are evaluated in the
order in which they are defined. The sequence flow whose condition evaluates to true is selected for
propagating the token flow.
Note that the semantics of an outgoing sequence flow:
•In general, in BPMN 2.0, all sequence flows whose conditions evaluate to true are selected to continue in a
parallel way. When using an exclusive gateway, only one sequence flow is selected.
•If no sequence flow can be selected, an exception will be thrown. To ensure a sequence flow will always be
selected, have no condition on one of your flows.
Exclusive Gateway Example
BPMN2.0- Inclusive Gateway
An inclusive Gateway specifies that one or more of the available paths will be taken. They
could all be taken, or only one of them.
1. Unlike the Exclusive Gateway, all condition Expressions are evaluated.

2. The true evaluation of one condition Expression does not exclude the evaluation of
other condition Expressions
3. All Sequence Flows with a true evaluation will be traversed by a token
4. Since each path is considered to be independent, all combinations of the paths MAY be
taken, from zero to all
5. However, it should be designed so that at least one path is taken.
Inclusive Gateway Example
BPMN2.0 – Parallel Gateway
Parallel gateways are used to represent two tasks in a business flow. A parallel gateway is used to visualize
the concurrent execution of activities. A parallel gateway models a fork into multiple paths of execution, or a
join of multiple incoming paths of execution.
•Fork – all outgoing sequence flows are followed in parallel, creating one concurrent execution for each
sequence flow.
•Join – all concurrent executions arriving at the parallel gateway wait at the gateway until execution has
completed for each of the incoming sequence flows. The process then continues.
A parallel gateway can have both fork and join behavior if there are multiple incoming and outgoing
sequence flows for the same parallel gateway. In this case, the gateway will first join all the incoming
sequence flows, before splitting into multiple concurrent paths of execution.
Parallel Gateway Examples
BPMN2.0 – Event Based Gateway
The Event-Based Gateway represents a branching point in the Process where the
alternative paths that follow the Gateway are based on Events that occur rather than the
evaluation of the process flow that lead to this point. A specific Event such as the receipt
of a message from a customer, determines the path that will be taken.
An event-based gateway must have at least two outgoing sequence flows. Each
sequence flow must to be connected to an intermediate catch event of type timer
or message.
When an event-based gateway is entered then the workflow instance waits at the
gateway until one of the events is triggered. When the first event is triggered then
the outgoing sequence flow of this event is taken. No other events of the gateway
can be triggered afterward.
Event Based Gateway Example
BPMN2.0 - Activities
It is a work that company or organization performs in a business process.
Activities can be performed by person or a system. It can be task or sub-
processes.
There are 3 types of activities in BPMN2.0
1. Task
2. Sub Process
3. Call Activity
Task
A person or applications will perform the task when it is executed.
In BPMN 2.0, there are different types of tasks identified for use in representing more
specific behavior that tasks might represent. Here is a list of BPMN 2.0 task type:
•Service Task
•Send Task
•Receive Task
•User Task
•Manual Task
•Business Rule Task
•Script Task
Task – Service Task
A Service Task is a Task that uses a Web service, an automated application, or other
kinds of service in completing the task.
Task – Send Task
A Send Task is represents a task that sends a Message to another lane or pool. The Task
is completed once the Message has been sent.
Task – Receive Task
A Receive Task indicates that the process has to wait for a message to arrive in order
to continue. The Task is completed once the message has received.
Task – User Task
A User Task represents that a human performer performs the Task with the use of a
software application.
Task – Manual Task
A Manual Task is a Task that is performed without the aid of any business process
execution engine or any application.
Task – Business Rule Task
Business rules describe initially in plain words how operations,

definitions, and constraints are applied by an organization. They can
apply to many different things like people, processes, or overall
corporate behavior.
It provides a mechanism for a process to provide input to a Business Rules Engine and
then obtain the output provided by the Business Rules Engine.
Business Rule Task - Example
Task – Script Task
A Script Task is executed by a business process engine. The task defines a script that the
engine can interpret. When the task begin, the engine will execute the script. The Task
will be completed when the script is completed.
BPMN2.0 Sub Process
A Sub-Process is an activity that contains other activities, gateways, events, and so on,
which in itself forms a process that is part of the bigger process. A Sub-Process is
completely defined inside a parent process (that’s why it’s often called an embedded Sub-
Process).
Constraints in using sub-process:
• A Sub-Process can only have one 'start event', no other start event types are allowed. A
Sub-Process must at least have one 'end event'. Note that the BPMN 2.0 specification
allows the omission of the start and end events in a Sub-Process
• Sequence flows cannot cross Sub-Process boundaries.
BPMN2.0 Sub Process Types
Types of BPMN2.0 sub process:
• Loop
• Multi-instance
• Compensation
• Ad-hoc
• Compensation and ad-hoc
BPMN2.0 sub process example
BPMN2.0 - Swimlanes
Swimlane objects in BPMN are rectangular boxes that represent participants of a
business process. A swim lane may contains flow objects that are performed by that lane
(participant), except for black box that must have an empty body.
Swimlanes may be arranged horizontally or vertically. They are semantically the same but
just different in representation. For horizontal Swimlanes, process flows from left to
right, while process in vertical Swimlanes flow from top to bottom.
There are two kinds of Swimlanes: Pools and Lanes.

Swimlanes - Pools
Pools represent participants in a business process. It can be a specific entity
(e.g. department) or a role (e.g. Administrator).
Inside a pool, there are flow elements. They represent the works that the
pool needs to perform under the process being modeled. However, there is
one kind of pool that has no content at all. It is known as the Blackbox
pool. Blackbox pool is often used when modeling entities external to the
business process. As it is external, its internal flow does not have any
impact on the process being modeled, hence can be skipped, producing a
Blackbox.
Pools - Examples
Swimlanes - Lanes
Lanes are sub-partition of pools. Same as pools, lanes can be used to
represent specific entities or roles who are involved in the process.
Swimlanes - Examples
BPMN2.0 – Connecting Objects
BPMN 2.0 defines four basic connecting objects: Sequence Flow, Message Flow
and two types of Associations. These connecting objects are graphically
represented with the following arrows.
Connecting Objects - Definition
• Sequence Flow - It is used to represent the order of Flow elements in process and
choreography models.
• Message Flow - It is used to show the flow of messages between two participants that
are able to send and receive them. In BPMN, two separate Pools in a Collaboration
Diagram will represent the two Participants.
• Data Association - It is used to show the flow of information between Activities in a

business process.
• Association – It is used to link Artefacts with other BPMN (graphical) elements.

Connecting Objects - Examples
BPMN2.0 - Artifacts
In business process modeling, BPMN Artifacts can be used to include additional
information about a process. There are two types of BPMN Artifacts: Group and Text
Annotation. You can use them to organize tasks and sub-processes or to add
comments/notes in describing process elements.
Artifacts - Grouping
BPMN Group is a visual container to use in creating informal, arbitrary grouping for elements
in a business process diagram. You can create a Group to contain elements that belong
together based on some common characteristic.
Artifacts - Annotations
A BPMN Text Annotation is simply a note – a note to process element or to the business
process itself. You can use Text Annotation to include addition information to flow
objects. Because Text Annotation is presented directly on the diagram, readers can
easily see the information without the need to drill-down into the specification of
elements.
Data Objects - Examples
Assessment
BPMN2.0 Practice Question1
As soon as an invoice is received from a customer, it needs to be checked for mismatches.
• The check may result in either of these three options: –
i) there are no mismatches, in which case the invoice is posted;

ii) there are mismatches but these can be corrected, in which case the invoice is re-sent to
the customer; and
iii) there are mismatches but these cannot be corrected, in which case the invoice is
blocked.
• Once one of these three activities is performed the invoice is parked and the process
completes.
BPMN2.0 – Practice Question 2
Once the boarding pass has been received, passengers proceed to the
security check. Here they need to pass the personal security screening and
the luggage screening. Afterwards, they can proceed to the departure level.
A company has two warehouses that store different products: Amsterdam
and Hamburg.
When an order is received, it is distributed across these warehouses: if some

of the relevant products are maintained in Amsterdam, a sub-order is sent
there; likewise, if some relevant products are maintained in Hamburg, a sub-
order is sent there.
Afterwards, the order is registered and the process completes.

BPMN2.0- Practice Question 4
After the reception of a meeting remainder, a new account must be created
if the employee does not already have one. The report is then reviewed for
automatic approval. Amounts under $200 are automatically approved,
whereas amounts equal to or over $200 require approval of the supervisor.
In case of rejection, the employee must receive a rejection notice by email.

The reimbursement goes to the employee’s direct deposit bank account. If
the request is not completed in 7 days, then the employee must receive an
“approval in progress” email If the request is not finished within 30 days,
then the process is stopped and the employee is advised to start again.
BPMN2.0 - Practice Question 5
Customer sends order to company A.
Order needs to be entered to CRM system and checked by operations and if

something is missing/wrong operations ask internal call center to contact the
customer and correct the order. When order is OK, it is sent to fulfillment for
company B (vendor).
Vendor sends the product to the customer.
Since the case study does not give you all the details you are free to make
some assumptions and create a diagram accordingly.
BPMN2.0 - Practice Question 6
The customer calls the support center and reports an issue about underperforming service or faulty equipment or
software.
The Front Office collects information from the Customer and tries to provide a solution directly to the Customer on the
other end of the line, otherwise they inform the Customer the issue is going to be escalated to technical experts and
they will be contacted again soon.
When the Front Office receives the solution from the technical experts, they contact the customer and try to close the
issue; otherwise they inform the Customer that the issue is going to be further escalated.
When the issue is escalated to the 1st Level Technical Support Agent, the agent tries to provide a solution to the Front
Office; otherwise they request further assistance from the 2nd Level Technical Support Agent and forward the solution
to the Front Office when a solution has been provided.
When the issue is escalated to the 2nd Level Technical Support Agent, the agent tries to find a solution for the 1st Level
Technical Support Agent; otherwise they request further assistance from the Supplier and forward the solution to the
1st Level Technical Support Agent when provided.
When the Supplier receives a request from the 2nd Level Technical Support Agent they provide a solution to the
reported issue. You are free to make assumptions if any details are missing.
The process starts when HR department receives information from a Candidate that she accepted the job offer. HR clerk
needs to send the contract to Candidate.
If the Candidate signed the contract, Clerk needs to notify the Responsible Department. In this case Candidate details are
stored in HRM application.
If the Candidate did not sign the contract, Clerk needs to review the contract and send it to Candidate (again).
After notifying the Responsible Department, Clerk needs to inform the Candidate of company policies and procedures.
Afterwards Candidate is registered for the medical insurance.
After receiving the notification, Responsible Department Clerk needs to identify the necessary preparations (on a basis of
data from the HRM application).
Preparations are standard procedures handled by other departments: IT (Prepare IT Environment), Payroll (Update Payroll
Records) and Facilities (Configure Access Cards).
When all 3 aspects were finished, Clerk needs to compile the welcome package for the new employee.
When this is done and HR Clerk registered the Candidate for medical insurance, Responsible Department Clerk passes the
welcome package to their new colleague, assigns a mentor and defines dates of necessary training.
This completes the process and new employee is ready for work.
You are free to make assumptions, if any details are missing.
You have been tasked with preparing the following Business Process Diagram ( BPD) using BPMN 2.0
Process Name : Administer Insurance Application

Company Name : Green Trees Insurance Limited
Process Participants : Sales Department , Underwriting Department
The process starts when an insurance application form is received from the customer by the Sales Department.
The first task is for the Sales Department to "Review Application". This task is performed by a system without any human
intervention.
If the application is completed correctly it gets sent to the Underwriting team
The first task for the Underwriting team is to review the applicant to see if he or she is deemed okay to insure
If the applicant is deemed okay to insure then the Underwriting team create a policy. They then send a copy a policy
confirmation notification to the customer and the process ends.
If the application is not complete when received by the Sales department it gets returned to the customer and the
process ends
If the Underwriting team are not comfortable insuring the applicant then the customer gets notified that their insurance
request has been rejected and the process ends.
You have been tasked with preparing the following Business Process Diagram ( BPD) using BPMN 2.0
Process Name : Administer Insurance Application

Company Name : Yellow Trees Limited
Process Participants : Policy Administration Department , Underwriting Department
The process starts when an insurance application form is received from the customer by the Policy Administration Department.
The first tasks are for the Admin Department to review the application for completeness" and to "Validate the customers proof of
identity (POI) details. Both of these tasks are performed by a human and can be completed in parallel.
If the application is completed correctly and if the POI details are validated the application moves to underwriting where a human
checks the applicants credit history
If the applicants credit history is okay then the Underwriting team create a policy. Once the policy is created the applicant gets an
automated notification informing them of their policy details and the process ends.
However, if the applicants credit history is not okay then a human sends them a rejection notification and the process ends.
Also, if the application that the customer submitted is deemed to be incomplete by the Policy Admin Team, then a signal is sent to the
other parallel path so that the task of validating the customers POI, if still being undertaken, can be interrupted and that path
brought to an end.
The application is returned to the customer and that path is brought to an end also.
If, while validating the customers POI details, an exception is found then the process level terminates immediately.
• A loan application is approved if it passes two checks: i) the Applicant’s credit history check,
done by a Financial Officer, and ii) the Applicant’s loan risk assessment, done by a Risk
Assessor. Once both checks have been performed, a Loan Officer can assess the Applicant’s
eligibility. If the Applicant is not eligible, the application is rejected, otherwise it is
approved.
• A loan application may be coupled with a home insurance which is offered at discounted
prices. The Applicant may express their interest in a home insurance plan at the time of
submitting their loan application to the Loan Provider. Based on this information, if the
loan application is approved, the Loan Provider may either only send an acceptance pack to
the Applicant, or also send a home insurance quote.
The motor claim handling process starts when a customer submits a claim
with the relevant documentation. The notification department at the car
insurer checks the documents upon completeness and registers the claim.
Next, the handling department picks up the claim and checks the insurance.
Then, an assessment is performed. If the assessment is positive, a garage is
phoned to authorize the repairs and the payment is scheduled (in this order).
Otherwise, the claim is rejected. In any case (whether the outcome is positive
or negative), a letter is sent to the customer and the process is considered to
be complete.
After a supplier notifies a retailer of the approval of a purchase order, the
supplier can either receive an order confirmation, an order change or an
order cancelation from the retailer. It may happen that no response is
received at all. If no response is received after 48 hours, or if an order
cancelation is received, the supplier will cancel the order. If an order
confirmation is received within 48 hours, the supplier will process the order
normally. If an order change is received within 48 hours, the supplier will
update the order and ask again the retailer for confirmation. The retailer is
allowed to change an order at most three times. Afterwards, the supplier will
automatically cancel the order. If the order is canceled the supplier send a
customer feedback questionnaire request to retailer.
Max is facing a new challenge. He receives a shipment from the wholesaler
and doesn’t know what to do next. His boss tells him: No worries Max. First
you check whether the order and the invoice are correct. If not, you give the
package back to the shipping clerk. If it’s correct you check if it’s a standard
order or if it’s an ordered by a customer. If it’s a standard order you simply
put the shoes into the warehouse. If it’s an order for a customer, put the
shoes behind the cash deck and that’s it! Your job now is to help Max by
creating a simple process. Ignore the tasks of the shipping clerk for now. Just
model what Max needs to do.
Gonzales has an idea. As his fuel team acted a bit slow the last time, he talks
to his manager and tells him: When I arrive at the box, both teams start to
work in parallel as usual. The wheel team simply changes the wheels. The
fuel team however, first checks how many rounds are left. If 5 or less rounds
are left, the fuel team will fill only half of the gas tank. If more than 5 round
are left, the entire gas tank needs to be filled. So the fuel refill is faster when
5 or less rounds are left. Your job now is to help the head of mechanics to
map the process so he can effectively communicate the procedure with his
team.
BPMN2.0 – Practice Questions 15
Susan is still keen on further optimizing the customer experience! Therefore,
she chats with her boss and tells him that she wants to develop a new process
that works like this: After the sample has been sent, I will dispatch a product
catalogue to the customer. We have only 2 product catalogues. I will check
which samples I've sent to the customer. If he or she got a cosmetic product,
I'll send our cosmetic catalogue. If he or she got a voucher, I'll send our
standard catalogue. If he or she received both, I'll send both catalogues. After
that, I'll document the catalogue shipment in our CRM system. Your job now is
to map this new process so Susan can effectively communicate the procedure
with her team.
The Wholesaler ‘Luxxis’ is a small company that sells Hi-Fi Equipment. In the early days the company developed and
produced its own Hi-Fi Equipment. However, cheap products from China turned the production into a loss-making
business. Therefore, Robert Smith, the son of the founder, turned the business into a profitable wholesaler by focusing on
their strong brand and establishing and excellent customer service.
The ‘Order Received to Order Fulfilled’ process is the heart of the operative side of the business. When a customer orders
a good, it is absolutely critical that she receives the ordered Hi-Fi equipment in time and is always informed about the
state of the order.
Robert Smith, the CEO of ‘Luxxis’, has just discovered how powerful BPMN is for the optimization and automation of his
business. The process documentation is always the first step for a process optimization or automation. He therefore hired
you as a consultant to map the ‘Order Received to Order Fulfilled’ process in BPMN. That’s why, you talk John Hank, the
Head of Operations in order to better understand the process.
Question 16 - Continued
The process starts when we receive an order from a customer. The accounting will then check if the order is valid. If
the order is not valid, for example if the customer forgot to state the amount of desired goods, the responsible sales
manager will contact the customer and correct the order.
After this, the warehouse team start their work. They will check if the ordered items are available. If so, all items will
be packed and shipped. Then, a shipping confirmation will be sent to the customer. If some Items are not in stock,
however, the warehouse team orders the missing items from the supplier. Then, they will inform the customer about
the delayed delivery. As soon as the items have arrived, they will pack and ship the items, and inform the customer,
as before.
Now, during the warehouse is executing these tasks, the accounting generates the invoice. They will send this invoice
to the customer, after the warehouse team has sent the shipping confirmation. Now, as soon as the accounting team
has received the money from the customer, they will close the case. With this, the process ends.
It’s now your task to translate the spoken words into a BPMN 2.0 process.
Space tourist are extremely demanding customers. You are hired as a consultant to design the boarding
process. The CEO of “Space Z” tells you: “When the passenger arrives at the space station, the boarding team
will perform the check-in. After that they will bring him or her to the waiting lounge. And - as we have very
demanding passengers - the boarding team will offer him or her cold drinks and snacks.
Thirty minutes before take off, the passenger will then be guarded safely on the space ship to his seat. In the
meantime, after the check-in, the cargo team will load the luggage of the passenger onto the cargo container.
Now one of two events can occur. First, the cargo container may be fully loaded. If this is the case, the cargo
team will load the container onto the space ship.
The second option is that only 30 minutes before take off are left. In this case, all containers – no matter if they
are full or not - will be collected and then loaded onto the space ship. After both teams have completed their
tasks, the space ship is ready for take off.”
Use Case Diagram
It is a diagram that captures high level functionality of a system using
notations for actors, use cases, and relationship among them. It summarizes
the details of your system's users (also known as actors) and their
interactions with the system.
A Use Case Diagram can help project team members discuss and represent:
• Scenarios in which your system or application interacts with people,
organizations, or external systems.
• Goals that your system or application helps those entities (known as
actors) achieve.
• The Scope of your system
Origin of Use Case Diagram
These days use case modeling is often associated with UML, although it has
been introduced before UML existed. Its brief history is as follow:
•In 1986, Ivar Jacobson first formulated textual and visual

modeling techniques for specifying use cases.
•In 1992 his co-authored book Object-Oriented Software Engineering - A Use

Case Driven Approach helped to popularize the technique for capturing
functional requirements, especially in software development.
Use Case Diagram – Purpose?
A use case diagram doesn't go into a lot of detail—for example, don't expect it to model
the order in which steps are performed. Instead, a proper use case diagram depicts a high-
level overview of the relationship between use cases, actors, and systems.
It can be applied for:
• Representing the goals of system-user interactions
• Defining and organizing functional requirements in a system
• Specifying the context and requirements of a system
• Modeling the basic flow of events in a use case

Components of Use Case Diagram
There are 4 key elements of Use Case Diagram:
1. Use Cases
2. Systems
3. Actors
4. Associations.
Sample Use Case Diagram
Use Case Diagrams – Components in detail
Actors: Actor is someone who interacts with use case(system functions) and has a responsibility toward the
system (inputs), and has expectations from the system (outputs). It is similar to the concept of users and is named
by a noun. It always stays away from the system boundary. Primary actors initiates/triggers the use case and their
goal is fulfilled by use case. Secondary actors provide information to the system and is sometimes referred to as
an external system. Primary actors are usually shown on the left of the system boundary and secondary actors
are shown towards the right. An actor can be a human or a system.
Use Cases: It represents system functions and is named by verb + noun. Each Actor must be linked to a use case,
while some use cases may not be linked to actors.
•Association: The participation of an actor in a use case is shown by connecting an actor to a use case by a solid
link. Actors may be connected to use cases by associations, indicating that the actor and the use case
communicate with one another using messages. Association can be between use cases and between actors.
•System: The system boundary is potentially the entire system as defined in the requirements document. For
large and complex systems, each module may be the system boundary. For example, for an ERP system for an
organization, each of the modules such as personnel, payroll, accounting, etc. can form a system boundary for
use cases specific to each of these business functions. The entire system can span all of these modules depicting
the overall system boundary
Use Case Diagram – Identifying Actors
• Who are the system’s primary users?
• Who requires system support for daily tasks?
• Who are the system’s secondary users?
• What hardware does the system handle?
• Which other (if any) systems interact with the system in question?
• Do any entities interacting with the system perform multiple roles as
actors?
• Which other entities (human or otherwise) might have an interest in the
system's output?
Association – Between Actors and Use Case
Associations between Use Cases - Include
When a use case is depicted as using the functionality of another use case, the relationship between the use cases is
named as include or uses relationship.
An include relationship is depicted with a directed arrow having a dotted line. The tip of arrowhead points to the child use
case and the parent use case connected at the base of the arrow. The stereotype "<<include>>" identifies the relationship
as an include relationship.
Association between Use Case - Extend
When an optional behavior is added to use Case then it can be shown through Extend relationship. It helps
keep the base use case unchanged while adding more specifics or conditional changes. Here base use case
is independent of the extend use case.
The stereotype "<<extends>>" identifies as an extend relationship

Associations between Use Case - Generalization
A generalization relationship is a parent-child relationship between use cases. The child use case is an enhancement of the
parent use case. Generalization is shown as a directed arrow with a triangle arrowhead. The child use case is connected at
the base of the arrow. The tip of the arrow is connected to the parent use case.
A generalization relationship means that a child use case inherits the behavior and meaning of the parent use case. The child
may add or override the behavior of the parent.
Generalization – Example
How to create a Use Case Diagram?
1.List main system functions (use cases) in a column: think of
business events demanding system’s response – users’
goals/needs to be accomplished via the system
2.Draw ovals around the function labels
3.Draw system boundary
4.Draw actors and connect them with use cases
5. Specify include, extend, and generalization relationships
between use cases
Use Case Diagram – Assignment 1
Railway Reservation System is a system used for booking tickets over internet. Any
Customer Can book tickets for different trains. Customer can book a ticket only if the
tickets are available. Customer searches for the availability of tickets then if the tickets
are available, he books the tickets by initially filling details in a form. Tickets can be
booked in two ways by i-ticket or by e-ticket booking.
In case of i-ticket booking customer can book the tickets online and the tickets are
couriered to Particular customer at their address. But in case of e-ticket booking and
cancelling tickets are booked and cancelled online sitting at the home and customer
himself has to take print of the ticket but in both the cases amount for tickets are
deducted from customer’s account. For cancellation of ticket the customer has to go at
reservation office than fill cancellation form and ask the clerk to cancel the ticket than
the refund is transferred to customer account. After booking ticket the customer has to
checkout by paying fare amount to clerk.
Use Case Diagram – Assignment 2
1.User who registers himself as a new user initially is regarded as staff or student for the library system.
1. For the user to get registered as a new user, registration forms are available that is needed to be fulfilled by the
user.
2. After registration, a library card is issued to the user by the librarian. On the library card, an ID is assigned to
cardholder or user.
2.After getting the library card, a new book is requested by the user as per there requirement.
3.After, requesting, the desired book or the requested book is reserved by the user that means no other user can request
for that book.
4.Now, the user can renew a book that means the user can get a new due date for the desired book if the user has
renewed them.
5.If the user somehow forgets to return the book before the due date, then the user pays fine. Or if the user forgets to
renew the book till the due date, then the book will be overdue and the user pays fine.
6.User can fill the feedback form available if they want to.
7.Librarian has a key role in this system. Librarian adds the records in the library database about each student or user every
time issuing the book or returning the book, or paying fine.
8.Librarian also deletes the record of a particular student if the student leaves the college or passed out from the college. If
the book no longer exists in the library, then the record of the particular book is also deleted.
9.Updating database is the important role of Librarian.
Data Flow Diagram
Data flow diagrams are used to graphically represent the flow of data from one
component to another component in a business information system. Through
DFD we can give overview of the system without going into the deep detail of
the system.
They can be used to analyze an existing system or model a new one. Like all the
best diagrams and charts, a DFD can often visually “say” things that would be
hard to explain in words, and they work for both technical and nontechnical
audiences.
Logical DFD vs physical DFD
These are the two categories of a data flow diagram: Logical and Physical.
A logical DFD focuses on the business and business activities, while a physical DFD looks at
how a system is implemented. So while any data flow diagram maps out the flow of
information for a process or system, the logical diagram provides the “what” and the
physical provides the “how.” They are two different perspectives on the same data flow,
each designed to visualize and improve the system. The logical DFD describes the business
events that take place and the data required for each event.
It provides a solid basis for the physical DFD, which depicts how the data system will work,
such as the hardware, software, paper files and people involved. In tandem, the logical and
physical can fully visualize the current state and model the new state to be considered and
then implemented.
Logical DFD vs Physical DFD - Example
Components of DFD
External Entity – Also known as actors, sources or sinks, and terminators, external entities produce and consume data that flows
between the entity and the system being diagrammed. These data flows are the inputs and outputs of the DFD. Since they are external
to the system being analyzed, these entities are typically placed at the boundaries of the diagram. They can represent another system
or indicate a subsystem.
Process – An activity that changes or transforms data flows. Since they transform incoming data to outgoing data, all processes must
have inputs and outputs on a DFD. This symbol is given a simple name based on its function, such as “Ship Order,” rather than being
labeled “process” on a diagram. In Gane-Sarson notation, a rectangular box is used and may be labeled with a reference number,
location of where in the system the process occurs and a short title that describes its function. Processes are typically oriented from top
to bottom and left to right on a data flow diagram.
Data Store – A data store does not generate any operations but simply holds data for later access. Data stores could consist of files held
long term or a batch of documents stored briefly while they wait to be processed. Input flows to a data store include information or
operations that change the stored data. Output flows would be data retrieved from the store.
Data Flow – Movement of data between external entities, processes and data stores is represented with an arrow symbol, which
indicates the direction of flow. This data could be electronic, written or verbal. Input and output data flows are labeled based on the
type of data or its associated process or data store, and this name is written alongside the arrow.
DFD- Symbols and Notations
Stating the type of data – D, M, T
Each data store which is drawn in a Data Flow Diagram are prefixed by a letter, which is 'D'
by default. The letter indicates the kind of data the data store holds. The letter 'D' is used to
represent a persistent computerized data, which is probably the most common kind of data
type in a typical information system.
Besides computerized data, data can also be held for a short time in temporary. We call this
kind of data transient data and is represented by letter 'T’.
Sometimes, data is stored without the use of a computer. We call this kind of data manual
data and is represented by letter 'M'. Finally, if the data is stored without using computer
and also is held for a short time, this is known as manual transient data and is represented
by T(M).
Rules for making DFD diagrams
1.Process labels should be verb phrases; data stores are represented by nouns
2.A data store must be associated with at least a process
3.An external entity must be associated with at least a process
4.Don't let it get too complex; normally 5 - 7 average people can manage processes
5.DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's
useful in identifying the processes when discussing with users
6.Datastores should not be connected to an external entity, otherwise, it would mean that
you're giving an external entity direct access to your data files
7.Data flows should not exist between 2 external entities without going through a process
8.A process that has inputs but without outputs is considered to be a black-hole process
Cautions while preparing DFD
Keep in mind that Data Flow Diagram was designed for representing the
exchange of information. Connectors in a Data Flow Diagram are for
representing data, not for representing process flow, step or anything else.
When we label a data flow that ends at a data store "a request", this means we
are passing a request as data into a data store. Although this may be the case
in implementation level as some of the DBMS do support the use of functions,
which intake some values as parameters and return a result, in Data Flow
Diagram, we tend to treat data store as a sole data holder that does not
possess any processing capability.
Common mistakes while making DFD diagram
Data Flow Diagram – Levels and Layers
DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or
beyond. The necessary level of detail depends on the scope of what you are
trying to accomplish.
DFD level 0 is also called context diagram and is at very high level. As you
keep on adding details in your DFD diagram, the level increases accordingly.
There is no specific definition or criteria for DFD levels.

DFD – Level 0 diagram(Context Diagram)
It’s a basic overview of the whole system or process being analyzed or modeled. It’s
designed to be an at-a-glance view, showing the system as a single high-level process, with
its relationship to external entities. It should be easily understood by a wide audience,
including stakeholders, business analysts, data analysts and developers.
DFD – Level 1 diagram
DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You will highlight the main functions
carried out by the system, as you break down the high-level process of the Context Diagram into its subprocesses.
DFD – Level 2 diagram
DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach the necessary level of
detail about the system’s functioning.
DFD – Assignment 1
Draw a data flow diagram for a railway company’s customer service system. The two external entities that will interact
with the system are : Customer Service executive and Passenger.
The processes involved are: Inquire transport details, Buy Souvenir, Buy ticket, and Report Lost.
A Passenger can receive Transport details from the Inquiry Transport Details process, and the details are provided by the
data stores Transport Details and Railway Live Statistic. CS Assistant can initiate the Buy Souvenir process, which will
result in having the Order details stored in the Order data store. Although customer is the real person who buy souvenir,
it is the CS Assistant who accesses the system for storing the order details.
CS Assistant can also initiate the Buy Ticket process by providing Order details and the details will be stored again in
the Order data store.
Finally, CS Assistant can initiate the Report Lost process by providing the Incident and item details and the information
will be stored in the Lost Item database.
DFD – Assignment 2
Draw a data flow diagram for Food Ordering System. The external entities are: Supplier,
Kitchen, Manager, and Customer.
The Food Order System contains three processes, four external entities, and two data stores.
Customer can place an Order. The Order Food process receives the Order, forwards it to
the Kitchen, store it in the Order data store, and store the updated Inventory details in
the Inventory data store. The process also delivers a Bill to the Customer.
The Manager can receive Reports through the Generate Reports process, which
takes Inventory details and Orders as input from the Inventory and Order data store
respectively.
The Manager can also initiate the Order Inventory process by providing Inventory order. The
process forwards the Inventory order to the Supplier and stores the updated Inventory
details in the Inventory data store.
Entity Relationship Diagram
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities”
such as people, objects or concepts relate to each other within a system. ER Diagrams are
most often used to design or debug relational databases in the fields of software
engineering, business information systems, education and research.
ER diagrams are related to data structure diagrams (DSDs), which focus on the relationships
of elements within entities instead of relationships between entities themselves. ER
diagrams also are often used in conjunction with data flow diagrams (DFDs), which map out
the flow of information for processes or systems.
Uses of ER Diagram
•Database design: ER diagrams are used to model and design relational databases, in terms of logic and
business rules (in a logical data model) and in terms of the specific technology to be implemented (in a
physical data model.) In software engineering, an ER diagram is often an initial step in determining
requirements for an information systems project. It’s also later used to model a particular database or
databases. A relational database has an equivalent relational table and can potentially be expressed that way
as needed.
•Database troubleshooting: ER diagrams are used to analyze existing databases to find and resolve problems
in logic or deployment. Drawing the diagram should reveal where it’s going wrong.
•Business information systems: The diagrams are used to design or analyze relational databases used in
business processes. Any business process that uses fielded data involving entities, actions and interplay can
potentially benefit from a relational database. It can streamline processes, uncover information more easily
and improve results.
•Business process re-engineering (BPR): ER diagrams help in analyzing databases used in business process re-
engineering and in modeling a new database setup.
Levels of ER Model
ER Models are typically drawn at up to three levels of detail:
•Conceptual data model: The highest-level view containing the least detail. Its value is
showing overall scope of the model and portraying the system architecture. For a system of
smaller scope, it may not be necessary to draw. Instead, start with the logical model.
•Logical data model: Contains more detail than a conceptual model. More detailed
operational and transactional entities are now defined. The logical model is independent of
the technology in which it will be implemented.
•Physical data model: One or more physical model may be developed from each logical
model. The physical models must show enough technology detail to produce and implement
the actual database.
Limitations of ER Diagram
•Only for relational data: Understand that the purpose is to show relationships. ER
diagrams show only that relational structure.
•Not for unstructured data: Unless the data is cleanly delineated into different fields, rows
or columns, ER diagrams are probably of limited use. The same is true of semi-structured
data, because only some of the data will be useful.
•Difficulty integrating with an existing database: Using ER Models to integrate with an

existing database can be a challenge because of the different architectures.
Components of ER Diagram
An ER Diagram has basically 3 components:
1. Entity - A definable thing—such as a person, object, concept or event—that can have data stored about it. Think of
entities as nouns. Examples: a customer, student, car or product.
2. Attribute - A property or characteristic of an entity.
3. Relationship - How entities act upon each other or are associated with each other
ERD Cardinality
Primary Key and Foreign Key
Composite keys
Understanding ER in a Table - Customer
Order Table
Product Table
Shipment Table
Primary Keys, Foreign Keys, Composite Primary Key - Examples
Bridge Table
Activity Diagram
The activity diagram is a flowchart to represent the flow of control among the activities in a
system. So, we basically depict workflows visually using an activity diagram. An activity
diagram focuses on condition of flow and the sequence in which it happens. We describe or
depict what causes a particular event using an activity diagram.
An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed. The flow of operation
can be sequential, branched, or concurrent. The activity diagram is sometimes considered as
a flowchart. Although the diagram looks like a flowchart but it is not.
Components of Activity Diagram
1. Start Node – The black small filled circle is the standard notation for an initial state before an activity take place.
2. Final activity node – The black circle that looks like a selected radio button is the symbol for the end state of
activity.
3. Activity – The activity symbols are the basic building blocks of an activity diagram and usually have a short description
of the activity that they represent.
4. Control flow – A solid line with an arrow represent the direction flow of the activities. The arrow points in the direction of
progressing activities.
5. Join Node – A join combines two concurrent activities back into a flow.
6. Fork Node – A fork splits single activity into two concurrent activities.
Fork and Join - Example
7. Decision – Diamond shape where two paths coming out of a decision and the condition text lets you know which options
are mutually exclusive.
8. Condition – It is placed next to a decision marker to let you know under what condition an activity flow should split off in
that direction.
9. Merge Node – Two activities are merged with condition and only one activity flows forward.
10. Final Flow Node – It represents the end of a specific process flow.
11. Partition – It is also known as swim lanes which are used to represent or group actions carried out by different actors in
a single thread.
12. Note – It is used to add relevant comment to elements.
13. Time event - This refers to an event that stops the flow for a time; an hourglass depicts it.
Activity Diagram – Assignment 1
Process Order - Problem Description:
Once the order is received, the activities split into two parallel sets of activities. One side fills and sends the order whi le the
other handles the billing.
On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight
Delivery activity or the Regular Delivery activity is performed.
Finally the parallel activities combine to close the order.

Activity Diagram – Assignment 2
Student Enrollment:
•An applicant wants to enroll in the university.

•The applicant hands a filled out copy of Enrollment Form.
•The registrar inspects the forms.
•The registrar determines that the forms have been filled out properly.
•The registrar informs student to attend in university overview presentation.
•The registrar helps the student to enroll in seminars
•The registrar asks the student to pay for the initial tuition.
Class Diagrams
Class Diagram is one of the most popular structural UML diagrams that helps to visualize, describe(what must be
present in the system being modeled), and document different aspects of the system that has to be designed.
A UML class diagram has 3 sections:
1. Top section - It represents the name of the class. A class represents an object or a set of objects that share a
common structure and behavior.
2. Middle section - It represents the attributes of the class. Attributes are a significant piece of data containing
values that describes each instance of the class. The attributes are shown by visibility factors such as public (+),
private (-), protected (#), and package (~).
3. Lower section - It represents the methods of the class. Methods are also called operations or functions that
allows you to specify any behavioral feature of a class. The methods are represented in the form of a list, where
each method is written in a single line. It demonstrates how a class interacts with data.
Class Diagrams – Visibility factors
• Private (-) : They can't be accessed by any other class or sub class.
• Public(+) : This is just opposite to private and can be accessed by any other class.
• Protected(#) : This can only be accessed by same class or sub class.
• Package(~) : This can be used by any other class as long as it is in the same package.
Class Diagrams - Relationships
1. Inheritance - It means the subclass(child) inherits all the methods and properties of super class. It is also
known as generalization and is symbolized with a straight connected line with a closed arrowhead pointing
towards the superclass(parent).
2. Association - It describes a static or physical connection between two or more objects. It depicts how many
objects are there in the relationship. It is shown by a straight line.
3. Aggregation - An aggregation is a subset of association that defines a part-whole or part-of relationship. In

this kind of relationship, the child class can exist independently of its parent class. It is shown by a line with
open diamond.
4. Composition - The composition is a subset of aggregation. It portrays the dependency between the parent
and its child, which means a child object wouldn't be able to exist if parent object is discarded. It represents
a whole-part relationship. It is shown by a line with closed diamond.
Class Diagrams – Additional Components
Multiplicity - It allows you to set numerical constraints on your relationship. It
defines a specific range of allowable instances of attributes. In case if a range is
not specified, one is considered as a default multiplicity.
Abstract Class - It is a type of class where no objects can be a direct entity of it.
It can can neither be declared nor be instantiated and is is written in italics.
Class Diagram - Example
SQL – Structured Query Language
Database : A database is a collection of information involving relationships between the data stored in it.
• Fields and records make up a table.

• One or more tables make up a database.
What is SQL?
SQL stands for structured query language that helps us to formulate questions a database can
respond to.
Properties of SQL:
• Write a question which a database can understand.

• It is white space independent.
• Express what you mean explicitly.
• Often is a series of smaller questions.
• Adopted into many DBMS.
• Language is SQL
• Originally called SEQUEL (It stands for Structured English Query Language.)
SQL statements
SQL statements are used to perform tasks such as update data on a database, or retrieve data
from a database. The standard SQL commands such as "Select", "Insert", "Update", "Delete",
"Create", and "Drop" can be used to accomplish almost everything that one needs to do with a
database.
STATEMENT
White Space Independent
Clauses
SQL Statements - Continued
Dual Roles of SQL
SQL Keyword
SELECT - The SELECT keyword tells the database we want some information returned to us.
WHERE – The WHERE keyword lets us add selection criteria to a statement.
LIKE ‘%...’ – This keyword return results that match part of a string. The % character represents the portion of the string to
ignore.
LIMIT - This keyword tells the database to stop returning results after n results has been returned.
OFFSET – This keywords tells the database to skip certain records.
ORDER BY – This keyword tells the database to order the record of a column in ascending or descending order.
LENGTH – It returns the length of the record.
DISTINCT – It returns the unique rows.
COUNT – It returns the total number of records.

Check your understanding
SQL - JOINS
It asks for records across two tables that are associated with each other based on a common piece of information.
SQL – CROSS JOINS
SQL – INNER JOINS
SQL – LEFT(OUTER) JOIN
SQL – RIGHT (OUTER) JOIN
SQL – FULL (OUTER) JOIN
Check your understanding
SQL – Data Types
Math in SQL
CRUD OPERATION
The INSERT keyword adds a record to a table.
The UPDATE keyword changes data stored in fields in a record.
The DELETE keyword deletes the rows.

Scrum- Overview
Scrum is one of the most popular Agile methods. It is an adaptive, iterative, fast, flexible, and effective framework designed
to deliver significant value quickly and throughout a project. Scrum ensures transparency in communication and creates an
environment of collective accountability and continuous progress.
A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into
short, concentrated work cycles called Sprints. Figure provides an overview of a Scrum project’s flow
The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product
Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project
requirements written in the form of User Stories.
Each Sprint begins with a Sprint Planning Meeting during which high priority User Stories are considered for
inclusion in the Sprint. A Sprint generally lasts between one and six weeks and involves the Scrum Team working
to create potentially shippable Deliverables or product increments.
During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss
daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner
and relevant stakeholders are provided a demonstration of the Deliverables.
The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint
cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and
performance as they move forward into the subsequent Sprint
Scrum Principles
Scrum principles are the core guidelines for applying the Scrum framework and should mandatorily be used in all Scrum
projects. The six Scrum principles presented in chapter 2 are:
1. Empirical Process Control

2. Self-organization
3. Collaboration
4. Value-based Prioritization
5. Time-boxing
6. Iterative Development
1. Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of
transparency, inspection, and adaptation.
2. Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized
and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more
conducive for growth.
3. Collaboration—This principle focuses on the three core dimensions related to collaborative work: awareness, articulation,
and appropriation. It also advocates project management as a shared value-creation process with teams working and
interacting together to deliver the greatest value.
4. Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from early in
the project and continuing throughout.
5. Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively
manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint
Planning Meetings, and Sprint Review Meetings.
6. Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and
build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related
to iterative development.
Scrum Aspects
1. Organization - Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the
successful implementation of Scrum. Scrum roles fall into two broad categories:
a) Core Roles—Core roles are those roles which are mandatorily required for producing the project’s product or
service. Individuals who are assigned core roles are fully committed to the project and are ultimately responsible for the
success of each project iteration and of the project as a whole.
These roles include:

• The Product Owner is the person responsible for achieving maximum business value for the project. He or she is also
responsible for articulating customer requirements and maintaining business justification for the project. The Product
Owner represents the Voice of the Customer
• The Scrum Master is a facilitator who ensures that the Scrum Team is provided with an environment conducive to
complete the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone
involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed.
• The Scrum Team is the group or team of people who are responsible for understanding the requirements specified by
the Product Owner and creating the Deliverables of the project.
b) Non-core Roles—Non-core roles are those roles which are not mandatorily required for the Scrum project and
may include team members who are interested in the project. They have no formal role in the project team and
may interface with the team, but may not be responsible for the success of the project. The non-core roles should
be taken into account in any Scrum project. Non-core roles include the following:
• Stakeholder(s), which is a collective term that includes customers, users, and sponsors, frequently interface
with the Scrum Core Team, and influence the project throughout the project’s development. Most importantly, it
is for the stakeholders that the project produces the collaborative benefits.
• Scrum Guidance Body (SGB) is an optional role, which generally consists of a set of documents and/or a group
of experts who are typically involved with defining objectives related to quality, government regulations, security,
and other key organizational parameters. This SGB guides the work carried out by the Product Owner, Scrum
Master, and Scrum Team.
• Vendors, including external individuals or organizations, provide products and/or services that are not within
the core competencies of the project organization
2. Business Justification - It is important for an organization to perform a proper business assessment prior to starting any project. This helps
key decision makers understand the business need for a change or for a new product or service, the justification for moving forward with a
project, and its viability.
3. Quality - In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve
the business value expected by the customer. To ensure a project meets quality requirements, Scrum adopts an approach of continuous
improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog
updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the
project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to
continually work and adapt to achieve those requirements.
4. Change - Every project, regardless of its method or framework used, is exposed to change. It is imperative that project team members
understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that
arise from change and minimize any negative impacts through diligent change management processes in accordance with the principles of
Scrum.
5. Risk - Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or
failure. Risks that are likely to have a positive impact on the project are referred to as opportunities, whereas threats are risks that could
affect the project in a negative manner. Managing risk must be done proactively, and it is an iterative process that should begin at project
initiation and continue throughout the project’s lifecycle. The process of managing risks should follow some standardized steps to ensure that
risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.
Scrum Processes
Initiate Phase:
1. Create Project Vision—In this process, the Project Business Case is reviewed to create a Project Vision Statement that will
serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.
2. Identify Scrum Master and Stakeholder(s)—In this process, the Scrum Master and Stakeholders are identified using
specific Selection Criteria.
3. Form Scrum Team—In this process, Scrum Team members are identified. Normally the Product Owner has the primary
responsibility of selecting team members, but often does so in collaboration with the Scrum Master.
4. Develop Epic(s)—In this process, the Project Vision Statement serves as the basis for developing Epics. User Group
Meetings may be held to discuss appropriate Epics.
5. Create Prioritized Product Backlog—In this process, Epic(s) are refined, elaborated, and then prioritized to create a
Prioritized Product Backlog for the project. The Done Criteria is also established at this point.
6. Conduct Release Planning—In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product
Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with
the project stakeholders. Length of Sprint is also determined in this process
Plan and Estimate Phase:
7. Create User Stories—In this process, User Stories and their related User Story Acceptance Criteria are created. User Stories
are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted
and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team
members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.
8. Estimate User Stories—In this process, the Product Owner clarifies User Stories in order for the Scrum Master and Scrum
Team to estimate the effort required to develop the functionality described in each User Story.
9. Commit User Stories—In this process, the Scrum Team commits to deliver Product Ownerapproved User Stories for a Sprint.
The result of this process would be Committed User Stories.
10. Identify Tasks—In this process, the Committed User Stories are broken down into specific tasks and compiled into a Task
List.
11. Estimate Tasks—In this process, the Scrum Core Team estimates the effort required to accomplish each task in the Task List.
The result of this process is an Effort Estimated Task List.
12. Create Sprint Backlog—In this process, the Scrum Core Team creates a Sprint Backlog containing all tasks to be completed
in a Sprint as part of the Sprint Planning Meeting.
Implement Phase:
13. Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint
Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and
activities being carried out. Issues or problems being faced by the Scrum Team could be
updated in an Impediment Log.
14. Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is
conducted referred to as the Daily Standup Meeting. This is the forum for the Scrum Team to
update each other on their progress and any impediments they may be facing.
15. Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is
continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be
held, in which any changes or updates to the backlog are discussed and incorporated into the
Prioritized Product Backlog as appropriate.
Review and Retrospect Phase:
16. Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to
the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to
secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.
17. Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned
throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints.
Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance
Body Recommendations.
Release Phase:
18. Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant
stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
19. Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core
Team members assemble to retrospect the project and identify, document, and internalize the lessons learned.
Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in
future projects.
Scrum Vs Traditional Project Management

BA Learning Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BA Learning Material

Uploaded by

Copyright:

Available Formats

BA HELPL!

Note:- This is free material shared on LinkedIn

As per BABOK(Business Analysis Body of Knowledge) Version 3, it is

A business analyst is anyone who performs business analysis

A requirement is a physical or functional need that a particular design,

Functional Requirements Non-Functional Requirements

Stakeholder Mapping is the technique to map the identified stakeholder

Understanding each attribute in detail:

Stages in requirement elicitation:

Questions are of two types: Open Ended and Closed.

• Formal Workshops – These are highly structured workshops with group of

• Process Improvement Workshops – These are less formal as compared to formal

What is done in Workshops?

Questions in the survey are again of two types:

When to use brainstorming technique:

There are 3 stages in document analysis:

Data dictionaries are a bit more technical in nature. A data dictionary

It is the process of breaking, organizing, modelling and prioritizing

Techniques used to prioritize requirements:

• Must have – These are non-negotiable requirement/product needs that

Steps to perform planning poker:

How to assign Fibonacci numbers:

Importance of requirement modelling:

Unified Modelling Language:

Data Flow Diagram

Role Activity Diagram

1. It helps stakeholders gain a better understanding of a process through a universally

Start event symbol – It signals the first step of a business process

End event symbol – It signals the final step in a process

Intermediate Catch Event is used to:

Types of Intermediate Catch Events are the following:

• Message Catching Intermediate Event

A Message Intermediate Throwing event sends a message to an external service.

When a conditional intermediate event is placed on an activity boundary, the

Types of Gateways in BPMN2.0:

1. Unlike the Exclusive Gateway, all condition Expressions are evaluated.

There are 3 types of activities in BPMN2.0

Business rules describe initially in plain words how operations,

Constraints in using sub-process:

There are two kinds of Swimlanes: Pools and Lanes.

• Data Association - It is used to show the flow of information between Activities in a

• Association – It is used to link Artefacts with other BPMN (graphical) elements.

• The check may result in either of these three options: –

i) there are no mismatches, in which case the invoice is posted;

When an order is received, it is distributed across these warehouses: if some

Afterwards, the order is registered and the process completes.

In case of rejection, the employee must receive a rejection notice by email.

Order needs to be entered to CRM system and checked by operations and if

Vendor sends the product to the customer.

Process Name : Administer Insurance Application

Process Name : Administer Insurance Application

•In 1986, Ivar Jacobson first formulated textual and visual

•In 1992 his co-authored book Object-Oriented Software Engineering - A Use

It can be applied for:

• Representing the goals of system-user interactions

• Defining and organizing functional requirements in a system

• Specifying the context and requirements of a system

• Modeling the basic flow of events in a use case

The stereotype "<<extends>>" identifies as an extend relationship

There is no specific definition or criteria for DFD levels.

•Difficulty integrating with an existing database: Using ER Models to integrate with an

2. Attribute - A property or characteristic of an entity.

12. Note – It is used to add relevant comment to elements.

Finally the parallel activities combine to close the order.