11 Requirements Reuse

Requirements Reuse Skill Guidance

Use When

• curating approved reusable requirement patterns and product-line variants after a stable baseline exists; use requirements-patterns to structure one project's complex behaviour.
• Use this procedure when the required source artefacts are available and Reusable requirements library is the next lifecycle deliverable.

Do Not Use When

• Use requirements-patterns 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 Reusable requirements library.
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. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require 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 Reusable requirements library 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 Reusable requirements library 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-patterns 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
• Product Line Requirements
• Reuse Patterns

Overview

This skill is OPTIONAL and intended for organizations building multiple related products or maintaining a portfolio of applications. It scans existing requirements artifacts, identifies candidates for reuse, classifies them by reuse type, and generates a requirements library catalog. The library accelerates future projects by providing vetted, parameterized requirements templates.

When to Use This Skill

• After requirements have been baselined and validated for at least one project.
• When an organization is starting a second or subsequent product that shares domain characteristics.
• During product line engineering to establish commonality and variability models.
• When regulatory requirements (GDPR, HIPAA, SOX) recur across multiple systems.

Quick Reference

• Inputs: All artifacts in projects/<ProjectName>/<phase>/<document>/, projects/<ProjectName>/_context/vision.md
• Outputs: projects/<ProjectName>/<phase>/<document>/requirements_library.md
• Tone: Cataloging, systematic, pattern-oriented

Input Files

Output Files

Core Instructions

Step 1: Read All Artifacts

Read every file in projects/<ProjectName>/<phase>/<document>/ and projects/<ProjectName>/_context/vision.md. Log each file path read. Build a consolidated list of all requirements with their full definitions, acceptance criteria, and trace links.

Step 2: Identify Reuse Candidates

Scan all requirements for patterns that indicate reuse potential. Candidates fall into three categories:

Cross-Cutting Concerns

Requirements that appear in virtually every software system:

Domain Patterns

Requirements specific to a business domain but recurring across products in that domain:

Regulatory and Compliance

Requirements mandated by law or regulation that apply to any system within scope:

Step 3: Classify Reuse Type

For each candidate requirement, classify the reuse type:

Verbatim Reuse Example

[LIB-SEC-001] The system shall encrypt all data at rest using AES-256.
Type: Verbatim | Domain: Security | Regulation: HIPAA, PCI DSS

Parameterized Reuse Example

[LIB-AUTH-001] The system shall lock the user account after
{MAX_ATTEMPTS} consecutive failed login attempts for {LOCKOUT_DURATION}.
Type: Parameterized | Domain: Authentication
Parameters: MAX_ATTEMPTS (integer, default: 5), LOCKOUT_DURATION (minutes, default: 15)

Pattern Reuse Example

[LIB-NOTIFY-001] The system shall deliver {NOTIFICATION_TYPE} notifications
to {RECIPIENT_ROLE} within {DELIVERY_SLA} of {TRIGGER_EVENT}.
Type: Pattern | Domain: Notification
Structure: Trigger -> Channel -> Recipient -> SLA

Step 4: Generate Library Catalog

For each reusable requirement, create a catalog entry:

Step 5: Define Adaptation Guidelines

Document the process for reusing requirements from the library in new projects:

1. Search: Query the library by domain, category, or keyword.
2. Evaluate: Assess applicability to the target project context.
3. Adapt: For parameterized and pattern types, fill in project-specific values.
4. Validate: Verify the adapted requirement against the target project's vision and constraints.
5. Register: Add the new usage to the library's usage tracking.
6. Trace: Establish trace links from the reused requirement to target project business goals.

Step 6: Commonality and Variability Analysis

For product line engineering, perform commonality/variability analysis:

• Common Requirements: Requirements shared by all products in the product line (mandatory inclusion).
• Variable Requirements: Requirements that differ between products (variation points).
• Optional Requirements: Requirements included only in specific product variants.

Document variation points with:

Step 7: Generate Output

Write projects/<ProjectName>/<phase>/<document>/requirements_library.md following the output format below.

Output Format

requirements_library.md

# Requirements Library: [Project Name]

**Generated:** [Date]
**Standards:** IEEE 29148-2018, Laplante Ch.9

---

## Library Summary

| Metric | Value |
|--------|-------|
| Total Library Entries | N |
| Cross-Cutting Concerns | N |
| Domain Patterns | N |
| Regulatory Requirements | N |
| Verbatim Reuse | N |
| Parameterized Reuse | N |
| Pattern Reuse | N |

---

## Library Catalog

### Cross-Cutting Concerns

| Library ID | Domain | Reuse Type | Description | Parameters |
|------------|--------|-----------|-------------|------------|
| LIB-AUTH-001 | Authentication | Parameterized | Account lockout | MAX_ATTEMPTS, LOCKOUT_DURATION |

### Domain Patterns

| Library ID | Domain | Reuse Type | Description | Parameters |
|------------|--------|-----------|-------------|------------|
| LIB-ECOM-001 | E-Commerce | Pattern | Checkout flow | PAYMENT_METHODS, TAX_RULES |

### Regulatory Requirements

| Library ID | Regulation | Reuse Type | Description | Applicability |
|------------|-----------|-----------|-------------|---------------|
| LIB-GDPR-001 | GDPR | Verbatim | Consent management | All EU-facing systems |

---

## Adaptation Guidelines

[Step-by-step process for reusing library entries]

---

## Commonality/Variability Analysis

| VP ID | Description | Variants | Binding Time |
|-------|-------------|----------|-------------|
| VP-001 | Payment processing | Stripe, PayPal, Square | Build-time |

---

## Usage Tracking

| Library ID | Source Project | Target Project | Date Reused | Adaptation Notes |
|------------|---------------|----------------|-------------|-----------------|
| LIB-AUTH-001 | Project A | Project B | [Date] | MAX_ATTEMPTS=3 |

Common Pitfalls

• Premature generalization: Do not extract a pattern from a single instance. A requirement is a reuse candidate only after it has appeared in at least one project and has clear cross-project applicability.
• Over-parameterization: Too many parameters make a template harder to use than writing from scratch. Limit parameterized templates to 5 or fewer variables.
• Stale library entries: Requirements that reference obsolete technologies or superseded regulations shall be marked Deprecated and excluded from new project reuse.
• Ignoring context: A requirement that works in one domain may be harmful in another. Always validate adapted requirements against the target project's specific constraints.
• Copy without trace: Reused requirements must still be traced to the target project's business goals. Reuse does not exempt a requirement from traceability obligations.

Verification Checklist

• All cross-cutting concerns in output artifacts have been evaluated for reuse potential.
• Each library entry has a unique LIB-[DOMAIN]-[NNN] identifier.
• Reuse type is classified as Verbatim, Parameterized, or Pattern.
• Parameterized templates include parameter definitions with defaults.
• Adaptation guidelines define the search-evaluate-adapt-validate-register-trace workflow.
• Variation points are documented for product line requirements.
• No library entry references undefined or subjective terms.

Integration

• Upstream: 08-requirements-management, 09-traceability-engineering, 10-requirements-metrics
• Downstream: Future project initialization skills, product line engineering
• Optional: This skill is not required for single-product organizations

Standards

• IEEE Std 29148-2018: Requirements reuse and product line provisions.
• Laplante Ch.9: Software product line engineering and requirements reuse.
• Wiegers Practice 20: Requirements process improvement and institutionalization.
• IEEE Std 610.12-1990: Terminology definitions.

Resources

• references/reuse-patterns.md: Requirements reuse pattern taxonomy and decision criteria.
• references/product-line-requirements.md: SPL commonality/variability analysis guide.

Last Updated: 2026-03-07 Skill Version: 1.0.0