A Simulationist's Framework
for Business Analysis

Basic Framework Summary

R.P. Churchill

Lean Six Sigma Black Belt

www.rpchurchill.com | Portfolio | Presentations
The Framework:
  • Project Planning
  • Intended Use
  • Assumptions, Capabilities, Limitations, and Risks and Impacts
  • Conceptual Model (As-Is State)
  • Data Sources, Collection, and Conditioning
  • Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  • Design (To-Be State: Detailed)
  • Implementation
  • Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose (Validation)
  • Acceptance (Accreditation)
  • Project Close
The Framework: Simplified
  •   Intended Use
  •   Conceptual Model (As-Is State)
  •   Data Sources, Collection, and Conditioning
  •   Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  •   Design (To-Be State: Detailed)
  •   Implementation
  •   Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose (Validation)
Basic Engagement Structures

Link to detailed discussion.

Engagement Structure Variations

Link to detailed discussion.

Continuous Iteration and Correction

Regardless of the structure of the engagement, the activities in each phase are carried out in an iterative fashion that continuously incorporates review, feedback, and correction both within and between phases.

Link to detailed discussion.

Phase Template

Items are tracked through each phase until they are completed.

Hierarchical information is embedded in each phase. Only the lowest-level items get individually tested, approved, and passed to subsequent phases.

Items can be created in each phase from items in the previous phase and in response to recognized omissions in subsequent phases.

Review and approval can involve many individuals and groups serially and in parallel.

Tracking Across the Engagement

Items are tracked using a Requirements Traceability Matrix.

Omissions recognized in later phases can cause items to be created in earlier phases.

Procedural requirements may apply to each phase.

Link to detailed discussion.

Project Planning

Sets up and kicks off the project using traditional project management techniques.

Considers intended management framework (Waterfall, Agile, Kanban, etc.) and special requirements for the effort (existing assets/PMO, identify stakeholders).

In classical project management terms this is where you do the charter, build the team, work out the communication plan, and so on.

This step is bookended by a Project Closeout step at the end of the effort.

Project Planning (cont'd)

What we generally think of as BA work happens within the Executing and Controlling phases of the PM framework.

The representation shown is notional. The Executing and Controlling phases are continuous and intertwined, so it's not like some BA phases happen in Executing and others in Controlling.

BAs can absolutely be part of all the Planning and Closing activities — and should be.

Link to detailed discussion.

  Intended Use

This defines the customer's goals for what the new or modified process, system, or product will accomplish.

It may describe technical and performance outcomes but must ultimately be expressed in terms of business value.

Each goal can be described in terms of:

  • Key Questions - questions to be answered
  • Application - decisions to be made
  • Outputs and Data - specific outputs to be generated

This information is included in the Project Charter from the PMBOK.

Assumptions, Capabilities, Limitations, and Risks & Impacts

Define the scope of the project and what capabilities and considerations will and will not be included.

Describe the risks inherent in the effort and the possible impacts of risk items occurring.

Reasons to omit features and capabilities:

  • Outside of natural or organizational boundaries
  • Insufficient data or understanding
  • Impact on results is small (benefit not worth cost)
  • Components aren't active in modes being investigated

Sometimes assume values when data can't be had, rather than omit an effect.

Really happens before, during, and after the Conceptual Model phase.

Assumptions, Capabilities, and Risks & Impacts (cont'd)

One way to think about (simplifying) assumptions as zeroing out terms in an equation when they don't apply.

  Conceptual Model (As Is State)

If an existing process is to be modified, improved, or automated, discover all operations and data items. This defines the As Is State. (In simulation this is known as building a Conceptual Model.)

If there is not an existing process, work backwards from the desired outcomes to determine what operations and data are required.

Map out the discovered process and document and collect data and parameters for each operation and communication.

The conceptual model is not a specific type of drawing, but is a representation of an existing system using any appropriate techniques.

Iteratively review maps, data, and descriptions with customers and SMEs until all agree that understanding is accurate and complete!

Customer Feedback Cycle

Agile is Dead (in a rigorously formal sense)

  Conceptual Model (As Is State) (cont'd)

This is where BAs learn what they don't know.

Techniques used in this phase include subject matter expert (SME) interviews, document reviews, observation, training, research, guided tours, and experimentation.

I brought a particular (not quite Liam Neeson-like) set of skills to my first jobs, but I've continued to learn every day since.

  • Some domains require specialized knowledge, others can be learned more easily.
  • Here's where having a good personality and good communication is most important. Show respect to and interest in those you're learning from.
  • What skills have you brought to your work as a BA? What have you learned? What would you like to learn?

Learning in a new field is called Domain Knowledge Acquisition.

  Data Sources, Collection, and Conditioning

Refers to input items (nouns) processed, and parameters (adjectives) that describe the operation and characteristics of the system.

Map sources, sinks, and messages to the Conceptual Model.

Data sources (or assumptions) must be found that support the generation of all required output data items. Trace backwards from desired outputs to required inputs and calculations.

Items must be validated for accuracy, authority, and obtainability.

Interfaces should be abstract initially (e.g., with management and through initial discovery and scoping), and then detailed in design and implementation with proper SMEs.

Ensure that data and flags, states, formats, and metadata are captured in sufficient detail. Work with implementation SMEs as needed.

Link to detailed discussion

Data Collection and Integration
  • System Description: data that describes the physical or conceptual components of a process (tends to be low volume and describes mostly fixed characteristics)
  • Operating Data: data that describe the detailed behavior of the components of the system over time (tends to be high volume and analyzed statistically)
  • Governing Parameters: thresholds for taking action (control setpoints, business rules, largely automated or automatable)
  • Generated Output: data produced by the system that guides business actions (KPIs, management dashboards, drives human-in-the-loop actions, not automatable)

Links to detailed discussions.

  Requirements (To-Be State: Abstract)


  • What the system DOES
  • Describes components, behaviors, entities, actions, inputs, and outputs.
  • Contains the details of the design the user sees and the mechanisms that generate results.


  • What the system IS
  • Describes qualities (in terms of "-ilities," e.g., reliability, modularity, flexibility, robustness, maintainability, scalability, usability, and so on).
  • Describes how the system is maintained and governed.
  • Describes how the system is hosted.

The requirements include the criteria by which functional and non-functional elements will be judged to be acceptable. (Definition of Done)

  Design (To-Be State: Concrete)

The design of the solution is a description of how the solution will be implemented and what resources will be required.

The design should also include plans for maintenance and governance going forward.

Design is more about the solution than the engagement.

This represents the To-Be State in concrete terms.


This phase is where the implementation is actually carried out, based on the design.

Implementation also means deployment.

Alternatively, deployment and delivery, and even handover and training, could be considered to be a new phase after testing, depending on the situation.


Operation, Usability, and Outputs (Verification)

  • Tests to ensure the system operates as intended and produces outputs accurately from the inputs and calculations.
  • This process ensures that the system:
    • makes sense to the users
    • enables manipulation of all relevant elements
    • prevents and corrects errors
    • maintains users' situational awareness
    • includes documentation, training, and help
  • These types of tests are most able to be automated.

Outputs and Fitness for Purpose (Validation)

  • Tests to confirm that the results produced are targeted to the problem under investigation.
  • Ensures simulation behavior matches real-world system for known cases.
  • Validation of results may be:
    • Objective, e.g., measured comparisons to known values in a simulation or calculation
    • Subjective, e.g., judged as "correct" by SMEs for novel situations and realizations of business value
  • These types of tests are most likely to require expert judgment.

Link to detailed discussion.

  Test (cont'd)

Specialized test SMEs may conduct the majority of system testing, but implementers, managers, customers, maintainers, and end users should all be involved.

Provisions for testing, V&V, and quality should be built into the process from the beginning.

Link to detailed discussion.

Acceptance (Accreditation)

This phase ensures that the customer's plans and criteria for acceptance are met. All of the stated acceptability criteria must be addressed.

This plan must include the process for handing the system or process over to the customer (internal or external). This process may include documentation, training, hardware, software, backups, licenses, and more.

The customer is the final judge of acceptance and may make three judgments:

  • Full Acceptance
  • Partial Acceptance with Limitations
  • Non-Acceptance
Project Close

This phase bookends the Project Planning phase.

Ongoing projects and programs may effectively never have a closing phase, but this usually only applies to in-house efforts.

Work performed for third parties usually has a defined endpoint.

The Solution vs. The Engagement

How much of either process are you a part of?

Link to detailed discussion.

The 50 Techniques
1Acceptance and Evaluation CriteriaSolution
2Backlog ManagementEngagement
3Balanced ScorecardEngagement
4Benchmarking and Market AnalysisEngagement
6Business Capability AnalysisEngagement
7Business CasesBoth
8Business Model CanvasBoth
9Business Rules AnalysisSolution
10Collaborative GamesEngagement
11Concept ModellingSolution
12Data DictionarySolution
13Data Flow DiagramsSolution
14Data MiningSolution
15Data ModellingSolution
16Decision AnalysisSolution
17Decision ModellingSolution
18Document AnalysisSolution
20Financial AnalysisBoth
21Focus GroupsSolution
22Functional DecompositionSolution
24Interface AnalysisSolution
26Item TrackingEngagement
27Lessons LearnedEngagement
28Metrics and KPIsSolution
29Mind MappingSolution
30Non-Functional Requirements AnalysisSolution
32Organizational ModellingSolution
34Process AnalysisSolution
35Process ModellingSolution
38Risk Analysis and ManagementBoth
39Roles and Permissions MatrixSolution
40Root Cause AnalysisSolution
41Scope ModellingBoth
42Sequence DiagramsSolution
43Stakeholder List, Map, or PersonasEngagement
44State ModellingSolution
45Survey or QuestionnaireBoth
46SWOT AnalysisBoth
47Use Cases and ScenariosSolution
48User StoriesSolution
49Vendor AssessmentBoth
Solution: 30     Engagement: 11     Both: 9

Link to detailed discussion.

Software Tools
5Azure DevOpsSolution
4Team Foundation ServerEngagement
3Google DocsEngagement
2MS DynamicsEngagement
2Visual StudioSolution
2SQL ServerSolution

Software greatly aids sharing and communications, so BAs will concentrate on this. However, a huge amount of solutioning will be aided by specific, technical software or will be software, with which BAs will tend to be less involved.

Link to detailed discussion. Link to survey results.

Extended Project / Program / Product Framework

Once a system is implemented, deployed, and accepted, it may be used, maintained, and modified over a long period of time, until it is removed and possibly replaced.

Ongoing modifications to an existing system will involve engagements with an existing As Is state which may have to be "re-discovered."

Ideally, ongoing work will be integrated and linked into the original project's core documentation.

  •   Operation and Maintenance
  •   End-of-Life and Replacement

Link to detailed discussion.

Structure of the BABOK
  • Chapter 1: Introduction (structure of the BABOK)

  • Chapter 2: Key Concepts (basic context of business analysis)

  • Chapters 3-8: Knowledge Areas (the basic flow of what gets done)

  • Chapter 9: Underlying Competencies (Analysis, Behavior, Domain Knowledge, Communication, Interaction, Tools/Tech)

  • Chapter 10: Techniques (50)

  • Chapter 11: Perspectives (Agile, BI, IT, Business Architecture, Process Management)

  • Appendices

BABOK Knowledge Areas vs. Bob's Framework
Bob's Framework Business Analysis Planning and Monitoring Elicitation and Collaboration Requirements Life Cycle Management Strategy Analysis Requirements Analysis and Design Definition Solution Evaluation Requirements per BABOK
Project Planning X x
Intended Use x X x x x Business Requirements
Assumptions, Capabilities, Limitations, and Risks & Impacts x X x
Conceptual Model
(As-Is State)
x X X
Data Sources, Collection, and Conditioning x X
(To-Be State: Abstract)
x X X x X Stakeholder Requirements
(To-Be State: Concrete)
x x X X Solution Requirements
(Functional and Non-Functional)
Implementation x X x X x x Transition Requirements
Test Operation, Usability, and Outputs
x X
Test Outputs and Fitness for Purpose
x x X
x X

This presentation and other information can be found at my website:


E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill