Skip to content

Business Workflow Specification (BWS)

Stage: Stage 3 - Strategic Domain Design

Artifact Code: BWS

1. Purpose

The Business Workflow Specification (BWS) exists to document how the business actually performs work for a specific approved Outcome.

It captures business actions, decisions, handoffs, and exceptions independent of technology, creating a shared, stable understanding of the real-world process.

The BWS is the authoritative source for how work flows in the business - not how systems behave.

2. Decision This Artifact Supports

Decision: Is the business workflow sufficiently understood and agreed upon to model the domain accurately?

Possible outcomes:

  • Accept BWS and proceed within Stage 3
  • Revise BWS (workflow unclear, incomplete, or disputed)
  • Pause (business process disagreement exists)

If the workflow is not agreed upon, domain modeling must not proceed.

3. Ownership and Roles

  • Owner: Business Analyst / Domain Facilitator
  • Contributors: Front-line staff, process owners, subject-matter experts
  • Reviewers / Approvers: Business stakeholders responsible for the workflow

There must be one accountable owner responsible for workflow accuracy.

4. Blank Artifact Template

# Business Workflow Specification (BWS)

## 1. Outcome Reference
**Outcome Name:** {Name from PRD}
**Initiative:** {Initiative Name}

---

## 2. Actors / Roles Involved
- {Role 1}
- {Role 2}
- {Role 3}

---

## 3. Inputs Required
Business inputs needed to begin the workflow:
- {Input 1}
- {Input 2}

---

## 4. Workflow Steps (Business Actions Only)
1. {Step}
2. {Step}
3. {Step}

---

## 5. Decision Points
Describe business decisions and their branches:
- **Decision:** {Decision description}
  **If Yes:** {Outcome}
  **If No:** {Outcome}

---

## 6. Exceptions
Describe business exceptions, not system errors:
- {Exception 1}
- {Exception 2}

---

## 7. Outputs / Results
What the business produces or achieves by completing the workflow:
- {Output 1}
- {Output 2}

5. Required Inputs

  • Product Requirements Document (PRD) - approved and stable

The BWS must be derived directly from the PRD and must not expand scope.

6. Input Acceptance Criteria

Before creating a BWS, verify:

  • The Outcome is clearly defined in the PRD
  • Business requirements are agreed
  • Workflow discussion is business-focused, not technical

If these are not true, return to the PRD.

7. Assumptions to Surface

Common assumptions at this stage include:

  • The workflow is the same for all scenarios
  • Exceptions are rare or unimportant
  • Roles are interchangeable
  • Informal steps do not matter

These must be surfaced explicitly.

8. What Must NOT Appear in This Artifact

The BWS must not include:

  • System behaviors or automation steps
  • UI actions or screen flows
  • Technical validations or errors
  • Performance or scaling concerns

If it describes system behavior, it does not belong here.

9. Example - Completed Artifact

# Business Workflow Specification (BWS)

## 1. Outcome Reference
**Outcome Name:** Customer is identified
**Initiative:** Customer Identification Improvement

---

## 2. Actors / Roles Involved
- Support Agent
- Customer
- Support Team Lead

---

## 3. Inputs Required
Business inputs needed to begin the workflow:
- Customer contact request
- Customer identifying information

---

## 4. Workflow Steps (Business Actions Only)
1. Customer submits a support request
2. Support agent requests identifying information
3. Customer provides identifying information
4. Support agent confirms customer identity

---

## 5. Decision Points
Describe business decisions and their branches:
- **Decision:** Is customer identity confirmed?
  **If Yes:** Proceed with support case
  **If No:** Request additional identifying information

---

## 6. Exceptions
Describe business exceptions, not system errors:
- Customer cannot provide required information
- Customer record cannot be matched confidently

---

## 7. Outputs / Results
What the business produces or achieves by completing the workflow:
- Confirmed customer identity
- Support case authorized to proceed

10. Output Quality Checklist

  • [ ] Steps describe business actions only
  • [ ] Decisions and branches are explicit
  • [ ] Exceptions reflect real business deviations
  • [ ] Inputs and outputs are business artifacts
  • [ ] Workflow aligns with PRD intent

All items must pass to proceed.

11. Common Failure Modes

  • Describing system or UI behavior
  • Omitting informal but critical steps
  • Treating exceptions as technical errors
  • Over-simplifying decision logic

These indicate loss of business fidelity.

12. Review Questions

Reviewers should ask:

  • Does this reflect how work actually happens?
  • Would front-line staff recognize this workflow?
  • Are decisions and handoffs clear?
  • Are any real-world variations missing?

If answers differ, revise the BWS.

13. What to Do If the Artifact Is Rejected

If the BWS is rejected:

  • Re-interview business participants
  • Clarify decision points and exceptions
  • Align steps more closely to reality

Do not proceed until the workflow is agreed.

14. Readiness Signal - Moving Forward

The BWS is ready when:

  • Business stakeholders agree on the workflow
  • Actions, decisions, and exceptions are explicit
  • No technical interpretation is required

Proceed to Domain Parts List (DPL) and SDD Integration.

15. What Invalidates This Artifact

The BWS must be revisited if:

  • Business process changes
  • Roles or responsibilities shift
  • New exceptions are identified

16. Downstream Dependencies

  • Next Artifacts: DPL, SDD

An inaccurate BWS produces an inaccurate domain model.

Reminder: The BWS describes business reality - not system behavior.