Business Analysis Checklist

8
Business Requirements
Why are we undertaking this project?
Reduce or avoid costs

REQUIREMENTS
Increase revenue CLASSIFICATIONS
Leverage an investment SUPPORT
Establish a new capability
Compliance
Stakeholder Requirements
A stakeholder in the role of ... needs to be able to ... Business Rules
ARE ACHIEVED BY Policies that direct and constrain the organization
Manage something
Order something DIRECT & CONSTRAIN Calculations, determinations
Review and approve something Authorizations, limitations
Initiate something new Triggers, constraints
IMPLEMENTED BY SUPPORT
Track something
Non-Functional Requirements Functional Requirements

MUST COMPLY WITH
Conditions of the environment in which the solution must operate - What must the solution do?
Globalization and localization Add, modify, delete, view

Legal, financial and auditing Search, display
Privacy Compare, transform Transition Requirements
Safety Summarize
Transition from the current state to the future state
Compliance, security and access Copy, send, store, report
User documentation, training and support Readying the business units
Usability and accessibility Data migration
Business continuity Documentation storage
Infrastructure hardware and software Commissioning methodology
Reliability, stability, monitoring Temporary support during commissioning
COLLECTIVELY CALLED
Performance
Support and maintenance Solution Requirements
Licensing
1.800.288.7246
+1.978.649.8200
info@corpedgroup.com
www.corpedgroup.com
© 2014 Phil Vincent
SOLUTION SUBJECT SUBJECT
SCOPE
CONTEXT DIAGRAM USE CASE DIAGRAM BUSINESS PROCESS MODEL
REQUIREMENTS
OR OR
USER PROFILES USER PERSONAS USER STORIES USE CASE DESCRIPTIONS

WORKFLOW MODEL
CONCEPTUAL DATA MODEL
STATE DIAGRAM
DATA DICTIONARY REPORTS WIREFRAMES, STORY BOARDS & PROTOTYPES
OR
NON-FUNCTIONAL FUNCTIONAL
REQUIREMENTS REQUIREMENTS CLASS MODEL BUSINESS RULES
LOGICAL DATA MODEL SPECIFICATION SPECIFICATION

1.800.288.7246 +1.978.649.8200
info@corpedgroup.com www.corpedgroup.com
© 2014 Phil Vincent
Use Case Requirements Validation Checklist
General
□ Unique name
□ Reflects the functional role and purpose of the use case
□ Includes all relevant actors
□ Avoids ambiguities, omissions, and impreciseness
Pre-Conditions
□ Explicit
□ Describes the state of the system when the use case begins, including data that must exist as well as
data that must not exist
□ Captures a valid business situation
Basic Flow
□ Consistent and compliant with relevant business rules
□ Includes only information that is relevant to the use case
□ Includes no references to other use cases that include this use case
□ Includes events in the correct order
□ References named alternate and exception flows at the appropriate points
□ References non-functional requirements that are specific to the use case, as applicable
□ Uses actor names instead of pronouns
□ Avoids the use of adverbs, adjectives, pronouns, synonyms, and negatives
□ Uses the present tense throughout
□ Avoids the use of design terms, such as user interface design or database design terms, including
but not limited to: click, button, screen, record, table, database, process, data, information
Corporate Education Group • 1 Executive Drive, Suite 301 • Chelmsford, MA 01824-2558 • USA
1.800.288.7246 (US only) or +1.978.649.8200 • www.corpedgroup.com
© 2012 Corporate Education Group, operated by Vatterott Educational Centers, Inc. All Rights Reserved.
Alternate Flows
□ Named
□ Comprehensive
□ Correctly state its starting point in the basic flow
□ Last step indicates the returning point within the basic flow
Exception Flows
□ Named
□ Correctly states starting point in the basic flow
□ Comprehensive
Post-Conditions
□ Explicit
□ Captures a valid business situation
□ Describes the state of the system when the use case ends, including data that must exist as well as
data that must not exist
Process: Follow-On Activities
□ Use case and associated documents are considered “final documentation” after sign-off has occurred
 Traceability is updated, up to the applicable test case/script
 Issues are assigned to appropriate parties and if necessary added to the project issue database
 Final documentation is copied and made available in a document repository
Extracted from BA112: Plan, Manage, and Communicate Requirements
Use Case Description Template 2
Purpose
To describe how a person or system interacts with the solution to achieve a certain goal.
Written as a series of steps performed by users, or as a series of steps performed by the solution that
enable the user to achieve a goal, optionally including special circumstances and exceptions that result in
failure to complete the goal.
Possible Format
1. Use Case Name: Unique name (and optionally a unique number) that describes the goal that the use
case will satisfy
1.1 Brief Description: Description of the use case context and scope
1.2 Triggers: The action on the system that starts the use case
2. Actors: Any person, system, or event external to the system that interacts with the system through a
use case, each with a unique name based on its role during the use case interactions
2.1 Actor:
2.2 Actor:
…
3. Pre-Condition(s): Description of the state of the system when the use case begins
3.1 Pre-Condition:
3.2 Pre-Condition:
…
4. Flow of Events (Scenarios): Descriptions of what an actor does during execution of the use case
4.1 Basic Flow, or Main Success Scenario: A typical series of steps that accomplishes the primary
actor’s goal
4.1.1 Step of the Basic Flow
4.1.2 …
4.2 Alternate Flows: Variants from the basic flow that must be addressed
4.2.1 Condition 1
4.2.1.1 Step of Alternate Flow 1
4.2.1.2 …
4.2.2 Condition 2
4.2.2.1 Step of Alternate Flow 2
4.2.2.2 …
4.3 Exception Flow: Conditions that cause the use case to terminate in a manner that is different
from the successful termination of the basic flow
4.3.1 Condition 1
4.3.1.1 Step of Exception Flow 1
4.3.1.2 …
4.3.2 Condition 2
4.3.2.1 Step of Exception Flow 2
4.3.2.2…
5. Post-Condition(s): Any fact that must be true when the use case is complete
5.1 Post-Condition:
5.2 Post-Condition:
…
6. Extension Points: A link to another use case(s), which is triggered because the main success
scenario can be interrupted in one or more ways, and the main success scenario is not in control of these
interruptions
6.1 Extension Point:
6.2 Extension Point:
…
7. Special Requirements: Technology and data variations. The steps of the use case are the same, but
how it is done can vary because of technology variations or differences in the data that must be captured.
7.1 Special Requirement:
7.2 Special Requirement:
…
Extracted from BA114: Model and Document Your Project Requirements
Use Case Description Template 1
Purpose
To describe how a person or system interacts with the solution to achieve a certain goal.
Written as a series of steps performed by users, or as a series of steps performed by the solution that
enable the user to achieve a goal, optionally including special circumstances and exceptions that result in
failure to complete the goal.
Possible Format
Use Case Name: Unique name (and optionally a unique number) that describes the goal that the use
case will satisfy
Actor: Any person, system, or event external to the system that interacts with the system through a use
case, each with a unique name based on its role during the use case interactions
Pre-Condition: Description of the state of the system when the use case begins, such as:
 User must be logged in
 Item must exist in catalog
Flow of Events: Descriptions of what an actor does during execution of the use case:
 Basic Flow, or Main Success Scenario: A typical series of steps that accomplishes the primary
actor’s goal
 Alternate Flow: Variant from the basic flow that must be addressed
 Exception Flow: Conditions that cause the use case to terminate in a manner that is different
from the successful termination of the basic flow
Post-Condition: Any fact that must be true when the use case is complete
Traceability Worksheet
1. Identify requirements artifacts that will be traced to other requirements artifacts.
Example: Business objectives to use cases
2. How to implement and maintain traceability. (Optional)
[Indicate the number of matrices that you will manage and the preferred structure of the matrices.
Estimate the size of each of the matrices, and describe how you will manage them; for instance, will you
buy a specific tool? Who will be trained to use the tool? Who will be responsible for keeping the
requirements traceability matrix (RTM) up-to-date?]
Stakeholder Analysis Template 2
Stakeholder Role Potential of Stakeholder as a Source of Requirements
Extracted from BA111: Core Competencies for the Business Analyst
Stakeholder Analysis Template 1
Stakeholder Group/
Project Role Description Category* 1 Category 2 Category 3 Category 4
Name Organization
*Select the number and types of categories to be employed based on the needs of your project, such as the following examples:
 Role in Requirements Processes
 Potential of Stakeholder as a Source of Requirements
 Priorities/Criteria for Success
 Risk Tolerance
 Key Issues
 Geographical Area
Risk Response Worksheet
Risk Probability Impact Risk Score
Actions to take to prevent the

risk from occurring, or to
reduce the likelihood that it
will occur
Actions to take to lessen the

impact if the risk does occur
Risk Log Template 2
Possible
Risk
Risk Responses - Selected
Description P I Score Status Owner
# Descriptions of Response
(P * I)
Approaches
Risk Score: Probability (P) multiplied by Impact (I)

Status: Open or Closed
Risk Responses: Avoid, Mitigate, Transfer, Accept
Risk Log Template 1
Risk
Date
Risk # Description P I Risk Score Response Status
Identified
Strategy
Risk Score: Probability (P) multiplied by Impact (I)

Status: Open or Closed
Risk Response Strategies: Avoid, Mitigate, Transfer, Accept
Requirements Review Log
Project Review Participants and Roles
Document Name Role

Review Date/Time Author
Review Location Scribe
Moderator
Peer
Reviewer
Reviewer
Page / Section Description Category Priority
Priority:
 High
 Medium
 Low
Category:
 Question/Comment
 Error/Defect
Requirements Management Plan Template
1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Definitions and Acronyms
2.0 REQUIREMENTS MANAGEMENT

2.1 Stakeholder Roles and Responsibilities
Name / Title Requirements Process Role


2.2 Processes and Techniques

2.2.1 Elicitation
2.2.1.1 Inputs
2.2.1.2 Techniques
2.2.2 Requirements Analysis and Documentation

2.2.2.1 Outputs
2.2.2.2 Techniques
2.2.3 Requirements Communication

2.2.3.1 Inputs
2.2.3.2 Techniques
Corporate Education Group • 1 Executive Drive, Suite 301 • Chelm sford, MA 01824-2558 • USA
2.3 Activities
2.3.1 Milestones
2.3.2 Tasks, Estimates, Resources
Task Resources Required: Time Estimate Per Resource


2.3.3 Tools
2.3.4 Assumptions
2.3.5 Reports and Measures

2.3.5.1 Traceability
2.3.5.2 Attributes
2.3.5.3 Requirements Stability Report
3.0 CHANGE MANAGEMENT

3.1 Purpose of Change Management
3.2 Change Request Form
3.3 Change Management Roles and Responsibilities
Names / Titles Role in Change Management Process

Initiate change request
Assess impact
Administers change management process
Change Control Board (CCB) member
Informed of changes
Corporate Education Group is operated by TechSkills LLC. © 2011 Corporate Education Group
3.4 Process Steps
3.5 Emergency Procedures
3.6 Measures and Reports
4.0 RISK MANAGEMENT

4.1 Roles and Responsibilities
Name / Title Risk Management Role


4.2 Preliminary Risks
5.0 TRAINING AND RESOURCES
Corporate Education Group • 1 Executive Drive, Suite 301 • Chelm sford, MA 01824-2558 • USA
Requirements Management Plan Checklist
Introduction
□ Includes the purpose of the requirements management plan
□ Defines the scope of the document
□ Addresses planning considerations based on organizational and project methodology
□ Includes definitions of terms and acronyms

Requirements Management
□ Lists stakeholders’ names, titles, and roles in the requirements process
□ Includes processes and techniques that will be used to elicit, analyze, and document requirements
□ Lists requirements related milestones
□ Lists requirements related tasks (discrete units of work) along with assigned resources and effort estimates
□ Describes tools used for requirements related tasks/techniques
□ Lists assumptions related to requirements
□ Describes the approach to tracing requirements back to business objectives
□ Describes the requirements attributes to be documented
□ Describes the requirements reports to be produced
□ Describes the requirements metrics to be captured

Change Management
□ Describes the steps in the change management process that suit the size and complexity of the project
□ Defines change management process roles and responsibilities

Risk Management
□ Lists stakeholders involved in risk management activities
□ Describes preliminary project risks

Training and Resources
□ Describes personnel and training required for requirements management activities

Communication
□ Includes activities and techniques that will be used to communicate with stakeholders
Requirements Attribute Table
Use Approver
Source Date Planned Verification Test Case
# Description Type Case of Planned Priority
(individual/group) Identified Release Method Numbers
ID Release
RACI Matrix Template
Person [Stakeholder] [Stakeholder] [Stakeholder] [Stakeholder] [Stakeholder]
Deliverable
Deliverable 1:
Deliverable 2:
Deliverable 3:
Deliverable 4:
Deliverable 5:
Code Stands for This is the person who ….
R Responsible Is the primary Subject Matter Expert (SME) who will take responsibility for
ensuring that the requirements are expressed correctly.
A Accountable Makes the final decision or approves the specifications.
C Consult Provides the requirements. These SMEs can be consulted by the business
analyst or the responsible SME.
I Inform Is informed after the final decision is made and can include stakeholders such
as designers, testers, project steering committee, etc.
RACI Chart Template
Task/Person
Code Stands for This is the person who is….
R Responsible Responsible for performing the task or creating the document

A Accountable Accountable for the task or document such as the project
manager, supervisor , or technical lead
S Supports Provides support for the task, such as materials or documents
(for RASCI chart)
C Consult Provides consulting or expertise to the person responsible for
the task or document and others.
I Inform Informed of task progress or results, usually by the person
responsible.
Extracted from BA113: Collaborate with Stakeholders to Elicit Requirements
Interview Log Template
Interview Date,
Time, Location
Stakeholder
(Interviewee)
Stakeholder’s
Job Title and
Role
Scribe
Objective of the
Interview
Questions and Questions:
Responses
Where
appropriate,
categorize
response as:
Notes:
 Potential
Requirement
 Assumption
 Constraint
Materials (References to samples of any forms, reports, documents, policies, standards, or

Discussed procedures referred to or discussed during the interview)
Performance- (Notes regarding performance-related information, such as information about volume

Related of transactions or documents, capacity, and quality)
Information
Summary
Information Requirements Worksheet
Data Mandatory, Input,

Maximum Allowed
Element Screen Label Data Type* Optional, or Output, or Description
Length Values
Name Conditional Both
*Data Types: Text, Number, Money, Date
Document Analysis Template
Document Version Relevant

# Date Author Source Location Accuracy/Currency
Name Number Information*
*Record and categorize relevant information:

a. Current problem, issue, or constraint
b. Current policy, procedure, or process
c. Current regulation
d. Current business rule
e. Potential new requirement
f. Organizational objective or vision
Document Analysis Log Template
Document Version Relevant

# Date Author Source Location Accuracy/Currency
Name Number Information*
*Record and categorize relevant information:

a. Current problem, issue, or constraint
b. Current policy, procedure, or process
c. Current regulation
d. Current business rule
e. Potential new requirement
f. Organizational objective or vision
Data Dictionary Template
Entity:
Attribute Name Description Data Type Maximum Length Minimum Value Maximum Value Allowed Values
Data Types: Text, Number, Money, Date
Communication Plan Template
Purpose of Delivery Presentation Documentation Level of

Activity Audience When Where
Communication Method Method Formats Formality
Delivery methods:
 One-on-one meeting (face-to-face/telephone)
 Group meeting (collocated/virtual)
 Document distribution (hardcopy/e-mail/shared repository)
Presentation methods:
 Verbal
 Visual presentation
 Handouts
Documentation formats:
 Text
 Tables
 Diagrams
 Models (may combine text, tables, and diagrams)
Level of formality:
 Formal
 Informal
Communication Needs Template
Stakeholder Role Role in Requirements Processes Communications Needs Proposed Communication Methods
(“Why” does this individual need to (“What” information does this (“How” can I best communicate
know about requirements?) individual need to know about requirements to this individual?)
requirements?)
Change Request Form 2
Project Information
Project Name Current Phase
Project Manager Project Sponsor
Change Request Information

Date of Request Type of Request Addition
Modification
Deletion
Source Date of Status Change
Description
Rationale
Change Request Form 2 (continued)
Impact Analysis
Contributors
Description of Impact
Priority
Cost of Change
Effort to Implement
Requirements Impacted
Schedule Impact
Risk
Disposition
Date of Disposition
Disposition Decision
Approved
Denied
Postponed
Returned for additional analysis of impact
Disposition Comments
Change Request Form 1
Project Information
Project Name Current Phase
Project Manager Project Sponsor
Change Request Information

Date of Request / / Type of Request □ Addition
Description □ Modification
Source □ Deletion
Rationale Date of Status Change / /
Impact Analysis
Contributors
Description of Impact
Priority
Cost of Change
Effort to Implement
Requirements
Impacted
Schedule Impact
Risk
Change Request Form 1 (continued)
Disposition
Date of Disposition / /
Disposition Decision □ Approved

□ Denied
□ Postponed
□ Returned for additional analysis of impact
Disposition Comments
Closure
Distribution List
Documentation
Updates Required
Business Case Template
1. Executive Summary
2. Introduction and Summary
a. Rationale for Preferred Option
b. Current Business Process
c. Description of the Problem
d. Opportunity
e. Project Objectives
f. Project Scope
g. Business Benefits
h. Project Costs
i. Assumptions
j. Analysis of Potential Impact on Business and Staff
k. Analysis of Potential Impact on Technology
l. Other Issues
m. Implementation Plan
3. Approach
a. Financial Metrics
b. Assessment of Impact on Privacy
c. Criteria for Evaluating Alternatives
4. Key Selection Criteria
a. Weighting
b. Constraints and Limitations
5. Preferred Alternative
a. Business Benefits
b. Costs
c. Assumptions
d. Analysis of Potential Impact on Business and Staff
e. Other Issues
6. Risk Management Plan
a. Risk Assessment
b. Risk Response
c. Benefit Realization
7. Conclusion and Recommendations
Brainstorming Agenda Template
Session
Objectives
Participants
Agenda 1. Introduce rules and objectives (10 minutes).

a. Review ground rules (Example):
 We recognize that all ideas are valuable and we will keep an open mind.
 We will agree to and stay focused on the objectives of the session.
 We recognize the need to respect and trust each other.
 We will try not to interrupt.
 We will accept everyone’s opinion as neither right nor wrong, just as
their opinion.
 We welcome all questions.
 We will follow the time allotments listed in the agenda.
 We will consider additional ground rules identified at the start of the
session.
b. Obtain agreement on session objective.
2. Share ideas (60 minutes, or approximately half the session time).
3. Prioritize and select requirements (60 minutes, or approximately half the
session time).
Business Analyst and Project Manager Planning Tasks (By Plan Type) Worksheet
Plan Type Business Analyst Planning Tasks Project Manager Planning Tasks
Scope
Management
Process
Improvement
Schedule
Management
Quality
Management
Communications
Management
Risk
Management
Staffing
Management
Procurement
Management
Cost
Management

Business Analysis Checklist

Uploaded by

Copyright:

Available Formats

You might also like

Business Analysis Checklist

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis Checklist

Uploaded by

Copyright:

Available Formats

8

Reduce or avoid costs

Non-Functional Requirements Functional Requirements

Globalization and localization Add, modify, delete, view

CONTEXT DIAGRAM USE CASE DIAGRAM BUSINESS PROCESS MODEL

USER PROFILES USER PERSONAS USER STORIES USE CASE DESCRIPTIONS

DATA DICTIONARY REPORTS WIREFRAMES, STORY BOARDS & PROTOTYPES

LOGICAL DATA MODEL SPECIFICATION SPECIFICATION

□ Reflects the functional role and purpose of the use case

□ Includes all relevant actors

□ Avoids ambiguities, omissions, and impreciseness

□ Captures a valid business situation

□ Consistent and compliant with relevant business rules

□ Includes only information that is relevant to the use case

□ Includes events in the correct order

□ References named alternate and exception flows at the appropriate points

□ Uses actor names instead of pronouns

□ Avoids the use of adverbs, adjectives, pronouns, synonyms, and negatives

□ Uses the present tense throughout

□ Correctly state its starting point in the basic flow

□ Correctly states starting point in the basic flow

□ Captures a valid business situation

Process: Follow-On Activities

Extracted from BA112: Plan, Manage, and Communicate Requirements

Extracted from BA114: Model and Document Your Project Requirements

Extracted from BA114: Model and Document Your Project Requirements

1. Identify requirements artifacts that will be traced to other requirements artifacts.

Example: Business objectives to use cases

2. How to implement and maintain traceability. (Optional)

Extracted from BA112: Plan, Manage, and Communicate Requirements

Stakeholder Role Potential of Stakeholder as a Source of Requirements

Extracted from BA111: Core Competencies for the Business Analyst

Extracted from BA112: Plan, Manage, and Communicate Requirements

Risk Probability Impact Risk Score

Actions to take to prevent the

Actions to take to lessen the

Extracted from BA112: Plan, Manage, and Communicate Requirements

Risk Score: Probability (P) multiplied by Impact (I)

Extracted from BA112: Plan, Manage, and Communicate Requirements

Risk Score: Probability (P) multiplied by Impact (I)

Extracted from BA112: Plan, Manage, and Communicate Requirements

Project Review Participants and Roles

Document Name Role

Review Location Scribe

Page / Section Description Category Priority

Extracted from BA112: Plan, Manage, and Communicate Requirements

1.3 Definitions and Acronyms

2.0 REQUIREMENTS MANAGEMENT

Name / Title Requirements Process Role

2.2 Processes and Techniques

2.2.2 Requirements Analysis and Documentation

2.2.3 Requirements Communication

2.3.2 Tasks, Estimates, Resources

Task Resources Required: Time Estimate Per Resource

2.3.5 Reports and Measures

2.3.5.3 Requirements Stability Report

3.0 CHANGE MANAGEMENT

3.2 Change Request Form

3.3 Change Management Roles and Responsibilities