Skill

complexity-analysis

Analyzes specification quality using Axiomatic Design principles, evaluating requirement independence, completeness, and information content. Use for optional advanced validation of critical systems.

documentation

npx claudepluginhub rafaelgorski/problem-based-srs

Tool Access

This skill uses the workspace's default tool permissions.

Preview

> **OPTIONAL Advanced Validation Tool** for Problem-Based SRS methodology

SKILL.md

Similar Skills

problem-based-srs

Orchestrates Problem-Based SRS methodology to derive traceable functional requirements from business problems via 6 structured steps and sub-skills.

2 files

problem-based-srs

spec

Transforms problem statements into structured PRDs, testable requirements, acceptance criteria, complexity tiers, CVA analysis, and spec artifacts like REQ/DESIGN/TASK MD files.

6 tools

copilot-cli-toolkit

requirements-quality

Assesses requirements quality against INVEST criteria, improves clarity, detects ambiguity, ensures completeness, and guides MoSCoW prioritization with checklists and refinement patterns.

3 files6 tools

spec-driven-development

Stats

Stars20

Forks3

Last CommitApr 29, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Complexity Analysis

OPTIONAL Advanced Validation Tool for Problem-Based SRS methodology
Purpose: Analyze specification quality using Axiomatic Design principles
When to use: After completing the standard process, when deeper quality analysis is needed

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.

⚠️ Optional Skill

This is NOT part of the standard Problem-Based SRS flow. Use it when you want to:

Verify specification independence (no coupled requirements)
Evaluate completeness levels mathematically
Identify redundancies or gaps in your specification
Apply rigorous engineering quality checks

Standard Flow: customer-problems → software-glance → customer-needs → software-vision → functional-requirements → zigzag-validator

Optional: complexity-analysis (call explicitly when needed)

Axiomatic Design Background

The complexity analysis is based on Axiomatic Design (Suh, 1990), an engineering design theory with two fundamental axioms:

Axiom	Name	Principle
Axiom 1	Independence	Maintain independence of functional requirements
Axiom 2	Information	Minimize the information content of the design

Analysis 1: Independence Analysis

Specification Types

Based on the relationship between domains, specifications fall into three categories:

Coupled Specification ❌

(Number of CNs < Number of CPs) OR (Number of FRs < Number of CNs)

Problem: Not all problems/needs are addressed
Action: Add missing CNs or FRs

Redundant Specification ⚠️

(Number of CNs > Number of CPs) OR (Number of FRs > Number of CNs)

Assessment: May be acceptable if elements are not competing
Action: Review for potential consolidation or verify independence

Ideal Specification ✅

(Number of CNs = Number of CPs) AND (Number of FRs = Number of CNs)

Status: Each element maps 1:1 across domains
Note: Ideal but not always achievable in practice

Independence Check Process

For each mapping (CP→CN and CN→FR), check:

One-to-One Mapping: Each source has exactly one target
No Competing Elements: Elements don't interfere with each other
No Functional Dependencies: Changing one doesn't require changing another

Design Matrix Analysis

Create a design matrix to visualize relationships:

         CN.1  CN.2  CN.3
CP.1     [X]   [ ]   [ ]    ← Ideal: one X per row
CP.2     [ ]   [X]   [ ]
CP.3     [ ]   [ ]   [X]

Matrix Types:

Type	Pattern	Status
Diagonal	One X per row/column	✅ Ideal (uncoupled)
Triangular	Xs below diagonal only	✅ Acceptable (semi-coupled)
Full	Xs scattered	❌ Coupled (needs revision)

Analysis 2: Completeness Levels

Use C (Complete) and P (Partial) markers to indicate how well each element addresses its source:

CP → CN Completeness Matrix

         CN.1  CN.2  CN.3
CP.1     [C]   [ ]   [ ]    C = CN completely solves CP
CP.2     [P]   [P]   [ ]    P = CN partially solves CP
CP.3     [ ]   [ ]   [C]

Interpretation:

C (Complete): The CN fully addresses the CP
P (Partial): The CN helps but doesn't fully solve the CP; MAY need additional CNs

CN → FR Completeness Matrix

         FR.1  FR.2  FR.3  FR.4
CN.1     [C]   [ ]   [ ]   [ ]
CN.2     [P]   [P]   [ ]   [ ]
CN.3     [ ]   [ ]   [C]   [P]

Completeness Rules

Every CP row MUST have at least one C or multiple Ps that together equal C
Every CN row MUST have at least one C or multiple Ps that together equal C
Blank rows indicate gaps (uncovered problems or needs)
Blank columns indicate orphans (requirements without traced needs)

Analysis 3: Information Content

Concept

Information Content (IC) measures the probability that a design will successfully satisfy its requirements. Lower IC = better design.

Formula:

IC = log₂(1/p)

Where p = probability of success

Practical Application

For each CN, estimate:

Need Range: The acceptable range of outcomes
System Range: What the proposed solution can actually deliver

Example:

CN.1: Manager needs to know account balances within 24 hours

Need Range: 0-24 hours (acceptable)
System Range: 0-2 hours (what system delivers)

Overlap: 100% → High probability of success → Low IC ✅

Simplified IC Assessment

Scenario	System vs Need	IC Level	Action
System range fully within need range	Full overlap	Low ✅	Good
System range partially overlaps need	Partial overlap	Medium ⚠️	Review constraints
System range outside need range	No overlap	High ❌	Redesign required

Output Template

When running complexity analysis, produce:

## Complexity Analysis Report

### 1. Element Count Summary

| Domain | Count |
|--------|-------|
| Customer Problems (CP) | [N] |
| Customer Needs (CN) | [N] |
| Functional Requirements (FR) | [N] |

**Specification Type:** [Coupled | Redundant | Ideal]

### 2. Independence Analysis

**CP → CN Matrix:**
[Include matrix with X markers]

**CN → FR Matrix:**
[Include matrix with X markers]

**Independence Status:** [Uncoupled ✅ | Semi-coupled ⚠️ | Coupled ❌]

### 3. Completeness Analysis

**CP → CN Completeness:**
[Include matrix with C/P markers]

**CN → FR Completeness:**
[Include matrix with C/P markers]

**Coverage Issues:**
- [List any uncovered CPs]
- [List any uncovered CNs]
- [List any orphan FRs]

### 4. Information Content Assessment

| CN | Need Range | System Range | Overlap | IC Level |
|----|------------|--------------|---------|----------|
| CN.1 | [range] | [range] | [%] | [Low/Med/High] |

### 5. Recommendations

1. [Specific recommendation based on analysis]
2. [Specific recommendation based on analysis]

When to Use This Analysis

Situation	Use Complexity Analysis?
Quick prototype or MVP	No
Learning the methodology	No
Critical system (safety, finance)	Yes
Large specification (>20 FRs)	Yes
Specification seems bloated	Yes
Requirements conflicts detected	Yes
Formal review required	Yes

Example: CRM System

Element Counts:

CPs: 5
CNs: 6
FRs: 8

Assessment: Redundant specification (CNs > CPs, FRs > CNs)

CP → CN Matrix:

         CN.1  CN.2  CN.3  CN.4  CN.5  CN.6
CP.1     [C]   [P]   [ ]   [ ]   [ ]   [ ]
CP.2     [ ]   [ ]   [C]   [ ]   [ ]   [ ]
CP.3     [ ]   [ ]   [ ]   [C]   [ ]   [ ]
CP.4     [ ]   [ ]   [ ]   [ ]   [C]   [P]
CP.5     [ ]   [ ]   [ ]   [ ]   [ ]   [C]

Result: Semi-coupled (triangular tendency). CP.1 and CP.4 have multiple CNs but they don't compete. Acceptable.

References

Suh, N.P. (1990). The Principles of Design. Oxford University Press.
Suh, N.P. (2001). Axiomatic Design: Advances and Applications. Oxford University Press.
Problem-Based SRS Dissertation (Gorski & Stadzisz, 2016) - Chapter 3, Section 3.4

Version: 1.2
Type: Optional Advanced Validation Tool
Command: /complexity-analysis