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