Requirement Workflow

1. Objective

The requirement workflow ensures that software work begins only after the requirement is sufficiently complete, reviewed, approved, and assigned a specific version.

2. Requirement Lifecycle

Primary states:

DRAFT
  ↓
SUBMITTED
  ↓
UNDER_BA_REVIEW
  ↓
UNDER_PM_REVIEW
  ↓
UNDER_TECHNICAL_REVIEW
  ↓
UNDER_QA_REVIEW
  ↓
APPROVED
  ↓
IN_DEVELOPMENT
  ↓
IMPLEMENTED
  ↓
QA_VERIFIED
  ↓
BA_ACCEPTED
  ↓
RELEASED

Alternative states: CHANGES_REQUESTED, REJECTED, ON_HOLD, CANCELLED, SUPERSEDED

3. Requirement Creation

A Business Analyst creates a requirement in DRAFT status.

Mandatory information:

• Project, title, business objective, detailed description
• Actor or user role, main workflow
• Business rules, acceptance criteria
• Priority, author, creation date

Conditionally mandatory:

• UI references, integration details, dependencies
• Data migration requirements, security considerations
• Attachments, alternative workflows, out-of-scope items

4. Draft Editing

While in DRAFT:

• The author may edit it freely
• Assigned collaborators may comment
• Validation warnings may be displayed
• Draft changes are still recorded in history

5. Submission

When the BA submits the requirement:

1. System validates required fields
2. System checks Definition of Ready
3. System assigns a review workflow
4. Requirement becomes SUBMITTED
5. Reviewers receive notifications

6. Review Process

BA Review

BA reviewer verifies:

• Business problem is clear
• Objective is measurable
• Workflows are complete and consistent
• Acceptance criteria are testable

PM Review

Project Manager verifies:

• Priority is clear and realistic
• Target release is achievable
• Dependencies are identified
• Scope boundaries are clear

Technical Review

Technical Lead verifies:

• Technical feasibility and architecture impact
• Integration and database impact
• Security impact and performance considerations
• Migration needs and development estimate readiness

QA Review

QA verifies:

• Acceptance criteria are testable
• Expected results are unambiguous
• Edge cases are identified
• Required test data is available

7. Approval

After all mandatory reviews pass:

1. System assigns next version number (starting at 1.0)
2. Requirement version becomes APPROVED
3. Version is locked (immutable)
4. Immutable snapshot is stored
5. Approval records are stored
6. Audit events are created
7. Approved version becomes current source of truth

8. Immutability Rule

Critical: An approved requirement version cannot be edited through:

• User interface
• Public API
• Bulk update
• Administrator screen

Any change must create:

• A change request
• A new draft requirement version
• A recorded reason for change
• A version relationship to the approved version

9. Development Transition

The requirement may enter IN_DEVELOPMENT when:

• At least one task is linked
• Required approvals are complete
• No blocking clarification remains
• PM assigns the work to a sprint

10. Implementation and Release

• IMPLEMENTED: All mandatory linked tasks are DONE
• QA_VERIFIED: Required test cases executed and passed
• BA_ACCEPTED: BA confirms implementation satisfies the approved version
• RELEASED: Included in an approved release and deployed

11. Clarifications

A clarification may be raised at any point before release.

Clarification fields:

• Question, asked by, assigned to, due date
• Requirement version, response, resolution
• Decision status, confirmed by, confirmed date

A clarification becomes an official project decision only after confirmation by an authorized role.

12. Version Numbering

Recommended rules:

• 1.0: First approved version
• 1.1: Minor clarification with limited scope impact
• 2.0: Major workflow, rule, scope, or acceptance change

13. Workflow Audit

The system preserves:

• Previous and new status, changed by, changed date
• Review comment, approval/rejection reason
• Requirement snapshot, version identifier
• Related change request, trace ID

Next: Review the Change Request Workflow →