Final BA Book PDF

Jump Start Your Career as a Business Analyst
A Guide for planning career in Business Analysis!
Business analysis is a research discipline of identifying business needs and

determining solutions to business problems. Solutions often include a software-
systems development component, but may also consist of process improvement,
organizational change or strategic planning and policy development.
This book talks about various activities, tools and techniques that are required to be
a successful business analyst. Author firmly believes that topics that are covered in
this book are enough to jump start one’s career in the field of Business Analysis.
Series: Business & Domain Series

Author: Swapnil Saurav
Price: ₹ 450
ISBN: 978-81-931739-7-8
Online shop: www.ekapress.org

About the Author
Swapnil Saurav
Swapnil Saurav has more than 14 years of work
experience in IT industry with focus on Supply Chain
Analytics. He is an ambitious, creative and highly
motivated individual, who has a passion for the Supply
Chain with focus on Retail and Manufacturing industries and an uncompromising
commitment to quality and outstanding customer service. He has been invited to be
the key note speaker at various industry forums and has a passion for teaching &
developing leaders for tomorrow. His expertise lies in figuring out ways to do what
others say can't be done. He holds MBA from S.P. Jain Institute of Management &
Research, M.S. (BITS, Pilani) and B.E. (Visvesvaraya Technological University).
Website: www.swapnil.asia
Linked In profile: https://in.linkedin.com/in/swapnilsaurav
Dear parents, Success is in my stride, because I
have parents like you by my side.
Dear Rupali, you made me dream, when I simply

saw. You made me execute, when I simply thought.
Thank you for being with me.
TABLE OF CONTENTS
1 GETTING READY FOR CAREER IN BUSINESS ANALYSIS....... 5

What is Business Analysis ............................................................................. 5
Role of BA in IT Project Delivery ................................................................... 6
Finding your path to BA ................................................................................ 8
2 INTRODUCTION ...........................................................................10
Key Concepts............................................................................................... 11
Requirements Classification Scheme.......................................................... 12
Knowledge Areas ........................................................................................ 13
Tasks............................................................................................................ 15
Stakeholders ............................................................................................... 16
3 Business Analysis Planning & Monitoring ................................19
Plan Bussiness Analysis Approach .............................................................. 19
Conduct Stakeholder Analysis .................................................................... 22
Plan Business Analysis Activities ................................................................. 26
Plan Business Analysis Communication ...................................................... 29
Plan Requirements Management Process ................................................. 31
Manage Business Analysis Performance .................................................... 33
4 Elicitation .....................................................................................36
Prepare for Elicitation ................................................................................. 36
Conduct Elicitation Activity ......................................................................... 37
Document Elicitation Results ...................................................................... 39
Confirm Elicitation Results .......................................................................... 40
5 Requirements Management & Communication ........................41
Manage Solution Scope & Requirements ................................................... 41
Manage Requirements Traceability............................................................ 43
1|P ag e
Maintain Requirements for Re-use ............................................................ 44

Prepare Requirements Package.................................................................. 45
Communicate Requirements ...................................................................... 48
6 Enterprise Analysis .....................................................................49
Define Business Need ................................................................................. 49
Assess Capability Gaps ................................................................................ 51
Determine Solution Approach .................................................................... 52
Define Solution Scope ................................................................................. 53
Define Business Case .................................................................................. 55
7 Requirements Analysis ...............................................................57
Prioritize Requirements .............................................................................. 57
Organize Requirements .............................................................................. 59
Specify and Model Requirements............................................................... 60
Define Assumptions and Constraints ......................................................... 61
VERIFY Requirements ................................................................................. 62
Validate Requirements ............................................................................... 63
8 Solution Assessment & Validation ............................................65
Assess Proposed Solution ........................................................................... 65
Allocate Requirements ............................................................................... 66
Assess Organizational Readiness ................................................................ 68
Define Transition Requirements ................................................................. 70
Validate Solution......................................................................................... 72
Evaluate Solution Performance .................................................................. 73
9 Underlying Competencies ..........................................................76
Business Effectiveness ................................................................................ 76
Personal Effectiveness ................................................................................ 79
Administration skills ................................................................................... 81
2|P ag e
10 Techniques.................................................................................82
Acceptance and Evaluation Criteria Definition........................................... 82
Benchmarking ............................................................................................. 82
Brainstorming ............................................................................................. 83
Business Rules Analysis ............................................................................... 83
Data Dictionary and Glossary ..................................................................... 84
Data Flow Diagrams .................................................................................... 84
Data Modeling ............................................................................................ 85
Decision Analysis......................................................................................... 86
Document Analysis ..................................................................................... 87
Estimation ................................................................................................... 87
Focus Groups .............................................................................................. 87
Functional Decomposition .......................................................................... 88
Interface Analysis ........................................................................................ 88
Interviews ................................................................................................... 89
Lessons Learned Process ............................................................................ 90
Metrics and Key Performance Indicators ................................................... 90
Non-functional Requirements Analysis ...................................................... 91
Observation ................................................................................................ 91
Organization Modeling ............................................................................... 92
Problem Tracking ........................................................................................ 92
Process Modeling........................................................................................ 92
Prototyping ................................................................................................. 93
Risk Analysis ................................................................................................ 94
Requirements Workshops .......................................................................... 94
Root Cause Analysis .................................................................................... 95
Scope Modeling .......................................................................................... 96
3|P ag e
Scenarios and Use Cases ............................................................................. 97

Sequence Diagrams .................................................................................... 98
State Diagrams ............................................................................................ 99
Structured Walkthrough ............................................................................. 99
Survey/Questionnaire ............................................................................... 100
SWOT Analysis .......................................................................................... 101
User Stories ............................................................................................... 101
Vendor Assessment .................................................................................. 102
Appendix: Software Requirements Specification (SRS) ...........103
4|P ag e
1 GETTING READY FOR CAREER IN BUSINESS ANALYSIS
WHAT IS BUSINESS ANALYSIS
WHAT IS BUSINESS ANALYSIS

Business analysis refers to the identification and analysis of business problems,
needs and opportunities through participation in the SDLC to help achieve the
organisation’s strategic vision and business goals.
WHAT IS BUSINESS ANALYST

BA refers to any person who is responsible for performing the business analysis
functions for IT system development projects such as analysing business needs,
facilitating the elicitation of user requirements, documenting and prioritising the
business requirements, verifying the major project deliverables, business
reengineering opportunities and workflow from business perspective, and
facilitating effective communication between business and IT sides.
IMPORTANCE OF AND NEED FOR A BA ROLE

(a) During IT system development, communication gap often exists between
IT staff and business users due to differences in knowledge, skills, background
and orientation. Users may not understand the IT terminology and technical
solutions while IT staff may not understand the business terminology,
functions, processes and environment, leading to difficulties in eliciting real
business needs and understanding of requirements as well as affecting the
design of the proposed system. The situation becomes even more challenging
if the IT project is outsourced, where more communication and collaboration
issues may arise especially when the external IT contractor is not familiar with
the Government environment and the business processes. Therefore, a BA
role is important and needed to be instituted in the IT project organisation to
improve the collaboration between users and IT staff throughout the SDLC.
(b) At project initiation stage before the formation of a project team, BA can
help explore improvement opportunities of current state by developing sound
business cases to justify the investment of IT project and produce a clear
project scope and estimation. BA role is especially helpful in scoping and
planning of large-scale projects at project initiation stage.
(c) Where the demand and resources justify, a permanent establishment of

the BA role is recommended to aid in future system maintenance, support and
enhancement.
5|P ag e
BENEFITS OF HAVING DEDICATED BA

BA serves as the bridge between the business users and the technical IT people.
Its presence will contribute significantly to the success of IT projects. The
anticipated benefits of having a dedicated BA include the following:
 able to deliver a clear project scope from a business point of view;
 able to develop sound business cases and more realistic estimation of
resources and business benefits;
 able to make a better project scoping, planning and management in costs
and schedule especially for large-scale IT projects;
 able to produce clear and concise requirements, which in turn, helps
provide clearer and more accurate tender requirements if the IT project is
outsourced;
 able to elicit the real business needs from users, and effectively manage
user expectations and changes;
 able to improve the quality of design for the proposed IT system so that it
is able to meet real user needs and achieve the anticipated benefits;
 able to ensure the quality of the system developed before passing on to
end-users for review and acceptance; and
 More competent to arrange the comprehensive and quality test on the
delivered systems or functions and provide feedback to the technical IT
people.
ROLE OF BA IN IT PROJECT DELIVERY
The major role of BA is to liaise between end-user side and IT side to help identify
and analyse business problems and needs, and work closely with the SA during
the development of IT system to achieve the business goals. The major
responsibilities of BA are listed as follows:
 Contribute to the Development of Business Case: Assist users in identifying
business problems, needs and functions, understand stakeholders’ concerns
and requirements, identify improvement opportunities, and contribute
business input for developing the business case for the IT system development
project.
 Facilitate the Elicitation and Analysis of Requirements: Collaborate and

communicate with stakeholders to elicit, consolidate, analyse and prioritise
requirements, manage their expectations and needs, and help ensure the
requirements are complete, unambiguous and map to real business needs.
6|P ag e
 Assess Proposed System Option and Organisation Readiness for System

Implementation: Provide support to users and coordinate with IT staff to help
review and provide input to the design of the IT system from the business
perspective, resolve issues/conflicts among stakeholders, help organise
comprehensive and quality UAT through assisting users in developing test
cases, and help organise training with the aim of ensuring the deployed IT
system is capable of meeting business needs and requirements as well as
realising the anticipated benefits.
 Plan and Monitor the Business Analysis Activities: Plan the scope, schedule
and approach for performing the activities related to business analysis for the
IT system development project, monitor the progress, coordinate with the
Internal PM and report to PAT or PSC on changes, risks and issues wherever
appropriate.
BA Activities in SDLC
Figure 1: BA Activities in SDLC
Business Analysis related activities are involved in various phases of the SDLC. An
overview of the key activities for BA in each phase of the SDLC is depicted in
Figure 1. We will discuss more about this in various chapters of the book.
7|P ag e
FINDING YOUR PATH TO BA
You might be asking, “How do I become a business analyst?” In what follows, I’ll
help you discover the transition path as well as address some of the most
common special circumstances that tend to come up from aspiring business
analysts. Before we begin, I want say that there is no one path to becoming a
Business Analyst and at the same time, as Lao Tzu had said, The journey of a
thousand miles begins with a single step. So lets that that first step. Follow the 5
steps process I suggest are:
Figure 2: Finding your path to BA
Step 1: Build Your BA Knowledge

 Learn Business Analysis concepts and practices
 Understand the business analyst roles. What is expected from them.
 You are ready to discover your inner BA. Look at your strengths and map
your career goals with your strength
Step 2: Identify BA Experiences

 Understand why BA jobs require experience: BAs are in direct contact with
stakeholders, BAs deal with the unexpected, and Successful BAs show a
pattern of successful project work.
 Identify Your Experience: Evaluate pre-BA roles and Mine BA roles for BA
Activities and Capabilities
Step 3: Identify Leverage Points

 “Soft Skills” are key to success: Develop Communication, Facilitation,
Analytical Thinking skills
8|P ag e
 Unique Areas of Expertise: What do you bring to the table? It could be

Organizational Knowledge and Practices and/or Application or Tool
Knowledge and/or Industry / Domain Expertise.
Step 4: Build Your Plan

 Where are you at: Already a BA? / Partially a BA?
 Plug Knowledge Gaps: get formal trained by senior BA, form study
groups, read blogs, etc
 Plug Experience Gaps: Small projects, hands-on excercises
Step 5 – Focus Your Search

 Leverage Your Qualifications: BA background, Leverage points and
Opportunities within your organization
BLUEPRINT FOR SUCCESS STARTING A BUSINESS ANALYST CAREER

 Understand why business analysis is a career with huge growth potential.
 Know how much or little technical knowledge is required (you might be
surprised!).
 Discover which of your past job experiences will land your first position.
 Decide if you have what it takes!
 Decide whether a business analyst role will give you the job satisfaction
you are searching for.
 Follow a simple step by step guide from where you are now to your first
role.
PERFORM RESEARCH ON JOB OPPORTUNITIES AND JOB DESCRIPTIONS:

 Uncover the top five reasons why you should become a business analyst
from job security through to low barriers to entry.
 Explore the full description of what makes a great business analyst so you
can be sure the role is for you.
 At last, three sentences in plain English that capture the essence of what it
means to be a business analyst.
 Identify Your Transferable Skills and Leverage Points to Develop Your
Positioning
Congratulations for taking the first step. I hope this book will provide you with
right tools to find a career in Business Analysis domain and also help you to
succeed. All the best!
9|P ag e
2 INTRODUCTION
What is Business Analysis?

Business analysis is the set of tasks and techniques used to work as a liaison
among stakeholders in order to understand the structure, policies, and operations
of an organization, and to recommend solutions that enable the organization to
achieve its goals.
Business analysis involves understanding how organizations function to

accomplish their purposes, and defining the capabilities an organization requires
to provide products and services to external stakeholders. It includes the
definition of organizational goals, how those goals connect to specific objectives,
determining the courses of action that an organization has to undertake to
achieve those goals and objectives, and defining how the various organizational
units and stakeholders within and outside of that organization interact.
Business analysis may be performed to understand the current state of an

organization or to serve as a basis for the later identification of business needs. In
most cases, however, business analysis is performed to define and validate
solutions that meet business needs, goals, or objectives.
Business analysts must analyze and synthesize information provided by a large

number of people who interact with the business, such as customers, staff, IT
professionals, and executives. The business analyst is responsible for eliciting the
actual needs of stakeholders, not simply their expressed desires. In many cases,
the business analyst will also work to facilitate communication between
organizational units. In particular, business analysts often play a central role in
aligning the needs of business units with the capabilities delivered by information
technology, and may serve as a “translator” between those groups.
A business analyst is any person who performs business analysis activities, no

matter what their job title or organizational role may be. Business analysis
practitioners include not only people with the job title of business analyst, but
may also include business systems analysts, systems analysts, requirements
engineers, process analysts, product managers, product owners, enterprise
analysts, business architects, management consultants, or any other person who
performs the tasks described in the role of a Business Analyst, including those
who also perform related disciplines such as project management, software
development, quality assurance, and interaction design.
10 | P a g e
KEY CONCEPTS
Domains
A domain is the area undergoing analysis. It may correspond to the boundaries of
an organization or organizational unit, as well as key stakeholders outside those
boundaries and interactions with those stakeholders.
Solutions
A solution is a set of changes to the current state of an organization that are made
in order to enable that organization to meet a business need, solve a problem, or
take advantage of an opportunity. The scope of the solution is usually narrower
than the scope of the domain within which it is implemented, and will serve as
the basis for the scope of a project to implement that solution or its components.
Most solutions are a system of interacting solution components, each of which
are potentially solutions in their own right. Examples of solutions and solution
components include software applications, web services, business processes, the
business rules that govern that process, an information technology application, a
revised organizational structure, outsourcing, insourcing, redefining job roles, or
any other method of creating a capability needed by an organization.
Business analysis helps organizations define the optimal solution for their needs,
given the set of constraints (including time, budget, regulations, and others)
under which that organization operates.
Requirements
A requirement is:
1. A condition or capability needed by a stakeholder to solve a problem or
achieve an objective.
2. A condition or capability that must be met or possessed by a solution or
solution 2. component to satisfy a contract, standard, specification, or
other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).
As implied by this definition, a requirement may be unstated, implied by or

derived from other requirements, or directly stated and managed. One of the key
objectives of business analysis is to ensure that requirements are visible to and
understood by all stakeholders.
The term “requirement” is one that generates a lot of discussion within the
business analysis community. Many of these debates focus on what should or
should not be considered a requirement, and what are the necessary
characteristics of a requirement. When learning, however, it is vital that
“requirement” be understood in the broadest possible sense. Requirements
11 | P a g e
include, but are not limited to, past, present, and future conditions or capabilities
in an enterprise and descriptions of organizational structures, roles, processes,
policies, rules, and information systems. A requirement may describe the current
or the future state of any aspect of the enterprise.
Much of the existing literature on business analysis is written with the assumption
that requirements only describe an information technology system that is being
considered for implementation. Other definitions may include future state
business functions as well, or restrict the meaning of the term to define the ends
stakeholders are seeking to achieve and not the means by which those ends are
achieved.
Similarly, we do not assume that requirements are analyzed at any particular level
of detail, other than to say that they should be assessed to whatever level of
depth is necessary for understanding and action. In the context of a Business
Process Management initiative, the requirements may be a description of the
business processes currently in use in an organization. On other projects, the
business analyst may choose to develop requirements to describe the current
state of the enterprise (which is in itself a solution to existing or past business
needs) before investigating changes to that solution needed to meet changing
business conditions.
REQUIREMENTS CLASSIFICATION SCHEME.
The following classification scheme is used by IIBA to describe requirements:
Business Requirements: are higher-level statements of the goals, objectives, or

needs of the enterprise. They describe the reasons why a project has been
initiated, the objectives that the project will achieve, and the metrics that will be
used to measure its success. Business requirements describe needs of the
organization as a whole, and not groups or stakeholders within it. They are
developed and defined through enterprise analysis.
Stakeholder Requirements are statements of the needs of a particular

stakeholder or class of stakeholders. They describe the needs that a given
stakeholder has and how that stakeholder will interact with a solution.
Stakeholder requirements serve as a bridge between business requirements and
the various classes of solution requirements. They are developed and defined
through requirements analysis.
12 | P a g e
Solution Requirements describe the characteristics of a solution that meet

business requirements and stakeholder requirements. They are developed and
defined through requirements analysis. They are frequently divided into sub-
categories, particularly when the requirements describe a software solution:
 Functional Requirements describe the behavior and information that the

solution will manage. They describe capabilities the system will be able to
perform in terms of behaviors or operations - specific information
technology application actions or responses.
 Non-functional Requirements capture conditions that do not directly relate

to the behavior or functionality of the solution, but rather describe
environmental conditions under which the solution must remain effective
or qualities that the systems must have. They are also known as quality or
supplementary requirements. These can include requirements related to
capacity, speed, security, availability and the information architecture and
presentation of the user interface.
Transition Requirements describe capabilities that the solution must have in

order to facilitate transition from the current state of the enterprise to a desired
future state, but that will not be needed once that transition is complete. They
are differentiated from other requirements types because they are always
temporary in nature and because they cannot be developed until both an existing
and new solution are defined. They typically cover data conversion from existing
systems, skill gaps that must be addressed, and other related changes to reach
the desired future state. They are developed and defined through solution
assessment and validation.
KNOWLEDGE AREAS
As per IIBA, Knowledge areas define what a practitioner of business analysis

needs to understand and the tasks a practitioner must be able to perform.
Business analysts are likely to perform tasks from all knowledge areas in rapid
succession, iteratively, or simultaneously. Tasks may be performed in any order as
long as the required inputs are available. In principle, a business analysis effort
may start with any task, although the most likely candidates are Define Business
Need or Evaluate Solution Performance.
13 | P a g e
Knowledge areas are not intended to represent phases in a project. It is certainly

possible and permissible to proceed from performing enterprise analysis activities,
to requirements analysis activities, to solution assessment and validation activities,
and treat each as a distinct phase in a project. However, we do not require that
you do so, and it should not be construed as a methodology for the performance
of business analysis.
Business Analysis Planning and Monitoring is the knowledge area that covers
how business analysts determine which activities are necessary in order to
complete a business analysis effort. It covers identification of stakeholders,
selection of business analysis techniques, the process that will be used to manage
requirements, and how to assess the progress of the work. The tasks in this
knowledge area govern the performance of all other business analysis tasks.
Figure 3: BA Knowledge areas
Elicitation describes how business analysts work with stakeholders to identify and
understand their needs and concerns, and understand the environment in which
they work. The purpose of elicitation is to ensure that a stakeholder’s actual
underlying needs are understood, rather than their stated or superficial desires.
Requirements Management and Communication describes how business

analysts manage conflicts, issues and changes in order to ensure that
stakeholders and the project team remain in agreement on the solution scope,
how requirements are communicated to stakeholders, and how knowledge
gained by the business analyst is maintained for future use.
14 | P a g e
Enterprise Analysis describes how business analysts identify a business need,

refine and clarify the definition of that need, and define a solution scope that can
feasibly be implemented by the business. This knowledge area describes problem
definition and analysis, business case development, feasibility studies, and the
definition of solution scope.
Requirements Analysis describes how business analysts prioritize and

progressively elaborate stakeholder and solution requirements in order to enable
the project team to implement a solution that will meet the needs of the
sponsoring organization and stakeholders. It involves analyzing stakeholder needs
to define solutions that meet those needs, assessing the current state of the
business to identify and recommend improvements, and the verification and
validation of the resulting requirements.
Solution Assessment and Validation describes how business analysts assess

proposed solutions to determine which solution best fits the business need,
identify gaps and shortcomings in solutions, and determine necessary
workarounds or changes to the solution. It also describes how business analysts
assess deployed solutions to see how well they met the original need so that the
sponsoring organization can assess the performance and effectiveness of the
solution.
Underlying Competencies describes the behaviors, knowledge, and other

characteristics that support the effective performance of business analysis.
TASKS
Each knowledge area describes the tasks performed by business analysts to

accomplish the purpose of that knowledge area. Each task has a purpose. The
purpose is a short description of the reason for a business analyst to perform the
task and the value created through performing the task.
INPUT
An input represents the information and preconditions necessary for a task to
begin. Inputs may be:
 Explicitly generated outside the scope of business analysis (e.g.,
construction of a software application).
 Generated by a business analysis task.
15 | P a g e
There is no assumption that the presence of an input or an output means that the
associated deliverable is complete or in its final state. The input only needs to be
sufficiently complete to allow successive work to begin. Any number of instances
of an input may exist during the lifecycle of an initiative.
STAKEHOLDERS
Each task includes a listing of generic stakeholders who are likely to participate in
the execution of that task or who will be affected by it. A generic stakeholder
represents a class of people that the business analyst is likely to interact with in a
specific way. Any stakeholder can be a source of requirements, assumptions, or
constraints. This list is not intended to be an exhaustive list of all possible
stakeholder classifications, as it would simply not be possible to compile such a
listing. In most cases, there will be multiple stakeholder roles found within each
category. Similarly, a single individual may fill more than one role.
Business Analyst
By definition, the business analyst is a stakeholder in all business analysis
activities. The most common roles to be assigned to business analysts, in addition
to the business analysis role, are the Domain Subject Matter Expert,
Implementation Subject Matter Expert, Project Manager, and Tester.
Customer
A customer is a stakeholder outside the boundary of a given organization or
organizational unit. Customers make use of products or services produced by the
organization and may have contractual or moral rights that the organization is
obliged to meet.
Domain Subject Matter Expert (SMEs)

A domain subject matter expert is any individual with in-depth knowledge of a
topic relevant to the business need or solution scope. This role is often filled by
people who will also be end users or people who will be indirect users of the
solution, such as managers, process owners, legal staff (who may act as proxies
for Regulators), consultants, and others.
End User
End users are stakeholders who will directly interact with the solution. The term is
most frequently used in a software development context, where end users are
those who will actually use the software application that is being developed, but
16 | P a g e
in the broader context of a solution they can include all participants in a business
process.
Implementation Subject Matter Expert (SMEs)

Implementation subject matter experts are responsible for designing and
implementing potential solutions. The implementation subject matter experts will
provide specialist expertise on the design and construction of the solution
components that fall outside the scope of business analysis.
While it is not possible to define a listing of implementation subject matter expert
roles that is appropriate for all initiatives, some of the most common roles are:
 Developers/Software Engineers
Developers are responsible for the construction of software applications.
Areas of expertise among developers or software engineers include particular
languages or application components. Good software development practices
will significantly reduce the cost to build an application, the predictability of
the development process, and the ability to implement changes in the
functionality supported by an application.
 Organizational Change Management Professionals

Organizational change management professionals are responsible for
facilitating acceptance and adoption of new solutions and overcoming
resistance to change. Areas of expertise among change management
professionals include industry and cultural expertise. Good change
management can help to create advocates for change within an organization.
 System Architects
System architects are responsible for dividing a software application into
components and defining the interactions between them. Areas of expertise
among system architects include understanding of methodologies and of
solutions offered by specific vendors. Good system architecture will facilitate
rapid development of solutions and reuse of components in other solutions.
 Trainers
Trainers are responsible for ensuring that the end users of a solution
understand how it is supposed to work and are able to use it effectively. Areas
of expertise among trainers may include classroom-based or online education.
Effective training will facilitate acceptance and adoption of a solution.
17 | P a g e
 Usability Professionals
Usability professionals are responsible for the external interaction design of
technology solutions and for making those solutions as simple to use as is
feasible. Areas of expertise among usability professionals include user
interface designers and information architects. Good usability will increase
productivity, customer satisfaction, and reduce cost in solution maintenance
and training.
Project managers
Project managers are responsible for managing the work required to deliver a
solution that meets a business need, and for ensuring that the project’s objectives
are met while balancing the project constraints, including scope, budget, schedule,
resources, quality, risk, and others.
Testers
Testers are responsible for determining how to verify that the solution meets the
solution requirements defined by the business analyst, as well as conducting the
verification process. Testers also seek to ensure that the solution meets
applicable quality standards and that the risk of defects of failures is understood
and minimized.
Regulators
Regulators are responsible for the definition and enforcement of standards.
Standards may be those that the team developing the solution is required to
follow, standards the solution must meet, or both. Regulators may enforce
legislation, corporate governance standards, audit standards, or standards
defined by organizational centers of competency.
Sponsors
Sponsors are responsible for initiating the effort to define a business need and
develop a solution that meets that need. They authorize work to be performed
and control the budget for the initiative.
Supplier
A supplier is a stakeholder outside the boundary of a given organization or
organizational unit. Suppliers provide products or services to the organization and
may have contractual or moral rights and obligations that must be considered.
18 | P a g e
3 Business Analysis Planning & Monitoring
The Business Analysis Planning and Monitoring Knowledge Area defines the tasks
associated with the planning and monitoring of business analysis activities,
including:
 identifying stakeholders
 defining roles and responsibilities of stakeholders in the business analysis
effort
 developing estimates for business analysis tasks
 planning how the business analyst will communicate with stakeholders
 planning how requirements will be approached, traced, and prioritized
 determining the deliverables that the business analyst will produce
 defining and determining business analysis processes
 determining the metrics that will be used for monitoring business analysis
work
PLAN BUSSINESS ANALYSIS APPROACH
Purpose
This task describes how to select an approach to performing business analysis,
which stakeholders need to be involved in the decision, who will be consulted
regarding and informed of the approach, and the rationale for using it.
DESCRIPTION
There are multiple established ways to approach business analysis work. In
software development, they range from those dictated by the waterfall approach
to the use of agile techniques. Similarly, there are a number of well-known
business process improvement methodologies, including Lean and Six Sigma, as
well as many proprietary and in-house methodologies, customs, and practices.
Elements from different approaches may be combined; however only a subset of
all possible combinations will be viable for the particular organizational
environment in which an initiative is being performed.
In order to plan the business analysis approach, the business analyst must
understand the organizational process needs and objectives that apply to the
initiative. These needs and objectives may include compatibility with other
organizational processes, constraints on time-to-market, compliance with
regulatory and governance frameworks, the desire to evaluate new approaches to
solution development, or other business objectives. If the objectives are not
19 | P a g e
known, the business analyst may be required to define the requirements that the
process must meet.
In many cases, organizations will have formal or informal standards in place
regarding how business analysis is done and how it fits into project and other
activities. If this is the case, the business analyst reviews any existing
organizational standards, including standards, guidelines, and processes relating
to the current initiative. These may suggest or dictate which approach to use.
Even where a standard approach exists, it must be tailored to the needs of a
specific initiative. Tailoring may be governed by organizational standards that
define which approaches are permitted, which elements of those processes may
be tailored, general guidelines for selecting a process, and so forth.
If no standards exist, the business analyst works with the appropriate
stakeholders to determine how the work will be completed. The business analyst
should be capable of selecting or creating an approach and working with key
stakeholders, particularly the project manager and project team, to ensure that it
is suitable.
The business analysis approach is often based on or related to the project
approach, but in some cases they may be independently determined (for example,
an organization may use a plan-driven approach to define its business processes
and then use a change-driven approach to build the supporting software
applications).
INPUT
Business Need: The business analysis approach will be shaped by the problem or
opportunity faced by the organization. It is generally necessary to consider the
risks associated with it, the timeframe in which the need must be addressed, and
how well the need is understood. This will help determine whether a plan-driven
or change-driven approach is appropriate.
Expert Judgment: Used to determine the optimal business analysis approach.

Expertise may be provided from a wide range of sources including stakeholders in
the initiative, organizational Centers of Competency, consultants, or associations
and industry groups. Prior experiences of the business analyst and other
stakeholders should be considered when selecting or modifying an approach.
Organizational Process Assets: Include the elements of existing business analysis

approaches in use by the organization. Organizational process assets that may be
useful in defining the business analysis approach include methodologies for
process change or software development, tools or techniques that are in use or
20 | P a g e
understood by stakeholders, corporate governance standards (such as COBIT™,

Sarbanes-Oxley, and Basel II), and templates for deliverables. In addition to these
general standards, the organization may have guidelines in place for tailoring the
process to fit a specific initiative.
TECHNIQUES
 Decision Analysis: May be used to rate available methodologies against
the organizational needs and objectives.
 Process Modeling: Process Models can be used to define and document
the business analysis approach.
 Structured Walkthrough: This can be used as a means of validating a
created, selected, or tailored business analysis approach.
STAKEHOLDERS
 Customer, Domain SME, End User or Supplier: The approach taken may
depend on their availability and involvement with the initiative.
 Implementation SME: The BA approach taken should be compatible with
the implementation lifecycle used by the implementation team.
 Project Manager: The project manager must ensure that the business
analysis approach is compatible with other project activities.
 Tester: The BA approach must facilitate appropriate testing activities.
 Regulator: Aspects of the approach or decisions made in the tailoring
process may require approval.
 Sponsor: The approach taken may depend on their availability and
involvement with the initiative. The sponsor may also have needs and
objectives that apply to the approach itself.
OUTPUT
Business Analysis Approach: A business analysis approach may specify team roles,
deliverables, analysis techniques, the timing and frequency of stakeholder
interactions, and other elements of the business analysis process. A methodology
is a formalized and repeatable business analysis approach. It includes a decision
about which organizational process assets will be applied and any decisions made
regarding tailoring of the process for a specific situation. Documentation
regarding the approach may eventually be added to the organization’s repository
of process assets.
21 | P a g e
CONDUCT STAKEHOLDER ANALYSIS
Purpose
This task covers the identification of stakeholders who may be affected by a
proposed initiative or who share a common business need, identifying
appropriate stakeholders for the project or project phase, and determining
stakeholder influence and/or authority regarding the approval of project
deliverables.
DESCRIPTION
Stakeholder analysis is performed as soon as a business need is identified and will
usually be an ongoing activity as long as business analysis continues. Stakeholder
analysis begins with identifying stakeholders who may be affected by the business
need or a new solution. Stakeholders may be grouped into categories that reflect
their involvement or interest in the initiative. The roles, responsibilities, and
authority over the requirements for each stakeholder or stakeholder group must
be clearly described. Stakeholder analysis also involves understanding stakeholder
influence on and attitude towards the initiative, and assessing positive and
negative attitudes and behaviors which may affect the outcome of the initiative
and acceptance of the solution.
INPUT
Business Need: Identify and analyze the position of the stakeholders affected by
the business need. As the understanding of that need evolves through definition
of business requirements, solution scope, stakeholder requirements, and solution
requirements, that additional information will be used to assist in identifying
additional stakeholders or understanding how existing stakeholders may have
changed their position.
Enterprise Architecture: Describes the organizational units that exist, their
interactions with other organizational units, customers, and suppliers, their
responsibilities within the organization, and the roles and relationships within
each organizational unit.
Organizational Process Assets: These include organizational policies and
procedures, forms that must be completed, suggested or prescribed
methodologies, templates, and project authorization guidelines. They may be
mandated or expressed in the form of guiding principles.
22 | P a g e
TECHNIQUES
 Acceptance and Evaluation Criteria Definition: The business analyst should,
as part of the stakeholder analysis, identify which stakeholders have
sufficient authority to accept or reject the solution.
 Brainstorming: May assist in identifying needs and requirements that lead
to possible stakeholders, or in creating a listing of possible stakeholder
roles.
 Interviews: Interviewees may be able to identify other stakeholders.
 Organization Modeling: Assess to determine if the organizational units or
people listed have any unique needs and interests that should be
considered. It will describe the roles and functions in the organization and
the ways in which stakeholders interact and so will help to identify
stakeholders who are affected by a change.
 Process Modeling: Any person involved in the execution of business
processes affected by the solution will be a stakeholder. Process models
can be a source for identifying additional stakeholders, since related
processes may be affected. In addition, categorizing stakeholders by the
systems that support their business processes can be useful when changes
need to be made to those processes and systems.
 Requirements Workshops: During requirements workshops, the business
analyst may ask participants if they can suggest other stakeholders.
 Risk Analysis: Risks to the initiative may result from stakeholder attitudes
or the ability of key stakeholders to participate in the initiative.
 Scenarios and Use Cases, and User Stories: Identified stakeholder roles
may serve as a useful starting point for identifying actors and roles.
 Scope Modeling: Scope models should show stakeholders that fall outside
the scope of the solution but still interact with it in some way.
 Survey/Questionnaire: Useful for identifying shared characteristics of a
stakeholder group.
RACI MATRIX
The RACI matrix describes the roles of those involved in business analysis
activities. It describes stakeholders as having one or more of the following
responsibilities for a given task or deliverable:
[R]esponsible does the work,

[A]ccountable is the decision maker (only one)
[C]onsulted must be consulted prior to the work and gives input
[I]nformed means that they must be notified of the outcome
23 | P a g e
An example of a RACI Matrix may be seen below:
Figure 4: Sample RACI Matrix
STAKEHOLDERS MAP
Figure 5: Stakeholder map

Stakeholder maps are visual diagrams that depict the relationship of stakeholders
to the solution and to one another. There are many forms of stakeholder map,
but two common ones include:
24 | P a g e
 A matrix mapping the level of stakeholder influence against the level of

stakeholder interest (shown in Figure 5 on previus page).
 An onion diagram indicating how involved the stakeholder is with the

solution (which stakeholders will directly interact with the solution or
participate in a business process, which are part of the larger organization,
and which are outside the organization)
Stakeholder maps often include lines of communication between stakeholders.
Figure 6: Stakeholder onion diagram
STAKEHOLDERS
 Domain SME: May be able to recommend other business experts to assist
in defining requirements.
 Implementation SME: May be able to identify and recommend
stakeholders.
 Project Manager: May be able to identify and recommend stakeholders. In
the context of a project with a designated project manager, responsibility
for stakeholder identification and management must be shared with the
project manager. The business analyst and project manager should
collaborate on performing this task. The project manager is accountable
for ensuring that the project team meets commitments made to the
stakeholders, managing the assignment of stakeholders to project tasks
and their involvement in the execution of the project, and ensuring that
25 | P a g e
changes that impact the project scope are appropriately managed and
approved. The business analyst will also assist the project manager in
defining which project team members should be involved in developing,
reviewing or approving business analysis deliverables.
 Tester: May be able to identify and recommend stakeholders.
 Regulator: May require that specific stakeholder representatives or groups
be involved in the process.
 Sponsor: May be able to identify domain subject matter experts to help
with requirements definition.
OUTPUT
Stakeholder List, Roles, and Responsibilities
Figure 7: Sample Output
PLAN BUSINESS ANALYSIS ACTIVITIES
Purpose
Determine the activities that must be performed and the deliverables that must
be produced, estimate the effort required to perform that work, and identify the
management tools required to measure the progress of those activities and
deliverables.
DESCRIPTION
26 | P a g e
The business analyst determines which activities are required for a given initiative,
how those activities will be carried out, the work effort involved, and an estimate
of how long the activities will take. This task includes activities to:
 Identify business analysis deliverables
 Determine the scope of work for the business analysis activities
 Determine which activities the business analyst will perform and when
 Develop estimates for business analysis work.
The activities that are executed and how they are executed will determine the
quality and timeliness of the business analysis deliverables and ultimately of the
solution. The business analysis plan(s) identify and schedule the activities and
resources required to produce a clear, concise set of requirements that support
development of the solution.
This planning activity will typically occur more than once on a given initiative or
project, as plans frequently must be updated to address changing business
conditions, issues encountered by the business analyst or other team members,
lessons learned through the performance of business analysis activities, or other
changing circumstances.
INPUT
Business Analysis Approach: Defines the lifecycle, deliverables, templates, and
tasks that should be included. Plan-driven approaches seek to define
requirements as early as possible to reduce uncertainty, while change-driven
approaches encourage requirements to be defined as close to implementation as
possible. The approach will also determine how the planning process is performed.
Business Analysis Performance Assessment: The business analyst must use prior
experiences on this initiative or on others to determine the effort involved in
performing business analysis work.
Organizational Process Assets: Lessons learned from previous initiatives, as well

as from currently ongoing business analysis activities, may be used in the
development of business analysis plans.
Stakeholder List, Roles, and Responsibilities: Stakeholders will exhibit individual

behaviors and preferences that may need to be met. For example, one key
stakeholder may prefer the use of process maps, which could influence the
planning of business analysis tasks related to this stakeholder. Another
stakeholder may have some experience using a particular technology and be in
27 | P a g e
favor of its choice for the current project, which might also influence the business
analysis deliverables, tasks, and estimates. Understanding their roles and
responsibilities on the project will help to determine how much those preferences
will shape the plan.
TECHNIQUES
 Estimation: A variety of estimation techniques can be used to produce an
overall assessment of the amount of business analysis work required. In
some cases, multiple techniques may be used to validate one another.
 Functional Decomposition: Decomposition of the tasks in a project (using
a work breakdown structure) or product (using a solution breakdown
structure) can be used to facilitate an understanding of the work at a
sufficient level of detail to enable estimation of tasks.
 Risk Analysis: Identify risks that might impact the business analysis plan(s).
STAKEHOLDERS
 Customer, Domain SME, End User, and Supplier: Their understanding of

business analysis techniques may shape the selection of techniques or
require that the business analyst devote some time to assist them in
understanding how the requirements are defined.
 Implementation SME: The Implementation SMEs may participate in

business analysis activities in order to facilitate understanding of
stakeholder needs.
 Operational Support: May use business analysis deliverables as a basis for

planning operational support activities or developing appropriate
documentation.
 Project Manager: The project manager should participate in business

analysis planning and is responsible for ensuring that those plans are
integrated with the work performed by other project personnel. The
project manager will also play a key role in identifying resources to
perform tasks, scheduling the activities, and developing cost estimates.
 Tester: Will need to know in what form and when deliverables will be
produced as inputs into their own activity planning.
 Sponsor: Must participate in the approval of business analysis deliverables.
28 | P a g e
OUTPUT
Business Analysis Plan(s): The business analysis plan(s) may include information
such as a description of the scope of work, the deliverable Work Breakdown
Structure, an Activity List, and estimates for each activity and task. It should also
describe when and how the plan should be changed in response to changing
conditions. The level of detail associated with the plan(s) is determined by the
business analysis approach and the overall methodology.
PLAN BUSINESS ANALYSIS COMMUNICATION
Purpose
A business analysis communications plan describes the proposed structure and
schedule for communications regarding business analysis activities. Record and
organize the activities to provide a basis for setting expectations for business
analysis work, meetings, walkthroughs, and other communications.
DESCRIPTION
Planning business analysis communications includes determining how best to
receive, distribute, access, update, and escalate information from project
stakeholders, and determining how best to communicate with each stakeholder.
Requirements can be presented in various formats. This task describes the work
required to decide which format(s) are appropriate for a particular initiative and
its stakeholders. Requirements should be presented in formats that are
understandable for the reviewer; they must be clear, concise, accurate, and at the
appropriate level of detail.
Considerations for the business analysis communications plan include:

 what needs to be communicated;
 what is the appropriate delivery method;
 who is the appropriate audience;
 and when the communication should occur.
Stakeholder needs and constraints relevant to communication include:

 Physical location/time zone of the stakeholders.
 Communication approach for the stakeholder.
 What types of communications will be required (e.g. status, anomalies,
issues and their resolution, risks, meeting results, action items, etc.)
29 | P a g e
 What types of requirements will be elicited (business, stakeholder,

solution, or transition; high level vs. detailed) and how best to elicit them
(see the Elicitation KA for options).
 How best to communicate requirements conclusions/packages, including
authority level (signoff authority, veto authority, or review only).
 Time and resource availability constraints.
INPUT
Business Analysis Approach: May include standards and templates used for
communication, and expectations regarding when and how communication
should occur.
Business Analysis Plan(s): Determines when work will be performed and the
deliverables that will be produced, and which need to be communicated.
Organizational Process Assets: May include a defined set of templates for use in
business analysis communication, including presentation formats, requirements
documentation templates, and others.
Stakeholder List, Roles, and Responsibilities: Used to identify the stakeholders

who will require information regarding business analysis work, determine when
information needs to be provided, and how a stakeholder is expected to use that
information.
TECHNIQUES
Structured Walkthrough: Time to conduct each walkthrough and address the
issues raised during the walkthrough must be included in the plan.
STAKEHOLDERS
 Customer and Supplier: Major customers of an organization or suppliers to
that organization (particularly institutional customers) may need to be
informed of planned changes well in advance of implementation.
 Domain SME: Domain SMEs often have influence over the approvers, even
if their approval is not formally required.
 End User: May also have considerable influence over approvers even if
their approval is not formally required.
 Implementation SME: May be involved in review and approval.
 Operational Support: focus on the requirements to support the solution.
30 | P a g e
 Project Manager: In a project, the business analysis communication plan

will generally be integrated into the overall project communications plan.
On small projects the plan may be very brief and may not be formally
documented. On large and complex projects and projects with many
stakeholders, it may be included as part of the project initiation
documentation and is essential as part of the overall project
communications plan.
 Tester: Be involved in verification and validation of the requirements.
 Regulator: Regulators may require that requirements, decisions, and other
information regarding the execution of business analysis processes or the
definition of the solution be retained and made available to them for
review.
 Sponsor: Communication needs for the sponsor are likely to focus on
business requirements and high-level stakeholder and solution
requirements.
OUTPUT
Business Analysis Communication Plan: Describes how, when and why the
business analyst will work directly with stakeholders. Components can include:
 The stakeholder communications requirements for business analysis
activities.
 Format, content, medium, level of detail.
o Responsibility for collecting, distributing, accessing, and updating
information.
PLAN REQUIREMENTS MANAGEMENT PROCESS
Purpose
Define the process that will be used to approve requirements for implementation
and manage changes to the solution or requirements scope.
DESCRIPTION
This task determines the appropriate requirements management process for a
particular initiative. It includes determining the process for requirements change,
which stakeholders need to approve change, who will be consulted or informed of
changes, and by extension, who does not need to be involved. The task also
includes assessing the need for requirements traceability and determining which
requirements attributes will be captured.
31 | P a g e
INPUT
Business Analysis Approach: The selected approach may include a definition of
appropriate requirements management processes.
Business Analysis Plan(s): The business analysis plan(s) define which deliverables
are to be produced and when. Deliverables cannot be managed until they are
created.
Organizational Process Assets: Standard templates or processes for requirements
management within the organization may exist. The business analyst must be
knowledgeable about the organization’s approach to requirements definition, as
it will greatly influence the process steps, tasks and deliverables required or
expected during the requirements planning and monitoring activities.
TECHNIQUES
 Decision Analysis: assess the possible value delivered by a change and
assess areas of uncertainty.
 Problem Tracking: to track possible changes and ensure that a decision is
reached.
 Risk Analysis: to identify possible risks associated with the change
management process and possible risks associated with making or
choosing not to make the change.
STAKEHOLDERS
 Domain SME: Consulted in order to determine the importance of
requirements and to assess the value of change requests.
 End User: Consulted in order to determine the importance of
requirements and to assess the value of change requests.
 Implementation SME: Consulted in order to determine the difficulty of
implementing a requirement or proposed change.
 Operational Support: Informed of changes to requirements to ensure that
the solution can operate effectively.
 Project Manager: Responsible for managing changes to the project scope
and accountable for delivery of the project scope. Changes to the solution
and requirements scope are almost certain to impact the project scope.
 Tester: Informed of changes to requirements to ensure that test plans are
effective.
 Sponsor: Accountable for the solution scope and must approve
prioritization of requirements and changes to requirements.
32 | P a g e
OUTPUT
Requirements Management Plan. A requirements management plan describes the:
 Approach to be taken to structure traceability.
 Definition of requirements attributes to be used.
 Requirements prioritization process.
 Requirements change process, including how changes will be requested,
analyzed, approved, and implemented.
MANAGE BUSINESS ANALYSIS PERFORMANCE
Purpose
To manage the performance of business analysis activities to ensure that they are
executed as effectively as possible.
DESCRIPTION
This task covers determining which metrics will be used to measure the work
performed by the business analyst. It includes how to track, assess, and report on
the quality of the work and take steps to correct any problems that may arise.
This may feed into the development of future business analysis plans. The
selected metrics are defined and described in the organizational process assets or
the business analysis plans. This task also describes how organizational process
assets governing business analysis activities are managed and updated.
INPUT
Business Analysis Performance Metrics: Actual performance measures are
captured, analyzed, and become the basis for taking corrective or preventive
action. Capturing actual performance metrics is a process that occurs through the
business analysis effort.
Business Analysis Plan(s): These plans describe deliverables, activities, tasks, and
estimates for all business analysis work. Conformance to these plans may be the
primary metric used to judge performance.
Organizational Performance Standards: May include mandated performance

metrics or expectations for business analysis work.
Requirements Management Plan: The requirements management plan may also
set expectations for the frequency of changes to requirements and the work
involved in managing that change.
33 | P a g e
TECHNIQUES
Interviews: Stakeholders may be interviewed to gather assessments of business

analysis performance.
Lessons Learned Process: Helps identify changes to business analysis processes

and deliverables that can be incorporated into future work.
Metrics and Key Performance Indicators: Can be used to determine what metrics
are appropriate for assessing business analysis performance and how they may be
tracked.
Problem Tracking: May be used to track issues that occur during the performance
of business analysis for later resolution.
Process Modeling: Can be used to define business analysis processes and

understand how to improve those processes to reduce problems from handoffs,
improve cycle times, or alter how business analysis work is performed to support
improvements in downstream processes.
Root Cause Analysis: Can help identify the underlying cause of failures or
difficulties in accomplishing business analysis work.
Survey/Questionnaire: Can be used to gather feedback from a large number of

stakeholders.
Variance Analysis: The purpose of this technique is to analyze discrepancies

between planned and actual performance, determine the magnitude of those
discrepancies, and recommend corrective and preventive action as required.
Variances can be related to planned versus actual estimates, cost, scope, product
expectations, or any measures that have been established during the planning
process.
34 | P a g e
STAKEHOLDERS
 Domain SME and End User: Should be informed of the performance of

business analysis activities in order to set expectations from them.
 Implementation SME, Operational Support, and Tester: Dependent on the

effective performance of business analysis activities to perform their role.
Should be consulted when assessing those activities.
 Project Manager: The PM is accountable for the success of a project and

must be kept informed of the current status of business analysis work.
 Sponsor: require reports on business analysis performance to address

problems as they are identified.
OUTPUT
Business Analysis Performance Assessment: This includes a comparison of

planned versus actual performance, understanding the root cause of variances
from the plan, and other information to help understand the level of effort
required to complete business analysis work.
Business Analysis Process Assets: This process analysis often results in

recommendations for improvement to the business analysis process. The revised
process and templates for business analysis deliverables should be analyzed and
documented and lessons learned should be recorded. These may be incorporated
into Organizational Process Assets.
35 | P a g e
4 Elicitation
Eliciting requirements is a key task in business analysis. Its essential that the
requirements be complete, clear, correct, and consistent. Leveraging proven
means to elicit requirements will help meet these quality goals. The definition of
elicitation is:
 to draw forth or bring out (something latent or potential)
 to call forth or draw out (as information or a response)
These definitions highlight the need to actively engage the stakeholders in
defining requirements.
Eliciting requirements is not an isolated or compartmentalized activity. Typically,

requirements are identified throughout the elicitation, analysis, verification and
validation activities. For example, requirements may be elicited in interviews or
requirements workshops. Later, when those requirements are used to build and
verify model(s), gaps in the requirements may be discovered. This will then
require eliciting details of those newly identified requirements.
Let’s discuss about processes under Elicitation knowledge areas

PREPARE FOR ELICITATION
Purpose
Ensure all needed resources are organized and scheduled for conducting the
elicitation activities.
DESCRIPTION
Build a detailed schedule for a particular elicitation activity, defining the specific
activities and the planned dates.
INPUT
Business Need: Required to ensure that the business analyst understands what
information should be elicited from the stakeholders.
Solution Scope and Business Case: Required to ensure that the business analyst
understands what information should be elicited from the stakeholders. These
inputs are used when eliciting stakeholder, solution, and transition requirements.
Stakeholder List, Roles, and Responsibilities: Used to identify the stakeholders

who should participate in elicitation activities.
36 | P a g e
TECHNIQUES
 Brainstorming  Observation
 Document Analysis  Prototyping
 Focus Groups  Requirements Workshops
 Interface Analysis  Survey/Questionnaire
 Interviews
STAKEHOLDERS
All Stakeholders: Depending on the requirements of the elicitation activity, any

stakeholder may be a participant.
Project Manager: The project manager will assist in ensuring that the needed
resources are available.
OUTPUT
Scheduled Resources: This includes the participants, the location in which the
elicitation activity will occur, and any other resources that may be required.
Supporting Materials: Any materials required to help explain the techniques used
or perform them.
CONDUCT ELICITATION ACTIVITY
Purpose
Meet with stakeholder(s) to elicit information regarding their needs.
DESCRIPTION
The elicitation event takes place (brainstorming, focus groups, interviews,
observation, prototyping, requirements workshops), or elicitation is performed
(document analysis, interface analysis) or distributed (survey/questionnaire).
INPUT
Business Need: Required to ensure that the business analyst understands what
information should be elicited from the stakeholders. This input is used when
eliciting business requirements (with the exception of the business need itself).
37 | P a g e
Organizational Process Assets: include templates or processes for these activities.
Requirements Management Plan: Determines what information needs to be

recorded and tracked as an outcome of the activity.
Scheduled Resources: The relevant stakeholders, location, and other resources

must be available.
Solution Scope and Business Case are required to ensure that the business
analyst understands what information should be elicited from the stakeholders.
These inputs are used when eliciting stakeholder, solution, and transition
requirements.
Supporting Materials: Whiteboards, flipcharts, documents, and other materials

must be available while the activity is conducted.
TECHNIQUES
Data Dictionary and Glossary: A business glossary is an essential asset for all
elicitation techniques. The glossary should contain key domain terms along with
their business definitions.
General Techniques:
 Document Analysis  Prototyping
 Focus Groups  Requirements Workshops
 Interface Analysis  Survey/Questionnaire
 Interviews
STAKEHOLDERS
Customer, Domain SME, End User, Supplier and Sponsor: May participate in this
task as a source of requirements.
Implementation SME, Operational Support, Project Manager, Supplier and

Tester: May participate to improve their understanding of the stakeholder needs
and to aid stakeholders in understanding the tradeoffs faced by the project team.
Regulator: May participate directly (as a source of requirements) and may also
dictate that a specific process be followed or that certain records be kept.
38 | P a g e
OUTPUT
Elicitation Results: May include documentation appropriate to the technique and

capture the information provided by the stakeholder.
DOCUMENT ELICITATION RESULTS
Purpose
Record the information provided by stakeholders for use in analysis.
DESCRIPTION
For an elicitation event (brainstorming, focus groups, interviews, observation,
prototyping, requirements workshops) a summary of the output from the event,
including issues is produced.
INPUT
Elicitation Results: Includes the information provided by stakeholders that will be
recorded and structured.
TECHNIQUES
 Document Analysis  Problem Tracking
 Focus Groups  Prototyping
 Interface Analysis  Requirements Workshops
 Interviews  Survey/Questionnaire
STAKEHOLDERS
Business Analyst: Other stakeholders do not need to participate in this task.
OUTPUT
Requirements [Stated]: Described from the perspective of the stakeholder. Stated

requirements describe the stakeholder’s need from the stakeholder’s perspective.
Stakeholder Concerns: Includes issues identified by the stakeholder, risks,

assumptions, constraints, and other relevant information.
39 | P a g e
CONFIRM ELICITATION RESULTS
Purpose
Validate that the stated requirements expressed by the stakeholder match the
stakeholder’s understanding of the problem and the stakeholder’s needs.
DESCRIPTION
Some elicitation techniques benefit from reviewing the documented outputs with
the stakeholders to ensure that the analyst’s understanding conforms to the
actual desires or intentions of the stakeholder.
INPUT
Requirements [Stated, Unconfirmed]: Represent the business analyst’s

understanding of the stakeholder’s intentions.
Stakeholder Concerns [Unconfirmed]: Represent the business analyst’s

understanding of issues identified by the stakeholder, risks, assumptions,
constraints, and other relevant information that may be used in business analysis.
TECHNIQUES
Interviews & Observation
STAKEHOLDERS
Any stakeholder who has participated in other elicitation tasks may participate in
this task.
OUTPUT
Requirements [Stated, Confirmed]: Identical to Requirements [Stated] for all
practical purposes, including use as an input to other tasks.
Stakeholder Concerns [Confirmed]: Identical to Stakeholder Concerns for all

practical purposes, including use as an input to other tasks.
40 | P a g e
5 Requirements Management & Communication
The Requirements Management and Communication Knowledge Area describes

the activities and considerations to ensure that all stakeholders have a shared
understanding of the nature of a solution and to ensure that those stakeholders
with approval authority are in agreement as to the requirements that the solution
shall meet.
Communicating requirements helps to bring the stakeholders to a common

understanding of the requirements. Because the stakeholders represent people
from different backgrounds and business domains, this communication is both
challenging and critical to the success of any initiative. It involves determining
which sets of requirements are relevant to a particular stakeholder group and
presenting those requirements in an appropriate format for that audience.
Let's look at requirements management and communication activities.

MANAGE SOLUTION SCOPE & REQUIREMENTS
Purpose
Obtain and maintain consensus among key stakeholders regarding the overall
solution scope and the requirements that will be implemented.
DESCRIPTION
This task involves securing approval of requirements from those stakeholders who
have the appropriate authority, and managing issues that emerge during
elicitation and analysis. Approval of requirements may be sought at the end of a
project phase or at a number of intermediate points in the business analysis
process.
Requirements may be baselined following approval. Any changes to requirements

after baselining, if changes are permitted, involves use of a change control
process and subsequent approval. As requirements are refined or changed as the
result of new information, changes will be tracked as well. The solution scope is
required as a basis for requirements management and is used to determine
whether a proposed requirement supports the business goals and objectives.
INPUT
Requirements Management Plan: Defines the process to be followed in
managing the solution scope and requirements.
41 | P a g e
Solution Scope: Requirements must support the solution scope in order to be

approved, unless the solution scope is modified accordingly. The solution scope is
also a requirement that can be managed in its own right.
Stakeholder List, Roles, and Responsibilities: This defines which stakeholders are
involved in reviewing and approving requirements.
Stakeholder, Solution, or Transition Requirements [Communicated or Traced]:

Requirements may be managed at any point in their lifecycle (stated, specified
and modeled, verified, validated, etc.), although stakeholder approval is normally
restricted to requirements that have been verified and validated. Requirements
must be communicated to be managed, as stakeholders cannot consent to
requirements if they are not aware of them.
TECHNIQUES
Problem Tracking: Allows the business analyst to manage any issues identified
with requirements by stakeholders and ensure that those issues are resolved.
Baselining: Once requirements are approved, they may be baselined, meaning

that all future changes are recorded and tracked, and the current state may be
compared to the baselined state. Subsequent changes to the requirement must
follow the change control process.
Signoff: Requirements signoff formalizes agreement by stakeholders that the

content and presentation of documented requirements is accurate and complete.
A formal sign-off of requirements documentation may be required by
organizational standards or for regulatory reasons.
STAKEHOLDERS
Domain SME: May be involved in the review and approval of requirements, as
defined by the stakeholder roles and responsibility designation.
Implementation SME: Will likely be involved in this process to ensure that the
requirements can be implemented.
Project Manager: The project manager is responsible and accountable for the
project scope. The project manager must be involved in assessing the solution
scope in order to define the project scope, and must be involved in reviewing any
changes to the solution scope for the same reason. In addition, if a proposed
42 | P a g e
requirement is not accepted by key stakeholders, the project manager must

manage the associated risk to the project (by altering the project scope,
escalating the issue, or through other appropriate responses).
Sponsor: The business case, solution or product scope and all requirements must
be reviewed and approved by the sponsor(s) according to the approval authority
stated in the requirements management plan.
OUTPUT
Requirements [Approved]: Requirements which are agreed to by stakeholders
and ready for use in subsequent business analysis or implementation efforts.
MANAGE REQUIREMENTS TRACEABILITY
Purpose
Create and maintain relationships between business objectives, requirements,
other team deliverables, and solution components to support business analysis or
other activities.
DESCRIPTION
“Tracing” a requirement refers to the ability to look at a requirement and the
others to which it is related. Tracing links business requirements to stakeholder
and solution requirements, to other artifacts produced by the team, and to
solution components.
Requirements traceability identifies and documents the lineage of each
requirement, including its backward traceability (derivation), its forward
traceability (allocation), and its relationship to other requirements. Traceability is
used to help ensure solution conformance to requirements and to assist in scope
and change management, risk management, time management, cost
management, and communication management. It also is used to detect missing
functionality or to identify if implemented functionality is not supported by a
specific requirement.
INPUT
Requirements: All requirements may potentially be traced to other requirements,
and all stakeholder and solution requirements must be traceable to a business
requirement.
43 | P a g e
Requirements Management Plan: Defines how and whether traceability is being

performed, the tools that will be used to support traceability and the processes
that will be used to manage it.
TECHNIQUES
Coverage matrix: A coverage matrix is a table or spreadsheet used to manage
tracing. It is typically used when there are relatively few requirements or when
tracing is limited to high-level requirements (e.g. features or models).
STAKEHOLDERS
Implementation SME: They must be able to link the requirements to the solution
components that will implement them.
Project Manager: Traceability supports project change management.
Tester: Testers need to understand how and where requirements are

implemented when creating test plans and test cases, and may trace test cases to
requirements.
OUTPUT
Requirements [Traced]: Traced requirements have clearly defined relationships to
other requirements within the solution scope such that it is relatively easy to
identify the effects on other requirements of a change.
MAINTAIN REQUIREMENTS FOR RE-USE
Purpose
To manage knowledge of requirements following their implementation.
DESCRIPTION
To re-use requirements they must be clearly named and defined and easily
available to other analysts. These requirements may be stored in a repository, and
a person should be identified to manage the repository. When an existing
requirement must be modified it can be accessed from the repository for re-use.
Maintenance of requirements can facilitate impact analysis of new, proposed
changes to the business, reduce analysis time and effort, assist in maintenance of
previously implemented solutions, and support other activities, including training,
corporate governance, and standards compliance.
44 | P a g e
INPUT
Organizational Process Assets: These set standards regarding how and when
requirements should be maintained for re-use.
Requirements: Requirements may be maintained for re-use as long as they

describe information of use to the organization beyond the lifetime of an initiative.
Requirements will usually be candidates for maintenance only if the describe the
actual current state of an organization.
TECHNIQUES
None in perticular
STAKEHOLDERS
Business Analyst: Re-used requirements are very likely to be used by a different
business analyst than the author at some unknown future date. It may be
necessary to revise and update the requirements documentation to ensure that it
is self-explanatory.
Domain SME: Ongoing requirements are likely to be referenced by Domain SMEs

on a regular basis to ensure that work products meet them.
Implementation SME: These requirements are likely to be used for a variety of

purposes, including development of regression tests and impact analysis of
enhancements.
OUTPUT
Requirements [Maintained and Reusable]: The output of this task are
requirements that are expressed in a form that makes them suitable for long-term
usage by the organization (even in the absence of the stakeholders who originally
defined the requirements).
PREPARE REQUIREMENTS PACKAGE
Purpose
To select and structure a set of requirements in an appropriate fashion to ensure
that the requirements are effectively communicated to, understood by, and
usable by a stakeholder group or groups.
45 | P a g e
DESCRIPTION
Requirements should be presented in formats that are understandable by the
stakeholder. This task describes the work required to decide which format(s) are
appropriate for a particular project and its stakeholders. They must be clear,
concise, accurate, and at the appropriate level of detail. Requirements
documentation should be created only to the extent needed to assure clear
understanding by the team.
INPUT
Business Analysis Communication Plan: This will typically describe the
stakeholder groups, their communication needs, and define whether a single
requirements package or multiple requirements packages are required. The
business analysis communication plan will also define the level of formality that is
appropriate for the requirements.
Organizational Process Assets: May include templates that can be used to

package requirements.
Requirements: The business analyst must understand which requirements will be

included in the package. Requirements may be packaged at any point in their
lifecycle.
Requirements Structure: A package should contain a consistent, cohesive, and

coherent set of requirements.
TECHNIQUES
Requirements Documentation: Requirements are frequently captured in a formal
document. Some of the most common types of requirements documents include:
 Business Requirements Document
 Product Roadmap
 Software/System Requirements Specification
 Supplementary Requirements Specification
 Vision Document
Requirements for Vendor Selection: If the solution team thinks that a potential
solution is available from an outside party, the business analyst may capture the
requirements in the form of a Request for Information (RFI), Request for Quote
(RFQ), or Request for Proposal (RFP).
46 | P a g e
STAKEHOLDERS
Domain SMEs and End Users: Need requirements that are written using familiar
terminology and that are easy to understand and review. They must fully
understand each requirement, since it is this group that will be most affected by
the solution implemented.
Implementation SMEs: Need to obtain an understanding of the overall

requirements for the project, and will focus on requirements they will use to
design the solution. External customers and suppliers will need detailed technical
interface requirements to order to construct the proper network and security
protocols in accordance with corporate policies.
Project Managers: Include deliverables (including specific requirements packages)

in the project plan and typically track them as milestones to assess project
progress. The deliverable acts as a “contract” for the project defining the agreed
upon work. The deliverable becomes a project asset because it represents a
project output.
Regulators: May have specific legal, contractual, or governance requirements

regarding what is included in a requirements document.
Sponsors (and other managers at the executive level): Often want summaries
and high-level requirements. Their primary goal is to understand that the solution
will meet the return on investment expectations in accordance with their business
plan, and to minimize the time required for them to make an effective decision.
The project scope may suffice, including the ROI (Return on Investment)
assessment, business benefits, project cost and target implementation date(s).
Testers: Focus on understanding the critical success factors of the project based
on the needs of the business users. They must acquire a thorough understanding
of the functional and non-functional requirements in order to build an effective
testing strategy.
OUTPUT
Requirements Package: The result of this task is a requirements document,

presentation, or package of requirements ready to be reviewed by stakeholders.
A package may contain all of the project requirements or may be broken into
several sub-packages.
47 | P a g e
COMMUNICATE REQUIREMENTS
Purpose
Communicating requirements is essential for bringing stakeholders to a common
understanding of requirements.
DESCRIPTION
Communicating requirements includes conversations, notes, documents,
presentations, and discussions. Concise, appropriate, effective communication
requires that the business analyst possess a significant set of skills, both soft
(communication) and technical (i.e. requirements).
INPUT
Business Analysis Communication Plan: Defines what information is to be
communicated, which stakeholders need to receive it, when communication
should occur, and the form it should occur in.
Requirements: Any requirement may be communicated.
Requirements Package: Requirements may be communicated without being in a

requirements package, but if a package has been assembled, it must be
distributed, reviewed, and the contents must be communicated to stakeholders.
TECHNIQUES
Requirements Workshops: Requirements may be presented as part of a
requirements workshop to familiarize all parties with the existing solution scope
and the current requirements.
Structured Walkthrough: A structured walkthrough often begins with a review of

the requirements to be discussed.
STAKEHOLDERS
All
OUTPUT
Communicated Requirements: Stakeholders should understand what the
requirements are and their current state.
48 | P a g e
6 Enterprise Analysis
The Enterprise Analysis Knowledge Area describes the business analysis activities
necessary to identify a business need, problem, or opportunity, define the nature
of a solution that meets that need, and justify the investment necessary to deliver
that solution. Enterprise analysis outputs provide context to requirements
analysis and to solution identification for a given initiative or for long-term
planning. Enterprise analysis is often the starting point for initiating a new project
and is continued as changes occur and more information becomes available. It is
through enterprise analysis activities that business requirements are identified
and documented.
It describes the business analysis activities that take place for organizations to:
 Analyze the business situation in order to fully understand business
problems and opportunities.
 Assess the capabilities of the enterprise in order to understand the change
needed to meet business needs and achieve strategic goals.
 Determine the most feasible business solution approach.
 Define the solution scope and develop the business case for a proposed
solution.
 Define and document business requirements (including the business need,
required capabilities, solution scope, and business case).
Lets now discuss Enterprise Analysis activities

DEFINE BUSINESS NEED
Purpose
Identify and define why a change to organizational systems or capabilities is
required.
DESCRIPTION
The definition of the business need is frequently the most critical step in any
business analysis effort. The business need defines the problem that the business
analyst is trying to find a solution for. The way the business need is defined
determines which alternative solutions will be considered, which stakeholders will
be consulted, and which solution approaches will be evaluated.
New business needs can be generated in several different ways:

 From the top down: the need to achieve a strategic goal
 From the bottom up: a problem with the current process/function/system
49 | P a g e
 From middle management: a manager needs additional information to

make sound decisions to meet business objectives
 From external drivers: driven by customer demand or business
competition in the marketplace
INPUT
Business Goals and Objectives: Business goals and objectives usually have to be
refined in order to define the business need. In some cases the goal or objective
may be exploratory—the business need may be to understand if a methodology
or business model can work.
Requirements [Stated]: Elicitation must be performed in order to assist

stakeholders in defining their perceived needs. Ensure that they reflect actual
business requirements, as opposed to describing solutions.
TECHNIQUES
 Benchmarking: Understanding what competing organizations and peers
are doing allows the organization to remain at a comparable level of
service or identify opportunities to increase efficiency.
 Brainstorming: Generate insights and options.
 Business Rules Analysis: Identify changes in the policies that guide the
organization towards achieving its goals and objectives.
 Focus Groups: To identify and discuss problems.
 Functional Decomposition: Convert business goals into achievable
objectives and measures.
 Root Cause Analysis: Determine the underlying source of a problem.
STAKEHOLDERS
 Customer or Supplier: New opportunities often arise as an unmet
customer need is identified.
 Domain SME and End User: Likely to have the most direct awareness of
problems or limitations that exist in current systems.
 Implementation SME: May be aware of capabilities currently present in or
easily added to existing systems that may provide new opportunities.
 Regulator: May impose new regulatory or governance requirements on
the organization.
 Sponsor: A sponsor must be identified within the organization who is
responsible for making sure that the business need is met and who can
authorize action to meet it.
50 | P a g e
OUTPUT
Business Need: A business need describes a problem that the organization is (or is
likely to) face or an opportunity that it has not taken, and the desired outcome.
The business need will guide the identification and definition of possible solutions.
ASSESS CAPABILITY GAPS
Purpose
To identify new capabilities required by the enterprise to meet the business need.
DESCRIPTION
Assess the current capabilities of the enterprise and identify the gaps that prevent
it from meeting business needs and achieving desired outcomes. Determine if it is
possible for the organization to meet the business need using its existing
structure, people, processes, and technology. However, if existing capabilities are
inadequate, it will probably be necessary to launch a project to create that
capability.
INPUT
 Business Need: Capabilities are assessed against the business need to
identify gaps.
 Enterprise Architecture: The enterprise architecture defines the current
capabilities of an organization.
 Solution Performance Assessment: Identifies shortcomings, problems or
limitations of an existing solution.
TECHNIQUES
 Document Analysis: Useful to understand the current state of the
enterprise, in as much as that current state is documented.
 SWOT Analysis: Identify how current capabilities and limitations (S and W)
match up against the influencing factors (O and T).
STAKEHOLDERS
 Customer and Supplier: Customers and suppliers may be impacted if the
business developed or changes the capabilities it has. They may also be in
a position to provide or support new capabilities themselves.
 Domain SME, End User, Implementation SME, and Sponsor: Will provide
information on the strengths and weaknesses of current capabilities.
51 | P a g e
OUTPUT
Required Capabilities: An understanding of the current capabilities of the
organization and the new capabilities (processes, staff, features in an application,
etc.) that may be required to meet the business need.
DETERMINE SOLUTION APPROACH
Purpose
To determine the most viable solution approach to meet the business need in
detail to allow for definition of solution scope and prepare the business case.
DESCRIPTION
The solution approach describes the general approach that will be taken to create
or acquire the new capabilities required to meet the business need. To determine
the solution approach, it is necessary to identify possible approaches, determine
the means by which the solution may be delivered and assess whether the
organization is capable of implementing.
Some possible approaches include:
 Utilize additional capabilities of existing software/hardware that already is
available within the organization
 Purchase or lease software/hardware from a supplier
 Design and develop custom software
 Add resources to the business or make organizational changes
 Change the business procedures/processes
 Partner with other organizations, or outsource work to suppliers
INPUT
 Business Need: Possible solutions will be evaluated against the business
need to ensure that it can be met by the selected approach.
 Organizational Process Assets: The organization may require that specific
approaches be taken to solutions of a given type (such as specific
methodologies).
 Required Capabilities: Identifies the new capabilities that any solution
must support.
TECHNIQUES
Benchmarking Brainstorming Decision Analysis
Estimation SWOT Analysis
52 | P a g e
STAKEHOLDERS
 Customer, Domain SME, End User and Supplier: May be able to provide
suggested approaches and identify assumptions and constraints.
 Implementation SME: Will be needed to assess the feasibility of possible
approaches.
 Sponsor: May be the source of constraints on the solution options and will
likely be required to approve the recommended approach.
OUTPUT
Solution Approach: Solution approaches describe the types of solution
components that will be delivered (new processes, a new software application,
etc.) and may also describe the methodology that will be used to deliver those
components.
DEFINE SOLUTION SCOPE
Purpose
To define which new capabilities a project or iteration will deliver.
DESCRIPTION
The purpose of this task is to conceptualize the recommended solution in enough
detail to enable stakeholders to understand which new business capabilities an
initiative will deliver. The solution scope will change throughout a project, based
on changes in the business environment or as the project scope is changed to
meet budget, time, quality, or other constraints. The solution scope includes:
 The scope of analysis (the organizational unit or process for which
requirements are being developed) which provides the context in which
the solution is implemented.
 The capabilities supported by solution components, such as business
processes, organizational units, and software applications.
 The capabilities to be supported by individual releases or iterations.
 The enabling capabilities that are required in order for the organization to
develop the capabilities required to meet the business need.
INPUT
 Assumptions and Constraints: Relevant assumptions and constraints may
include assumptions about how stakeholders will respond to a new
product or service or about the availability of technology. Constraints may
53 | P a g e
include limitations on what may be included in the solution scope. Include

any schedule or funding limitations and significant standards, policies,
regulations to be followed and supporting data required.
 Business Need: The goals, objectives, and desired outcomes of the
organization.
 Required Capabilities: Describes the new capabilities required to meet the
business need, which serve as the basis for the solution scope.
 Solution Approach: The general approach taken to delivery of the new
capabilities required by the business will be used when assessing options
for the implementation of solution components.
TECHNIQUES
 Functional Decomposition: To understand the scope of work and to break
the solution scope into smaller work products or deliverables.
 Interface Analysis: Depict the scope of work required to integrate the new
solution into the business and technical environments.
 Scope Modeling: Identify appropriate boundaries for the solution scope
 User Stories: Describe stakeholders and the goals the system supports and
as such can also be used to define the solution scope.
STAKEHOLDERS
 Domain SME: Will participate in identifying the affected organizational
units, modeling the scope of possible solutions, and determining the
relative priorities of the required capabilities.
 Implementation SME: Will participate in the allocation of capabilities to
solution components and in determining the time and effort required to
deliver new capabilities.
 Project Manager: May assist with the development of the overall solution
scope, which will be used as an input into the Project Charter.
 Sponsor: Will participate in setting priorities and approving the solution
scope.
OUTPUT
Solution Scope: Defines what must be delivered in order to meet the business
need, and the effect of the proposed change initiative on the business and
technology operations and infrastructure.
54 | P a g e
DEFINE BUSINESS CASE
Purpose
To determine if an organization can justify the investment required to deliver a
proposed solution.
DESCRIPTION
The business case describes the justification for the project in terms of the value
to be added to the business as a result of the deployed solution, as compared to
the cost to develop and operate the solution. The business case may also include
qualitative and quantitative benefits, estimates of cost and time to break even,
profit expectations, and follow on opportunities. This provides a framework to
demonstrate how the initiative is expected to achieve business objectives. In
addition, the business case lists the constraints associated with the proposed
project, along with the estimated budget, and alignment with strategies
established by the organization.
INPUT
 Assumptions and Constraints: Include assumptions about the revenue
generated or retained by the solution or non-financial improvements it
will deliver.
 Business Need: Defines the value that a solution will deliver to the
organization and how it aligns with the business goals and objectives.
 Solution Scope: Defines the capabilities that will be implemented, the
methods that will be used to deliver them, and the areas of the
organization that will be affected.
 Stakeholder Concerns: May include risks or issues that must be accounted
for in the business case.
TECHNIQUES
 Decision Analysis: Cost-benefit analysis compares the costs of
implementing a solution against the benefits to be gained. Financial
analysis includes the use of financial models that estimate the market
value of an organizational asset.
 Estimation: Forecast the size of the investment required to deploy and
operate the proposed solution.
 Metrics and Key Performance Indicators: Assessed to support benefit
management, measurement and reporting, including where realignment
55 | P a g e
of internal measures or systems is needed to ensure that the behaviors we

are seeking can be seen, evaluated, and realized.
 Risk Analysis: Used to assess potential risks that may impact the solution
and the costs and benefits associated with it.
 SWOT Analysis: Demonstrate how the solution will help the organization
maximize strengths and minimize weaknesses.
 Vendor Assessment: If purchase or outsourcing to a third party is in
consideration, an assessment of the vendor may be performed as part of
the business case.
STAKEHOLDERS
 Sponsor: Approves the business case and authorizes funding.
 Domain SME: Assists in estimating business benefits expected from the
new initiative.
 Implementation SME: Assists in estimating cost projections for the
technology needed to support the new solution.
 Project Manager: Participates in developing time and cost estimates, and
may develop a preliminary project plan or Work Breakdown Structure in
collaboration with the project team. The project manager will use the
business case as an input for a project charter.
OUTPUT
Business Case: Presents the information necessary to support a go/no go decision
to invest and move forward with a proposed project.
56 | P a g e
7 Requirements Analysis
The Requirements Analysis Knowledge Area describes the tasks and techniques
used by a business analyst to analyze stated requirements in order to define the
required capabilities of a potential solution that will fulfill stakeholder needs. It
covers the definition of stakeholder requirements, which describe what a solution
must be capable of doing to meet the needs of one or more stakeholder groups,
and solution requirements, which describe the behavior of solution components
in enough detail to allow them to be constructed. The tasks in this knowledge
area apply to both stakeholder and solution requirements.
Requirement Analysis activities are listed below:

PRIORITIZE REQUIREMENTS
Purpose
Prioritization of requirements ensures that analysis and implementation efforts
focus on the most critical requirements.
DESCRIPTION
Requirement prioritization is a decision process used to determine the relative
importance of requirements. The importance of requirements may be based on
their relative value, risk, difficulty of implementation, or on other criteria.
These priorities are used to determine which requirements should be targets for
further analysis and to determine which requirements should be implemented
first.
INPUT
 Business Case: The business case states the key goals and measures of
success for a project or organization, and priorities should be aligned with
those goals and objectives.
 Business Need: Serves as an alternative to the business case if no business
case has been defined.
 Requirements: Any requirement may be prioritized, at any point in its
lifecycle. Requirements prioritization requires that requirements have
been stated by stakeholders; however, the requirements may not have
been fully analyzed or in their final form.
 Requirements Management Plan: Defines the process that will be used to
prioritize requirements.
57 | P a g e
 Stakeholder List, Roles, and Responsibilities: The list of stakeholders,

annotated with their levels of authority and influence, is used to
determine which stakeholders need to participate in prioritization.
TECHNIQUES
 Decision Analysis: Decision analysis may be used to identify high-value
requirements.
 Risk Analysis: Requirements that are considered risky may need to be
investigated or implemented first, so that if risks cause the project to fail,
the organization has invested as little as possible at that point.
 MoSCoW Analysis: MoSCoW analysis divides requirements into four
categories: Must, Should, Could, and Won’t.
 Timeboxing/Budgeting: Timeboxing or budgeting prioritizes requirements
for investigation and implementation based on allocation of a fixed
resource.
 Voting: Voting methods allocate a fixed amount of resources (votes, play
money, or other tokens) to each participant for them to distribute among
proposed features or requirements.
STAKEHOLDERS
 Domain SME: Domain subject matter experts may be invited to participate
in the prioritization of requirements, to assess the relative business need,
and to negotiate their importance.
 Implementation SME: Implementation subject matter experts may be
asked to evaluate the relative complexity or risk associated with the
implementation of certain requirements.
 Project Manager: The project manager is responsible for the
implementation of the solution and will use the priority of requirements as
an input into the project plan.
 Sponsor: Since sponsors are ultimately accountable for the business
solution and major project decisions, they need to be invited to participate
in the discussion.
OUTPUT
Requirements [Prioritized]: A prioritized requirement has an attribute that
describes its relative importance to stakeholders and the organization. At the
completion of this task, each requirement should have an assigned priority. The
priorities may apply to a requirement or to a group or related requirements.
58 | P a g e
ORGANIZE REQUIREMENTS
Purpose
The purpose of organizing requirements is to create a set of views of the
requirements for the new business solution that are comprehensive, complete,
consistent, and understood from all stakeholder perspectives.
DESCRIPTION
There are two key objectives when organizing requirements.
 Understand which models are appropriate for the business domain and
solution scope.
 Identify model interrelationships and dependencies. Requirements alone
are not complex; it is the relationships and interdependencies among
requirements that adds the element of complexity.
INPUT
 Organizational Process Assets: Describe the structures and types of
requirements information that stakeholders expect.
 Requirements [Stated]: Requirements are stated in various forms as an
output from elicitation activities. Stated requirements are the expressed
desires of stakeholders, which must be analyzed to ensure that they
reflect a genuine need.
 Solution Scope: The selected requirements models must be sufficient to
fully describe the solution scope from all needed perspectives.
TECHNIQUES
Business Rules Analysis Data Flow Diagrams Data Modeling

Functional Decomposition Organization Modeling Process Modeling
Scenarios and Use Cases Scope Modeling User Stories
STAKEHOLDERS
 Domain SME, End User, Implementation SME, and Sponsor: Affected by
analysis techniques used to organize requirements since they need to
verify and validate the requirements.
 Project Manager: Uses the organized set of requirements to verify the
scope of the solution and assess the work that needs to be done in the
project.
59 | P a g e
OUTPUT
Requirements Structure: The output of this task is an organized structure for the
requirements and a documented set of relationships between them. Each model
or set of requirements within the structure should have a clear implicit scope.
SPECIFY AND MODEL REQUIREMENTS
Purpose
To analyze expressed stakeholder desires and/or the current state of the
organization using a combination of textual statements, matrices, diagrams and
formal models.
DESCRIPTION
Specifications and models are created to analyze the functioning of an
organization and provide insight into opportunities for improvement. They also
support a number of other objectives, including development and
implementation of solutions, facilitating communication among stakeholders,
supporting training activities and knowledge management, and ensuring
compliance with contracts and regulations.
The specifics of this task are highly dependent on the techniques used for
specifying and modeling requirements.
INPUT
 Requirements [Stated]: Specification or modeling of requirements is
performed to structure and improve our understanding of needs as
expressed by stakeholders.
 Requirements Structure: Defines how the requirement fits into the general
requirements and which other sets of requirements may include related
information.
TECHNIQUES
Acceptance and Evaluation Data Dictionary and Metrics and Key
Criteria Definition Glossary Performance Indicators
Business Rules Analysis Non-functional Scenarios and Use Cases
Data Flow Diagrams Requirements Analysis Functional Decomposition
Data Modeling Interface Analysis Organization Modeling
Process Modeling Prototyping Sequence Diagrams
State Diagrams User Stories
60 | P a g e
STAKEHOLDERS
Any Stakeholder: The business analyst may choose to perform this task alone and
then separately package and communicate the requirements to stakeholders for
their review and/or approval, or invite some or all stakeholders to participate in
this task (depending on which requirements are being analyzed, the business
analysis approach, the preferences of the business analyst, and other factors).
OUTPUT
Requirements [Analyzed]: Modeled and specified requirements are produced by
this task.
DEFINE ASSUMPTIONS AND CONSTRAINTS
Purpose
Identify factors other than requirements that may affect which solutions are
viable.
DESCRIPTION
Assumptions are factors that are believed to be true, but have not been
confirmed. The business analyst identifies and documents assumptions, attempts
to confirm the accuracy of the assumptions, and identifies and manages risks
related to the ability of a solution to meet the business need.
Constraints are defined as restrictions or limitations on possible solutions.

Solution constraints describe aspects of the current state, or planned future state
that may not be changed. They are not requirements, since they are not
implemented in any form by the project team.
INPUT
Stakeholder Concerns: Assumptions and constraints are identified through
elicitation from stakeholders.
TECHNIQUES
 Problem Tracking: Both assumptions and constraints are often identified,
reviewed and managed using the ongoing planning, monitoring, and
issue/risk management activities of the project team.
 Risk Analysis: Assess the risk (both positive and negative) if an assumption
proves invalid, or a constraint is removed.
61 | P a g e
STAKEHOLDERS
 Implementation SME: Must take the assumptions and constraints into
account when designing a solution.
 Project Manager: Must assess assumptions and constraints to identify
potential risks that may impact project delivery, and manage against
schedule, cost and resource constraints.
 All Stakeholders: Since assumptions and constraints can originate from
and/or affect any stakeholder all stakeholders may be involved.
OUTPUT
Assumptions and Constraints: Assumptions and constraints will limit potential
solution options and will be monitored for potential changes. While they are not
technically requirements, they can be managed and communicated.
VERIFY REQUIREMENTS
Purpose
Requirements verification ensures that requirements specifications and models
meet the necessary standard of quality to allow them to be used effectively to
guide further work.
DESCRIPTION
Verifying requirements ensures that the requirements have been defined
correctly; that is, that they are of acceptable quality. Requirements that do not
meet quality standards are defective and must be revised. Verify key stakeholders
to determine that the requirements are:
 ready for formal review and validation by the customers and users, and
 provide all the information needed for further work based on the
requirements to be performed.
INPUT
Requirements [Any Except Stated]: Any requirement may be verified (including
business, stakeholder, solution, and transition requirements). Verification is a
quality check performed following analysis of a requirement.
TECHNIQUES
Acceptance and Evaluation Problem Tracking Structured Walkthrough
Criteria Definition
62 | P a g e
STAKEHOLDERS
All Stakeholders: The business analyst, in conjunction with the domain and
technical subject matter experts, has the primary responsibility for determining
that this task has been completed.
OUTPUT
Requirements [Verified]: Verified requirements are of sufficient quality to allow
further work based on those requirements to be performed.
VALIDATE REQUIREMENTS
Purpose
The purpose of requirements validation is to ensure that all requirements support
the delivery of value to the business, fulfill its goals and objectives, and meet a
stakeholder need.
DESCRIPTION
Requirements validation is an ongoing process to ensure that stakeholder,
solution, and transition requirements align to the business requirements.
Assessing what the outcome will be for the stakeholder when their need is
satisfied can be helpful when validating requirements. Implementation of the
requirements as a whole must be sufficient to achieve that desired future state
for customers and users. In many cases, stakeholders will have different,
conflicting needs and expectations that may be exposed through the validation
process and will need to be reconciled.
INPUT
Business Case: The business case describes the overall business objectives and
measurements that the solution is expected to deliver. To be valid, a requirement
must contribute directly or indirectly to the business case. Other business
requirements, including the business need, required capabilities, and solution
scope may also be used for validation.
Stakeholder, Solution, or Transition Requirements [Verified]: Requirements need

to be verified for validation to be completed. If a requirement cannot be verified,
it cannot be successfully implemented and so cannot meet a business need.
However, validation activities may begin before requirements are completely
verified.
63 | P a g e
TECHNIQUES
Acceptance and Evaluation Prototyping Risk Analysis

Criteria Definition
Metrics and Key Performance Structured Walkthrough
Indicators
STAKEHOLDERS
All Stakeholders: Virtually all stakeholders are involved in or impacted by
validation activities.
OUTPUT
Requirements [Validated]: Validated requirements are those that can be
demonstrated to deliver value to stakeholders and are aligned with the business
goals and objectives. If a requirement cannot be validated, it does not benefit the
organization, does not fall within the solution scope, or both.
64 | P a g e
8 Solution Assessment & Validation
The Solution Assessment and Validation Knowledge Area describes the tasks that
are performed in order to ensure that solutions meet the business need and to
facilitate their successful implementation. These activities may be performed to
assess and validate business processes, organizational structures, outsourcing
agreements, software applications, and any other component of the solution.
Activities in Solution Assessment & Validation are:

ASSESS PROPOSED SOLUTION
Purpose
To assess proposed solutions in order to determine how closely they meet
stakeholder and solution requirements.
DESCRIPTION
Solution assessment may be performed on a single solution or to compare
multiple proposed solutions. When assessing a single solution, the business
analyst determines whether the solution delivers enough business value to justify
its implementation. When assessing multiple alternative solutions, the business
analyst has the additional goal of attempting to determine which solution delivers
the greatest business value.
INPUT
 Assumptions and Constraints: Assumptions may lead to certain solutions
being favored, while constraints may limit available solution options.
 Requirements [Prioritized and Approved]: The relative priorities of
requirements allow analysis to identify the choices that meet the most
important requirements. Requirements must be approved in order to
allow a decision to be made.
 Solution Option(s): Information on each proposed solution must be
available. The information should be in a form that facilitates effective
comparison of the different available options.
TECHNIQUES
Acceptance and Evaluation Decision Analysis Vendor Assessment

Criteria Definition
65 | P a g e
STAKEHOLDERS
 Domain SME: Domain SMEs can provide feedback during the selection
process or participate in assessing options.
 Implementation SME: Gather information from experts with specific
expertise in the solution options under consideration. Interoperability with
the organization’s enterprise architecture needs to be considered.
 Operational Support: Provide information on technical constraints that
may limit the solutions that can be implemented.
 Project Manager: Will need to plan and manage the selection process.
 Supplier: Will provide information on the functionality associated with a
particular solution option.
 Sponsor: Approves the expenditure of resources to purchase or develop a
solution and approve the final recommendation.
OUTPUT
Assessment of Proposed Solution: Assess the value delivered by each proposed
solution. If multiple options are available, a recommendation of the best solution
should be made. A recommendation to terminate the initiative may be given if no
solution delivers enough value to justify being implemented.
ALLOCATE REQUIREMENTS
Purpose
Allocate stakeholder and solution requirements among solution components and
releases in order to maximize the possible business value given the options and
alternatives generated by the design team.
DESCRIPTION
Requirements allocation is the process of assigning stakeholder and solution
requirements to solution components and to releases. Requirements allocation
typically begins early in the project lifecycle (as soon as the solution approach can
be determined) and will continue to be performed until all valid requirements are
allocated.
INPUT
 Requirements [Prioritized and Approved]: Requirements allocation may be
performed with requirements in any state (e.g. stated, analyzed, verified,
66 | P a g e
validated) although completion of this task requires requirements have

been approved.
 Solution [Designed]: The solution design must have a defined set of
components, and the costs and effort associated with delivery of those
components must have been estimated. Tradeoffs can then be made
between the functionality allocated to each component and the cost
associated with developing that component.
 Solution Scope: The solution scope allocates business requirements to
components and releases. The associated stakeholder and solution
requirements should match that allocation, or the solution scope will have
to be revised.
TECHNIQUES
 Acceptance and Evaluation Criteria Definition: A minimal set of acceptance
criteria may need to be met by a particular release.
 Business Rules Analysis: Business rules can be managed and monitored by
people or automated by a software application.
 Decision Analysis: Can be used to estimate the value associated with
different allocation decisions and optimize those decisions.
 Functional Decomposition: Can be used to break down solution scope into
smaller components for allocation
 Process Modeling: Activities in the process model may be allocated to
different roles, or outsourced to a supplier. A solution can be developed
that incrementally supports some subprocesses or activities.
 Scenarios and Use Cases: Alternative flows can be separated from the base
use case and included in an extension to be moved into a later release.
STAKEHOLDERS
 Customers and Suppliers: Will be affected by how and when requirements
are implemented and may have to be consulted about, or agree to, the
allocation decisions.
 Domain SME: May have recommendations regarding the set of
requirements to be allocated to a solution component or to a release.
 End User: May require a minimal defined set of requirements to be
implemented before a release can be accepted.
 Implementation SME: Will be responsible for the design and construction
of some or all solution components and the estimation of the work
required.
67 | P a g e
 Operational Support: Will be affected by the allocation of requirements to

components and releases and need to be aware of when and where
requirements are allocated.
 Project Manager: Responsible for the work being done by the project team
and will need to participate in requirements allocation in order to manage
the project scope and work.
 Tester: Responsible for verifying releases and solution components and
will therefore need to know how requirements have been allocated.
 Sponsor: Responsible for funding of the project and therefore required to
approve the allocation of requirements to components and releases based
on the recommendation of the business analyst and the project team.
OUTPUT
Requirements [Allocated]: Allocated requirements are associated with a solution
component that will implement them.
ASSESS ORGANIZATIONAL READINESS
Purpose
Assess whether the organization is ready to make effective use of a new solution.
DESCRIPTION
An organizational readiness assessment describes the effect a new solution will
have on an organization and whether the organization is prepared for the
organizational change that the solution implementation will cause. Effective
communication of solution impacts assists in enabling necessary organizational
change management practices and identifying training requirements for solution
implementation.
In order to identify impacts the business analyst should understand what changes
will occur in the business area, technical infrastructure or processes and how
these affect other business units or operations.
INPUT
 Enterprise Architecture: Describes the current state of the enterprise like:
the organizational structure, processes, systems, information, etc.
 Solution Scope: used to determine which components of the business
architecture are affected.
 Solution [Designed]: Used in place of the solution scope, if available.
 Stakeholder Concerns: Used to assess potential problems or issues.
68 | P a g e
TECHNIQUES
General Techniques:
Acceptance and Evaluation Data Flow Diagrams Process Models
Criteria Definition Focus Groups Interviews
Survey/Questionnaire Organization Modeling Problem Tracking
Risk Analysis SWOT Analysis
Forece Field Analysis
Figure 8: Force field analysis

Force field analysis is a graphical method for depicting the forces that support and
oppose a change. It involves identifying the forces that support and oppose a
change, depicting them on opposite sides of a line, and then estimating the
strength of each force in order to assess which set of forces are stronger. Once
this analysis is complete, the next step is to look for ways to strengthen the forces
that support the desired outcome or generate new forces.
STAKEHOLDERS
Domain SME: Provides information on the likely impact to stakeholders and the
capabilities of the enterprise.
69 | P a g e
Implementation SME: Supplies information on the skills and capabilities

necessary to successfully operate the new solution.
Usability SMEs assist with the evaluation and design of software applications that
are easier to understand and use.
Training SMEs assist with the creation of a training plan to help stakeholders
develop the skills that they need to effectively use the new solution.
Operational Support: Provides information on their ability to support the
operation of the solution. Will need to understand the nature of the solution in
order to be able to support it.
Project Manager: Requires the organizational readiness assessment to determine
if additional project work is required for a successful implementation of the
solution.
Sponsor: Authorizes and champions action to resolve problems identified in the
organizational readiness assessment.
OUTPUT
Organizational Readiness Assessment: Describes whether stakeholders are
prepared to accept the change associated with a solution and are able to use it
effectively. May lead to revisions in solution or project scope.
DEFINE TRANSITION REQUIREMENTS
Purpose
To define requirements for capabilities needed to transition from an existing
solution to a new solution.
DESCRIPTION
In most cases, a solution is implemented within an enterprise in order to enhance
or replace an existing solution. During the transition period (the time when both
the old and new solutions are operational), the enterprise may need to operate
both solutions in parallel, move information between the new and old solution,
conduct training to enable stakeholders to effectively operate the new solution,
and so forth. In addition to developing the solution itself, the implementation
team is likely to have to develop additional capabilities to support this transition.
Transition requirements are elicited, analyzed, managed, and communicated by

performing the same tasks as for other requirements. The difference is not in the
methods for defining them, but in the inputs, the nature of transition
70 | P a g e
requirements, and in that they cease to be relevant once the existing solution is
eliminated.
In instances where there is no existing solution, and the new solution is adding an
entirely new capability to the enterprise rather than extending and improving an
existing capability, then transition requirements do not need to be analyzed.
INPUT
 Organizational Readiness Assessment: Used to identify areas where the
organization needs to add new capabilities to manage and operate the
new solution.
 Requirements [Stated]: Stakeholders will identify the information and
processes they need during transition.
 Solution [Deployed]: The deployed (or existing) solution will be
investigated to understand what needs to be transitioned to the new
solution. It may be necessary to elicit a description of the capabilities of
the solution and perform some analysis tasks in order to ensure that
current capabilities are fully understood.
 Solution [Designed]: The design for the new solution must be sufficiently
defined to allow major differences to be identified.
TECHNIQUES
 Business Rules Analysis: Additional business rules may be defined to assist
in migrating data, or to manage work migrated from the existing solution.
 Data Flow Diagrams, Process Modeling and Organization Modeling: To
identify the differences between the existing and new solutions.
 Data Modeling: Physical data models of the existing and new solutions will
be compared to enable a mapping between the two.
STAKEHOLDERS
 Customer: May be negatively affected if information is incorrectly
transferred.
 Domain SME: Will provide information on the existing solution and assist
in verification and validation of the transition requirements.
 End User: If the existing and the new solution are both in use for a period,
they will need to know how to co-ordinate between them.
 Implementation SME: Main source for many transition requirements.
 Operational Support: May need to operate two solutions simultaneously.
 Project Manager: Will need to plan for the work required to implement
the transition requirements. This may affect the project scope.
71 | P a g e
 Regulator: May require that records of the transition requirements and

process be retained for long-term review and compliance with regulations.
 Tester: Will verify that the transition has been performed correctly,
including the development of test plans.
 Sponsor: Will need to be informed of the potential effects of the transition
on the costs and benefits of the new solution.
OUTPUT
Transition Requirements: Transition requirements describe capabilities that must
be developed in order for an organization to successfully transition between
solutions. Transition requirements are analyzed by this task and must still be
verified, validated, managed and communicated.
VALIDATE SOLUTION
Purpose
Validate that a solution meets the business need and determine the most
appropriate response to identified defects.
DESCRIPTION
Solution validation is required to ensure that a delivered solution meets the
business needs on an ongoing basis. Problems that are identified through solution
validation will be reported and prioritized for resolution. When a problem is
identified with the solution (i.e. a failure to meet a stakeholder need, whether or
not the requirement was correctly specified) the business analyst will be able to
help the team determine the most appropriate action.
INPUT
Solution [Constructed]: Validation can only be performed against a solution that
actually exists. The solution may or may not be in actual use by the enterprise.
Requirements [Prioritized and Validated]: The priorities are needed to determine
which requirements are candidates for acceptance criteria and to determine
whether outputs of the solution fall within acceptable parameters.
TECHNIQUES
Acceptance and Evaluation Criteria, Problem Tracking and Root Cause Analysis
72 | P a g e
STAKEHOLDERS
 Domain SME: Will provide input into the development of acceptance and
evaluation criteria.
 End User: May assist in the development of acceptance and evaluation
criteria and participate in acceptance testing.
 Implementation SME: Will support the validation process, investigate
defects, correct identified defects, and participate in the defect
prioritization and resolution process.
 Operational Support: Will support the deployment of defect resolutions.
 Project Manager: Responsible for co-ordination of work between the
parties involved in the validation process.
 Tester: Solution verification (that is, verifying that the solution behaves in
accordance with the solution requirements) is the responsibility of the
tester. Testers will develop and execute tests to identify defects which
may need to be assessed and validated by the business analyst. Test plans
may be reviewed to ensure that the planned set of test activities will be
sufficient to assure the organization that the solution is in conformance
with the requirements.
 Regulator: May review the results of acceptance testing and require that
records be kept regarding the process and outcomes.
 Sponsor: The sponsor (or designate) must accept the solution.
OUTPUT
Identified Defects: Known problems that exist in a solution.
Mitigating Actions: Steps that can be taken, or processes that can be followed, to
reduce or eliminate the effect an identified defect has on a stakeholder or
stakeholder group.
Solution Validation Assessment: An assessment of whether the solution is able to

meet the business need at an acceptable level of quality.
EVALUATE SOLUTION PERFORMANCE
Purpose
Evaluate functioning solutions to understand the value they deliver and identify
opportunities for improvement.
73 | P a g e
DESCRIPTION
Solution evaluation involves investigating how a solution is actually used after it is
deployed, and assessing the effect it has had, both positive and negative. It may
also be referred to as post-implementation assessment when performed
immediately following the completion of a project.
Solutions may be adapted and modified directly by end users, including use of
manual workarounds, recording of additional information, and adoption of
informal policies and procedures in order to resolve problems that have occurred
or to allow new uses of the solution. In order to properly evaluate the solution, it
is also necessary to understand when, where and why this has occurred and
assess the benefit that these changes have brought to the organization.
INPUT
Business Requirements: The performance of the solution will be measured
against the business requirements. Without clear business requirements it is
impossible to assess the solution’s performance effectively.
Identified Defects: Any known defects must be considered in assessing the quality
of a solution.
Solution Performance Metrics: These represent the criteria by which the

performance of the solution is to be assessed. They may be quantitative
(measures of time, volume, revenue, errors found, or other information for which
hard numbers are available) or qualitative (user or customer satisfaction,
recommendations, or other measures which summarize the opinions of
stakeholders).
Solution [Deployed]: This task cannot be performed until the solution is in use.
TECHNIQUES
 Decision Analysis: A cost/benefit analysis.
 Focus Groups: Useful to gain a detailed qualitative understanding of the
value of a solution.
 Observation: May reveal uses or problems that are not being reported.
 Survey/Questionnaire: Enables gathering quantitative and qualitative
information from large numbers of stakeholders.
74 | P a g e
STAKEHOLDERS
Customer, Domain SME, and Supplier: May provide recommendations for

improvements.
End User: responsible for the day-to-day operation of the solution and a major
source of information on problems or defects.
Operational Support: Will be involved in monitoring the performance and

effectiveness of a solution or its components.
Regulator: May have requirements regarding the performance of a solution that

must be met on an ongoing basis.
Sponsor: The person responsible for the operation of the solution from a business
perspective will be responsible for deciding if the solution evaluation warrants the
initiation of a change initiative.
OUTPUT
Solution Performance Assessment: Describes how the solution is performing in
relation to business goals and objectives.
75 | P a g e
9 Underlying Competencies
The underlying competencies are, of course, not unique to the business analysis
profession. They are described here to ensure readers are aware of the range of
fundamental skills required, and provide a basis for them to investigate further
into the skills and knowledge that will enable them to be accomplished and
adaptable business analysts.
Three sets of competencies are seen as fundamental to success; each set is
further divided into sub-sets as follows (not all may applicable to everyone):
Figure 9: Competencies for BA
BUSINESS EFFECTIVENESS
Business Knowledge and Expertise: The ability to interpret the business in the
context of the project.
 Applies detailed business operational knowledge to the benefit of the role
 Operates consistently with the organisation's culture
 Where possible follows standard processes
 Identifies and minimises risk to the business’s ongoing operations
 Seeks to identify improvement opportunities within the business
 Understands the business organisational structure and can identify all
impacted project stakeholders
 Identifies customer expectations and objectives and can utilise customer's
specialist and/or technical expertise
76 | P a g e
Technical Knowledge and Expertise (mainly for Technical BAs): The ability to
identify and assess technology solutions and risks.
 Can describe the basic function of the business’s core systems (typically
managed by IT)
 Can describe the basic elements of the system or systems affected by the
project (infrastructure, network, data, applications)
 Consistently identifies technology interfaces and focuses on integration
aspects of projects
 Actively researches technology within their area of expertise
 Can describe areas of likely evolution of the next generation of technology
within their area of expertise
 Regularly provides guidance and advice to others within their area of
technical expertise
 Can describe the role of Enterprise Architecture team in systems
development (if they exist)
 Identifies risks & impacts associated with proposed technology options
Industry Knowledge and Expertise: The ability to identify industry trends, risks
and opportunities.
 Applies general industry knowledge to the benefit of the business
 Actively researches competitors and markets
 Feeds back industry trends and opportunities to the business
 Can describe current “best practice” within their area of expertise
 Actively participates in industry association events and develops informal
industry networks
Planning: The ability to think things through in advance to achieve your and
customer objectives.
 Can determine & communicate the best approach completing the specific role
 Clearly articulates customer objectives and needs
 Can identify key project milestones and define project scope
 Can identify and define proposed Business Benefits
 Ensures a mechanism is in place to capture project Risks, Issues and Scope
changes until a Project Manager is appointed
 Thoroughly considers assumptions, constraints and dependencies and ensures
that these are fully recorded
 Ensures planning tools and techniques are applied effectively
77 | P a g e
Researching: The ability to search for and collate facts to support the
achievement of the project objectives.
 Identifies sources of existing and potential information relating to the
project
 Can efficiently collect and collate existing documented information
required for project
 Can interview individuals and accurately transfer their opinion into a
concise written form
 Can workshop with a group to capture a number of independent sources
of information relating to the project, gaining consensus where possible
 Can validate and if necessary summarise collected information
 Is able to capture areas of opposing opinion without inflaming conflict
Knowledge Management: The ability to store, reference, collate and manage

information for comparison and evaluation purposes.
 Can plan and implement a knowledge management plan for the role
 Can store, reference and find information in an efficient manner
appropriate to the role
 Information captured is documented in a consistent manner
 Changes to information are controlled and outputs are version controlled
 Presentation of information is consistently designed to address the needs
of the recipients of the data
 Missing or inaccurate data is clearly identified
 Learnings are captured and fed back to organsiation
Evaluation and Analysis: The ability to review information, identify trends,

problems and opportunities and compile these for decision makers.
 By reviewing information, can identify gaps, obvious errors and potentially
inaccurate data
 Follows up with individuals and/or groups to clarify or complete the
identified gaps and errors
 By reviewing validated data, can identify trends
 By reviewing validated data, can identify risks and opportunities
 Through initial analysis can propose potential solution options
Modelling: The ability to show how a solution and/or outcomes could be achieved.
A Technical Analyst will utilize modelling techniques such as UML and Use Cases.
A Commercial Analyst will utilize modelling techniques such as NPV/ROI type
analysis. A Process Analyst will utilize modelling techniques such as flowcharting,
cause & effect diagrams, etc.
78 | P a g e
 Can identify the most appropriate modelling technique(s) required to

achieve the project outcomes
 Can implement and utilize modelling technique(s) appropriate to the role
 Utilises models to determine and communicate solution options
 Utilises models for “what if” scenarios to predict impact of change
Decision Making: The ability to make the most appropriate solution

recommendation to the customer. The decision making authority will change the
business as per delegation authorities. Sometimes it rests with Divisional Steering
Committees, alternatively at Group or Board level depending on cost and risk
profile of the project.
 Can validate, refine and optimise solution option models
 Through analysis of options, can select the option with the greatest
business benefit bearing in mind the customer’s objectives
 Can form a recommendation or recommendations, with justification, to
the decision making authority
 Will accept the decision of the decision making authority, even if it
conflicts with their own recommendations
PERSONAL EFFECTIVENESS
Communication and Facilitation: The ability to match content, style and language
to suit the audience and context, so maximizing understanding.
 Selects the appropriate communication method to ensure messages are
understood effectively
 Communicates difficult issues concisely and effectively at all levels within
the organisation
 Varies style and content to suit the audience
 Listens to the views of others, is responsive and checks understanding
 Can prepare for and conduct a workshop focused on specified outcomes
 Can manage a group of individuals in a workshop setting to collect
individual and group ideas
 Provides feedback and follow up to meetings and workshops
Influencing People: The ability to change people’s perceptions and motivate them
to support an initiative and contribute knowledge, skills and/or resources.
 Shows empathy with individuals, listens to and understands their
circumstances
 Identifies an individual’s likely motivators
79 | P a g e
 Identifies opportunities to utilise power if appropriate

 Applies effective influencing strategies
 Builds trust through effective and professional behaviour
Marketing Benefits: The ability to “sell” new projects or strategies.

 Clearly articulates the vision, objectives and benefits of a new initiative
 Can link the proposed benefits with an individual’s context
 Can pass on the sponsors passion and commitment
 Inspires others through a positive “can do” attitude.
 Focuses on achievements as well as problems.
 Remains objective and doesn’t exaggerate benefits or ignore risks
Conflict Management: The ability to identify, handle and resolve conflict

effectively.
 Identifies potential areas of conflict and works to avoid their occurrence or
their impact Identifies current areas of conflict and seeks to understand
apposing points of view
 Uses conflict resolution techniques effectively to resolve conflict where
possible
 Uses effective negotiation and influencing skills to gain consensus
 Actively works to diffuse conflict and avoids passing on or inflaming
conflict situations
 Focuses on project outcomes during conflict situations
Credibility: The ability to build trust through developing relationships, acting

professionally and meeting customer’s expectations. Endeavours to meet the
needs of the business and it's customers.
 Has presence
 Has a reputation for quality and timely delivery
 Networks effectively, builds professional relationships
 Acts ethically and professionally at all times
 Owns up to mistakes and readily admits when wrong or doesn't know
 Recognises and acts on what is important to the customer
 Respects other people’s time and responsibilities
Drive: The passion and ability to get things done.

 Is pro-active and committed to the timely delivery of assignment
objectives
 Maintains a high energy level
 Is enthusiastic and self-motivated
80 | P a g e
 Is results driven
 Takes personal responsibility
 Is persistent and tenacious in overcoming adversity
Flexibility: The ability to adapt to the requirements of the assignment and make
appropriate changes in style.
 Tailors personal approach to suit the customer and the requirements
 Is able to take fresh views and avoid rigid thought patterns
 Is prepared to investigate and challenge the unknown
 Applies common sense and doesn't go “over the top”
 Accepts and supports senior management decisions, even if contrary to
recommendations made
Innovation: The ability to identify and develop solutions which deliver better
business results.
 Has vision, sees the end goal.
 Thinks laterally, explores many options to solve a problem
 Learns from experience, seeks advice when unsure
 Is creative within the constraints of the business
 Doesn't impose artificial constraints
 Delivers and works with new business solutions and processes
ADMINISTRATION SKILLS
 General Office Skills: The ability to work efficiently within the constraints
of the business environment.
 Time Management: The ability to manage your own work and the
expectations of others.
 Estimating & Financial Skills (mainly for Commercial BAs): The ability to
contribute to the estimating, financial analysis, budgeting and forecasting
processes.
 Computer and Application Skills: The ability to make best use of the
information technology in the organization
 Configuration Management: The ability to ensure that the version of the
deliverables and documentation is consistent, so minimizing the chances
of mistakes through change.
 Document Writing: The ability to convey in writing knowledge, decisions
or ideas in a format which is easily understood by others.
81 | P a g e
10 Techniques
The techniques listed here are only a subset of the techniques used by
practitioners of business analysis. The ones listed here are applicable to enough
different situations and business domains, and have been adopted by enough
business analysis practitioners, that a skilled generalist should reasonably be
expected to be familiar with the existence and purpose of the technique. Business
analysts who specialize in a particular methodology or business domain may need
to understand a smaller set of techniques in greater depth, or may need to
develop expertise in techniques not described here.
ACCEPTANCE AND EVALUATION CRITERIA DEFINITION
To define the requirements that must be met in order for a solution to be

considered acceptable to key stakeholders.
Determine which requirements can most effectively be used as acceptance or
evaluation criteria.
 Acceptance criteria describe the minimal set of requirements that must be
met in order for a particular solution to be worth implementing.
 Evaluation criteria are the set of requirements that will be used to choose
between multiple solutions.
Either acceptance and evaluation criteria may be used to determine if a solution
or solution component can be shown to objectively meet a requirement.
Acceptance criteria are typically used when only one possible solution is being
evaluated and are generally expressed as a pass or fail. Evaluation criteria are
used to compare multiple solutions or solution components and allow for a range
of possible scores.
BENCHMARKING
Benchmark studies are performed to compare the strengths and weaknesses of

an organization against its peers and competitors. Benchmark studies are
conducted to compare organizational practices against the best-in-class practices
that exist within competitor enterprises in government or industry. The objective
of benchmark studies is to determine how companies achieve their superior
performance levels and use that information to design projects to improve
operations of the enterprise. Benchmarking is usually focused on strategies,
operations and processes.
82 | P a g e
BRAINSTORMING
Brainstorming is an excellent way to foster creative thinking about a problem. The

aim of brainstorming is to produce numerous new ideas, and to derive from them
themes for further analysis.
Brainstorming is a technique intended to produce a broad or diverse set of
options. Brainstorms help answer specific questions such as (but not limited to):
 What options are available to resolve the issue at hand?
 What factors are constraining the group from moving ahead with an
approach or option?
 What could be causing a delay in activity ‘A’?
 What can the group do to solve problem ‘B’?

Brainstorming works by focusing on a topic or problem, and then coming up with
many possible solutions to it. This technique is best applied in a group as it draws
on the experience and creativity of all members of the group. In the absence of a
group, one could brainstorm on one’s own to spark new ideas. To heighten
creativity, participants are encouraged to use new ways of looking at things and
free associate in any direction. Facilitated properly, brainstorming can be fun,
engaging and productive.
BUSINESS RULES ANALYSIS
To define the rules that govern decisions in an organization and that define,
constrain, or enable organizational operations. Policies and rules direct and
constrain the organization and operation of an organization. A business policy is a
non-actionable directive that supports a business goal. A business rule is a specific,
actionable, testable directive that is under the control of an organization and that
supports a business policy. Particularly complex rules, or rules with a number of
interrelated dependencies, may be expressed as a decision table or decision tree,
as described in Decision Analysis.
A number of basic principles guide the business analyst when stating and
managing business rules. The business rules should be:
 Stated in appropriate terminology to enable domain SMEs to validate the
rules.
 Documented independently of how they will be enforced.
 Stated at the atomic level and in declarative format.
 Separated from processes that the rule supports or constrains.
 Maintained in a manner that enables
83 | P a g e
DATA DICTIONARY AND GLOSSARY
A data dictionary or glossary defines key terms and data relevant to a business
domain. Data dictionaries or glossaries are used to formally identify and define all
terminology used by the organization or organizational unit. For example, an
organizational unit may differentiate between a client and a customer, where a
client is a party with whom the business has an enforceable professional service
agreement, whereas a customer may have a much more casual, transaction based
relationship with the business.
DATA FLOW DIAGRAMS
To show how information is input, processed, stored, and output from a system.
Figure 10: Example of DFD

The Data Flow Diagram (DFD) provides a visual representation of how information
is moved through a system. It shows the:
 External Entities that provide data to, or receive data from, a system
 The Processes of the system that transform data
 The Data Stores in which data is collected for some period of time
 The Data Flows by which data moves between External Entities, Processes
and Data Stores
84 | P a g e
DATA MODELING
The purpose of a data model is to describe the concepts relevant to a domain, the
relationships between those concepts, and information associated with them. A
data model usually takes the form of a diagram supported by textual descriptions.
It visually represents the types of people, places, things and concepts that are
important to the business, attributes associated with them, and the significant
business relationships among them. Data models are often supported by a Data
Dictionary and Glossary and by Business Rules Analysis.
The two most widely used types of data model are the entity-relationship diagram
(ERD) and the class diagram, although other modeling notations remain in use.
Figure 11: Example of Class Diagra
85 | P a g e
Figure 12: Example of ER Diagram
DECISION ANALYSIS
To support decision-making when dealing with complex, difficult, or uncertain

situations. Decision analysis is an approach to decision-making that examines and
models the possible consequences of different decisions.
Figure 13: Example of Decision Analysis
86 | P a g e
Decision analysis assists in making an optimal decision under conditions of

uncertainty. Uncertainty may exist because of unknown factors that are relevant
to the decision problem, because there are too many possible interrelated factors
to consider, because of conflicting perspectives on a situation, or because of
tradeoffs between the different available options.
Effective decision analysis requires that the analyst understand:
 The values, goals and objectives that are relevant to the decision problem
 The nature of the decision that must be made
 The areas of uncertainty that affect the decision
 And the consequences of each possible decision.
DOCUMENT ANALYSIS
Document analysis is a means to elicit requirements by studying available

documentation on existing and comparable solutions and identifying relevant
information. Document analysis may include analysis of business plans, market
studies, contracts, requests for proposal, statements of work, memos, existing
guidelines, procedures, training guides, competing product literature, published
comparative product reviews, problem reports, customer suggestion logs, and
existing system specifications, among others. Identifying and consulting all likely
sources of requirements will result in improved requirements coverage, assuming
the documentation is up to date.
ESTIMATION
Estimating techniques forecast the cost and effort involved in pursuing a course of
action. Estimation techniques are used to develop a better understanding of the
possible range of costs and effort associated with any initiative. Estimation is used
when it is impossible to determine exact costs. Estimation cannot and does not
eliminate uncertainty; rather, the purpose of estimation is to get a reasonable
assessment of likely costs or effort required.
FOCUS GROUPS
A focus group is a means to elicit ideas and attitudes about a specific product,
service or opportunity in an interactive group environment. The participants share
their impressions, preferences and needs, guided by a moderator.
87 | P a g e
A focus group is composed of pre-qualified individuals whose objective is to

discuss and comment on a topic. This is an opportunity for individuals to share
their own perspectives and discuss them in a group setting. This could lead
participants to re-evaluate their own perspectives in light of others’ experiences.
A trained moderator manages the administrative pre-work, facilitates the session
and produces the report. Observers may record or monitor the focus group but to
not participate.
As this elicitation technique is considered a form of qualitative research, the

session results are analyzed and reported as themes and perspectives, rather than
numerical findings. The report may also include selected quotations to support
the themes.
FUNCTIONAL DECOMPOSITION
To decompose processes, functional areas, or deliverables into their component

parts and allow each part to be analyzed independently. Functional
decomposition involves breaking down a large problem into smaller functions or
deliverables. The primary goal of functional decomposition is to ensure that the
problem is separated into sub-problems that are as independent as possible, so
that work can be assigned to different groups. This provides the ability to scale
and manage larger projects.
Figure 14: Example of Functional Decomposition
INTERFACE ANALYSIS
To identify interfaces between solutions and/or solution components and define

requirements that describe how they will interact. An interface is a connection
88 | P a g e
between two components. Most software applications require one or more

interfaces. Interface types include:
 User interfaces, including human users directly interacting with the system,
as well as reports provided to the user
 Interfaces to and from external applications
 Interfaces to and from external hardware devices
Interface analysis helps to clarify the boundaries of the interfacing applications. It

distinguishes which application provides specific functionality along with the input
and output data needs. By clearly and carefully separating the requirements for
each application while defining the shared interface requirements, a basis for
successful interoperability is established.
INTERVIEWS
An interview is a systematic approach designed to elicit information from a

person or group of people in an informal or formal setting by talking to an
interviewee, asking relevant questions and documenting the responses.
In an interview, the interviewer formally or informally directs questions to a

stakeholder in order to obtain answers that will be used to create formal
requirements. One-on-one interviews are typically most common. In a group
interview (with more than one interviewee in attendance) the interviewer must
be careful to elicit responses from all attendees.
For the purpose of eliciting requirements, interviews are of two basic types:
 Structured Interview: where the interviewer has a pre-defined set of
questions and is looking for answers.
 Unstructured Interview: where, without any pre-defined questions, the
interviewer and the interviewee discuss topics of interest in an open-
ended way.
Successful interviewing depends on several factors including, but not limited to:
 Level of understanding of the domain by the interviewer.
 Experience of the interviewer in conducting interviews.
 Skill of the interviewer in documenting the discussions.
 Readiness of interviewee to provide the relevant information.
 Degree of clarity in interviewee’s mind about what the business requires
of the target system.
 Rapport of the interviewer with the interviewee.
89 | P a g e
LESSONS LEARNED PROCESS
The purpose of the lessons learned process is to compile and document successes,
opportunities for improvement, failures, and recommendations for improving the
performance of future projects or project phases. Lessons learned sessions can
include any format or venue that works for the key stakeholders identified as
participants in these sessions.
METRICS AND KEY PERFORMANCE INDICATORS
The purpose of metrics and key performance indicators are to measure the
performance of solutions, solution components, and other matters of interest to
stakeholders. A metric is a quantifiable level of an indicator that an organization
uses to measure progress.
An indicator identifies a specific numerical measurement that represents the

degree of progress toward achieving a goal, objective, output, activity or further
input. A Key Performance Indicator is one that measures progress towards a
strategic goal or objective. Reporting is the process of informing stakeholders of
metrics of indicators in specified formats at specified intervals.
Figure 15: Example of KPI
90 | P a g e
NON-FUNCTIONAL REQUIREMENTS ANALYSIS
The purpose of non-functional requirements is to describe the required qualities

of a system, such as its usability and performance characteristics. These
supplement the documentation of functional requirements, which describe the
behavior of the system. Non-functional requirements document the qualities of a
system that are important to:
 the user community, such as usability, learnability, reliability, etc.
 the development community, such as scalability, maintainability,
reusability, etc.
Strictly speaking, the term “non-functional requirements” only applies when

describing a software application. However, the various categories of non-
functional requirements may be applicable to other solution components for
which requirements can be developed. For example, reliability requirements for
an organizational unit might include specified hours of service, and performance
efficiency requirements for a business process might include cycle time to deal
with a customer request and may be captured in a service level agreement (SLA).
In these cases, an alternative term like “quality of service” requirements may be
preferred.
OBSERVATION
Observation is a means of eliciting requirements by conducting an assessment of

the stakeholder’s work environment. This technique is appropriate when
documenting details about current processes or if the project is intended to
enhance or change a current process. There are two basic approaches for the
observation technique:
Passive/invisible: In this approach, the observer observes the user working

through the business routine but does not ask questions. The observer records
what is observed, but otherwise stays out of the way. The observer waits until the
entire process has been completed before asking any questions.
Active/visible: In this approach, while the observer observes the current process
and takes notes they may dialog with the user. When the observer has questions
as to why something is being done as it is, they ask questions right away, even if it
breaks the routine of the user.
91 | P a g e
ORGANIZATION MODELING
An organizational model defines how an organization or organizational unit is

structured. Organizational units bring together a group of people to fulfill a
common purpose or goal. This purpose may be functional, meaning that the
people in question share a common set of skills and knowledge, or to serve a
particular market. An organizational model will define the scope of the
organizational unit, the formal relationships between the people who are
members of that unit, the roles those people fill, and the interfaces between that
unit and other units or stakeholders.
PROBLEM TRACKING
Problem tracking provides an organized approach to tracking, management, and

resolution of defects, issues, problems, and risks throughout business analysis
activities. Problems may include issues, questions, risks, defects, conflicts, or
other concerns that need to be tracked to resolution. A problem tracking system
ensures that issues are not simply neglected or lost. For each problem, the
tracking tool may include an identification of the problem, status updates,
assigning of related actions that are required to team members and tracking
expected resolution dates, resolution results, actions and decisions taken, priority,
and impacts. The current status of problems should be communicated to all
relevant stakeholders. Ensure problem tracking leads to:
 Resolution of problems in a timely manner that eliminate or minimize
negative impacts.
 Allocation of resources to resolve problems.
 Identification of root causes of problems.
PROCESS MODELING
A process describes how multiple people or groups collaborate over a period of

time to perform work. Processes involve a number of activities that are linked by
a sequence flow. A process is repeatable and may have multiple paths to
completion. Events may be actions taken by a person, rules which cause action to
be taken, or simply the passage of a period of time. The process model may
involve manual activities, be completely automated, or a combination thereof.
The process is complete when the objective or the goal of the process is
completed.
92 | P a g e
A process model is a visual representation of the sequential flow and control logic
of a set of related activities or actions. Process modeling is used to obtain a
graphical representation of a current or future process within an organization. A
model may be used at its highest level to obtain a general understanding of a
process or at a lower level as a basis for simulation so that the process can be
made as efficient as possible.
Figure 16: Process Modeling example
PROTOTYPING
Prototyping details user interface requirements and integrates them with other
requirements such as use cases, scenarios, data and business rules. Stakeholders
often find prototyping to be a concrete means of identifying, describing and
validating their interface needs.
Prototyping can be categorized in two ways:

Functional Scope. A horizontal prototype models a shallow, and possibly wide
view of the system’s functionality. It typically does not have any business logic
running behind the visualization. A vertical prototype models a deep, and usually
narrow slice of the entire system’s functionality.
93 | P a g e
Usage Throughout System Development Lifecycle. A “Throw-away” prototype

seeks to quickly uncover and clarify interface requirements using simple tools,
sometimes just paper and pencil. The focus is on functionality that is not easily
elicited by other techniques, has conflicting viewpoints, or is difficult to
understand. An “Evolutionary or Functional” prototype extends the initial
interface requirements into a fully functioning system and requires a specialized
prototyping tool or language. This prototype produces a working software.
RISK ANALYSIS
To identify and manage areas of uncertainty that can impact an initiative, solution,
or organization. A risk describes an uncertain event or occurrence that may have
an effect on the ability of the business analyst, project team, or organization to
achieve an objective. Risks by their nature can be positive or negative. Risk
analysis involves understanding the risk tolerance levels of the organization,
assessing risks, and identifying responses.
Figure 17: Example of Risk Analysis
REQUIREMENTS WORKSHOPS
A requirements workshop is a structured way to capture requirements. A

workshop may be used to scope, discover, define, prioritize and reach closure on
requirements for the target system. A requirements workshop is a highly
94 | P a g e
productive focused event attended by carefully selected key stakeholders and

subject matter experts for a short, intensive period (typically one or a few days).
The workshop is facilitated by a team member or ideally, by an experienced,

neutral facilitator. A scribe (also known as a recorder) documents the
requirements elicited as well as any outstanding issues. A business analyst may be
the facilitator or the scribe in these workshops. In situations where the business
analyst is a subject matter expert on the topic, they may serve as a workshop
participant.
ROOT CAUSE ANALYSIS
The purpose of root cause analysis is to determine the underlying source of a

problem. Root cause analysis is a structured examination of the aspects of a
situation to establish the root causes and resulting effects of the problem. A
critical element of root cause analysis is to ensure that the current business
thinking and processes are challenged. That is, do they still make sense or provide
good business value in light of current realities?
THE FISH BONE DIAGRAM
95 | P a g e
A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is

used to identify and organize the possible causes of a problem. This tool helps to
focus on the cause of the problem versus the solution and organizes ideas for
further analysis. The diagram serves as a map depicting possible cause-and-effect
relationships.
THE “FIVE WHYS”
The Five Whys is a question-asking

process to explore the nature and
cause of a problem. The Five Whys
approach repeatedly asks
questions in an attempt to get to
the root cause of the problem.
This is one of the simplest
facilitation tools to use when
problems have a human
interaction component.
SCOPE MODELING
Scope models are used to describe the scope of analysis or the scope of a solution.
Scope models serve as a basis for defining and delimiting the scope of business
analysis and project work. Scope models allow the definition of a “complete”
scope—that is, the boundaries of the scope correspond with the natural
boundaries of a business domain.
CONTEXT DIAGRAM
A context diagram is a top-level data flow diagram. It uses a single data process to
describe the scope and shows the external entities and data stores that provide
data to and receive data from the system.
96 | P a g e
Figure 18: Example of Context diagram
SCENARIOS AND USE CASES
Scenarios and use cases are written to describe how an actor interacts with a
solution to accomplish one or more of that actor’s goals, or to respond to an
event. Scenarios are written as a series of steps performed by actors or by the
solution that enable an actor to achieve a goal.
Figure 19: Example of Use Case diagram
97 | P a g e
A use case describes several scenarios in the form of primary and alternate flows.
The primary or basic flow represents the simplest way to accomplish the goal of
the use case. Special circumstances and exceptions that result in a failure to
complete the goal of the use case are documented in alternate flows.
SEQUENCE DIAGRAMS
Sequence diagrams are used to model the logic of usage scenarios, by showing
the information passed between objects in the system through the execution of
the scenario. A sequence diagram shows how classes and objects interact during a
scenario. The classes required to execute the scenario are displayed on the
diagram, as are the messages they pass to one another (triggered by steps in the
use case). The sequence diagram shows how objects used in the scenario interact
but not how they are related to one another. Sequence diagrams are also often
used to show how user interface components or software components interact.
Figure 20: Example of Sequence diagram
98 | P a g e
STATE DIAGRAMS
A state diagram specifies a sequence of states that an object goes through during
its lifetime, and defines which events cause a transition between those states. The
allowable behavior of the object is dependent on its current state. There are
many titles for the state diagram including State Machine Diagram, State
Transition Diagram, and Entity Life Cycle Diagram.
Figure 21: State Diagram example
STRUCTURED WALKTHROUGH
Structured walkthroughs are performed to communicate, verify and validate

requirements. A structured walkthrough is a working session where invited
participants review and discuss a set of requirements. Participants are required to
ask questions, and make comments and suggestions. Other issues may also be
identified during the session. All questions, comments, concerns, and suggestions
are recorded.
A walkthrough may result in revised requirements as well as issues that require

investigation. A walkthrough may also be referred to as a requirements review.
An inspection is similar, but follows a more formal process and uses checklists and
other tools.
99 | P a g e
Figure 22: Roles in structured walk-through
SURVEY/QUESTIONNAIRE
A survey is a means of eliciting information from many people, sometimes

anonymously, in a relatively short period of time. A survey can collect information
about customers, products, work practices and attitudes. A survey may also be
referred to as a questionnaire.
Figure 23: Example of questionnaire
100 | P a g e
SWOT ANALYSIS
A SWOT analysis is a valuable tool to quickly analyze various aspects of the

current state of the business process undergoing change. SWOT is an acronym for
Strengths, Weaknesses, Opportunities, and Threats. SWOT analysis is a framework
for strategic planning, opportunity analysis, competitive analysis, business and
product development.
Figure 24: Example of SWOT analysis
USER STORIES
User Stories are a brief description of functionality that users need from a
solution to meet a business objective. A user story is a textual description of
things that the solution needs to allow users to do. User stories are typically a
sentence or two that describes who uses the story, the goal they are trying to
accomplish, and any additional information that may be critical to understanding
the scope of the story.
Figure 25: Example of a User story
101 | P a g e
VENDOR ASSESSMENT
To assess the ability of a potential vendor to meet commitments regarding a

product or service. When solutions are in part provided by external vendors (who
may be involved in design, construction, implementation, or maintenance of the
solution or solution components), or when the solution is outsourced, there may
be specific requirements in regard to the involvement of that third party.
For example, there may be a need to ensure that the supplier is financially secure,
capable of maintaining specific staffing levels, committing appropriately skilled
staff to support the solution, and so forth.
Figure 26: Example of a vendor assessment form
102 | P a g e
Appendix: Software Requirements Specification (SRS)
EMR Data Analysis
103 | P a g e
Software Requirements Specification (SRS)
EMR Data Analysis
Authors: James Drallos, Jordan Clare, Joseph Korolewicz, Daniel Laboy
Customer: Dr. Gary Ferenchick
1 Introduction
This document outlines the software requirements for an electronic medical record
(EMR) data analysis clinical decision support system. It will cover the overall description of
the system, specific requirements as well as modeling requirements, diagrams and a
description of a prototype to be built to demonstrate the system‟s functionality.
1.1 Purpose
This document is intended to inform those who have a vested interest in the EMR data
analysis clinical support system of its purpose and design. It should be useful to the customer(s)
as well as any members of a software development team who are tasked to build and/or maintain
the system itself. Users of the system need not concern themselves with the information in this
document unless they desire a deeper understanding of the system‟s architecture. However, this
document does include a prototype, which demonstrates how the final system will look and
function.
1.2 Scope
The software system of which this document concerns is an EMR data analysis-based clinical
decision support system (CDSS). The system will be a software package that will be installed on
a server machine and be accessible from any internet-enabled client machine in order to better
assist medical personnel in the diagnosis and treatment of patients. It is intended to focus on
patients exhibiting symptoms of Methicillin-Resistant Staphylococcus aureus (MRSA), a
common bacteria which has become resistant to typically prescribed drugs. The system will
provide access to patient data contained in an EMR such as symptoms, medical history and
current prescriptions. The system will then evaluate known data about a patient and use it to
suggest a case-specific treatment plan. The system will receive data from remote databases
including relevant clinical trials that can be prescribed and medical best practice guidelines to be
followed. Treatment will then be monitored. The system will improve the quality of medical care
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have been
made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
1
by providing a wealth of data from various sources to medical professionals, by promoting the
use of best practices and tracking treatment.
1.3 Definitions, acronyms, and abbreviations
Artifact – A document or image containing the results of a medical treatment.

Best Practices – Generally accepted medical guidelines for the treatment of a condition.
CA-MRSA – Community-acquired MRSA, the typical case in which MRSA is contracted from
the patient's community.
CDSS – Clinical Decision Support System. Software that generates case-specific advice based
on a medical knowledge base and patient data.
Clinical Trials – Medical trials conducted to allow safety and efficacy data to be collected for
new drugs or devices.
EMR – Electronic Medical Record. A digital form of a patient‟s past medical information.
EMR_DataAnalysisManager - A class belonging to the system that manages the different
subsystems.
EMRSA – Epidemic MRSA, a particular strain of MRSA heavily infecting a specific region.
HA-MRSA – Health-care-acquired MRSA, a strain of MRSA acquired from a health care
facility.
MRSA – Methicillin-Resistant Staphylococcus aureus. The medical condition targeted by the
system for evaluation.
MRSA Health Surveillance System – National surveys conducted on MRSA that provide a
representative „snapshot‟ of the overall epidemiology of MRSA.
HL-7 – Health Level Seven standards for interoperability of health information technology.
Patient History – Data which includes a patient's problems, medications, allergies, family
history, social history, allergies, etc.
TreatmentManager – A class belonging to the system that uses data to suggest a treatment
plan.
XAML – Extensible Application Markup Language: is a declarative XML-based language
which is used to initialize structured values and objects.
1.4 Organization
This document is organized in seven sections with various subsections describing various
aspects of the system. Section two gives the overall description of the product, including major
functions and constraints. Section three lists specific requirements, section four contains
diagrams outlining the design and use of the system, section five describes the product prototype,
section six lists references and section seven gives the point of contact for questions about the
product.
2 Overall Description
This section contains the complete description of the project. It states the perspective of the
system, how the system is just one part of a complete EMR. This section also shows the
2
constraints faced by the system, and the assumptions that were made both about the systems it
will be interacting with, and the people who will be using the system.
2.1 Product Perspective
The system is the data analysis portion of an electronic medical record. The system will,
given a diagnosis from a doctor about a certain patient, find and create a relevant treatment plan
for that patient. The system will suggest these treatments using information regarding patient
specific information, medical best practices and relevant clinical trials. As seen in figure 2.1, the
TreatmentManager will get all of this information and then be able to design a treatment.
ClinicalTrials
EMR_DataAnalysisManager TreatmentManager PatientHistory
MedicalGuidelines
Figure 2.1. TreatmentManager
The system is just one part of a complete EMR system. The other pieces of an EMR system
are the data collection and data dissemination pieces respectively. The data collection piece of
the system would be required to collect all of the input given by medical professionals, and store
all of this data into an accessible location. The project would use this information and make a
treatment decision using all of this data. The other piece of a successful EMR, the data
dissemination piece, would take the information, and find current medical trends. It would check
whether people from a certain area were more prone to a certain disease. See Figure 2.2 for an
example of a complete EMR system. Notice that the data dissemination and data analysis pieces
run concurrently. This is because both systems take the same data from the data collection
section, and use it in different ways.
Data Analysis
Data Collection
Data Dissemination
Figure 2.2. Complete EMR System

3
For the system to work, there must be certain information present. There must be databases
set up for patient history, medical best practices, and clinical trials. The system would then
check these databases, and pull out relevant information. It would then use this information to
build a treatment that would be customized for the current patient and current state of the
medical field.
2.2 Product Functions
 The system shall provide customized treatment plans for patients who have been
diagnosed with different diseases.
 The system shall confirm a clinical diagnosis given by a medical professional by

checking the symptoms present with the diagnosis.
 The system shall provide access to relevant clinical trials for a given patient, and give a
medical professional the choice of whether or not he or she would like to try and use this
particular trial information for their current treatment or enter the patient into said trial.
 The system shall provide a plan for preventive care for its patients.
 The system shall show the medical best practices of a given diagnosis, and remind a
physician as to what guidelines have not yet been completed.
 The system shall track previously diagnosed patients, and check to see if there are any
treatments or diagnostic studies that still need to be done.
 The system shall be able to differentiate whether a patient has a certain kind of MRSA,
and how to treat that patient.
 The system shall abide by HL-7 standards.
2.3 User Characteristics
This system has certain expectations of the user. The user must be able to properly input the
symptoms or diagnosis, because if any incorrect input were put into the system, the treatment
plan provided by the system would not be valid. Also, the user needs to have some kind of
medical experience, and must have a certain level of certification as defined by the medical
practice using the system. The user needs to be able to understand the treatment provided, and
can be able to act upon that treatment accordingly.
4
2.4 Constraints
 The system must have access to databases that contain medical records of patients,
relevant clinical trials, and medical best practices for different diseases.
 The system will only work for diseases that are currently in the databases.
 The input into the system must be correct, if a doctor enters a wrong diagnosis, the
treatment provided will not be relevant to the current patient.
2.5 Assumptions and Dependencies
The system assumes that there are databases set up that hold patients medical records,
ongoing clinical trials, and medical guidelines for specific diseases, and that the system has
access to these pieces of information. Without this information, the system has no information to
base its recommendations for treatment.
2.6 Approportioning of Requirements
The customer stated that it would be ideal for the project to contain voice recognition for a
method of input; however, this cannot be implemented due to time constraints.
3 Specific Requirements
The following is a list of specific requirements that the system will model its behavior from.
1. Manage clinical information:
1.1 Identify and prescribe relevant clinical trials / protocols:
The system will query the list of clinical trials hosted on www.clinicaltrials.gov
and determine if there are any ongoing trials that are relevant to the patient‟s diagnosis
and, if so, will display information about the trial to the physician.
1.2 Track orders for treatment:
The system will allow the user to view information regarding both the patient‟s
treatment history, as well as any treatment that has been scheduled. Information about
previously administered treatments will be available in a variety of forms depending on
the type of treatment, for example X-rays, lab reports, or prescriptions. Information
pertaining to treatments that have been scheduled to take place sometime in the future
will contain the proposed date and location, as well as any notes the physician has entered
5
regarding treatment customization. Once the treatment has been completed, the relevant
artifact will be available for viewing.
1.3 Referral follow-up:
The system will allow the user to view information about all treatments the
patient received, including treatments that were referred to a medical facility using an
identical or compatible EMR system.
1.4 Prescribe preventative care:
The system will provide the user with general guidelines for relevant preventative
care for a given diagnosis.
2. Decision Support:
2.1 Confirm a clinical diagnosis:
The system will compare the signs, symptoms and risk factors the user has
acquired based on a patient‟s symptoms and compare them against a database of
symptoms for a given diagnosis. If the system finds the diagnosis to be inconsistent with
symptoms, then the system will display a message to that effect as a warning to the user.
2.2 Suggest treatment plan processes:
The system, when given a diagnosis, will compare treatments the patient has
already received to a list of possible treatments for that diagnosis. The system will then
suggest the relevant treatment plan and call attention to elements of the plan that have not
already been administered.
2.3 Promote the use of “best practices”:
The system, when presented with a diagnosis, will present a list of generally
accepted treatments for the diagnosis. The list will be retrieved from a database that
contains a list of best practice guidelines and is maintained by the system.
2.4 Customize treatment according to specific conditions:
The system will allow the user to enter any notes or special instructions (i.e.,
allergies, recent trauma, etc.) when scheduling a treatment. Any special instructions that a
user adds will be viewable by any other user observing the patient's medical history.
2.5 Distinguish between various types of MRSA:
2.5.1 Determine if MRSA is Health-Care acquired (HA-MRSA)
6
The system, when presented with a diagnosis of MRSA, will check its
database to see if the patient has been admitted in the last 48 hours or has been in
staying in the hospital. If so, the system will display a message to the user
indicating the possibility of HA-MRSA.
2.5.2 Determine if MRSA is the result of an epidemic (EMRSA)
The system, when presented with a diagnosis of MRSA, will check the
MRSA Health Surveillance System to see if there has been an unusually large
number of MRSA cases in the area, which is consistent with a diagnosis of
Epidemic-MRSA.
2.5.3 Determine if MRSA is Community acquired (CA-MRSA)
The system, when presented with a diagnosis of MRSA, will conclude that
if MRSA was not contracted from a health care facility or from an epidemic in the
area, that the type is CA-MRSA, acquired from the patient‟s community.
3. Compliance with HL-7 standards
The system will conform to HL-7 standards in all data storage and message passing protocols.
7
4 Modeling Requirements
Figure 4.1. Use Case Diagram
Figure 4.1 depicts the typical use cases of the system. A user is able to view patient info,
schedule treatments for patients in the system, and enter diagnoses for patients in the system. As
shown, when a diagnosis is made the system confirms the diagnosis, gets a list of best practices,
and relevant sensitivity charts for various medications.
8
Figure 4.2 (below) is a UML class diagram for the system. This diagram shows the
relationships between the classes as well the attributes and methods each class contains. The
PatientInfo class is a collection of all the relevant information about a patient such as height,
weight, vitals, as well as a reference to the patient‟s medical history which will have all the
information about previous treatments, diagnoses, as well as current symptoms. The Diagnosis
class contains a reference to the BestPractices class is a collection of widely approved methods
for treating a given diagnosis. The EMR_DataAnalysisManager coordinates the different
subsystems and lets the user move easily between various tasks such as looking at a patient‟s
history and scheduling a new treatment. The TreatmentManager is the core of the system. The
TreatmentManager provides the vast majority of the functionality of the system and is invoked
whenever a user makes a diagnosis, schedules a treatment, or wishes to view details about
previous treatments. Each instance of the Treatment class, which stores information about a
single treatment that a user can administer, also has zero or more Artifacts associated with it.
The Artifact class has a digital copy of various results of a given treatment, such as an X-Ray,
lab result, or copy of a prescription.
EMR – Data Analysis Class Diagram

PatientHistory Symptom
Medication
-_description : string
-_date -_name : string
*
PatientInfo +addSymptom(in symptom : Symptom)

* -_description : string
-_fName : string +addMedication(in medication : Medication)
* -_dosage : uint
-_mInital : string +addDiagnosis(in diagnosis : Diagnosis)
-_sideEffects : string
-_lName : string +viewHistory() : <unspecified>
-_knownInteractions : string
-_height : uint 1 +getSymptoms() : Symptom
-_weight : uint +getDiagnoses() : Diagnosis
-_vitals : Vitals +getMedications() : Medication
-_systemID : string +getTreatments() : Treatment
*
+addTreatment(in treatment : Treatment)

+getName() : string 1
Diagnosis
+getFirstName() : string
+getLastName() : string -_disease : string BestPractices
*
+getVitals() : string -_bestPractices : BestPractices -_guidelines : string
+getHeight() : string -_symptoms : Symptom
+getWeight() : string -_date 11
+getHistory() : string
*
* *
*
ClincalTrial
-_title : string
TreatmentManager
Treatment -_location : string
-patientInfo : PatientInfo -_relevantCondition : string
1 1 -_type : string
+scheduleTreatment(in treatment : Treatment) -_tags : string
-_date
+confirmDiagnosis() 1 -_description : string +getInfo() : <unspecified>
+checkForHAMRSA() -_notes : string
+checkForEMRSA() +ViewDetails()
+getClinicalTrials(in diagnosis : string) : <unspecified>
1 1
1 HealthSurveillanceSystem *
1
+GetSensitivityChart(in location) Artifact

EMR_DataAnalysisManager
+view()
+CallTreatmentManager(in patientInfo : PatientInfo)
1
1 +EnterDiagnosis() : string
EMR_Database
X-Ray LabResult Prescription

+GetPatients(in physician : string) : PatientInfo 1
-
+view() +view() +view()
Figure 4.2. EMR – Data Analysis Class Diagram
9
Figure 4.3 is a sequence diagram displaying one example use of the system from the
initial login until treatmentManager has finished initializing. Each box at the top represents an
object in the system with an object lifeline protruding from the bottom. This lifeline represents
the objects behavior over time. The solid arrows represent the invocations of the objects
methods while the dotted arrows signify a return from said method.
Sequence Diagram 1 – System login to initialization of TreatmentManager
EMR_DataAnalysisManager: TreatmentManager: treatmentMan HealthSurveillanceSystem:

User manager EMR_Database: database ager surveillance
Login
Initial login GetPatients(physician)
Retrieve
patient <patients>
list
Make a EnterDiagnosis:=EnterDiagnosis()
diagnosis
CallTreatmentManager
confirmDiagnosis
Perform checkForEMRSA
analysis
steps
checkForHAMRSA
GetSensitivityChart
SensitivityChart
Figure 4.3 Sequence Diagram 1
10
Figure 4.4 is a sequence diagram illustrating a scenario in which the treatmentManager
has already been launched. In this example the user views the details of a past treatment, its
resulting artifact, schedules a new treatment and prescribes a medication.
Sequence Diagram 2 – Various Treatment Operations
TreatmentManager: treatmentMan HealthSurveillanceSystem:

ager Treatment: treatment LabResult: labResult PatientHistory: patientHistory HSSystem
confirmDiagnosis()
Analysis steps
checkForEMRSA()
checkForHAMRSA()
getClinicalTrials(diagnosis)
GetSensitivityChart(location)
SensitivityChart
ViewDetails
view
Veiw treatment
details as well as
a lab result
Schedule a new scheduleTreatment(newTreatment)

treatment addTreatment(newTreatment)
addMedication(medication)
Add a
medication
Figure 4.4 Sequence Diagram 2
11
Figure 4.5. (below) is the state diagram for the TreatmentManager class. Each of
the round-tangles represents a possible state of the object. The arrows between these round-
tangles are the transitions by which the object changes states. These transitions are labeled with
the action that causes the transition as well as any conditions that must be satisfied in order for
the transition to occur. Initially whenever the TreatmentManager is launched it enters the
Analyze state. In this state various checks and analyses are performed such as confirming the
user‟s diagnosis and in the event of a MRSA diagnosis determining the type of MRSA the
patient may have. Once these steps are complete the TreatmentManager transitions into the
View Treatment Plan/Progress state. From here the user can view the progress of treatments that
have already been carried out, see a list of upcoming treatments, view a list of relevant clinical
trials, as well as choose to schedule a new treatment for the patient. If the user chooses to view
the progress of a treatment that has already been scheduled the TreatmentManager enters the
Detailed View state and from here the user can view more detailed information about the
treatment as well as any artifacts if the treatment has already been completed. If the user chooses
to schedule a treatment, then the TreatmentManager enters the Schedule Treatment state and the
user can then schedule a new treatment.
Cancel
TreatmentManager
view()[Artifact != NULL] / viewArtifact
View Artifact
Cancel
ViewDetails() Detailed View

Exit
Analysis Complete
View Treatment Plan/Progress
checkForHAMRSA()[diagnosis == MRSA]
getInfo(getInfo)
Analyze
confirmDiagnosis()
scheduleTreatment(treatment)
Cancel
checkForEMRSA()[diagnosis == MRSA]
CallTreatmentManager(patientInfo) addTreatment(treatment)
Schedule Treatment
Figure 4.5. TreatmentManager State Diagram
12
5 Prototype
The prototype will illustrate the interaction between a healthcare provider and the EMR –
Data Analysis system to diagnose a case of a type of MRSA. This process will show how the
doctor will be able to use the EMR – Data Analysis system to create, customize, and maintain a
treatment plan for the specific patient relevant to the diagnosis, along with decision support
provided by the software.
5.1 How to Run Prototype
The prototype will be implemented using Microsoft's Silverlight, version 3. Microsoft

Silverlight is a cross-platform, cross-browser plug-in that is similar to the more widely used
Adobe Flash. Silverlight was used for this application because it allows for easy creation and
customization of rich application user interfaces either directly using XAML encoding or
through a separate program developed by Microsoft (Microsoft's Blend) to facilitate the design
and customization of applications using Silverlight. Silverlight also allows for implementation of
custom interactions within the user interface elements by utilizing code behind files written in
the C# programming language. Another reason for the use of Silverlight is that the default toolkit
of user interface elements provided to design user interfaces is simple and has high aesthetic
value.
In order to run the application, the only requirements are that the user is on a computer
with an updated browser (Firefox, Safari, Internet Explorer, etc.) and that they download a small
(4.3 MB) plug-in when they navigate to the application for the first time. Silverlight is not
platform or browser specific, so there are no hardware, networking or operating system
requirements.
The prototype can be accessed through the web via a link on the team website at
http://www.cse.msu.edu/~cse435/Projects/F09/EMR-Analysis/web/.
13
5.2 Sample Scenario
When a doctor, or any other healthcare provider, starts the prototype he/she will first
encounter the log in screen shown below in Figure 5.1. The doctor will enter his/her user
credentials in the appropriate fields and then click the “Log In” button, which will authenticate
on the main EMR server.
Figure 5.1 – Log In page of prototype
14
Upon logging in to the system, the user will next encounter the home screen shown in
Figure 5.2 below. This home screen will have a table in the upper third of the screen that
contains a list of all patients accessible to the doctor. Below the patient list will be the patient
detail view area. When the doctor selects a patient from the list, the detail view area will show
important information about the selected patient, including: full name, measured height and
weight, any recent vitals measurements, and a brief overview of the patients medical history.
Figure 5.2 – Patient Select page of prototype
15
After the user has selected a patient and has completed any review of information
contained in the detail view, the user can click on the button at the bottom of the screen, which
brings him/her to the diagnosis screen, shown in Figure 5.3. Considering the scope of the project,
Analysis and Decision Support, the design of this page is very simple and consists of a single
text box and a “Next” button. The user will enter his/her diagnosis (as shown in the diagram,
MRSA) in this box and click the button to continue to the next screen.
Figure 5.3 – Diagnosis Entry page of prototype
16
After submitting the diagnosis, the program submits the information to the data server for
cataloging and queries all relevant information on the given diagnosis and patient. The following
screen, labeled the Treatment screen, shown in Figure 5.4, will display the received information
from the previous query for the user to review. Next, we describe each region displayed in
further detail.
Figure 5.4 – Treatment Planning page of prototype
17
The information contained in the table in the top left of the screen, shown in Figure 5.5, is the
“Best Practices” of the corresponding diagnosis. This table lists the most widely accepted
treatment plan for the diagnosis, and indicates, with green check marks, if any of those steps
have been completed for the patient. Any incomplete tasks will be marked with an “X” mark and
highlighted in red. Any tasks in the “Best Practices” list that have been scheduled for the patient,
but have not yet been completed are highlighted in blue with a “?” symbol.
Figure 5.5 – Best Practices status view
In the bottom left of the screen, shown in Figure 5.6, are two tables labeled “Tasks
Completed” and “Tasks Scheduled.”
Figure 5.6 – Completed and Scheduled Treatment status view
18
The first of these tables, Tasks Completed, lists any and all work orders that have been
performed on the patient. The user can select any of the items in this list, and click the “View
Details” button below the table to bring up a window that will display the results and details of
the work order, shown in Figure 5.7.
Figure 5.7 – Completed Task Details view
The second of these tables, Tasks Scheduled, lists all work orders that have been scheduled
for the patient and are pending completion. The user can click “Add Task…” to schedule an
additional task to be completed on the patient, shown in Figure 5.8. The user can also select an
existing scheduled task from the list and click “Remove” to remove the task from the schedule.
Figure 5.8 – Add New Task window
19
In the upper right corner of the screen is a table, illustrated in Figure 5.9, indicating all, if any,
medications to which the patient is currently prescribed. This list alerts the user to any
combination of medications to which the patient has been prescribed that have known side
effects or adverse reactions when taken in conjunction with one other by highlighting the
conflicting drugs in yellow with a “!” caution marker. Selecting a medication and then clicking
the “Remove” button will remove the medication from the patient‟s prescribed medication list.
Figure 5.9 – Current Medication List view
20
Selecting a medication in the list will also enable the “Detail View” button below the list.
Clicking the button will display a window, shown in Figure 5.10, which contains all details of
the medication, including common side effects, known drug-drug conflicts, etc.
Figure 5.10 – Medication Detail view
Below the medication table is an optional section for displaying any relevant clinical trials
associated with the diagnosis, shown in Figure 5.11. Double-clicking a listed trial will navigate
the user to the selected trial's information page. If there are no applicable trials, then this section
will be grayed out and disabled.
Figure 5.11 – Relevant Trials List view
21
6 References
[1] 3Plus EMR. 10 Dec 2009. Scytec Consulting, Inc., Web. 3 Nov 2009.
<http://www.3plus-emr.com/emr.asp>.
[2] Alberta Netcare. 2009. Government of Alberta, Web. 2 Nov 2009.
<http://www.albertanetcare.ca/>.
[3] ClinicalTrials.gov. 07 Apr 2008. National Library of Medicine & Food and Drug
Administration, Web. 14 Nov 2009. <http://www.clinicaltrials.gov>.
[4] "Electronic Health Record." Allscripts. 2009. Allscripts-Misys Healthcare Solutions, Inc.,
Web. 3 Nov 2009. <http://www.allscripts.com/products/electronic-health-
record/default.asp>.
[5] "EMR." SequelMed. 2009. Sequel Systems, Inc. , Web. 2 Nov 2009.
<http://www.sequelmed.com/Products/electronic_medical_records.aspx>.
[6] "EMR Systems: Separating the Wheat from the Chaff." Future Healthcare. 2008.
Analysts In Media, Web. 20 Nov 2009. <http://www.futurehealthcareus.com/?mc=emr-
systems&page=hit-viewresearch>.
[7] "MRSA." Google Health. 2009. Google, Web. 15 Nov 2009.
<https://health.google.com/health/ref/MRSA>.
[8] "PubMed." The diffusion of decision support systems in healthcare: are we there yet?.
Aug 2009. Web. 27 Nov 2009.
<http://www.ncbi.nlm.nih.gov/pubmed/11067416?itool=EntrezSystem2.PEntrez.Pubmed
.Pubmed_ResultsPanel.Pubmed_RVDocSum&ordinalpos=1>.
7 Point of Contact
For further information regarding this document and project, please contact Prof. Betty H.C.
Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this document
have been sanitized for proprietary data. The students and the instructor gratefully acknowledge
the participation of our industrial collaborators.
22

Final BA Book PDF

Uploaded by

Copyright:

Available Formats

Final BA Book PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final BA Book PDF

Uploaded by

Copyright:

Available Formats

What is the role of a business analyst?

What is the role of a business analyst?

What are the main knowledge areas and tasks of a business analyst?

What are the main knowledge areas and tasks of a business analyst?

Jump Start Your Career as a Business Analyst

A Guide for planning career in Business Analysis!

Business analysis is a research discipline of identifying business needs and

Series: Business & Domain Series

Online shop: www.ekapress.org

Swapnil Saurav has more than 14 years of work

experience in IT industry with focus on Supply Chain

Analytics. He is an ambitious, creative and highly

motivated individual, who has a passion for the Supply

Chain with focus on Retail and Manufacturing industries and an uncompromising

commitment to quality and outstanding customer service. He has been invited to be

Research, M.S. (BITS, Pilani) and B.E. (Visvesvaraya Technological University).

Dear Rupali, you made me dream, when I simply

1 GETTING READY FOR CAREER IN BUSINESS ANALYSIS....... 5

Maintain Requirements for Re-use ............................................................ 44

Scenarios and Use Cases ............................................................................. 97

1 GETTING READY FOR CAREER IN BUSINESS ANALYSIS

WHAT IS BUSINESS ANALYSIS

WHAT IS BUSINESS ANALYSIS

WHAT IS BUSINESS ANALYST

IMPORTANCE OF AND NEED FOR A BA ROLE

(c) Where the demand and resources justify, a permanent establishment of

BENEFITS OF HAVING DEDICATED BA

ROLE OF BA IN IT PROJECT DELIVERY

 Facilitate the Elicitation and Analysis of Requirements: Collaborate and

 Assess Proposed System Option and Organisation Readiness for System

Figure 1: BA Activities in SDLC

FINDING YOUR PATH TO BA

Figure 2: Finding your path to BA

Step 1: Build Your BA Knowledge

Step 2: Identify BA Experiences

Step 3: Identify Leverage Points

 Unique Areas of Expertise: What do you bring to the table? It could be

Step 4: Build Your Plan

Step 5 – Focus Your Search

BLUEPRINT FOR SUCCESS STARTING A BUSINESS ANALYST CAREER

PERFORM RESEARCH ON JOB OPPORTUNITIES AND JOB DESCRIPTIONS:

What is Business Analysis?

Business analysis involves understanding how organizations function to

Business analysis may be performed to understand the current state of an

Business analysts must analyze and synthesize information provided by a large

A business analyst is any person who performs business analysis activities, no

As implied by this definition, a requirement may be unstated, implied by or

REQUIREMENTS CLASSIFICATION SCHEME.

The following classification scheme is used by IIBA to describe requirements:

Business Requirements: are higher-level statements of the goals, objectives, or

Stakeholder Requirements are statements of the needs of a particular

Solution Requirements describe the characteristics of a solution that meet

 Functional Requirements describe the behavior and information that the

 Non-functional Requirements capture conditions that do not directly relate

Transition Requirements describe capabilities that the solution must have in

As per IIBA, Knowledge areas define what a practitioner of business analysis

Knowledge areas are not intended to represent phases in a project. It is certainly

Figure 3: BA Knowledge areas

Requirements Management and Communication describes how business