A Simulationist's Framework
for Business Analysis

Part 01:

Requirements Traceability

R.P. Churchill

CBAP, IIBA-CBDA, PMP, CSPO, CSM
Lean Six Sigma Black Belt

www.rpchurchill.com/presentations/BAseries/01_RTM www.rpchurchill.com | Portfolio | Presentations

30 Years of Simulation

Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.

30 Years of Simulation

Industries

Paper (Chemical/Process)
Nuclear (Power Generation)
Metals (Steel, Non-Ferrous)
HVAC (Building Control)
Insurance, Banking, Legal
Security, Inspections
Passenger Processing
Medical Facilities
Evacuations
Area Control
Threat Response
Logistics, Supply
Maintenance and Reliability
Staff Level Determination
Fleet Management

Applications

Design and Sizing
Operations Research
Real-Time Control
Operator Training
Risk Analysis
Economic Analysis
Impact Analysis
Process Improvement (BPR)

Architectural Considerations

Continuous vs. Discrete-Event
Interactive vs. Fire-and-Forget
Real-Time vs. Non-Real-Time
Single-Platform vs. Distributed
Deterministic vs. Stochastic

The Framework:

Project Planning
Intended Use
Assumptions, Capabilities, and Risks and Impacts
Conceptual Model (As-Is State)
Data Sources
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)
Fitness for Purpose (Validation)

Acceptance (Accreditation)
Project Close

Keep in mind that...

You should be aware of the entire process as a whole

...even if you don't participate in every part of it.

You should understand and plan for how each phase is going to be conducted and tracked right from the beginning.

DevOps is one approach, but it's not the only one.

The Framework: Simplified

Intended Use
Conceptual Model (As-Is State)
Data Sources
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)
Fitness for Purpose (Validation)

Data Collection and Integration

Data fits into the process in roughly the same way in every context.

I identify three (or is that four?) kinds of data:

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.

Basic Engagement Structures

Link to detailed discussion.

Engagement Structure Variations

Link to detailed discussion.

So What Are We REALLY Doing?

Whatever form your effort takes, it effectively ends up like this.

Embodies communication, feedback, clarification, and correction.

HOT TAKE: Agile and Scrum are a scam!

I'm being a little hyperbolic here, but the point is that this isn't new (and wasn't in the late-90s).
Ensure that communication, development, and integration and testing is continuous.
Even the people who created the Agile Manifesto assert that Agile is Dead.
Don't get bogged down in specific, formal processes.
If you're trying to force your process to be rigorously "by the book" -- you're doing it wrong.

Customer Feedback Cycle

Review every phase with the customer until they agree it's correct, especially for the Conceptual Model (As-Is State).

Needs discovered later could require the creation of earlier elements.

Link to detailed discussion.

So How Do Make Sense Of All This?

We have a question outstanding from a couple weeks ago:

How do we identify requirements that ensure we solve the actual problem?

Requirements Traceability Matrix

Best represented by a relational data structure but any method will work.

Needs discovered later could require the creation of earlier elements.

Methodological requirements (at bottom) can each be thought of as a kind of non-functional requirement that doesn't need to be mapped.

Link to detailed discussion.

Breaking Things Down

Breaking larger items down into smaller ones is always going to happen.

This can happen anywhere from the Requirements phase to the Test phase.

The question is what do you call them? Epics, features, and tasks are just one possible breakdown, but others involve different kinds of tests, documentation, graphics and art, design reviews, and anything that might involve a different specialist.

How Do We Track This Stuff?

Any method that works is appropriate.

The level of formality should increase with the scope and complexity of the project.

Shareability is highly desirable.

Spreadsheets, word-processing documents, custom databases (with custom queries), post-its on bulletin boards, and other methods can reasonably be used.

Items in different phases may require different fields.

All items need things like titles, text descriptions, and links to items in other phases.

Methods will ideally be able to represent one-to-many, many-to-one, and many-to-many relationships.

A consistent coding system should be used to give further context to each item.

How Do We Track This Stuff? (cont'd)

There's a tension between representing assignable and trackable tasks and representing the context of items within the framework.

This representation shows the status of items in each phase.

How Do We Track This Stuff? (cont'd)

This representation shows each item in its context within the framework.

It shows items and connections, but not status (though that could be added).

Maintaining bi-directional links is kind of painful, so links should be one way. I prefer backwards.

As each item is created, it suggests the downstream items that could be created automatically.

There are two definitions of done for each item: the completion and approval of the item itself, and the completion and approval of all connected, downstream items.