BA - Business Analyst Key Concepts
Business Analysis is must have skill need today in the industry. This doc is all about explaining and focusing on key area for anyone who is interested in learning this skill.
Content
AGILE METHODS
What is the Scrum method?
Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the
development of information systems. The Scrum method brings a small team together to work on a
specified set of features over a period of 30-days (called a sprint).
Both the term Scrum and sprint are borrowed from the sport Rugby. A scrum is where the two teams are
engaged in a huddled to begin play following a period where play has been stopped. The fast moving
period of play from the point of the scrum until play ends again is called a sprint.
The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team
comes together). The kickoff meeting lasts a full day and the features of the system to be developed are
discussed. The outcome of the kickoff meeting is a set of features that will be developed over the 30-day
sprint along with estimates of how long the analysis and development of each feature will take.
In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested,
Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps
due to an initial underestimation of the time required, the feature will be pushed to a later sprint.
Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a
short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up
meeting). The purpose of this meeting is for the team to discuss what they accomplished the day before,
what they will accomplish over the coming day, and to raise any obstacles that they have encountered
that may impede progress.
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size. Most
Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.
Product Owner – identifies the features that will be included in the next 30-sprint and set the
priority of each. This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesn’t exist.
Scrum Master – acts much like the project manager. While the Scrum Master does not micromanage the teams deliverables, this person ensures that the 30-day sprint is on track and
enforces the key rules that guide Scrum such as; no new features can be added to the sprint
once it is kicked off, and team members cannot be pulled off to work on other side project in the
middle of a sprint.
Team Member – unlike traditional software development methods, in Scrum there is little
separation of duties between team members. Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.
Describe what is meant by Agile.
Agile is a general term and conceptual framework used to describe a number of “light-weight”
methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development
(RAD), which exhibit a series of common characteristics. Some of these characteristics include:
Iterative analysis and development
Time-boxed iterations of a predefined length
Delivery of the most critical features and functions first
Delivery of a complete build with an initial set of limited features within a few months (often 1-2
months)
Small cross-functional teams usually of 6-9 team members.
Daily team communication meetings
Reduced levels of documentation
Most Agile methods begin with a prioritized feature list where features are group together into deliverable
chunks and assigned to a particular iteration in which they will be developed and delivered. Using small
teams and daily communication among all team members the Agile team can achieve a high level of
efficiency.
Agile methods are intended to overcome or circumvent many of the recurring challenges that are
encountered during software development projects. The iterative nature of these methods, along with the
desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving
requirements, unclear project stakeholder direction, and unforeseen project complexities that typically
arise during the latter stages of analysis and development. Some of the most salient advantages of
Agile methods include:
Availability of working software much sooner which allows for more immediate feedback from
application users.
More immediate, and therefore larger, Return on Investment from software features that are
developed in short iterations and release to production immediately.
Less project overhead due to smaller team sizes.
Avoidance of large schedule overruns.
Avoidance of large budget overruns.
What is a Daily Scrum Meeting?
The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team
(ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be
completed next. It provides an update to the entire team while providing a daily refocus for each team member as
they deliver their status.
The daily scrum meeting is led by a Scrum Master. The scrum master leads the scrum meetings, measures progress,
identifies obstacles that are slowing or stopping the progress of work, and makes decisions about how to move
forward when necessary. The Scrum Master should be someone who has been given the authority to make
immediate decisions whenever possible.
During each meeting the Scrum Master asks each team member 3 questions:
1.
What did you do since the last meeting?
2.
Were there any obstacles that impeded your work?
3.
What will you do before the next meeting?
The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes. Standardizing the
time and place of the meeting results in increased efficiency by eliminating overhead associated with finding rooms
to schedule and team members determining where they should be each day. It also tends to decrease the number of
late arrivals. A primary key to the Daily Scrum Meeting is to keep it short. Any topics unrelated to the 3 questions
asked of each team members should be tabled during the meeting and handled at a later time.
What are User Stories?
Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories. They are short
descriptions of functionality the system should provide. The initial descriptions are often created or written by the
users or customers of the system. The user stories are used during the iterative planning and development cycles to
determine a unit of work and estimate how long it will take. Most practitioners strive to make a user stories fit into a
1-3 week span of development
User stories do not end at a 2-3 line description of functionality. Each user story consists of three parts:
The Card: Named for the standard index cards on which a user story is often captured. The cards are used
for planning the work that will be completed during each iteration of development.
The Conversations: Discussions about each user story are had with the users/customers of the system to
flesh out details. The conversations are captured and documented as part of the user story.
The Confirmation: Test scenarios that capture details about the user story that can be used to verify that the
user story has been successfully implemented.
Using these three parts, the goal of the user story is to provide enough detail that a developer can understand what
needs to be done while providing a means to verify that they have achieved the goal. User stories are often equated
to a single use case scenario, such as the main use case scenario or an alternative path. The “Card” portion of the
use case scenario is written in a manner similar to a brief description of a use case.
What is a Burndown Chart?
A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work
completed. It compares the amount of work remaining (typically measured along the vertical axis) against time
(measured along the horizontal axis). The amount of work remaining can be measured in whatever way works best
for the project, i.e., work-hours, work-days, story points, or any other work unit. Similarly the time axis can be
measured using a variety of units, the most common being days or iterations. The burndown chart gives a quick
view of the amount of work that is completed over time.
When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level (a specific
iteration of development) or at the release level (multiple iterations that deliver the total functionality for a product
release). After the amount of work completed has been measured over several units of time, the burndown chart can
be used to forecast the completion of an overall release or project.
ANALYTICAL AND PROBLEM SOLVING SKILLS
What is the PDCA method and how is its application by the Business Analyst
beneficial?
PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for
Plan, Do, Check, Act. It was popularized by Dr. W Edwards Deming in the 1950s during his work in
Japan where he taught top management how to improve product design, quality, testing and sales.
The process is originally attributed to Walter A. Shewhart and was referred to by Deming himself as the
Shewhart Cycle. The Shewhart Cycle steps were listed as Specification, Production, and Inspection.
However, over time, the steps were shortened to the more easily remembered Plan, Do, Check, Act (also
referred to as PDSA—Plan, Do, Study, Act) where the Act step emphasized the need to take action on the
knowledge gained from the prior step.
PDCA (or PDSA) is firmly rooted in the Scientific Method—Hypothesis, Experiment, Evaluation. A
fundamental principle of these methods is iteration. Once the result of a process is confirmed (or
negated) the cycle is repeated and the new knowledge can be acted upon. It is this process of taking
action, measuring the results, and utilizing those results to develop the next course of action that make
the PDCA method and others like it, such as the Six Sigma DMAIC process (Define, Measure, Analyze,
Improve and Control), so powerful and beneficial as a tool for the Business Analyst.
These methods, and others like them, which employ and iterative feedback loop embody two key points:
Creating a feedback loop based on measurable results
Making incremental changes and improvements over time
What techniques do you use to ensure that you have identified the principle
problem or requirement?
Problem solving and problem resolution is a common part of a business analyst’s role. But before you
spend time figuring out resolutions to the problem, you should be sure that you’re solving the right
problem or that you have the true requirement.
Problem Restatement is one category of techniques that can be used to determine that the principle
problem has been identified. Some problem restatement techniques are:
1. Problem Paraphrasing – Alter the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. Repeat the process until you have arrived at
the principle problem.
2. 5W + 1H (Who, What, When, Where, Why, + How) – Create multiple variations of the problem
statement beginning each statement with one of the 5W + 1H keywords.
3. Repeatedly Ask Why – Starting with the original problem statement, ask ‘Why’ to identify a new
problem statement. Continue to ask why to each new problem statement until you arrive at what
is clearly the principle problem.
Give an example of how you would use the problem restatement technique of
‘Repeatedly Ask Why’.
The Repeatedly Ask Why technique starts with the original problem statement and asks ‘Why’ to identify a
new problem statement. The Business Analyst continues to ask why to each new problem statement until
he or she arrives at what is clearly the principle problem.
This technique is so natural that all of us have used it as toddlers. Using the ‘Repeatedly Ask Why’
technique allows the Business Analyst to overcome any assumptions that may have been made when
developing the original problem statement. So revert back to that 2 year old kid and ask ‘Why’.
Example:
We need a new cafeteria vendor at our company campus. – Why?
Because the quality of the food continues to get worse. – Why?
Because they keep reusing leftovers and using lower quality products. – Why?
Because they are trying to make enough money to be profitable. – Why?
Because over the last few months fewer people have been going to the cafeteria. – Why?
Because we had layoffs and there are less people on our company campus.
At this point we can identify that the principle problem is the layoffs resulting in fewer people using the
cafeteria. No matter what vendor you hire, they will have troubles being profitable under these
conditions. So the original problem statement stating that a new vendor is needed is incorrect.
Give an example of how you would use the problem restatement technique of ‘5W
+ 1H’.
The ‘5W + 1H’ technique (Who, What, When, Where, Why, + How) is used to create multiple variations of
the problem statement beginning each statement with one of the 5W + 1H key words.
Example:
Should we alter our current customer service procedures?
Who should alter their current customer service procedures?
What should our current customer service procedures be?
When should we change our current customer service procedures?
Why should we alter our current customer service procedures?
How can we alter our current customer service procedures?
Rewriting the statement using the ‘5W + 1H’ technique broadens the focus of the Subject Matter Experts
and Business Analysts. This technique can be used at anytime, but is particularly important if the initial
problem statement is close ended phrase requiring a simple yes or no answer. This often constrains the
thought process of the Subject Matter Experts and Business Analysts. The resulting statements often
shed new light on the problem and help the group determine the principle issue.
Give an example of how you would use the problem restatement technique of
‘Problem Paraphrasing’.
Problem Paraphrasing is altering the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. The process is repeated until you have arrived at the
principle problem.
Example:
Drivers keep cutting me off.
Drivers keep passing me and pulling in front of me.
Drivers keep changing lanes to pass me and then pulling back in front of me.
Drivers keep pulling around me.
Drivers keep pulling around me while going the speed limit.
I’m driving to slow!
A Subject Matter Expert can tell you if each new statement still reflects a valid scenario. It’s important that
each statement be valid and correct. However, this technique is useful because a Subject Matter Expert
may not be able to jump directly to the principle problem. The paraphrasing technique helps the group
gradually arrive at the principle problem.
Describe Convergent and Divergent Thinking as a Problem Solving Technique
Divergent and Convergent thinking when used together can help an analyst arrive at better and more
creative solutions than he or she otherwise might have. Divergent thinking is the process of breaking a
topic down and generating many ideas that branch out from the original concept while Convergent
thinking is the process of focusing on a fewer set of ideas and evaluating them based on selection criteria.
Divergent and Convergent thinking can be used together in a three step process:
1. Brainstorming
2. Reducing and Categorizing
3. Ranking and Selecting
The first step, brainstorming, is a divergent thinking process and is most effective when a couple of
guidelines are followed. When using divergent thinking to generate a list of potential solutions, remember
the following:
1. The more ideas that are generated the better
2. Generate new ideas by building on previous ones
3. There is no such thing as bad ideas (even off-the-wall ideas can help generate other more viable
ones)
4. Don’t evaluate ideas during the divergent thinking process
Once a list of potential ideas has been generated, the second step of reducing and categorizing can take
place (a convergent thinking process). During this step the most impractical ideas will now be eliminated
and the remaining ideas can be grouped together into different categories based on their similarities.
Finally, the remaining list of ideas can be ranked based on the pros and cons of each (another convergent
thinking process) and a final solution selected.
Consider the following example of using Divergent and Convergent thinking for problem solving.
A manufacturer of jumbo hard pretzels always experiences a certain amount of broken product on their
manufacturing lines. They have initiated projects in the past to reduce the amount of breakage from 7%
to 4% measured by weight. However, is would not be cost effective to try and reduce breakage further via
other projects. Each week all of the pieces of broken pieces are collected and discarded. What other
options might the company have to reduce or eliminate their losses due to broken product?
Step 1: Brainstorm
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch
Sell the broken product to a shipping company as packaging filler
Sell the broken product to a bird food manufacturer
Season the broken product and market and sell it as a new product of its own
Give the broken product to a food shelter and take it as a tax write off
Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
Step 2: Reducing and Categorizing
Category: Sell to another company
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch (impractical)
Sell the broken product to a shipping company as packaging filler (impractical)
Sell the broken product to a bird food manufacturer
Category: Develop another product internally
Season the broken product and market and sell it as a new product of its own
Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
Category: Tax write off
Give the broken product to a food shelter and take it as a tax write off
Step 3: Ranking and Selecting
1. Season the broken product and market and sell it as a new product of its own (Selected for
maximum revenue)
2. Give the broken product to a food shelter and take it as a tax write off
3. Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
4. Sell the broken product to a dog food company as a filler ingredient for dog food
5. Sell the broken product to a bird food manufacturer
What is Cost Benefit Analysis (CBA)?
Cost Benefit Analysis is a technique used to determine if the financial benefit s of a project outweigh the
associated cost of undertaking the project in the first place. For a short term project where the benefit
may be an immediate one-time cash windfall this may be as simple as subtracting the total of all the
project cost from the total of all of the project benefits. If the total is positive, then the project may be
worth completing.
Project Duration = 2 months
Project Costs = $50,000
Immediate Project Benefits = $75,000
$75,000 - $50,000 = $25,000
However, project costs and benefits rarely result in such a simple example. Project costs and benefits
often occur over time. For this reason, Cost Benefit Analysis should consider all project cost and benefits
in terms of the present value (PV) of money.
To determine the present value of a future cost or benefit we discount the value of the dollars to account
for time. To calculate the Present Value we use the formula PV = FV /[(1 + i)^t].
PV = Present Value
FV = Future Value
i = Discount Rate
t = time
In our example, if the $50,000 cost was incurred immediately and the $75,000 benefit was realized 3
years in the future, using a 5% discount rate would result in the following:
PV = $75,000 / [(1 + .05)^3] = $64,787.82
$64,787.82 - $50,000 = $14,787.82
The net benefit of this project is now clearly less than originally thought.
Taking this a step further, consider the example where we have multiple cashflows (costs and benefits)
over time.
@ T0, Cost = -$25,000
@ T1, Cost = -$25,000, Benefit = $15,000
@T2, Benefit = $30,000
@T3, Benefit = $30,000
By subtracting the present value of future costs from the present value of future benefits, we can arrive at
the Net Present Value (NPV) of the costs and benefits for each year of the project. The sum of all NPV
calculations will give us the NPV of the entire project.
NPV = FVben – FVcost / [(1 + i)^t]
NPV0 = $0 - $25,000 / [(1 + .05)^0] = -$25,000
NPV1 = $15,000 - $25,000 / [(1 + .05)^1] = -$9,523.81
NPV2 = $30,000 - $0 / [(1 + .05)^2] = $27,210.88
NPV3 = $30,000 - $0 / [(1 + .05)^3] = $25,915.13
For a total of $18,602.20 in benefit.
What is Joint Application Development (JAD)?
JAD stands for Joint Application Development. JAD is a requirements-definition and software system design
methodology in which stakeholders, subject matter experts (SME), end-users, business analysts, software architects
and developers attend collaborative workshops (called JAD sessions) to work out a system's details.
The JAD approach, in comparison with more traditional practices, is thought to lead to faster development times and
greater client satisfaction, because the client is involved throughout the development process
The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives,
SME’s, end-users, business analysts, software architects and developers. It is essential that the roles, responsibilities,
and rules for the JAD sessions are well defined and communicated in advance to all participants.
Some typical roles found in a JAD session include:
Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,
Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,
End users – 3 to 5, attend all sessions,
Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,
Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,
Subject Matter Experts,
Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.
BUSINESS ANALYSIS
What is PEST Analysis?
PEST is an acronym that stands for Political, Economic, Social, Technological. PEST analysis is
one way that a business can analyze the environment in which it operates.
Political Environment: refers to government laws, regulations, and policies. These are things
that impact the business either directly or indirectly. This may include trade laws, tariffs, labor
laws, taxes, environmental regulations, zoning restrictions, etc. Some of these, if passed
recently, may have a long term affect on the economy as well. While PEST covers the economic
environment, some political environment considerations, such as leadership changes that come
from elections, may not have impacted the economy yet (this is an example of an indirect
impact). So the analyst should watch for how new government regulations may impact the
economy longer term and assess its impact on the business.
Economic Environment: refers to the forces at play within the economy that the business has
little control over. These may include interest rates, inflation rate, exchange rates, increase in
Gross Domestic Product (GDP), the financial and stock markets, the job market, etc. All of these
have impacts on the business from the ability to generate revenue to the cost of borrowing money
to the salaries they will need to pay employees.
Social Environment: refers to the demographics of the environment that the company operates
within. Since demographics are nothing more than characteristics of a human population this
could include a nearly infinite number of groups. Some common demographics that are
considered are gender, race, age, income, disabilities, educational attainment, employment status,
and religion. Ultimately, if the strategic plans of a business affect a particular group, they may
react positively or negatively. A business may face criticism, negative publicity or even protests
based on the decisions it makes. These factors could have an enormous impact on the operations
and revenue of the business.
Technological Environment: refers to the technology that currently exists that the business has
accessible to them. This could include servers, computers, networks, software and software
frameworks, database technologies, wireless capabilities, availability of Software as a Service
(Saas), and more. The rate of technological progress should also be considered, particularly if
the business has plans to develop a system or product that takes advantage of cutting edge
technology.
What is meant by Forming, Storming, Norming, and Peforming?
The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce
Tuckman. He described that most teams follow a consistent path from the point when they are first
assembled to the time when they become a highly proficient, highly effective group. This path leads them
through four distinct stages; Forming, Storming, Norming, and Performing.
The “Forming” stage begins when new team members are first brought together. Initially everybody is
very positive and polite to one another. Some people are anxious, some are excited. The team members
are fairly unaware of the details of the work ahead (blissfully naïve perhaps) and they look for clear
direction from the leader. Formal processes and project frameworks are not yet established. This stage is
usually short in comparison to the others.
Next is the “Storming” stage. At this stage team members become clear about their roles and what is
expected of them. Processes and project structures are put into full effect. The team may feel frustrated
and overwhelmed by the work as they become more aware of the realities of the job. They may be
stressed by how much there is to accomplish and they may have uncertainties about their ability to do the
assigned work. Or, they may simply be uncomfortable with the approach that is laid out by the leader.
Team members still don’t know each other that well as they continue to form opinions of one another.
They may be jockeying for position within the team or even challenging the leader’s authority. Conflicts
arise more often during this stage. A great deal of oversight is needed by the team leader to ensure the
processes are followed and the work is completed to expectations.
The “Norming” stage is where the team begins to catch their stride. The pecking order of the team is
established and team processes and workflow are beginning to solidify. Each team member understands
the strength of the other members and they all begin to work more as a team. They help each other and
provide peer reviews and constructive criticism. At this point, the team is following the processes and
project framework but may not be working as efficiently as they could be. They still need oversight but
significantly less than in the storming stage.
Finally, the “Performing” stage is reached. The team has a solid understanding of the processes and
project framework that have been put into place and follow them efficiently. The team has become
efficient and productive and it reaches its goals with regularity. At this stage if a team member joins or
leaves it will have little impact on the rest of the team’s performance. The team leader can delegate to
team members with confidence and provide minimal oversight.
What is Function Point Analysis?
Function Point Analysis (FPA) refers to the practice of using function points to size and estimate the cost
of work on systems. Function Points are a normalized unit of measure used to:
Quantify the amount of business functionality a system provides business users
Estimate the cost to develop a system or set of features based on the number of function points it
supports
Determine how costly a system is to maintain based on the number of function points it supports
To state things differently, Function Points are good for answering questions like:
How big is system “A”? Is system “A” bigger than system “B” and by how much? (It answers
these in terms of features)
How much will it cost me to build system “A”?
If I’m paying $500,000/yr to maintain system “B” is that cost effective?
Function Points, being a normalized unit of measure, provides an apples-to-apples comparison of
systems and the costs associated with building and supporting them.
This method of measuring systems was first developed in 1979 by Allan Albrecht of IBM. Today it is
supported by a group called the International Function Point User Group (or IFPUG for short).
To count the number of function points that a system possesses, a skilled practitioner first categorizes
each feature into one of five types (outputs, inquiries, inputs, internal files, and external interfaces). Then
a complexity is assigned to each feature. Finally, a number of function points can be assigned to each
feature. Certain types of system also have additional function point adjustment factors that are used.
The end result is a single number for the entire system called a Function Point Index. Based on this value
and historical function point data, the cost to develop the system can be estimated.
FPA brings structure and rigor to a process that is often very subjective. However, there are a number of
potential challenges that are often voiced when discussing the merits of FPA.
Counting Function Points can be a tricky task to do well. Getting consistent results is a challenge
unless you are a skilled practitioner at counting function points. There is a sizable “Function Point
Counting Practices Manual” available to direct the practitioner in this exercise.
FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.
While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try
to compensate for these challenges.
What is the H-Method?
The H-method is an analysis tool that aids the BA in organizing a fact finding interview with a business
representative or system user.
Before discussing the benefits of the H-Method and how it works, let’s consider a typical interviewing
process. Without the use of a framework for organizing an interview, an analyst and business
representative will often participate in a relatively unstructured dialogue in which the analyst asks
questions such as:
Tell me what you do?
What does your system do?
Who do you interact with?
Why is “x” important?
Then based on the answers given the analyst will continue to ask follow up questions. The success of the
fact finding is typically dependent upon the experience level of the analyst. While this method can work,
the analyst will often walk away with several pages of unstructured notes. The important information must
then be extracted and organized into something meaningful and useful. Only then will the analyst be able
to determine if they have discovered all of the necessary pieces of information or if there are still gaps in
their understanding.
The H-method uses the following “H” shaped diagram to provide a structured framework to guide the
interview and to allow the analyst to captured information in an organized way from the start.
This diagram also asks the business representative questions is a business friendly manner. As
information is gathered, the analyst can document it in the appropriate area of the “H” shaped diagram.
Finally, the information gathered using the first diagram can be mapped to more business analysis centric
concepts on the following revised diagram.
The H-method is successful because it provides both a structured framework to guide the interview
process and because it reminds the business analyst to avoid business analysis jargon that may confuse
the business representative. Instead it asks questions that align more closely with how the business
representative views their world.
What is a Use Case Realization?
A use case realization provides a construct to organize artifacts which shown how the physical design of a
system supports the logical business behavior outlined by a used case. To show this traceability between
the logical and physical design, in the use case diagram each use case is depicted as an oval shown with
a solid-line border. Then for each use case can you may show a use case realization as an oval with a
dotted-line border. The use case and its corresponding use case realization are linked using a realization
dependency which is shown in UML as a dashed line with a triangular arrowhead at the end
corresponding to the realized element (the use case).
Each use case realization will define the physical design in terms of classes and collaborating objects
which support the use case. Therefore, each use case realization typically is made up of a class diagram
and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or
interaction between physical objects.
Use case realizations allow the analyst to clearly separate the concerns of the logical and physical
design. Since a logical design (the business behavior and requirements) can be implemented or realized
via a number of different physical implementations, if a physical design changes the logical use case can
remain unaffected. Also, a use case realization is an excellent form of requirements traceability from the
logical business requirements down to the physical implementation of the solution.
What is a RACI Matrix?
RACI Matrix is the name given to a table which is used to describe the type and degree of involvement
that stakeholders have in completing tasks or deliverables for a project or business process. Also
sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool
used by business analysts and project managers for establishing roles and responsibilities early on in a
project. In this way it reduces project risk and sets expectations about the level of involvement that is
expected by various stakeholders.
RACI is an acronym which stands for Responsible, Accountable, Consulted, Informed. Since using an
acronym makes for easier recollection, the term RACI Matrix tends to be the most commonly used name
for this tool
The RACI Matrix displays deliverables or tasks along one axis:
Project Charter
Business Requirements Document
AS-IS Process Flow
Functional Specifications
Requirements Traceability Matrix, etc.
Then it displays project roles or stakeholders along the other axis
Project Champion
Project Manager
Analysis Lead
Analyst/Analysis Team
Development Manager, etc.
Finally, at each intersecting cell the type or degree of involvement is documented (Responsible,
Accountable, Consulted, Informed).
Ultimately, each organization varies a bit in how they define each level of participation in a task or creation
of a document. The following are some commonly accepted definitions.
Accountable – This is the person who is ultimately on the hook to ensure that the deliverable or task has
been completed and is thorough and correct. This is usually a lead or manager of some kind. The
accountable person may be directing the work of the responsible person, but in the end the buck stops
here. There can only be one truly accountable person. This avoids finger pointing when something
doesn’t get done or is done incorrectly.
Responsible – The responsible person(s) is the worker bee. It can be one person, or a team of people.
They will be the ones getting their hands dirty finding the information they need and putting it to use to
complete the task or create the deliverable. They may be reporting to a lead or manager who is
accountable for the task or deliverable. However, for smaller tasks or deliverables, when there is only one
responsible person listed, they may ALSO be listed as the accountable party.
Consulted – The consulted person(s) is a subject matter expert. They are the person whose opinions or
knowledge of a particular system or process is sought. They don’t usually participate in completing a task
or deliverable other than by providing the information that the responsible person needs to achieve their
task or deliverable.
Informed – These are the people who need to be kept up to date on a task or deliverable. They may
need to track the amount of progress being made, but usually these people care only about the
completion of a task or deliverable. Typically they are either reviewers of the completed document and
provide formal sign-off and approval, or they may be dependent on the information that results from the
task or deliverable.
What strategies might a business analyst consider when planning for a company's growth?
If a company is to ensure its growth, it needs to plan for it. There are a number of growth strategies that
can be used. Deciding which is the right growth strategy for a company depends on it current success
and position within the marketplace in which it operates. Four of these growth strategies are:
Market Penetration (Existing Products/Existing Markets)
Market Development (Existing Products/New Market)
Product Development (New Products/Existing Market)
Diversification (New Products/New Market)
Market Penetration focuses on getting more out of the current markets serviced by an organization while
offering the same products. New products and new markets can mean additional unknowns which, in
turn, increase risk and chances of failure. For this reason, a company may choose to select a growth
strategy of market penetration. The goal of market penetration is to increase the percentage of market
share that the organization possesses through pricing, marketing, loyalty programs, incentives,
advertising, etc.
Market Development is used to describe the growth strategy of an organization which chooses to
venture into new markets or new customer segments with their existing products. Their existing products
are likely proven which provides a degree of stability, but moving into new markets increases risk. This
may still be viewed by some organizations as a fairly conservative strategy and is often adopted by
companies as they feel their current markets getting squeezed tighter and tighter by competition.
Entrance into new markets often requires skilled marketing professionals to ensure a company receives
the attention it is looking for.
Product Development describes the growth strategy of creating new products for existing markets. An
organization may have the benefit of understanding the intricacies of their market but this can create a
false sense of security. Not all new products carry the same risk. However, for certain types of product,
especially those in fast moving technology markets, projecting the outcome of a new product launch can
be very difficult. To overcome some of this risk organizations should be prepared to continuously adapt
their products after launch to ensure marketplace success.
Diversification is the term given to the strategy of delivering new products to entirely new markets. The
growth strategy accepts the risks of two unknowns; the product and the market. Diversification is highrisk but, as with many things, high risk often can mean high reward. Organizations with a track record of
innovation will have the greatest success with this strategy. With diversification as a growth strategy,
everything will be new and the company will need to be prepared to quickly eliminate any risks that
manifest themselves.
The four growth strategies described here are based on a simple 2 x 2 matrix called Ansoff’s Matrix which
considers markets and products along its two axis.
Ansoff’s Matrix
Existing Products
Existing
Markets
New Markets
New Products
Market Penetration Product Development
Market
Development
Diversification
What is Benchmarking?
When companies want to improve, they first need to have an accurate means of measuring performance.
Without accurate measurement, determining process improvement is not feasible. Measurement
establishes a baseline against which the organization can determine the degree of improvement that has
been made.
However, improvement alone may not be enough. If an organization doesn’t know what the standard is it
cannot compare itself against it. For example, if an organization obtains a customer satisfaction rating of
80%, but its competitor receives 90%, they will lose ground in the long run. Benchmarking is the key to
understanding how an organization measures up against others.
Benchmarking is the process of determining how an organization stacks up against industry leaders by
measuring its performance across a series of standard metrics and then comparing the performance
against other best-of-breed organizations within the same industry or service line. Companies may
measure and compare policies, practices, philosophies, and other performance measures.
Benchmarking is usually part of a larger process re-engineering or quality improvement initiative such as
Six Sigma or Total Quality Management.
What is Balanced Scorecard?
Balanced Scorecard is a strategic planning and management system that was formalized in the 1990s by
Dr. Robert Kaplan (of the Harvard Business School) and Dr. David Nortan. The goal of Balanced
Scorecard is to implement a performance measurement framework which provides strategic non-financial
performance measures that when coupled with traditional financial metrics provides a more “balanced”
view of the organization. Using Balanced Scorecard a company can align daily business activities to the
vision and strategy of the organization effectively transforming their strategic plan from a passive
document into a plan which provides clear and measurable goals for all areas of the organization.
As described by Kaplan and Nortan, Balanced Scorecard retains the traditional financial measures, but
financial measures reflect past events. This alone is inadequate for guiding and evaluating a company’s
future direction. A company’s future success is driven through customer relationships, supplier
relationships, employee development, process improvement, technology improvement, and innovation.
To improve in these areas Balanced Scorecard organizes the development of metrics and the tracking of
progress against these metrics into four perspectives.
The Learning and Growth Perspective
The Business Process Perspective
The Customer Perspective
The Financial Perspective
The Learning and Growth Perspective focuses on the development of metrics around training of
employees and education of the organization as a whole. These metrics should be structured in a way to
guide managers to focus their training funds where they will help most. They should also drive other
methods of learning such as mentoring and ensuring that knowledge can easily be communicated and
shared throughout the organization.
The Business Process Perspective focuses on the development of metrics that allow managers to know
how well the internal business processes are running and how well they meet the needs of the
organization’s customers.
The Customer Perspective focuses on the development of metrics around customer satisfaction. This
perspective cannot be underestimated as it has been found that customer satisfaction is a leading
indicator of the future performance of the company. Over time, dissatisfied customers will seek out other
organizations that can meet their needs better.
The Financial Perspective focuses on traditional financial metrics. Companies often already place a
heavy emphasis on financials which can lead to an unbalanced view of a situation. While this perspective
is very important, Balanced Scorecard aims to balance this perspective by considering it in conjunction
with the metrics and data of the other perspectives.
What is Document Analysis?
Document Analysis is a technique used to gather requirements during the requirements elicitation phase
of a project. It describes the act of reviewing the existing documentation of comparable business
processes or systems in order to extract pieces of information that are relevant to the current project, and
therefore should be consider projects requirements.
Business analysts can elicit requirements in many ways, and eliciting them from stakeholders using
questionnaires, interviews, or facilitating sessions are most common. However document analysis is
particularly valuable when replacing one or more existing systems with a new system that will offer
increased functionality or a better overall user experience. Existing documentation can be scoured for an
understanding of key functions, business rules, business entities, and business entity attributes.
Document analysis may also be necessary when stakeholders are not available to offer insight into
existing business processes or systems.
Some forms of documents that are useful in document analysis may be obvious, while others less so.
Here is a list of potential documents that an analyst should consider reviewing based on their particular
project type.
Benchmarking studies
Business plans
Business process and procedure documentation
Company memos
Competing product literature and reviews
Customer contracts
Customer suggestions
Requests for proposals
System defect reports
System specifications (of existing systems)
Training guides
Vision documents for related projects
How is the Business Analysis Planning and Monitoring (BABOK v2.0) knowledge area
defined?
The Business Analysis Planning and Monitoring knowledge area describes the process of how a business
analyst determines which activities will be needed to complete the business analysis effort. The tasks
within this knowledge area govern the business analysis tasks in all of the other knowledge areas. These
tasks include:
1. Plan Business Analysis Approach
2. Conduct Stakeholder Analysis
3. Plan Business Analysis Activities
4. Plan Business Analysis Communication
5. Plan Requirements Management Process
6. Manage Business Analysis Performance
What is BPMN?
BPMN stands for Business Process Modeling Notation. BPMN is an industry standard
that provides businesses with the capability of visualizing and communicating their
internal business processes and their external business to business processes in a
standard manner. Beyond the obvious use of modeling business processes, BPMN
has been created with the key goal of creating a bridge between the business
process modeling notation (BPMN) and IT-oriented execution languages that will
implement the modeled business processes within a business process management
system. This is done by maintaining and supporting a strict internal model that
maps the rich set of graphical objects and object attributes of BPMN to executable
languages such as the Business Process Execution Language for Webs Services
(BPEL4WS) or Business Process Modeling Language (BPML) to support immediate
execution of modeled buiness processes.
NOTE: From the business systems analyst perspective, BPMN is a modeling notation
which provides the analyst with a rich graphical notation for modeling business
processes, sub-processes, and activities.
Many business analysts use BPMN diagrams instead of UML activity diagrams.
In addition, BPMN is a visual notation used by many of today's business process
modeling and management tools.
Name a few of the industry standards, methodologies, or best practices used by
business analysts and systems analysts?
-UML
-BPMN
-RUP
- Agile
- SDLC
What is the Scrum method?
Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the
development of information systems. The Scrum method brings a small team together to work on a
specified set of features over a period of 30-days (called a sprint).
Both the term Scrum and sprint are borrowed from the sport Rugby. A scrum is where the two teams are
engaged in a huddled to begin play following a period where play has been stopped. The fast moving
period of play from the point of the scrum until play ends again is called a sprint.
The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team
comes together). The kickoff meeting lasts a full day and the features of the system to be developed are
discussed. The outcome of the kickoff meeting is a set of features that will be developed over the 30-day
sprint along with estimates of how long the analysis and development of each feature will take.
In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested,
Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps
due to an initial underestimation of the time required, the feature will be pushed to a later sprint.
Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a
short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up
meeting). The purpose of this meeting is for the team to discuss what they accomplished the day before,
what they will accomplish over the coming day, and to raise any obstacles that they have encountered
that may impede progress.
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size. Most
Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.
Product Owner – identifies the features that will be included in the next 30-sprint and set the
priority of each. This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesn’t exist.
Scrum Master – acts much like the project manager. While the Scrum Master does not micromanage the teams deliverables, this person ensures that the 30-day sprint is on track and
enforces the key rules that guide Scrum such as; no new features can be added to the sprint
once it is kicked off, and team members cannot be pulled off to work on other side project in the
middle of a sprint.
Team Member – unlike traditional software development methods, in Scrum there is little
separation of duties between team members. Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.
Describe what is meant by Agile.
Agile is a general term and conceptual framework used to describe a number of “light-weight”
methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development
(RAD), which exhibit a series of common characteristics. Some of these characteristics include:
Iterative analysis and development
Time-boxed iterations of a predefined length
Delivery of the most critical features and functions first
Delivery of a complete build with an initial set of limited features within a few months (often 1-2
months)
Small cross-functional teams usually of 6-9 team members.
Daily team communication meetings
Reduced levels of documentation
Most Agile methods begin with a prioritized feature list where features are group together into deliverable
chunks and assigned to a particular iteration in which they will be developed and delivered. Using small
teams and daily communication among all team members the Agile team can achieve a high level of
efficiency.
Agile methods are intended to overcome or circumvent many of the recurring challenges that are
encountered during software development projects. The iterative nature of these methods, along with the
desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving
requirements, unclear project stakeholder direction, and unforeseen project complexities that typically
arise during the latter stages of analysis and development. Some of the most salient advantages of
Agile methods include:
Availability of working software much sooner which allows for more immediate feedback from
application users.
More immediate, and therefore larger, Return on Investment from software features that are
developed in short iterations and release to production immediately.
Less project overhead due to smaller team sizes.
Avoidance of large schedule overruns.
Avoidance of large budget overruns.
What is a Daily Scrum Meeting?
The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team
(ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be
completed next. It provides an update to the entire team while providing a daily refocus for each team member as
they deliver their status.
The daily scrum meeting is led by a Scrum Master. The scrum master leads the scrum meetings, measures progress,
identifies obstacles that are slowing or stopping the progress of work, and makes decisions about how to move
forward when necessary. The Scrum Master should be someone who has been given the authority to make
immediate decisions whenever possible.
During each meeting the Scrum Master asks each team member 3 questions:
1.
What did you do since the last meeting?
2.
Were there any obstacles that impeded your work?
3.
What will you do before the next meeting?
The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes. Standardizing the
time and place of the meeting results in increased efficiency by eliminating overhead associated with finding rooms
to schedule and team members determining where they should be each day. It also tends to decrease the number of
late arrivals. A primary key to the Daily Scrum Meeting is to keep it short. Any topics unrelated to the 3 questions
asked of each team members should be tabled during the meeting and handled at a later time.
What are User Stories?
Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories. They are short
descriptions of functionality the system should provide. The initial descriptions are often created or written by the
users or customers of the system. The user stories are used during the iterative planning and development cycles to
determine a unit of work and estimate how long it will take. Most practitioners strive to make a user stories fit into a
1-3 week span of development
User stories do not end at a 2-3 line description of functionality. Each user story consists of three parts:
The Card: Named for the standard index cards on which a user story is often captured. The cards are used
for planning the work that will be completed during each iteration of development.
The Conversations: Discussions about each user story are had with the users/customers of the system to
flesh out details. The conversations are captured and documented as part of the user story.
The Confirmation: Test scenarios that capture details about the user story that can be used to verify that the
user story has been successfully implemented.
Using these three parts, the goal of the user story is to provide enough detail that a developer can understand what
needs to be done while providing a means to verify that they have achieved the goal. User stories are often equated
to a single use case scenario, such as the main use case scenario or an alternative path. The “Card” portion of the
use case scenario is written in a manner similar to a brief description of a use case.
What is a Burndown Chart?
A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work
completed. It compares the amount of work remaining (typically measured along the vertical axis) against time
(measured along the horizontal axis). The amount of work remaining can be measured in whatever way works best
for the project, i.e., work-hours, work-days, story points, or any other work unit. Similarly the time axis can be
measured using a variety of units, the most common being days or iterations. The burndown chart gives a quick
view of the amount of work that is completed over time.
When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level (a specific
iteration of development) or at the release level (multiple iterations that deliver the total functionality for a product
release). After the amount of work completed has been measured over several units of time, the burndown chart can
be used to forecast the completion of an overall release or project.
ANALYTICAL AND PROBLEM SOLVING SKILLS
What is the PDCA method and how is its application by the Business Analyst
beneficial?
PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for
Plan, Do, Check, Act. It was popularized by Dr. W Edwards Deming in the 1950s during his work in
Japan where he taught top management how to improve product design, quality, testing and sales.
The process is originally attributed to Walter A. Shewhart and was referred to by Deming himself as the
Shewhart Cycle. The Shewhart Cycle steps were listed as Specification, Production, and Inspection.
However, over time, the steps were shortened to the more easily remembered Plan, Do, Check, Act (also
referred to as PDSA—Plan, Do, Study, Act) where the Act step emphasized the need to take action on the
knowledge gained from the prior step.
PDCA (or PDSA) is firmly rooted in the Scientific Method—Hypothesis, Experiment, Evaluation. A
fundamental principle of these methods is iteration. Once the result of a process is confirmed (or
negated) the cycle is repeated and the new knowledge can be acted upon. It is this process of taking
action, measuring the results, and utilizing those results to develop the next course of action that make
the PDCA method and others like it, such as the Six Sigma DMAIC process (Define, Measure, Analyze,
Improve and Control), so powerful and beneficial as a tool for the Business Analyst.
These methods, and others like them, which employ and iterative feedback loop embody two key points:
Creating a feedback loop based on measurable results
Making incremental changes and improvements over time
What techniques do you use to ensure that you have identified the principle
problem or requirement?
Problem solving and problem resolution is a common part of a business analyst’s role. But before you
spend time figuring out resolutions to the problem, you should be sure that you’re solving the right
problem or that you have the true requirement.
Problem Restatement is one category of techniques that can be used to determine that the principle
problem has been identified. Some problem restatement techniques are:
1. Problem Paraphrasing – Alter the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. Repeat the process until you have arrived at
the principle problem.
2. 5W + 1H (Who, What, When, Where, Why, + How) – Create multiple variations of the problem
statement beginning each statement with one of the 5W + 1H keywords.
3. Repeatedly Ask Why – Starting with the original problem statement, ask ‘Why’ to identify a new
problem statement. Continue to ask why to each new problem statement until you arrive at what
is clearly the principle problem.
Give an example of how you would use the problem restatement technique of
‘Repeatedly Ask Why’.
The Repeatedly Ask Why technique starts with the original problem statement and asks ‘Why’ to identify a
new problem statement. The Business Analyst continues to ask why to each new problem statement until
he or she arrives at what is clearly the principle problem.
This technique is so natural that all of us have used it as toddlers. Using the ‘Repeatedly Ask Why’
technique allows the Business Analyst to overcome any assumptions that may have been made when
developing the original problem statement. So revert back to that 2 year old kid and ask ‘Why’.
Example:
We need a new cafeteria vendor at our company campus. – Why?
Because the quality of the food continues to get worse. – Why?
Because they keep reusing leftovers and using lower quality products. – Why?
Because they are trying to make enough money to be profitable. – Why?
Because over the last few months fewer people have been going to the cafeteria. – Why?
Because we had layoffs and there are less people on our company campus.
At this point we can identify that the principle problem is the layoffs resulting in fewer people using the
cafeteria. No matter what vendor you hire, they will have troubles being profitable under these
conditions. So the original problem statement stating that a new vendor is needed is incorrect.
Give an example of how you would use the problem restatement technique of ‘5W
+ 1H’.
The ‘5W + 1H’ technique (Who, What, When, Where, Why, + How) is used to create multiple variations of
the problem statement beginning each statement with one of the 5W + 1H key words.
Example:
Should we alter our current customer service procedures?
Who should alter their current customer service procedures?
What should our current customer service procedures be?
When should we change our current customer service procedures?
Why should we alter our current customer service procedures?
How can we alter our current customer service procedures?
Rewriting the statement using the ‘5W + 1H’ technique broadens the focus of the Subject Matter Experts
and Business Analysts. This technique can be used at anytime, but is particularly important if the initial
problem statement is close ended phrase requiring a simple yes or no answer. This often constrains the
thought process of the Subject Matter Experts and Business Analysts. The resulting statements often
shed new light on the problem and help the group determine the principle issue.
Give an example of how you would use the problem restatement technique of
‘Problem Paraphrasing’.
Problem Paraphrasing is altering the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. The process is repeated until you have arrived at the
principle problem.
Example:
Drivers keep cutting me off.
Drivers keep passing me and pulling in front of me.
Drivers keep changing lanes to pass me and then pulling back in front of me.
Drivers keep pulling around me.
Drivers keep pulling around me while going the speed limit.
I’m driving to slow!
A Subject Matter Expert can tell you if each new statement still reflects a valid scenario. It’s important that
each statement be valid and correct. However, this technique is useful because a Subject Matter Expert
may not be able to jump directly to the principle problem. The paraphrasing technique helps the group
gradually arrive at the principle problem.
Describe Convergent and Divergent Thinking as a Problem Solving Technique
Divergent and Convergent thinking when used together can help an analyst arrive at better and more
creative solutions than he or she otherwise might have. Divergent thinking is the process of breaking a
topic down and generating many ideas that branch out from the original concept while Convergent
thinking is the process of focusing on a fewer set of ideas and evaluating them based on selection criteria.
Divergent and Convergent thinking can be used together in a three step process:
1. Brainstorming
2. Reducing and Categorizing
3. Ranking and Selecting
The first step, brainstorming, is a divergent thinking process and is most effective when a couple of
guidelines are followed. When using divergent thinking to generate a list of potential solutions, remember
the following:
1. The more ideas that are generated the better
2. Generate new ideas by building on previous ones
3. There is no such thing as bad ideas (even off-the-wall ideas can help generate other more viable
ones)
4. Don’t evaluate ideas during the divergent thinking process
Once a list of potential ideas has been generated, the second step of reducing and categorizing can take
place (a convergent thinking process). During this step the most impractical ideas will now be eliminated
and the remaining ideas can be grouped together into different categories based on their similarities.
Finally, the remaining list of ideas can be ranked based on the pros and cons of each (another convergent
thinking process) and a final solution selected.
Consider the following example of using Divergent and Convergent thinking for problem solving.
A manufacturer of jumbo hard pretzels always experiences a certain amount of broken product on their
manufacturing lines. They have initiated projects in the past to reduce the amount of breakage from 7%
to 4% measured by weight. However, is would not be cost effective to try and reduce breakage further via
other projects. Each week all of the pieces of broken pieces are collected and discarded. What other
options might the company have to reduce or eliminate their losses due to broken product?
Step 1: Brainstorm
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch
Sell the broken product to a shipping company as packaging filler
Sell the broken product to a bird food manufacturer
Season the broken product and market and sell it as a new product of its own
Give the broken product to a food shelter and take it as a tax write off
Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
Step 2: Reducing and Categorizing
Category: Sell to another company
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch (impractical)
Sell the broken product to a shipping company as packaging filler (impractical)
Sell the broken product to a bird food manufacturer
Category: Develop another product internally
Season the broken product and market and sell it as a new product of its own
Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
Category: Tax write off
Give the broken product to a food shelter and take it as a tax write off
Step 3: Ranking and Selecting
1. Season the broken product and market and sell it as a new product of its own (Selected for
maximum revenue)
2. Give the broken product to a food shelter and take it as a tax write off
3. Develop a product that affixes the pieces together to form a bio-degradable “clay pigeon” for
skeet shooting
4. Sell the broken product to a dog food company as a filler ingredient for dog food
5. Sell the broken product to a bird food manufacturer
What is Cost Benefit Analysis (CBA)?
Cost Benefit Analysis is a technique used to determine if the financial benefit s of a project outweigh the
associated cost of undertaking the project in the first place. For a short term project where the benefit
may be an immediate one-time cash windfall this may be as simple as subtracting the total of all the
project cost from the total of all of the project benefits. If the total is positive, then the project may be
worth completing.
Project Duration = 2 months
Project Costs = $50,000
Immediate Project Benefits = $75,000
$75,000 - $50,000 = $25,000
However, project costs and benefits rarely result in such a simple example. Project costs and benefits
often occur over time. For this reason, Cost Benefit Analysis should consider all project cost and benefits
in terms of the present value (PV) of money.
To determine the present value of a future cost or benefit we discount the value of the dollars to account
for time. To calculate the Present Value we use the formula PV = FV /[(1 + i)^t].
PV = Present Value
FV = Future Value
i = Discount Rate
t = time
In our example, if the $50,000 cost was incurred immediately and the $75,000 benefit was realized 3
years in the future, using a 5% discount rate would result in the following:
PV = $75,000 / [(1 + .05)^3] = $64,787.82
$64,787.82 - $50,000 = $14,787.82
The net benefit of this project is now clearly less than originally thought.
Taking this a step further, consider the example where we have multiple cashflows (costs and benefits)
over time.
@ T0, Cost = -$25,000
@ T1, Cost = -$25,000, Benefit = $15,000
@T2, Benefit = $30,000
@T3, Benefit = $30,000
By subtracting the present value of future costs from the present value of future benefits, we can arrive at
the Net Present Value (NPV) of the costs and benefits for each year of the project. The sum of all NPV
calculations will give us the NPV of the entire project.
NPV = FVben – FVcost / [(1 + i)^t]
NPV0 = $0 - $25,000 / [(1 + .05)^0] = -$25,000
NPV1 = $15,000 - $25,000 / [(1 + .05)^1] = -$9,523.81
NPV2 = $30,000 - $0 / [(1 + .05)^2] = $27,210.88
NPV3 = $30,000 - $0 / [(1 + .05)^3] = $25,915.13
For a total of $18,602.20 in benefit.
What is Joint Application Development (JAD)?
JAD stands for Joint Application Development. JAD is a requirements-definition and software system design
methodology in which stakeholders, subject matter experts (SME), end-users, business analysts, software architects
and developers attend collaborative workshops (called JAD sessions) to work out a system's details.
The JAD approach, in comparison with more traditional practices, is thought to lead to faster development times and
greater client satisfaction, because the client is involved throughout the development process
The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders, executives,
SME’s, end-users, business analysts, software architects and developers. It is essential that the roles, responsibilities,
and rules for the JAD sessions are well defined and communicated in advance to all participants.
Some typical roles found in a JAD session include:
Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,
Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly document all decisions,
End users – 3 to 5, attend all sessions,
Technical Experts – 1 or 2, question for clarity and give feedback on technical constraints,
Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t attend,
Subject Matter Experts,
Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.
BUSINESS ANALYSIS
What is PEST Analysis?
PEST is an acronym that stands for Political, Economic, Social, Technological. PEST analysis is
one way that a business can analyze the environment in which it operates.
Political Environment: refers to government laws, regulations, and policies. These are things
that impact the business either directly or indirectly. This may include trade laws, tariffs, labor
laws, taxes, environmental regulations, zoning restrictions, etc. Some of these, if passed
recently, may have a long term affect on the economy as well. While PEST covers the economic
environment, some political environment considerations, such as leadership changes that come
from elections, may not have impacted the economy yet (this is an example of an indirect
impact). So the analyst should watch for how new government regulations may impact the
economy longer term and assess its impact on the business.
Economic Environment: refers to the forces at play within the economy that the business has
little control over. These may include interest rates, inflation rate, exchange rates, increase in
Gross Domestic Product (GDP), the financial and stock markets, the job market, etc. All of these
have impacts on the business from the ability to generate revenue to the cost of borrowing money
to the salaries they will need to pay employees.
Social Environment: refers to the demographics of the environment that the company operates
within. Since demographics are nothing more than characteristics of a human population this
could include a nearly infinite number of groups. Some common demographics that are
considered are gender, race, age, income, disabilities, educational attainment, employment status,
and religion. Ultimately, if the strategic plans of a business affect a particular group, they may
react positively or negatively. A business may face criticism, negative publicity or even protests
based on the decisions it makes. These factors could have an enormous impact on the operations
and revenue of the business.
Technological Environment: refers to the technology that currently exists that the business has
accessible to them. This could include servers, computers, networks, software and software
frameworks, database technologies, wireless capabilities, availability of Software as a Service
(Saas), and more. The rate of technological progress should also be considered, particularly if
the business has plans to develop a system or product that takes advantage of cutting edge
technology.
What is meant by Forming, Storming, Norming, and Peforming?
The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce
Tuckman. He described that most teams follow a consistent path from the point when they are first
assembled to the time when they become a highly proficient, highly effective group. This path leads them
through four distinct stages; Forming, Storming, Norming, and Performing.
The “Forming” stage begins when new team members are first brought together. Initially everybody is
very positive and polite to one another. Some people are anxious, some are excited. The team members
are fairly unaware of the details of the work ahead (blissfully naïve perhaps) and they look for clear
direction from the leader. Formal processes and project frameworks are not yet established. This stage is
usually short in comparison to the others.
Next is the “Storming” stage. At this stage team members become clear about their roles and what is
expected of them. Processes and project structures are put into full effect. The team may feel frustrated
and overwhelmed by the work as they become more aware of the realities of the job. They may be
stressed by how much there is to accomplish and they may have uncertainties about their ability to do the
assigned work. Or, they may simply be uncomfortable with the approach that is laid out by the leader.
Team members still don’t know each other that well as they continue to form opinions of one another.
They may be jockeying for position within the team or even challenging the leader’s authority. Conflicts
arise more often during this stage. A great deal of oversight is needed by the team leader to ensure the
processes are followed and the work is completed to expectations.
The “Norming” stage is where the team begins to catch their stride. The pecking order of the team is
established and team processes and workflow are beginning to solidify. Each team member understands
the strength of the other members and they all begin to work more as a team. They help each other and
provide peer reviews and constructive criticism. At this point, the team is following the processes and
project framework but may not be working as efficiently as they could be. They still need oversight but
significantly less than in the storming stage.
Finally, the “Performing” stage is reached. The team has a solid understanding of the processes and
project framework that have been put into place and follow them efficiently. The team has become
efficient and productive and it reaches its goals with regularity. At this stage if a team member joins or
leaves it will have little impact on the rest of the team’s performance. The team leader can delegate to
team members with confidence and provide minimal oversight.
What is Function Point Analysis?
Function Point Analysis (FPA) refers to the practice of using function points to size and estimate the cost
of work on systems. Function Points are a normalized unit of measure used to:
Quantify the amount of business functionality a system provides business users
Estimate the cost to develop a system or set of features based on the number of function points it
supports
Determine how costly a system is to maintain based on the number of function points it supports
To state things differently, Function Points are good for answering questions like:
How big is system “A”? Is system “A” bigger than system “B” and by how much? (It answers
these in terms of features)
How much will it cost me to build system “A”?
If I’m paying $500,000/yr to maintain system “B” is that cost effective?
Function Points, being a normalized unit of measure, provides an apples-to-apples comparison of
systems and the costs associated with building and supporting them.
This method of measuring systems was first developed in 1979 by Allan Albrecht of IBM. Today it is
supported by a group called the International Function Point User Group (or IFPUG for short).
To count the number of function points that a system possesses, a skilled practitioner first categorizes
each feature into one of five types (outputs, inquiries, inputs, internal files, and external interfaces). Then
a complexity is assigned to each feature. Finally, a number of function points can be assigned to each
feature. Certain types of system also have additional function point adjustment factors that are used.
The end result is a single number for the entire system called a Function Point Index. Based on this value
and historical function point data, the cost to develop the system can be estimated.
FPA brings structure and rigor to a process that is often very subjective. However, there are a number of
potential challenges that are often voiced when discussing the merits of FPA.
Counting Function Points can be a tricky task to do well. Getting consistent results is a challenge
unless you are a skilled practitioner at counting function points. There is a sizable “Function Point
Counting Practices Manual” available to direct the practitioner in this exercise.
FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.
While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try
to compensate for these challenges.
What is the H-Method?
The H-method is an analysis tool that aids the BA in organizing a fact finding interview with a business
representative or system user.
Before discussing the benefits of the H-Method and how it works, let’s consider a typical interviewing
process. Without the use of a framework for organizing an interview, an analyst and business
representative will often participate in a relatively unstructured dialogue in which the analyst asks
questions such as:
Tell me what you do?
What does your system do?
Who do you interact with?
Why is “x” important?
Then based on the answers given the analyst will continue to ask follow up questions. The success of the
fact finding is typically dependent upon the experience level of the analyst. While this method can work,
the analyst will often walk away with several pages of unstructured notes. The important information must
then be extracted and organized into something meaningful and useful. Only then will the analyst be able
to determine if they have discovered all of the necessary pieces of information or if there are still gaps in
their understanding.
The H-method uses the following “H” shaped diagram to provide a structured framework to guide the
interview and to allow the analyst to captured information in an organized way from the start.
This diagram also asks the business representative questions is a business friendly manner. As
information is gathered, the analyst can document it in the appropriate area of the “H” shaped diagram.
Finally, the information gathered using the first diagram can be mapped to more business analysis centric
concepts on the following revised diagram.
The H-method is successful because it provides both a structured framework to guide the interview
process and because it reminds the business analyst to avoid business analysis jargon that may confuse
the business representative. Instead it asks questions that align more closely with how the business
representative views their world.
What is a Use Case Realization?
A use case realization provides a construct to organize artifacts which shown how the physical design of a
system supports the logical business behavior outlined by a used case. To show this traceability between
the logical and physical design, in the use case diagram each use case is depicted as an oval shown with
a solid-line border. Then for each use case can you may show a use case realization as an oval with a
dotted-line border. The use case and its corresponding use case realization are linked using a realization
dependency which is shown in UML as a dashed line with a triangular arrowhead at the end
corresponding to the realized element (the use case).
Each use case realization will define the physical design in terms of classes and collaborating objects
which support the use case. Therefore, each use case realization typically is made up of a class diagram
and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or
interaction between physical objects.
Use case realizations allow the analyst to clearly separate the concerns of the logical and physical
design. Since a logical design (the business behavior and requirements) can be implemented or realized
via a number of different physical implementations, if a physical design changes the logical use case can
remain unaffected. Also, a use case realization is an excellent form of requirements traceability from the
logical business requirements down to the physical implementation of the solution.
What is a RACI Matrix?
RACI Matrix is the name given to a table which is used to describe the type and degree of involvement
that stakeholders have in completing tasks or deliverables for a project or business process. Also
sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool
used by business analysts and project managers for establishing roles and responsibilities early on in a
project. In this way it reduces project risk and sets expectations about the level of involvement that is
expected by various stakeholders.
RACI is an acronym which stands for Responsible, Accountable, Consulted, Informed. Since using an
acronym makes for easier recollection, the term RACI Matrix tends to be the most commonly used name
for this tool
The RACI Matrix displays deliverables or tasks along one axis:
Project Charter
Business Requirements Document
AS-IS Process Flow
Functional Specifications
Requirements Traceability Matrix, etc.
Then it displays project roles or stakeholders along the other axis
Project Champion
Project Manager
Analysis Lead
Analyst/Analysis Team
Development Manager, etc.
Finally, at each intersecting cell the type or degree of involvement is documented (Responsible,
Accountable, Consulted, Informed).
Ultimately, each organization varies a bit in how they define each level of participation in a task or creation
of a document. The following are some commonly accepted definitions.
Accountable – This is the person who is ultimately on the hook to ensure that the deliverable or task has
been completed and is thorough and correct. This is usually a lead or manager of some kind. The
accountable person may be directing the work of the responsible person, but in the end the buck stops
here. There can only be one truly accountable person. This avoids finger pointing when something
doesn’t get done or is done incorrectly.
Responsible – The responsible person(s) is the worker bee. It can be one person, or a team of people.
They will be the ones getting their hands dirty finding the information they need and putting it to use to
complete the task or create the deliverable. They may be reporting to a lead or manager who is
accountable for the task or deliverable. However, for smaller tasks or deliverables, when there is only one
responsible person listed, they may ALSO be listed as the accountable party.
Consulted – The consulted person(s) is a subject matter expert. They are the person whose opinions or
knowledge of a particular system or process is sought. They don’t usually participate in completing a task
or deliverable other than by providing the information that the responsible person needs to achieve their
task or deliverable.
Informed – These are the people who need to be kept up to date on a task or deliverable. They may
need to track the amount of progress being made, but usually these people care only about the
completion of a task or deliverable. Typically they are either reviewers of the completed document and
provide formal sign-off and approval, or they may be dependent on the information that results from the
task or deliverable.
What strategies might a business analyst consider when planning for a company's growth?
If a company is to ensure its growth, it needs to plan for it. There are a number of growth strategies that
can be used. Deciding which is the right growth strategy for a company depends on it current success
and position within the marketplace in which it operates. Four of these growth strategies are:
Market Penetration (Existing Products/Existing Markets)
Market Development (Existing Products/New Market)
Product Development (New Products/Existing Market)
Diversification (New Products/New Market)
Market Penetration focuses on getting more out of the current markets serviced by an organization while
offering the same products. New products and new markets can mean additional unknowns which, in
turn, increase risk and chances of failure. For this reason, a company may choose to select a growth
strategy of market penetration. The goal of market penetration is to increase the percentage of market
share that the organization possesses through pricing, marketing, loyalty programs, incentives,
advertising, etc.
Market Development is used to describe the growth strategy of an organization which chooses to
venture into new markets or new customer segments with their existing products. Their existing products
are likely proven which provides a degree of stability, but moving into new markets increases risk. This
may still be viewed by some organizations as a fairly conservative strategy and is often adopted by
companies as they feel their current markets getting squeezed tighter and tighter by competition.
Entrance into new markets often requires skilled marketing professionals to ensure a company receives
the attention it is looking for.
Product Development describes the growth strategy of creating new products for existing markets. An
organization may have the benefit of understanding the intricacies of their market but this can create a
false sense of security. Not all new products carry the same risk. However, for certain types of product,
especially those in fast moving technology markets, projecting the outcome of a new product launch can
be very difficult. To overcome some of this risk organizations should be prepared to continuously adapt
their products after launch to ensure marketplace success.
Diversification is the term given to the strategy of delivering new products to entirely new markets. The
growth strategy accepts the risks of two unknowns; the product and the market. Diversification is highrisk but, as with many things, high risk often can mean high reward. Organizations with a track record of
innovation will have the greatest success with this strategy. With diversification as a growth strategy,
everything will be new and the company will need to be prepared to quickly eliminate any risks that
manifest themselves.
The four growth strategies described here are based on a simple 2 x 2 matrix called Ansoff’s Matrix which
considers markets and products along its two axis.
Ansoff’s Matrix
Existing Products
Existing
Markets
New Markets
New Products
Market Penetration Product Development
Market
Development
Diversification
What is Benchmarking?
When companies want to improve, they first need to have an accurate means of measuring performance.
Without accurate measurement, determining process improvement is not feasible. Measurement
establishes a baseline against which the organization can determine the degree of improvement that has
been made.
However, improvement alone may not be enough. If an organization doesn’t know what the standard is it
cannot compare itself against it. For example, if an organization obtains a customer satisfaction rating of
80%, but its competitor receives 90%, they will lose ground in the long run. Benchmarking is the key to
understanding how an organization measures up against others.
Benchmarking is the process of determining how an organization stacks up against industry leaders by
measuring its performance across a series of standard metrics and then comparing the performance
against other best-of-breed organizations within the same industry or service line. Companies may
measure and compare policies, practices, philosophies, and other performance measures.
Benchmarking is usually part of a larger process re-engineering or quality improvement initiative such as
Six Sigma or Total Quality Management.
What is Balanced Scorecard?
Balanced Scorecard is a strategic planning and management system that was formalized in the 1990s by
Dr. Robert Kaplan (of the Harvard Business School) and Dr. David Nortan. The goal of Balanced
Scorecard is to implement a performance measurement framework which provides strategic non-financial
performance measures that when coupled with traditional financial metrics provides a more “balanced”
view of the organization. Using Balanced Scorecard a company can align daily business activities to the
vision and strategy of the organization effectively transforming their strategic plan from a passive
document into a plan which provides clear and measurable goals for all areas of the organization.
As described by Kaplan and Nortan, Balanced Scorecard retains the traditional financial measures, but
financial measures reflect past events. This alone is inadequate for guiding and evaluating a company’s
future direction. A company’s future success is driven through customer relationships, supplier
relationships, employee development, process improvement, technology improvement, and innovation.
To improve in these areas Balanced Scorecard organizes the development of metrics and the tracking of
progress against these metrics into four perspectives.
The Learning and Growth Perspective
The Business Process Perspective
The Customer Perspective
The Financial Perspective
The Learning and Growth Perspective focuses on the development of metrics around training of
employees and education of the organization as a whole. These metrics should be structured in a way to
guide managers to focus their training funds where they will help most. They should also drive other
methods of learning such as mentoring and ensuring that knowledge can easily be communicated and
shared throughout the organization.
The Business Process Perspective focuses on the development of metrics that allow managers to know
how well the internal business processes are running and how well they meet the needs of the
organization’s customers.
The Customer Perspective focuses on the development of metrics around customer satisfaction. This
perspective cannot be underestimated as it has been found that customer satisfaction is a leading
indicator of the future performance of the company. Over time, dissatisfied customers will seek out other
organizations that can meet their needs better.
The Financial Perspective focuses on traditional financial metrics. Companies often already place a
heavy emphasis on financials which can lead to an unbalanced view of a situation. While this perspective
is very important, Balanced Scorecard aims to balance this perspective by considering it in conjunction
with the metrics and data of the other perspectives.
What is Document Analysis?
Document Analysis is a technique used to gather requirements during the requirements elicitation phase
of a project. It describes the act of reviewing the existing documentation of comparable business
processes or systems in order to extract pieces of information that are relevant to the current project, and
therefore should be consider projects requirements.
Business analysts can elicit requirements in many ways, and eliciting them from stakeholders using
questionnaires, interviews, or facilitating sessions are most common. However document analysis is
particularly valuable when replacing one or more existing systems with a new system that will offer
increased functionality or a better overall user experience. Existing documentation can be scoured for an
understanding of key functions, business rules, business entities, and business entity attributes.
Document analysis may also be necessary when stakeholders are not available to offer insight into
existing business processes or systems.
Some forms of documents that are useful in document analysis may be obvious, while others less so.
Here is a list of potential documents that an analyst should consider reviewing based on their particular
project type.
Benchmarking studies
Business plans
Business process and procedure documentation
Company memos
Competing product literature and reviews
Customer contracts
Customer suggestions
Requests for proposals
System defect reports
System specifications (of existing systems)
Training guides
Vision documents for related projects
How is the Business Analysis Planning and Monitoring (BABOK v2.0) knowledge area
defined?
The Business Analysis Planning and Monitoring knowledge area describes the process of how a business
analyst determines which activities will be needed to complete the business analysis effort. The tasks
within this knowledge area govern the business analysis tasks in all of the other knowledge areas. These
tasks include:
1. Plan Business Analysis Approach
2. Conduct Stakeholder Analysis
3. Plan Business Analysis Activities
4. Plan Business Analysis Communication
5. Plan Requirements Management Process
6. Manage Business Analysis Performance
What is BPMN?
BPMN stands for Business Process Modeling Notation. BPMN is an industry standard
that provides businesses with the capability of visualizing and communicating their
internal business processes and their external business to business processes in a
standard manner. Beyond the obvious use of modeling business processes, BPMN
has been created with the key goal of creating a bridge between the business
process modeling notation (BPMN) and IT-oriented execution languages that will
implement the modeled business processes within a business process management
system. This is done by maintaining and supporting a strict internal model that
maps the rich set of graphical objects and object attributes of BPMN to executable
languages such as the Business Process Execution Language for Webs Services
(BPEL4WS) or Business Process Modeling Language (BPML) to support immediate
execution of modeled buiness processes.
NOTE: From the business systems analyst perspective, BPMN is a modeling notation
which provides the analyst with a rich graphical notation for modeling business
processes, sub-processes, and activities.
Many business analysts use BPMN diagrams instead of UML activity diagrams.
In addition, BPMN is a visual notation used by many of today's business process
modeling and management tools.
Name a few of the industry standards, methodologies, or best practices used by
business analysts and systems analysts?
-UML
-BPMN
-RUP
- Agile
- SDLC
