From harness-sdlc-suite
Business Analysis domain skill for the harness plugin. Provides BA methodology selection (Waterfall BA, Agile BA, Lean BA, Design Thinking BA, Six Sigma BA), development methodology (Requirements-First, User-Story-First, Process-First, Data-First, Stakeholder-First), verification strategy, deliverable verification, evaluation criteria (completeness, traceability, stakeholder_alignment, feasibility), and sprint contract checklist templates. Activated when domain_profile is "business_analysis".
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-sdlc-suite:harness-baThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Domain-specific.** This skill provides the HOW for business analysis projects. The harness provides the WHEN (orchestration, sprint contracts, feature ledger). This skill provides the HOW (methodology selection, development methodology, deliverable verification, evaluation criteria anchors, and BA-specific patterns).
Domain-specific. This skill provides the HOW for business analysis projects. The harness provides the WHEN (orchestration, sprint contracts, feature ledger). This skill provides the HOW (methodology selection, development methodology, deliverable verification, evaluation criteria anchors, and BA-specific patterns).
Activated when domain_profile: business_analysis is declared in .harness/spec.md.
This skill covers the full Business Analysis lifecycle:
It is methodology-agnostic at its core — any of the supported approaches can be selected. Agile BA is the default because it provides the most natural mapping to harness sprint boundaries.
This skill activates when domain_profile: business_analysis is set in .harness/spec.md or .harness/state.json.
Before using this skill's procedures:
business-analysis/ directory exists -> if yes, verify against the Repository Structure (Section 9)Select based on project characteristics during /harness:start:
| Methodology | When to Use | Phase Structure | Harness Mapping |
|---|---|---|---|
| Waterfall BA | Regulated industries, fixed-scope contracts | Inception, Elaboration, Construction, Transition | 1 sprint = 1 phase deliverable set |
| Agile BA | Iterative delivery, evolving requirements | Discovery, Elaboration, Delivery, Validation | 1 sprint = 1 user story cluster |
| Lean BA | Startup/MVP, hypothesis-driven | Problem, Solution, Validate, Pivot/Persevere | 1 sprint = 1 hypothesis + validation |
| Design Thinking BA | User-centric projects, innovation | Empathize, Define, Ideate, Prototype, Test | 1 sprint = 1 design thinking phase |
| Six Sigma BA | Process improvement, quality focus | Define, Measure, Analyze, Improve, Control (DMAIC) | 1 sprint = 1 DMAIC phase |
Default: Agile BA (if not specified by user).
The planner writes the selected methodology into spec.md during initialization. The coordinator uses the mapping to structure sprint boundaries accordingly.
Select based on project type and stakeholder needs:
| Methodology | When to Use | How It Drives the Generator |
|---|---|---|
| Requirements-First | Compliance, regulated, audit-heavy | Generator documents formal requirements FIRST (BRD sections, acceptance criteria), then derives use cases and process models |
| User-Story-First | Agile teams, user-facing products | Generator writes user stories FIRST (persona, goal, acceptance criteria), then derives process flows and data needs |
| Process-First | Business process reengineering | Generator maps current-state processes FIRST (BPMN), then identifies improvement opportunities and requirements |
| Data-First | Data migration, analytics, master data | Generator defines data entities and relationships FIRST (ERD, data dictionary), then derives business rules and processes |
| Stakeholder-First | Political/complex organizations | Generator maps stakeholder concerns and influence FIRST, then derives requirements aligned to stakeholder priorities |
Default: Requirements-First for all BA projects (if not specified).
The chosen methodology affects every phase:
| Methodology | Generator produces first | Then |
|---|---|---|
| Requirements-First | Business Requirements Document with numbered requirements | Use cases, process models, traceability matrix |
| User-Story-First | User story map with personas and acceptance criteria | Process flows, data requirements, non-functional requirements |
| Process-First | Current-state BPMN process models | Gap analysis, future-state processes, derived requirements |
| Data-First | Conceptual data model and data dictionary | Business rules, data flow diagrams, integration requirements |
| Stakeholder-First | Stakeholder register with concerns and influence matrix | Prioritized requirements aligned to stakeholder needs |
| Verification Type | BA Equivalent | Method |
|---|---|---|
| Unit test | Requirement validation | Each requirement has a unique ID, is testable, unambiguous, and traced to a business need |
| Integration test | Cross-document consistency | References between BRD, use cases, and process models resolve correctly |
| E2E test | Scenario walkthrough | Business scenario traces through all deliverables without gaps (stakeholder need -> requirement -> use case -> process -> acceptance criteria) |
| Smoke test | Deliverable completeness | Required documents exist and contain all mandatory sections |
| Regression | Standards compliance | BABOK knowledge areas covered, naming conventions followed, template structure maintained |
Since BA produces documents, not running software, "build verification" means:
| Check | What to Verify | How |
|---|---|---|
| Document structure | Required sections present per template | Check headings/sections against BA document template |
| Cross-references | References between documents resolve | Grep for requirement IDs, verify targets exist in traceability matrix |
| Requirement quality | Each requirement is SMART (Specific, Measurable, Achievable, Relevant, Time-bound) | Pattern-check requirement text for ambiguous words ("should", "may", "etc.") |
| Naming conventions | Consistent naming across artifacts | Pattern matching on requirement IDs (REQ-xxx), use case IDs (UC-xxx), process IDs (BP-xxx) |
| Traceability | Business needs to requirements to use cases to test cases | Traceability matrix completeness check — no orphan requirements |
| Stakeholder coverage | All identified stakeholders have requirements addressed | Cross-reference stakeholder register with requirements ownership |
| Glossary consistency | Terms defined once and used consistently | Check glossary entries against document usage |
| Section | Required Content |
|---|---|
| Executive Summary | Problem statement, proposed solution, business value |
| Stakeholders | Register with roles, concerns, influence, communication plan |
| Business Context | Current state, pain points, opportunity description |
| Scope | In-scope items, out-of-scope items, assumptions, constraints |
| Requirements | Functional requirements (numbered), non-functional requirements, business rules |
| Use Cases | Primary use cases with actors, preconditions, main flow, alternate flows |
| Process Models | Current-state and future-state BPMN diagrams |
| Data Requirements | Conceptual data model, data dictionary, data quality rules |
| Acceptance Criteria | Measurable criteria for each requirement group |
| Appendices | Glossary, traceability matrix, references |
The 4 primary criteria for the business_analysis domain profile. The evaluator MUST use these anchors for consistent scoring across sprints.
| Score | Anchor Description |
|---|---|
| 0 | Absent — no requirements or BA deliverables produced |
| 1 | Severely incomplete — some requirements listed but no structure, missing major sections |
| 2 | Below acceptable — requirements exist but significant gaps in coverage, missing stakeholder needs or non-functional requirements |
| 3 | Acceptable — all mandatory BRD sections present, functional and non-functional requirements documented, no critical gaps |
| 4 | Strong — comprehensive requirements with edge cases addressed, complete use cases, thorough data requirements |
| 5 | Excellent — exhaustive coverage including business rules, exception flows, data quality rules, and measurable acceptance criteria for every requirement |
| Score | Anchor Description |
|---|---|
| 0 | Absent — no traceability between artifacts |
| 1 | Severely incomplete — requirements exist but no IDs, no links to business needs |
| 2 | Below acceptable — requirement IDs assigned but traceability matrix incomplete or inconsistent |
| 3 | Acceptable — traceability matrix links business needs to requirements, each requirement has a unique ID and source reference |
| 4 | Strong — bidirectional traceability from business needs through requirements to use cases and acceptance criteria, no orphan requirements |
| 5 | Excellent — full forward and backward traceability with impact analysis capability, every requirement traced from business driver to test case, change impact paths documented |
| Score | Anchor Description |
|---|---|
| 0 | Absent — no stakeholder analysis performed |
| 1 | Severely incomplete — stakeholders mentioned but not systematically identified or analyzed |
| 2 | Below acceptable — stakeholder register exists but concerns not mapped to requirements, no communication plan |
| 3 | Acceptable — all key stakeholders identified with roles and concerns, requirements address stated concerns, sign-off readiness evident |
| 4 | Strong — stakeholder influence matrix complete, conflicting concerns resolved with documented rationale, prioritization reflects stakeholder input |
| 5 | Excellent — stakeholder concerns systematically traced to requirements, conflict resolution documented, communication plan active, feedback incorporated into requirements |
| Score | Anchor Description |
|---|---|
| 0 | Absent — requirements are unrealistic or no feasibility consideration |
| 1 | Severely incomplete — requirements exist but no resource, timeline, or technical feasibility assessment |
| 2 | Below acceptable — some feasibility notes but no systematic analysis, risks not identified |
| 3 | Acceptable — requirements are implementable, key risks identified, resource and timeline estimates reasonable |
| 4 | Strong — detailed feasibility analysis with risk mitigations, phased implementation plan, technology constraints documented |
| 5 | Excellent — proven feasibility with comparable case studies, detailed risk register with quantified impact, contingency plans, and stakeholder agreement on trade-offs |
Pre-built checklists for 5 BA phases. The generator includes the relevant checklist(s) in each sprint contract. The evaluator uses them as acceptance criteria.
| Standard | Scope | Key Concepts |
|---|---|---|
| BABOK v3 (IIBA) | BA knowledge areas, techniques, competencies | 6 knowledge areas, 50+ techniques, underlying competencies |
| PMI-PBA | Business analysis in project context | Needs assessment, planning, analysis, traceability, evaluation |
| ISO/IEC 29148 | Requirements engineering standard | Requirements processes, documentation templates, quality attributes |
| IEEE 830 | Software requirements specification | SRS template, requirement characteristics (correct, unambiguous, complete, consistent) |
| TOGAF Business Architecture | Business architecture within EA context | Business capability modeling, value streams, organization mapping |
| Framework | When to Use | Key Deliverables |
|---|---|---|
| Business Model Canvas | Strategy and innovation projects | 9-block canvas covering value proposition, segments, channels |
| Value Stream Mapping | Process improvement, Lean initiatives | Current and future state value stream maps |
| RACI Matrix | Role clarity and governance | Responsibility assignment for processes and decisions |
| Kano Model | Feature prioritization, product management | Feature classification (must-be, one-dimensional, attractive, indifferent) |
| Jobs-to-be-Done | Customer-centric analysis | Job statements, outcome expectations, underserved needs |
| Element | Symbol | Usage |
|---|---|---|
| Start Event | Circle (thin border) | Beginning of a process flow |
| End Event | Circle (thick border) | Termination of a process flow |
| Task | Rounded rectangle | A unit of work performed by a participant |
| Gateway (Exclusive) | Diamond with X | Decision point — one path selected |
| Gateway (Parallel) | Diamond with + | Fork/join — all paths executed |
| Gateway (Inclusive) | Diamond with O | One or more paths selected |
| Sequence Flow | Solid arrow | Order of activities |
| Message Flow | Dashed arrow | Communication between pools |
| Pool/Lane | Horizontal container | Organization/role boundary |
| Data Object | Document icon | Data input/output for activities |
| Element | Representation | Usage |
|---|---|---|
| Actor | Stick figure | External entity interacting with the system |
| Use Case | Oval/ellipse | A goal the actor achieves using the system |
| System Boundary | Rectangle | Scope of the system under analysis |
| Include | Dashed arrow with <> | Mandatory sub-behavior |
| Extend | Dashed arrow with <> | Optional/conditional behavior |
| Generalization | Solid arrow with open arrowhead | Actor or use case inheritance |
| Element | Symbol | Usage |
|---|---|---|
| Process | Circle or rounded rectangle | Transforms data inputs into outputs |
| Data Store | Open-ended rectangle (parallel lines) | Persistent data repository |
| External Entity | Rectangle | Source or destination outside system boundary |
| Data Flow | Arrow with label | Movement of data between elements |
The generator should organize BA deliverables following this repository structure:
.harness/
spec.md # BA Statement of Work
features.json # BA deliverable tracker
project-root/
business-analysis/
1-elicitation/
stakeholder-register.md # Stakeholder identification and analysis
elicitation-plan.md # Techniques, schedule, participants
interview-notes/ # Raw interview/workshop outputs
business-context.md # Current state, pain points, opportunities
2-requirements/
brd.md # Business Requirements Document
functional-requirements.md # Detailed functional requirements (REQ-xxx)
non-functional-requirements.md # Performance, security, usability requirements
business-rules.md # Business rules catalog
3-use-cases/
use-case-model.md # Use case diagram and overview
UC-001-*.md # Individual use case specifications
UC-002-*.md
4-process-models/
current-state/ # As-is BPMN process models
future-state/ # To-be BPMN process models
gap-analysis.md # Process gaps and improvements
5-data/
conceptual-data-model.md # Entity-relationship overview
data-dictionary.md # Field-level data definitions
data-quality-rules.md # Validation and quality constraints
6-validation/
traceability-matrix.md # Requirements traceability (needs -> requirements -> use cases -> tests)
acceptance-criteria.md # Measurable acceptance criteria
sign-off-tracker.md # Stakeholder sign-off status
glossary.md # Consistent term definitions
diagrams/
*.bpmn # BPMN source files
*.mermaid # Mermaid source files
The evaluator verifies repository structure completeness per phase:
| After Phase | Required Directories | Required Files (minimum) |
|---|---|---|
| Elicitation | 1-elicitation/ | stakeholder-register.md, business-context.md |
| Requirements | 2-requirements/ | brd.md, functional-requirements.md |
| Use Cases | 3-use-cases/ | use-case-model.md, at least 1 UC spec |
| Process Modeling | 4-process-models/ | at least 1 current-state model, gap-analysis.md |
| Data Analysis | 5-data/ | conceptual-data-model.md, data-dictionary.md |
| Validation | 6-validation/ | traceability-matrix.md, acceptance-criteria.md |
| Any | root | glossary.md |
The evaluator should flag these common BA anti-patterns when grading:
| Anti-Pattern | What It Looks Like | Impact | Score Penalty |
|---|---|---|---|
| Requirements Amnesia | Requirements gathered but not documented or traced | traceability: -2 | Drop traceability to max 2 |
| Stakeholder Blindspot | Key stakeholders missing from analysis, only IT consulted | stakeholder_alignment: -2 | Drop stakeholder_alignment to max 2 |
| Gold Plating | Excessive detail on low-priority requirements while critical ones are vague | completeness: -1 | Flag as scope risk |
| Solution Jumping | Requirements describe a specific solution instead of business needs | feasibility: -1 | Require needs-based rewrite |
| Scope Creep Enablement | No explicit out-of-scope list, assumptions undocumented | completeness: -1 | Require scope boundary definition |
| Ambiguity Tolerance | Requirements use vague language ("should", "may", "appropriate", "etc.") | completeness: -2 | Cannot verify without measurable criteria |
| Traceability Theater | Traceability matrix exists but links are incorrect or incomplete | traceability: -1 | Require matrix validation |
| Analysis Paralysis | Attempting exhaustive analysis of every edge case before any validation | feasibility: -1 | Flag as delivery risk |
Stakeholder interviews are a core elicitation technique for business analysis. This section provides a structured interview guide that the generator uses when producing elicitation artifacts, and the evaluator uses to verify interview documentation quality.
Complete before every stakeholder interview:
Organize interview questions into these categories. Select 2-4 questions per category based on the interview objective.
Context Questions (establish the stakeholder's perspective):
Pain Point Questions (identify problems and frustrations):
Goal Questions (understand desired outcomes):
Constraint Questions (identify boundaries and limitations):
Success Criteria Questions (define measurable acceptance):
# Interview Record: [Stakeholder Name]
## Metadata
- **Stakeholder**: [Name], [Role], [Department]
- **Interviewer**: [Name]
- **Date**: [YYYY-MM-DD]
- **Duration**: [Actual duration]
- **Interview Objective**: [What information was sought]
## Key Findings
### Context
- [Summary of stakeholder's perspective and domain knowledge]
### Pain Points Identified
| ID | Pain Point | Severity (H/M/L) | Frequency | Affected Process |
|----|-----------|-------------------|-----------|-----------------|
| PP-01 | [Description] | [H/M/L] | [Daily/Weekly/Monthly] | [Process name] |
### Goals and Desired Outcomes
| ID | Goal | Priority (H/M/L) | Measurable Outcome |
|----|------|-------------------|-------------------|
| GL-01 | [Description] | [H/M/L] | [How to measure] |
### Constraints Identified
- [Constraint 1: description and impact]
- [Constraint 2: description and impact]
### Requirements Candidates
| Candidate ID | Description | Type (Functional/Non-Functional/Rule) | Source (this interview) |
|-------------|------------|---------------------------------------|------------------------|
| RC-01 | [Description] | [Type] | [Stakeholder name, date] |
## Follow-Up Actions
| Action | Owner | Due Date |
|--------|-------|----------|
| [Action item] | [Name] | [Date] |
## Interviewer Notes
[Observations about stakeholder engagement, concerns not explicitly stated, potential conflicts with other stakeholder views]
Prioritization is critical for managing stakeholder expectations and allocating development effort. This section provides three complementary techniques. Select based on project context, or use multiple techniques for cross-validation.
MoSCoW classifies requirements into four categories based on delivery necessity within the current time-box.
| Category | Definition | Decision Criteria | Typical Allocation |
|---|---|---|---|
| Must have | Non-negotiable for this release; without it the solution has no value or fails compliance | Legal/regulatory requirement, core business process dependency, safety-critical | 60% of effort |
| Should have | Important but workaround exists; painful to omit but solution is still viable | Significant business value, high stakeholder demand, but deferral does not break core functionality | 20% of effort |
| Could have | Desirable; included if time and budget permit after Must and Should items are delivered | Nice-to-have improvements, efficiency gains, user experience enhancements | 15% of effort |
| Won't have (this time) | Explicitly excluded from this release; acknowledged for future consideration | Low priority, high cost relative to value, dependent on deferred capability, or stakeholder agreed to defer | 5% of effort (planning only) |
MoSCoW Classification Template:
| Req ID | Requirement | MoSCoW | Rationale | Stakeholder Agreement |
|---|---|---|---|---|
| REQ-001 | [Description] | Must | [Why this classification] | [Stakeholder name, date] |
| REQ-002 | [Description] | Should | [Why this classification] | [Stakeholder name, date] |
| REQ-003 | [Description] | Could | [Why this classification] | [Stakeholder name, date] |
| REQ-004 | [Description] | Won't | [Why this classification] | [Stakeholder name, date] |
The Kano model classifies features based on their relationship between implementation and customer satisfaction.
| Category | Customer Expectation | If Present | If Absent | Example |
|---|---|---|---|---|
| Must-be (Basic) | Taken for granted; expected as baseline | No increase in satisfaction | Strong dissatisfaction | Login functionality, data validation, error messages |
| One-dimensional (Performance) | Explicitly requested; satisfaction proportional to fulfillment | Satisfaction increases proportionally | Dissatisfaction proportional to gap | Response time, report detail level, search accuracy |
| Attractive (Delighter) | Not expected; pleasantly surprised | Disproportionate satisfaction increase | No dissatisfaction (not missed) | Predictive suggestions, auto-generated reports, smart defaults |
| Indifferent | No impact on satisfaction either way | No effect | No effect | Internal logging format, backend implementation details |
| Reverse | Actively unwanted by some users | Dissatisfaction for some users | Satisfaction for those who dislike it | Mandatory tutorials, forced update prompts |
Kano Classification Template:
| Feature ID | Feature | Functional Question Response | Dysfunctional Question Response | Classification | Confidence |
|---|---|---|---|---|---|
| F-001 | [Description] | [Like/Expect/Neutral/Tolerate/Dislike] | [Like/Expect/Neutral/Tolerate/Dislike] | [Must-be/One-dimensional/Attractive/Indifferent/Reverse] | [High/Medium/Low] |
To classify: ask stakeholders two questions per feature: (1) "How would you feel if this feature is present?" (functional) and (2) "How would you feel if this feature is absent?" (dysfunctional). Map the response pair to the Kano category using the evaluation matrix:
| Like (functional) | Expect | Neutral | Tolerate | Dislike | |
|---|---|---|---|---|---|
| Like (dysfunctional) | Questionable | Attractive | Attractive | Attractive | One-dimensional |
| Expect | Reverse | Indifferent | Indifferent | Indifferent | Must-be |
| Neutral | Reverse | Indifferent | Indifferent | Indifferent | Must-be |
| Tolerate | Reverse | Indifferent | Indifferent | Indifferent | Must-be |
| Dislike | Reverse | Reverse | Reverse | Reverse | Questionable |
Weighted scoring provides a quantitative comparison when stakeholder priorities conflict or when MoSCoW is too coarse.
Step 1: Define Criteria and Weights
| Criterion | Description | Weight (%) |
|---|---|---|
| Business Value | Revenue impact, cost reduction, strategic alignment | [e.g., 30%] |
| User Impact | Number of users affected, frequency of use, pain severity | [e.g., 25%] |
| Implementation Effort | Development time, complexity, dependencies | [e.g., 20%] |
| Risk Reduction | Compliance, security, operational risk mitigation | [e.g., 15%] |
| Strategic Alignment | Alignment with organizational goals and roadmap | [e.g., 10%] |
| Total | 100% |
Weights are agreed upon by stakeholders before scoring begins. Adjust criteria to match project context.
Step 2: Score Requirements
| Req ID | Requirement | Business Value (1-5) | User Impact (1-5) | Effort (1-5, inverted) | Risk Reduction (1-5) | Strategic (1-5) | Weighted Score | Rank |
|---|---|---|---|---|---|---|---|---|
| REQ-001 | [Description] | [Score] | [Score] | [Score] | [Score] | [Score] | [Calculated] | [#] |
Weighted Score Formula: Score = SUM(criterion_score * criterion_weight)
Note: For the Effort criterion, invert the scale (5 = low effort, 1 = high effort) so that higher scores consistently mean "more desirable."
This section defines the approval lifecycle for BA deliverables, the stakeholder sign-off process, and the change control procedure for post-baseline modifications.
| Stage | Status | Description | Entry Criteria | Exit Criteria | Responsible |
|---|---|---|---|---|---|
| 1 | Draft | Initial authoring; requirements being elicited and documented | Sprint contract accepted | All mandatory BRD sections populated; internal consistency check passed | Business Analyst |
| 2 | Internal Review | Peer review by BA team and technical leads | Draft complete, no known gaps | All review comments resolved or deferred with rationale | BA Lead, Technical Lead |
| 3 | Stakeholder Review | Business stakeholders review for accuracy and completeness | Internal review passed | All stakeholder comments addressed; no open blockers | Business Owners, SMEs |
| 4 | Approved | Formally accepted by designated approvers | Stakeholder review passed; sign-off criteria met | All required signatures obtained | Executive Sponsor, Business Owner |
| 5 | Baselined | Version-locked; changes require formal change control | Approved status reached; version number assigned | Baseline published to repository; change control activated | Configuration Manager or BA Lead |
# Requirements Sign-Off Record
## Document
- **Title**: [BRD / Requirements Specification title]
- **Version**: [Version number]
- **Baseline Date**: [YYYY-MM-DD]
## Scope of Sign-Off
[Brief description of what is being approved -- e.g., "Functional requirements for Phase 1 of the Order Management System"]
## Sign-Off Register
| Name | Role | Department | Decision | Comments | Date |
|------|------|-----------|----------|----------|------|
| [Name] | Executive Sponsor | [Dept] | Approved / Approved with conditions / Rejected | [Comments or conditions] | [Date] |
| [Name] | Business Owner | [Dept] | Approved / Approved with conditions / Rejected | [Comments or conditions] | [Date] |
| [Name] | Technical Lead | [Dept] | Approved / Approved with conditions / Rejected | [Comments or conditions] | [Date] |
## Conditions (if any)
| Condition ID | Description | Resolution Owner | Resolution Date |
|-------------|------------|-----------------|----------------|
| COND-01 | [Description of condition] | [Name] | [Target date] |
## Result
- **Overall Decision**: [Approved | Approved with Conditions | Rejected]
- **Next Step**: [Baseline and activate change control | Revise and re-submit | Escalate to steering committee]
Once requirements are baselined, all modifications must follow this change control procedure:
Step 1: Change Request
| Field | Description |
|---|---|
| CR ID | Unique identifier (CR-NNN) |
| Requestor | Name and role of the person requesting the change |
| Date Submitted | Date the change request was raised |
| Affected Requirements | List of Requirement IDs impacted (REQ-NNN) |
| Description | Clear description of the proposed change |
| Business Justification | Why this change is needed; what happens if it is not made |
| Priority | Critical / High / Medium / Low |
Step 2: Impact Assessment
| Assessment Area | Analysis |
|---|---|
| Scope Impact | Which requirements, use cases, and processes are affected? |
| Effort Impact | Estimated additional effort (hours/days) for implementation |
| Schedule Impact | Effect on delivery timeline -- slip, compression, or no impact |
| Cost Impact | Additional cost or budget reallocation required |
| Risk Impact | New risks introduced or existing risks changed |
| Dependency Impact | Other requirements or features affected by this change |
Step 3: Approval Authority
| Change Priority | Approval Authority | Turnaround Target |
|---|---|---|
| Critical | Executive Sponsor + Business Owner | 1 business day |
| High | Business Owner + BA Lead | 3 business days |
| Medium | BA Lead + Technical Lead | 5 business days |
| Low | BA Lead (sole authority) | 10 business days |
Step 4: Implementation
After approval: update affected requirements, increment version number, update traceability matrix, notify affected stakeholders, and update the baseline. Record the CR resolution in the change log.
The traceability matrix links business needs to requirements, features, test cases, and acceptance criteria. It serves as the primary tool for verifying requirements completeness and impact analysis.
| Requirement ID | Requirement Title | Business Need / Source | Feature / Capability ID | Test Case ID | Acceptance Criteria | Status | Priority | Owner |
|---|---|---|---|---|---|---|---|---|
| REQ-001 | [Short title] | [BN-001 or stakeholder interview reference] | [F-001 or CAP-001] | [TC-001, TC-002] | [Measurable criterion] | [Draft / Reviewed / Approved / Implemented / Verified] | [Must / Should / Could] | [Name] |
| REQ-002 | [Short title] | [BN-002] | [F-001, F-003] | [TC-003] | [Measurable criterion] | [Draft] | [Must] | [Name] |
| Status | Meaning |
|---|---|
| Draft | Requirement documented but not yet reviewed |
| Reviewed | Requirement reviewed by BA team; no outstanding issues |
| Approved | Requirement approved by stakeholder sign-off |
| Implemented | Requirement implemented in the solution (for software) or addressed in the deliverable (for documents) |
| Verified | Requirement verified through test execution or deliverable review |
| Deferred | Requirement moved to a future release or phase |
| Rejected | Requirement rejected during review; rationale documented |
Run these checks to validate matrix completeness:
| Check | Rule | Severity |
|---|---|---|
| No orphan requirements | Every REQ-NNN must have at least one Business Need reference | Blocker |
| No untested requirements | Every Approved or Implemented REQ-NNN must have at least one Test Case ID | Blocker |
| No unlinked features | Every Feature/Capability ID must trace to at least one REQ-NNN | Warning |
| No missing acceptance criteria | Every REQ-NNN with Status = Approved or later must have an Acceptance Criteria entry | Blocker |
| No stale statuses | Requirements with Status = Draft should not persist beyond 2 sprint rounds after creation | Warning |
| Priority consistency | Must-have requirements should not have Status = Deferred unless a change request (CR-NNN) justifies it | Blocker |
Use the traceability matrix to identify gaps:
Report gaps in the evaluation as non-blocking issues (unless the gap affects a Must-have requirement, in which case it is a blocker).
npx claudepluginhub xuzhijie-ownself/harness --plugin harness-sdlc-suiteCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.