From problem-based-srs
Validates traceability and consistency across Customer Problems, Customer Needs, and Functional Requirements domains. Identifies gaps and ensures requirements trace to business problems.
npx claudepluginhub rafaelgorski/problem-based-srsThis skill uses the workspace's default tool permissions.
> **Validation & Consistency Tool** for Problem-Based SRS methodology
Orchestrates Problem-Based SRS methodology to derive traceable functional requirements from business problems via 6 structured steps and sub-skills.
Performs requirements analysis: decomposes problems, scans stakeholders, structures and prioritizes needs. Produces 1-requirements.md lifecycle doc before tech-spec. Not for task tickets or solutions.
Generates ISO 29148 requirements cascade documents: BRS → StRS → SyRS → SRS with traceability relations. For regulated systems, multi-team projects, complex distributed systems.
Share bugs, ideas, or general feedback.
Validation & Consistency Tool for Problem-Based SRS methodology
Purpose: Map and decompose between CP, CN, and FR domains
Single Responsibility: Ensure traceability and consistency across domain hierarchies
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.
This skill is used during and after Steps 1, 3, and 5 to validate and refine mappings between domains. It does not replace the generation skills—it complements them.
Diagram preference: When visualizing traceability mappings, prefer Mermaid UML diagrams (e.g.,
flowchartfor hierarchy trees,graphfor dependency maps) over ASCII art where rendering supports it.
┌─────────────────────────────────────────────────────────────────────────┐
│ ZIG ZAG DECOMPOSITION │
│ │
│ Customer Customer Functional │
│ Problems Needs Requirements │
│ Domain Domain Domain │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ CP │───────▶│ CN │─────────▶│ FR │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ ◀─ZIG │ ◀─ZIG │ │
│ ┌──▼──┐ ZAG─▶ ┌──▼──┐ ZAG─▶ ┌──▼──┐ │
│ │CP.1 │───────▶│CN.1 │─────────▶│FR.1 │ │
│ │CP.2 │───────▶│CN.2 │─────────▶│FR.2 │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ │
│ │CP.1.1│──────▶│CN.1.1│────────▶│FR.1.1│ │
│ │CP.1.2│──────▶│CN.1.2│────────▶│FR.1.2│ │
│ └─────┘ └─────┘ └─────┘ │
│ │
│ "WHY" "WHAT" "HOW" │
│ (Problem) (Outcome) (Capability) │
└─────────────────────────────────────────────────────────────────────────┘
This skill adapts the Zig Zag method from Axiomatic Design (Suh, 1990) to Problem-Based SRS:
| Axiomatic Design | Problem-Based SRS | Mapping |
|---|---|---|
| Customer Domain | Customer Problems (CP) | WHY - Why the solution is needed |
| Functional Domain | Customer Needs (CN) | WHAT - What the software provides |
| Physical Domain | Functional Requirements (FR) | HOW - How the system behaves |
Zigzagging Principle: Decompose hierarchies by alternating between domains. Each level in one domain informs the decomposition in the next.
Validate and ensure consistency between CP, CN, and FR domains by:
For each item in the left domain, identify corresponding items in the right domain:
For each item in the right domain, verify it traces back:
Map items from source domain to target domain.
Input: Source domain items (CP, CN, or FR) Output: Mapping table showing relationships
Format:
| Source | Target(s) | Relationship | Gap? |
|---|---|---|---|
| CP.1 | CN.1, CN.2 | CP.1 addressed by CN.1 (primary), CN.2 (secondary) | No |
| CP.2 | — | No CN addresses CP.2 | YES |
Verify each item traces back to its source.
Input: Target domain items (CN or FR) Output: Validation report
Format:
| Item | Traces To | Valid? | Issue |
|---|---|---|---|
| FR.1 | CN.1 | ✅ | — |
| FR.7 | — | ❌ | Orphan FR - no CN source |
Decompose a high-level item into sub-items, zigzagging between domains.
Process:
Format:
CP.1: [High-level problem statement]
├── CN.1.1: [Outcome needed to address part of CP.1]
│ ├── FR.1.1.1: [Capability for CN.1.1]
│ └── FR.1.1.2: [Capability for CN.1.1]
└── CN.1.2: [Another outcome for CP.1]
└── FR.1.2.1: [Capability for CN.1.2]
Perform complete consistency analysis across all three domains.
Output:
Each FR SHOULD ideally map to one CN. If an FR affects multiple CNs, flag for review—it may indicate a coupled design.
When decomposing, sub-items SHOULD align across domains:
CP.1: Sales managers must know customer purchase history within 5 minutes
otherwise losing sales opportunities during client calls.
Step 1 - ZAG: What outcome (CN) addresses this problem?
CN.1: The sales manager needs a CRM system to know the complete purchase
history of each customer at any time.
Step 2 - ZIG: Does CN.1 fully address CP.1?
Step 3 - DECOMPOSE CN:
CN.1.1: Sales manager needs CRM to display purchase history instantly.
CN.1.2: Sales manager needs CRM accessible during phone calls (mobile/desktop).
Step 4 - ZAG: What FRs deliver these CNs?
FR.1.1.1: The CRM shall display customer purchase history within 3 seconds.
FR.1.1.2: The CRM shall allow search by customer name or phone number.
FR.1.2.1: The CRM shall be accessible via mobile application.
FR.1.2.2: The CRM shall provide one-click access from phone integration.
Step 5 - ZIG: Validate FRs trace to CNs
| FR | CN | Valid |
|---|---|---|
| FR.1.1.1 | CN.1.1 | ✅ |
| FR.1.1.2 | CN.1.1 | ✅ |
| FR.1.2.1 | CN.1.2 | ✅ |
| FR.1.2.2 | CN.1.2 | ✅ |
CP.1: Sales managers must know customer purchase history within 5 minutes
├── CN.1.1: Display purchase history instantly
│ ├── FR.1.1.1: Display within 3 seconds
│ └── FR.1.1.2: Search by name/phone
└── CN.1.2: Accessible during phone calls
├── FR.1.2.1: Mobile application
└── FR.1.2.2: Phone integration
Use C (Complete) and P (Partial) markers to indicate how well each element addresses its source:
## CP → CN Coverage Matrix
| | CN.1 | CN.2 | CN.3 | CN.4 |
|------|------|------|------|------|
| CP.1 | C | | | |
| CP.2 | | C | P | |
| CP.3 | | | | C |
**Legend:**
- **C** = Complete — CN fully addresses the CP
- **P** = Partial — CN helps but doesn't fully solve the CP
- (blank) = No relationship
**Coverage Summary:**
- CP.1: Fully covered by CN.1 ✅
- CP.2: Covered by CN.2 (complete) + CN.3 (partial) ✅
- CP.3: Fully covered by CN.4 ✅
## Gap Analysis Report
### Uncovered Customer Problems
| CP | Statement | Suggested Action |
|----|-----------|------------------|
| CP.3 | [statement] | Generate CN using customer-needs skill |
### Orphan Items
| Item | Type | Issue | Suggested Action |
|------|------|-------|------------------|
| FR.7 | FR | No CN traces | Remove or identify missing CN |
| CN.5 | CN | No CP traces | Validate business need or remove |
### Redundancies
| Items | Overlap | Suggested Action |
|-------|---------|------------------|
| FR.2, FR.8 | Both handle user search | Merge or differentiate scope |
| Situation | Operation | Input |
|---|---|---|
| After CP generation | ZAG-MAP | CPs → verify CN coverage planned |
| After CN generation | ZIG-VALIDATE | CNs → verify all trace to CPs |
| After FR generation | CONSISTENCY-CHECK | All domains → full audit |
| Refining requirements | DECOMPOSE | Specific CP or CN to break down |
Before completing zig zag analysis:
Version: 1.2
Type: Validation & Consistency Tool
Domains: CP ↔ CN ↔ FR