Stats
Actions
Tags
From s2s
Structures requirements using ISO 25010 quality model with 8 characteristics and 31 sub-characteristics. Helps define FRs, NFRs, acceptance criteria, and traceability.
How this skill is triggered — by the user, by Claude, or both
Slash command
/s2s:iso25010-requirementsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
ISO 25010 defines a product quality model with 8 characteristics and 31 sub-characteristics. This skill helps structure requirements to ensure comprehensive quality coverage.
ISO 25010 defines a product quality model with 8 characteristics and 31 sub-characteristics. This skill helps structure requirements to ensure comprehensive quality coverage.
| Characteristic | Sub-characteristics | Key Questions |
|---|---|---|
| Functional Suitability | Completeness, Correctness, Appropriateness | Does it do what users need? |
| Performance Efficiency | Time behavior, Resource utilization, Capacity | Is it fast and efficient? |
| Compatibility | Co-existence, Interoperability | Does it work with other systems? |
| Usability | Learnability, Operability, Accessibility | Can users use it effectively? |
| Reliability | Maturity, Availability, Fault tolerance, Recoverability | Does it work consistently? |
| Security | Confidentiality, Integrity, Non-repudiation, Accountability, Authenticity | Is it secure? |
| Maintainability | Modularity, Reusability, Analysability, Modifiability, Testability | Can it be maintained? |
| Portability | Adaptability, Installability, Replaceability | Can it run in different environments? |
These IDs are immutable across roundtable rounds and output formats.
| Prefix | Description | Example |
|---|---|---|
REQ-{NNN} | Generic requirement | REQ-001 |
FR-{AREA}-{NNN} | Functional requirement (with area) | FR-AUTH-001 |
NFR-{QUAL}-{NNN} | Non-functional requirement | NFR-PERF-001 |
BR-{NNN} | Business rule | BR-001 |
EX-{NNN} | Exclusion (out-of-scope) | EX-001 |
| Prefix | Description | Example |
|---|---|---|
ARCH-{NNN} | Architecture decision | ARCH-001 |
COMP-{NNN} | Component definition | COMP-001 |
| Prefix | Description | Example |
|---|---|---|
IDEA-{NNN} | Idea from dreamer phase | IDEA-001 |
RISK-{NNN} | Risk from critic phase | RISK-001 |
MIT-{NNN} | Mitigation for risk | MIT-001 |
| Prefix | Description | Example |
|---|---|---|
OQ-{NNN} | Open question | OQ-001 |
CONF-{NNN} | Conflict between participants | CONF-001 |
UC-{NNN} | Use case / user workflow | UC-001 |
CN-{NNN} | Technical/business constraint | CN-001 |
AS-{NNN} | Assumption to validate | AS-001 |
Area codes for REQ- (functional requirements):
Quality codes for NFR- (non-functional):
Mapping to Output Formats:
| Internal ID | SRS Section | Volere | Checklist |
|---|---|---|---|
| REQ-AUTH-001 | 3.1.1 | REQ-1 | ☐ Feature |
| NFR-PERF-001 | 4.1 | NFR-1 | ☐ Quality |
| EX-001 | 5.x | Excluded | (omitted) |
Examples:
REQ-AUTH-001 Login with email/password
REQ-USER-002 View user profile
NFR-PERF-001 Response time < 2s
NFR-SEC-001 Data encryption at rest
BR-001 Maximum 5 login attempts
UC-001 New user registration flow
EX-001 Mobile app (future phase)
CN-001 Must use existing PostgreSQL
AS-001 Users have stable internet
### {FR|NFR}-{ID}: {Title}
**Priority**: {P0|P1|P2|P3} or {Must|Should|Could|Won't}
**Status**: {Draft|Approved|Implemented|Verified}
**Description**:
{Clear statement of what is required}
**Rationale**:
{Why this requirement exists}
**Acceptance Criteria**:
- [ ] {Measurable criterion 1}
- [ ] {Measurable criterion 2}
**Dependencies**:
- Depends on: {requirement IDs}
- Enables: {requirement IDs}
### NFR-PERF-001: Response Time
**Metric**: API response time
**Target**: p95 < 200ms, p99 < 500ms
**Measurement**: Application metrics under normal load
**Acceptance Criteria**:
- [ ] 95th percentile response time under 200ms
- [ ] No request exceeds 2 second timeout
- [ ] Measured under expected peak load
### NFR-REL-001: System Availability
**Metric**: System uptime
**Target**: 99.9% availability (monthly)
**Measurement**: Monitoring system alerts
**Acceptance Criteria**:
- [ ] Monthly uptime ≥ 99.9%
- [ ] No single outage exceeds 15 minutes
- [ ] Recovery time objective: 5 minutes
### NFR-SEC-001: Authentication Security
**Metric**: Authentication strength
**Standard**: OWASP ASVS Level 2
**Acceptance Criteria**:
- [ ] Passwords hashed with bcrypt (cost ≥ 12)
- [ ] Session tokens are cryptographically random
- [ ] Failed login attempts are rate-limited
- [ ] No sensitive data in URLs or logs
In Spec2Ship projects:
.s2s/requirements.mdnpx claudepluginhub spec2ship/spec2ship --plugin s2sDefines measurable non-functional requirements (NFRs) for performance, reliability, security, privacy, accessibility, observability, and operations. Use when quality attributes need verification.
Assesses requirements quality against INVEST criteria, improves clarity, detects ambiguity, ensures completeness, and guides MoSCoW prioritization with checklists and refinement patterns.
Authors, updates, and validates atomic functional and non-functional requirements with traceability matrices, validation packs, and explicit human-in-the-loop approvals. Use for creating or reviewing requirements as source of truth.