Skip to content

Step 8 - Business Worfklow Spec (BWS)

Purpose

Document the real-world business workflow required to achieve a selected Outcome defined in the PRD.

This step exists to describe what the business does, who does it, and how work progresses through decisions and exceptions — without introducing system behavior, UI steps, or technical implementation.


When To Run This Step

This step is executed by a person after a Product Requirements Document (PRD) has been completed and approved.

Run this step when:

  • Stage 3 has produced an approved PRD
  • The business workflow for the selected Outcome needs to be explicitly defined
  • Domain modeling and SDD work require a clear, shared understanding of business operations

This step must not run if:

  • A PRD does not exist
  • Business requirements are still unclear or unstable
  • The team is attempting to design systems, screens, or technical flows

Inputs (Required)

  • An approved Product Requirements Document (PRD)
  • A single Outcome selected from the PRD

Prompt to Run

  • Prompt Name: Business Workflow Specification (BWS) Generator
  • Prompt Version: v1.0
  • Prompt Location: BWS Generator

Instruction: Run the BWS prompt using the approved PRD as input and focus on documenting the real-world business workflow for the selected Outcome.

Describe only business actions, decisions, roles, inputs, and outputs. Do not include system behavior or implementation detail.


Outputs (Produced)

The step produces a Business Workflow Specification (BWS) containing:

  • Outcome reference
  • Business actors and roles
  • Required business inputs
  • Step-by-step business workflow
  • Decision points and branches
  • Business exceptions
  • Business outputs and results

The output must strictly follow the BWS template.


Artifact Storage

Store the BWS in the predefined system of record selected during setup.

  • One BWS per approved Outcome
  • One primary storage location only
  • The artifact must be referenceable
  • Ownership must be clear

Validation Rules

The BWS is valid only if:

  • All steps describe business actions, not system behavior
  • Roles and responsibilities are explicit
  • Decisions and branches are clearly defined
  • Exceptions represent business deviations, not technical errors
  • Inputs and outputs are business artifacts
  • Missing information is explicitly marked as TBD

The BWS is invalid if it:

  • Includes UI interactions or system steps
  • Introduces technical assumptions or solutions
  • Rewrites or alters the approved Outcome
  • Collapses multiple business actions into vague steps

Invalid BWS artifacts must be corrected before proceeding.


Decision Gate

Question: Is the business workflow fully and unambiguously documented in business terms?

Outcomes:

  • Yes: Proceed to domain modeling and Strategic Domain Design
  • No: Gather missing workflow details and revise the BWS

No other outcomes are allowed.


Failure Modes & Anti-Patterns

  • Treating the workflow as a system flow or UI sequence
  • Describing what software does instead of what people do
  • Skipping decision logic or exceptions
  • Inventing steps without business confirmation
  • Using technical language to explain business actions

If the workflow is inaccurate or polluted with system thinking, downstream design will be flawed.


Traceability

  • Previous: Stage 3 — Product Requirements Document (PRD)
  • Next: Stage 3 — Domain Modeling / SDD
  • Consumes: Product Requirements Document (PRD)
  • Produces: Business Workflow Specification (BWS)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned