04 Requirements Analysis

Requirements Analysis Skill

Use When

• classifying, reconciling, prioritising, and testing the feasibility of elicited requirements; use requirements-validation for the independent pre-baseline review.
• Use this procedure when the required source artefacts are available and Analysed requirements set and conflict log is the next lifecycle deliverable.

Do Not Use When

• Use requirements-validation when that neighbouring route owns the decision or deliverable.
• Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.

Required Inputs

Workflow

1. Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.
2. Apply this skill's existing domain workflow and decision rules to produce Analysed requirements set and conflict log.
3. Stop when a required source, accountable decision owner, or deterministic test oracle is absent.
4. Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.

Outputs

Evidence Produced

Capability and permission boundaries

Read and search are required. This procedure is read-only by default. Editing the reviewed artefact, publishing, production mutation, destructive action, spending, or certification requires explicit authority.

Degraded mode

Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check not assessed; never convert an unassessed check into a pass.

Decision Rules

Quality Standards

• Preserve stable identifiers and bidirectional traceability from project evidence to Analysed requirements set and conflict log and its acceptance checks.
• Apply ISO/IEEE measures only with a named metric, method, threshold, evidence source, and responsible reviewer; run the anti-slop gate before release.

Anti-Patterns

• Producing Analysed requirements set and conflict log from assumed context. Fix: cite the project source or mark the scope blocked.
• Accepting a material requirement without a deterministic oracle. Fix: add a measurable result, boundary, and verification method.
• Crossing into requirements-validation without routing the decision. Fix: hand off the named input and preserve trace links.
• Treating an unavailable check as passed. Fix: mark it not assessed and state the release consequence.
• Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.

References

• Skill authoring and release standard
• Conflict Detection
• Feasibility Analysis
• Goal Modeling
• Requirements Prioritization

Overview

This skill transforms raw elicitation artifacts into a structured analysis report. It classifies requirements by type and priority, detects conflicts between competing requirements, assesses feasibility across five dimensions (TELOS), and applies a stakeholder-selected prioritization method. The output serves as the authoritative analysis baseline before specification and validation activities begin.

When to Use This Skill

• After elicitation activities have produced elicitation_log.md with raw requirements
• When the requirements set has grown large enough that conflicts and redundancies are likely
• Before writing formal SRS specifications to ensure only feasible, conflict-free requirements proceed
• When stakeholders need a defensible prioritization of the requirements backlog

Quick Reference

Input Files

Output Files

Core Instructions

Follow these steps in order. Halt and notify the user if a required input file is missing.

Step 1: Read and Inventory Context Files

Read elicitation_log.md, vision.md, features.md, and optionally business_rules.md from projects/<ProjectName>/_context/. Assign a temporary identifier (e.g., RAW-001) to each requirement that lacks one. Log the total count of raw requirements discovered.

Step 2: Classify Requirements

Classify each requirement along two axes:

By Type (IEEE 29148 Section 6.5.2):

By Obligation (IEEE 1233):

Produce a classification matrix table listing every requirement with its type, obligation level, and source reference.

Step 3: Detect Conflicts

Scan the classified requirements for four conflict types per Wiegers Practice 8:

1. Contradiction: Two requirements specify mutually exclusive behaviors for the same stimulus. Flag both with [CONFLICT-CONTRADICTION].
2. Redundancy: Two requirements specify the same behavior in different words. Flag the duplicate with [CONFLICT-REDUNDANCY].
3. Subsumption: One requirement is a strict subset of another. Flag the subsumed requirement with [CONFLICT-SUBSUMPTION].
4. Boundary Conflict: Two requirements define overlapping numeric ranges or thresholds that cannot simultaneously be satisfied. Flag both with [CONFLICT-BOUNDARY].

For each detected conflict, document:

• The conflicting requirement identifiers
• The conflict type
• A recommended resolution strategy (merge, escalate, defer, remove)
• The escalation path if stakeholder arbitration is required

See references/conflict-detection.md for the detection algorithm and resolution strategies.

Step 4: Assess Feasibility (TELOS Framework)

Evaluate every mandatory requirement against five feasibility dimensions:

Compute a composite feasibility score:

$FeasibilityScore = \frac{T + E + L + O + S}{5}$

Apply the following thresholds:

• Score >= 4.0: Go (proceed to specification)
• Score 2.5-3.9: Conditional (proceed with documented risks)
• Score < 2.5: No-Go (defer or remove; flag with [FEASIBILITY-FAIL])

See references/feasibility-analysis.md for the scoring rubric and go/no-go decision criteria.

Step 5: Prioritize Requirements

Apply the prioritization method selected by the stakeholder team. If no method has been chosen, recommend one using the decision tree in references/requirements-prioritization.md.

Supported Methods:

1. MoSCoW (Wiegers Practice 9): Assign each requirement to Must Have, Should Have, Could Have, or Won't Have. Validate that Must Have requirements do not exceed 60% of total effort capacity.

2. Kano Model: Classify requirements as Basic (expected), Performance (linear satisfaction), or Excitement (delight). Ensure all Basic requirements are included before Performance requirements.

3. WSJF (Weighted Shortest Job First): Calculate priority score: $WSJF = \frac{UserValue + TimeCriticality + RiskReduction}{JobSize}$

4. 100-Dollar Method: Distribute 100 hypothetical dollars across requirements. Aggregate stakeholder allocations and rank by total investment.

Produce a prioritized requirements list sorted by priority score or category, with justification for each ranking decision.

Step 6: Goal Modeling (Optional)

If business goals in vision.md are complex or hierarchical, decompose them using goal-oriented requirements engineering:

• Build AND/OR goal decomposition trees linking business goals to functional requirements
• Identify goal conflicts where satisfying one goal impedes another
• Map agents (actors) to goals they are responsible for achieving

See references/goal-modeling.md for KAOS and i* modeling guidance.

Step 7: Generate Analysis Report

Write the completed analysis to projects/<ProjectName>/<phase>/<document>/requirements_analysis_report.md using the output format below. Log summary statistics: total requirements, classifications, conflicts detected, feasibility failures, and priority distribution.

Output Format Specification

The generated requirements_analysis_report.md SHALL contain the following sections:

# Requirements Analysis Report: [Project Name]

## 1. Document Information
## 2. Analysis Summary
### 2.1 Scope and Objectives
### 2.2 Input Artifacts Analyzed
### 2.3 Key Findings
## 3. Requirements Classification Matrix
### 3.1 By Type (Functional / Non-Functional / Constraint / Interface)
### 3.2 By Obligation (Mandatory / Desirable / Optional)
### 3.3 Classification Summary Statistics
## 4. Conflict Detection Report
### 4.1 Contradictions
### 4.2 Redundancies
### 4.3 Subsumptions
### 4.4 Boundary Conflicts
### 4.5 Resolution Recommendations
## 5. Feasibility Assessment
### 5.1 TELOS Scoring Matrix
### 5.2 Go / Conditional / No-Go Summary
### 5.3 Risk Register for Conditional Requirements
## 6. Requirements Prioritization
### 6.1 Method Selected and Rationale
### 6.2 Prioritized Requirements List
### 6.3 Priority Distribution Analysis
## 7. Goal Model (if applicable)
## 8. Recommendations and Next Steps
## 9. Appendix: Standards Traceability

Common Pitfalls

1. Classifying implementation details as requirements: A requirement describes what the system shall do, not how it shall be built. Filter out design decisions during classification.
2. Ignoring non-functional conflicts: Two NFRs can conflict (e.g., "response time < 100ms" vs. "encrypt all data at rest with AES-256"). Analyze NFR interactions explicitly.
3. Feasibility scores without evidence: Every score SHALL include a one-sentence justification. A number without rationale is an opinion.
4. MoSCoW inflation: Stakeholders tend to classify everything as "Must Have." Enforce the 60% capacity cap and challenge classifications with evidence.
5. Skipping redundancy detection: Redundant requirements inflate effort estimates and create maintenance burden in the SRS.

Verification Checklist

• All required input files were read and logged.
• Every raw requirement has a unique identifier and classification.
• Conflict detection covered all four conflict types.
• Every mandatory requirement has a TELOS feasibility score with justification.
• No-Go requirements are flagged with [FEASIBILITY-FAIL] and excluded from prioritization.
• Prioritization method is documented with rationale for selection.
• Must Have requirements do not exceed 60% of capacity (if MoSCoW is used).
• No subjective adjectives appear without a defined metric.
• Standards traceability appendix maps sections to IEEE 29148 and IEEE 1233 clauses.

Integration

Standards Compliance

Resources

• references/conflict-detection.md -- Conflict types, detection algorithm, resolution strategies
• references/feasibility-analysis.md -- TELOS framework with scoring rubric
• references/requirements-prioritization.md -- Four prioritization methods compared
• references/goal-modeling.md -- KAOS and i* goal-oriented requirements engineering
• Java enterprise requirements overlay -- analyse Java/JVM constraints as supported lifecycle, correctness, resource, failure, and migration obligations