Seven steps to mastering business analysis

Barbara A. Carkenord

Chapter 1. Possess a clear understanding of business analyst

A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an
objective.

Core requirements components:

Data Processes
(attributes, (or use
entities) cases)

External agents
(or actors)

Chapter 2. Know your audience

Stakeholder analysis (including expert judgment and understanding the political environment),
balancing stakeholder needs & establish trust with your stakeholders

Vendor relationship lifecycle:

8.
Ongoing
support, 1. Sales
new calls /
releases, product
enhance demos
7. ments,
bug fixes 2. Vendor
Customiz
selected
ation,
as
training,
possible
impleme
supplier
ntation

6. 3. Issue
Contract RFP to
negotiati multiple
ons vendors

4. Review
5. Select RFP
a vendor response
s

Seven steps to mastering business analysis - Barbara A. Carkenord Page 1

Chapter 3. Know your project
 Business case development - project initiated:
o Because of a problem – root cause analysis / the 5 whys
o To eliminate costs (jobs)
o By outside regulation
o By an opportunity
o For marketing or advertising
o To align business processes – optimize/integrate commercial off-the-shelf (COTS)
software packages => search for ‘the best fit’
 Bidding process:
o RFI: request for information – brief document outlining the business problem or
opportunity that a company is trying to solve, and asking vendors to provide initial,
general information about product offerings.
o RFQ: Request for Quotation – brief document asking vendors to provide a formal price
quotation (typically for products that are standard from one vendor to another).
o RFP: Request for Proposal – typically longer document, describing, in detail, the needs of
the company, and asking vendors to specifically describe how their product will match the
needs of the organization.
 Strategic planning and portfolio & program management

Project
Project planning
Program
& scoping
Project
Business analysis
planning &
scoping
Project
Strategic
Program
planning
Project

Project

Program

Project

Portfolio

Portfolio: collection of projects and programs that an organization has identified and
prioritized to support the strategic plans
Program: ongoing strategic business initiative that supports multiple related projects
 Enterprise architecture: describing current environment and future plans
o Business architecture: describes the current structure of an organization and outlines a
plan for where the business is headed. Includes SWOT analysis.

Strenghts Weaknesses
Opportunities Pursue opportunities that are a Overcome weaknesses to pursue
good fit with strengths opportunities
Threats Establish a defensive plan to
Use strengths to mitigate threats
prevent vulnerability

Seven steps to mastering business analysis - Barbara A. Carkenord Page 2

 o Information architecture: a plan for where the organization will store information so that
it is safe, secure and easily accessible.
o Application architecture: a plan for an organization’s application systems, including plans
for maintaining legacy applications and strategies for replacement, plans for new
applications and their interfaces, awareness of how new technologies may impact
existing and future applications, and plans to support the expected business growth.
Must be flexible to evolve with the business.
o Technology architecture: supports the application architecture by outlining the strategic
direction for brands and types of hardware, software, operating systems, networks,
programming language, DBMS, etc.
 Project initiation:
o Define business need
o Define solution scope: revisit scope frequently + mitigate scope creep!
o Approach/methodology
o Statement of purpose – elevator pitch
o Objectives
o Problems/opportunities
o Stakeholders
o Business risks
 Business risk assessment:

Business risk Probability Risk response / Impact

contingency strategy

 Four main risk strategies:

 Avoid: change the project to eliminate the threat
 Transfer: shift the risk to another project or group
 Mitigate: reduce the probability or impact of the risk
 Accept: allow the risk to exist as is and develop a contingency plan
o Items out of scope
o Assumptions & constraints
o Scope of the business area
 Context-level data flow diagram, with:
 Organizational units that will interface with the project (external agents)
 Existing enterprise applications that may require an interface to the
project (external agents or interactions)
 Personnel, customers, vendors, etc. that will be involved with the project
(external agents)
 The name of the project or area of study (the circle)
 Information that flows into and out of the project (arrows)

Seven steps to mastering business analysis - Barbara A. Carkenord Page 3

  High-level business processes
 Use case diagram:

Chapter 4. Know your business environment

 Vision statement: an enduring reason for being; energizes stakeholders to pursue common goals
 Mission statement: describes the operational, ethical and financial guidelines of an organization
 Read marketing materials, financial reports, corporate strategic plan
 Try seeing things from the business perspective => including prioritizing needs!
 Review existing documentation, observation, interviews, surveys & questionnaires, facilitated
sessions, focus groups (sessions with randomly selected individuals who represent a particular
demographic or viewpoint), competitive analysis and benchmark studies, interface analysis
(identify interfaces that may impact or be impacted by the current project and plan the changes
necessary to smoothly integrate the new solution into the existing environment).
 Learn current (as is) system, may include reverse engineering (analysis of existing software)
 Business process – specify and model requirements

Seven steps to mastering business analysis - Barbara A. Carkenord Page 4

Term General Usage Examples
Function Ongoing activities of the business Human resources
management, marketing,
finance
Process Can mean anything from a very high-level activity in the Receive order
organization (e.g. sell product), to a low-level, detailed activity Validate order
(e.g. record order) – how work is done / goals of the work / how
software is developed (= Rational Unified Process)
Names are usually verb-noun phrases.
Processes should be named from the perspective of the business.
Sub process A portion of a major process
Activity Used interchangeably with process, task or procedure
Task Generally considered a lower level sub process. Add new account
Usually defined as an individual unit of work that can be
accomplished by one business worker in a shorter period of time
Names are verb-noun phrases
Procedure Set-by-step activities that define how work should be done. Often, New employee procedure,
procedures are considered manual tasks (not entirely supported hiring procedure, file a claim
by software) procedure
Use case Defined as the goal of the business (high-level or detailed) Place order
Named from the perspective of the actor (person for whom the
goal is desired)
Event Something that happens – and causes the business to react. There Customer requests product
are several types of events, primarily external and temporal. (cfr.
event partitioning)

 The WHAT, not the HOW! “The analyst should look at the business through “glasses” that filter
out the technology”
 “Perfect technology”: there are no limitations and the business process can be built to be
ultimately efficient and effective – assume:
 No storage limitations or constraints
 Completely error-free processing is available
 No performance limits or constraints
 Technology is available at no cost
 Essential business processes
 Process vs use case

Process Use case

Business activity
Named with a verb describing the work performed by the
business (validate order)
Defined without reference to whom performs it
Defined so that it could be performed by any business
worker and/or external customer/supplier/vendor
Always defined as independent of specific procedures or
technologies
Goal of the system needed by a particular actor
Named with a verb describing the action taken by the actor
(place order)
Tied to a specific role (the actor)
Designed to be executed (often specified as a conversation
between the actor and the software)
Business use cases may be independent of technology;
system use cases describe how the software will support
the activity

 Indicators, metrics and reporting! E.g. resource use, time to complete, efficiency, number of
times performed, etc. – Six sigma: approach to business process improvement relying heavily on
metrics with the objective to eliminate defects and variations in processes
 Seeing things from the top and from the bottom
 Implementation planning: define transition requirements / determine organizational readiness

Seven steps to mastering business analysis - Barbara A. Carkenord Page 5

Chapter 5. Know your technical environment
“Understand the technology, but don’t talk like a technologist”

Areas important to a business analyst:

 Software development / programming terminology

Software development methodologies:
o Waterfall
o IE: Information Engineering – adds the importance of requirements models and
introduces a data-centric focus + brings business stakeholders into design discussions
o IDEF: Integration DEFinition – reinforces the value of modeling requirements
o JAD: Joint Application Development/Design – emphasizes user involvement with
software design
o RAD: Rapid Application Development – adds prototyping and faster development
concepts
o Iterative/incremental approaches – recognize the value of revisiting phases to catch
missed requirements; break projects into smaller deliverables that can be
implemented faster
o Object-Oriented Analysis and Design – introduced reusable components in program
code; utilizes the concept of encapsulation, making software components more
independent
o RUP: Rational Unified Process – the most well-known OO approach to software
development
o Agile development practices – focus on small, co-located teams ; decreased focus on
formal requirements
 Technical architecture
 Operating systems
 Computer networking
 Data management: concepts like data integrity, conceptual, logical and physical data
modeling, relational database structures, data dictionary, data warehouse and business
intelligence systems, data mart, database access methods, data security issues // database
management systems (e.g. Oracle, SQL Server, etc.):
o Who owns the data? How is this ownership maintained?
o How is the data used? Why is it maintained?
o What volume of data is expected?
o What is the data’s “golden” source? How many places is this data stored?
o How is data mapped after a merger?
o How will data be converted from a legacy system to a new Web application?
o How often does data change?
o How often is data in the data warehouse refreshed? Is real-time data needed?
SQL: Structured Query Language – Tip: Sams Teach yourself SQL in 10 Minutes
 Software usability / human interface design
o Suitability for the task
o Self-descriptiveness
o Controllability

Seven steps to mastering business analysis - Barbara A. Carkenord Page 6

 o Conformity with user expectations
o Error tolerance
o Suitability for individualization
o Suitability for learning
 Software testing: validate that the product meets business needs
o Software testing phases:
 Unit testing: a small piece of the software that can be tested individually =>
find problems in the smallest component of a system before testing the
system in its entirety
 Integration testing: requires the individually tested units to be integrated
and tested as larger unit of subsystem => find problems in how components
of a system work together: validate software architecture design
 System testing: to find problems in how the software meets the users’
needs: validate original requirements
 Regression testing: after any software change, retest functions of the
software that have not changed to be sure that the results are still correct
 User acceptance testing: to validate that the end solution meets the business
needs
 Post-implementation user assessment: evaluate the effectiveness of the
software after it has been used thoroughly in the business area

o System level tests:

Test type Purpose
Requirements validation Makes sure that system logic supports the business and
functional requirements
Performance testing Measures the speed of response
Stress testing Pushes the software to its limits in terms of number of users
and rate of input
Volume testing Uses high-volume transactions to verify that the software
will handle all growth projections
Security testing Makes sure that unauthorized users cannot gain access to
confidential data and that authorized users can effectively

Seven steps to mastering business analysis - Barbara A. Carkenord Page 7

 complete their required tasks
Installation testing Important for software that will be shipped to users and
requires local installation
Configuration testing Determines how the software will perform on various types
of hardware, operating system, networks, and in
conjunction with other software packages running on the
same system
Usability testing Verifies that the software has been designed for the users
within the principles of usability

Chapter 6. Know your analysis techniques

 Collecting and managing requirements
 Categorizing requirements
o IIBA BABOK example categories: business requirements, stakeholder requirements,
solution requirements (functional and non-functional requirements), and
implementation or transition requirements
o Carkenord suggestion:
 Business requirements: detailed description of information, business activities,
business rules, and external interactions needed to accomplish the business
mission (independent of how the issue might be solved!)
 Functional requirements: describe how work will be done, how the software will
function
For each business requirement, there may be several functional requirements
that support it
Non-functional requirements: supplementary requirements, constraints, or
quality of service requirements, e.g.: accessibility, audit & control, compatibility,
effectiveness (resulting performance in relation to effort), efficiency (resource
consumption for a given load), extensibility (adding features and carry-forward of
customizations at next major version upgrade), legal & licensing issues,
maintainability, performance/response time, quality (e.g. faults discovered,
faults delivered), reliability, resource constraints (processor speed, memory, disk
space, network bandwidth, etc.), safety, scalability (horizontal, vertical), security,
stability, system availability, usability & learn ability
 Technical requirements: specify how the solution should be built and integrated
into the existing systems in the organization: detailed descriptions of the
technical architecture framework, database definitions, business rule engines,
program logic, development objects, application interfaces, network
architecture, security components, etc.

Seven steps to mastering business analysis - Barbara A. Carkenord Page 8

 Requirements components

Data Processes
(attributes, (or use
entities) cases)

External agents
(or actors)

 Data (entities & attributes): information used by a business to do work

o Entity: a uniquely identifiable person, thing, or concept whose information is
important to a business (e.g. customer, product, order)
in UML/OO = objects or classes
named with nouns or noun phrases => consistent!
o Attribute: pieces of information that further describe entities
In UML/OO = attributes, characteristics of objects or classes
named with nouns or noun phrases => consistent!
avoid redundancy (data integrity!)
attribute uniqueness / mandatory or optional / attribute repetitions
 Processes (use cases): a business activity that transforms input (data) into outputs
Recommendation: process names start with a verb and include a noun (data)
 External agents (actors): people, organizations or other systems that interact with
the area of a business being discussed
o Internal versus external: external cannot be changed by a project
 Business rules: constraints or guidelines under which a business operates
Key requirements component!
Recommended: a rules administrator and shared repository
~ decision points
Tip: Business Rules Applied by Barbara von Halle

Entity relationship diagram: defines 3 data components: entities, attributes and relationships

Tip: Data Modeling essentials by Simsion and Witt

Seven steps to mastering business analysis - Barbara A. Carkenord Page 9

 Analysis techniques and presentation formats
 Glossary
 Workflow diagrams: visually detail one or more business processes to clarify
understanding or make process improvement recommendations, including how work
is accomplished and the sequence in which things are done.

o Business Process Modeling Notation – www.bpmn.org

o Six Sigma SIPOC diagram (Supplier, Inputs, Process, Outputs and Customer):
to show a high-level view of an entire business transaction and identify and
measure current business activities and perform root cause analysis to find
process inefficiencies
o Lean approaches: value stream mapping to analyze the flow of materials and
information to bring a product or service to the customer www.lean.org
 Entity Relationship Diagramming (ERD): representing data requirements
(Logical) data model = ERD with accompanying descriptions and details: a
visual representation of the information requirements of a business domain
or of an application software system

Seven steps to mastering business analysis - Barbara A. Carkenord Page 10

  Decomposition Diagram: shows all of the essential business processes without
showing any sequence or relationships between them
Typically used for strategic planning / not obvious
Process/business model: decomposition diagram in combination further described
with triggers, trailers, related business rules, and data
Rules:
o Only one type of relationship between components: parent to child
o Only one type of requirement (requirements OR components)
o Every parent has more than one child
o No sequence is shown (no arrows)
o A child must be at a lower level than its parent (more detailed, finer
distinctions)

 Use case Diagram: shows how a software system interacts with its users (actors)
Useful for showing the scope of a project or a software product

Use cases are depicted as ovals and actors as stick people; use case diagram includes an automation
boundary, delineating what the software includes and shows the interfaces to the software with
association lines. Associations to people actors represent user interfaces like screens and reports.
Associations to system or organization actors represent automated or electronic interfaces.

Use case description: all of the requirements components for a particular software function; also
includes a sequential set of steps that describe how the software and actors should interact to
achieve a business goal, typically a happy path along with alternate paths.

Seven steps to mastering business analysis - Barbara A. Carkenord Page 11

  Prototypes/Simulations: a model of a user interface in an automated system to
show the stakeholders what the software will ‘look like’.
Storyboard shows a series of screens and how the software user should be able to
navigate between them
Screen layout
Simulation
Report layouts specify how data from the database will be presented to users,
including formatting, column headers, and pagination
 Event modeling: identifying and analyzing events (something that happens outside a
business area, to which the business area must respond; the responses to events are
business processes)
 Entity State Transition / UML State Machine Diagrams: think through all of the
states a particular entity or object may be in
 Object modeling / Class modeling: combine data and processes into one
requirements components
 User stories

Seven steps to mastering business analysis - Barbara A. Carkenord Page 12

  Traceability matrices: identify which requirements components are related to each
other, along with any characteristics about the relationship

CRUD (create, read, update and delete) matrix: link between data and process

 GAP analysis: find specific gaps in either software or manual procedures, comparing
two or more systems using a structured documentation format
 Data Flow Diagramming (DFD)
Basic assumption: a process must have at least one input and at least one output
flow
Often used: context-level DFD

 AS IS versus TO BE analysis
 Packaging requirements: Request for Proposal!
 Characteristics of excellent requirements: complete, correct, unambiguous, verifiable,
necessary, feasible and prioritized
 Getting Sign-Off
 Requirements Tool, Repositories, and Management

Seven steps to mastering business analysis - Barbara A. Carkenord Page 13

Chapter 7. Increase your value
 Build your foundation
o Skills: Get started, analytical thinking & problem solving, note taking, brainstorming,
work with complex details
 Time management
o Skills: understand the nature of project work, prioritize
o Techniques: understand the 80-20 rule (business analysts spend 20% of their time
eliciting 80% of the requirements; the other 80% of analysis time is spent gathering 20%
of the requirements), time-boxing
 Build your relationships and communications kills
o Skills: build strong relationships (knowledge & experience, access & openness), ask the
right questions, listen actively (barriers to listening: filters, lack of interest, preconceived
ideas, be careful not to formulate responses or follow-up questions while the person is
still talking, do not finish statements for others), write effectively, make excellent
presentations, facilitate and build consensus, conduct effective meetings, conduct
requirements reviews (e.g. walkthroughs, peer reviews, and inspections)
 Keep learning new analysis techniques
o Technique: avoid analysis paralysis, root cause analysis (fishbone diagram / 5 whys)

oSkill: intelligent disobedience (being able to disagree with an organizational decision

without jeopardizing one’s career or relationships – requires 1) get your facts together,
2) present the facts without emotion, 3) be willing to accept the decision and move
forward)
 Continually improve your skills
o Skills: make recommendations for solutions (requires 1) understand the problem, 2)
imagine possible solutions, 3) evaluate solutions to select the best), be able to accept
constructive criticism, recognize and act on your weaknesses
o Techniques: lessons learned
 Business analysis planning
o Techniques: assess business impact (number of users, number of stakeholders, level of
stakeholders, geographical location of the stakeholders, business complexity, solution

Seven steps to mastering business analysis - Barbara A. Carkenord Page 14

 complexity, business risk, quality requirements&expectations, firm due date, length of
project, project budget relative to project size), conduct stakeholder analysis, plan your
communications, map the project:

Current (as is) Future (to be)

Description of the current
New service or product for the
Business analysis (the “what”) business are independent of
organization
how the work is done
The current The design plans for a new or
Solution/Functional analysis systems/procedures used to updated system or procedure
(the “why”) accomplish the business to better accomplish the
processes business processes
o Skills: plan your work, choose appropriate requirements deliverables, develop a business
analysis task list, estimate your time

Seven steps to mastering business analysis - Barbara A. Carkenord Page 15