The "-ilities" framework for non-functional requirements. Use when defining NFRs, evaluating architecture trade-offs, or ensuring quality attributes are addressed in system design. Covers scalability, reliability, availability, performance, security, maintainability, and more.
Provides a comprehensive framework of quality attributes (NFRs) for system design. Use when defining requirements, evaluating architectural trade-offs, or conducting design reviews to ensure all "-ilities" are addressed.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install systems-design@melodic-softwareThis skill is limited to using the following tools:
This skill provides a comprehensive framework for understanding and applying quality attributes (non-functional requirements) in system design.
Keywords: NFR, non-functional requirements, quality attributes, -ilities, scalability, reliability, availability, performance, security, maintainability, ISO 25010
Use this skill when:
Quality attributes (QAs) describe HOW a system performs, not WHAT it does. They're often called:
Key insight: Functional requirements define features; quality attributes define how well those features work.
| Attribute | Definition | Key Question |
|---|---|---|
| Scalability | Handle growing load | Can we grow 10x? 100x? |
| Reliability | Consistent correct operation | Does it work correctly every time? |
| Availability | System uptime | Is it running when needed? |
| Performance | Speed and throughput | How fast is it? |
| Security | Protection from threats | Is it safe from attacks? |
| Maintainability | Ease of change | Can we update it easily? |
| Attribute | Definition | Key Question |
|---|---|---|
| Testability | Ease of verification | Can we test it effectively? |
| Observability | System visibility | Can we see what's happening? |
| Operability | Ease of operation | Can we run it in production? |
| Portability | Platform independence | Can we move it? |
| Interoperability | System integration | Can it work with others? |
| Cost Efficiency | Resource optimization | Is it cost-effective? |
Definition: The ability to handle increased load by adding resources.
| Type | Description | Example |
|---|---|---|
| Vertical | Add more power to existing machines | Upgrade to larger instance |
| Horizontal | Add more machines | Add more servers behind load balancer |
| Elastic | Automatic scaling based on load | Auto-scaling groups |
Measurement:
- Maximum concurrent users
- Requests per second at given latency
- Data volume supported
- Cost per transaction at scale
Trade-offs:
Definition: The probability of correct operation over time.
| Concept | Definition |
|---|---|
| MTBF | Mean Time Between Failures |
| MTTR | Mean Time To Recovery |
| Fault Tolerance | Continue despite component failures |
| Resilience | Recover from failures gracefully |
Measurement:
- Error rate (errors / total requests)
- Failure rate (failures / time period)
- Data accuracy percentage
- Successful transaction rate
Trade-offs:
Definition: The proportion of time a system is operational.
| Level | Uptime | Downtime/Year | Downtime/Month |
|---|---|---|---|
| 99% | Two 9s | 3.65 days | 7.31 hours |
| 99.9% | Three 9s | 8.76 hours | 43.8 minutes |
| 99.99% | Four 9s | 52.6 minutes | 4.38 minutes |
| 99.999% | Five 9s | 5.26 minutes | 26.3 seconds |
Measurement:
Availability = Uptime / (Uptime + Downtime)
= MTBF / (MTBF + MTTR)
Trade-offs:
Definition: How fast and efficient the system operates.
| Metric | Definition |
|---|---|
| Latency | Time to complete one request |
| Throughput | Requests processed per unit time |
| Response Time | Total time user waits |
| Utilization | Resource usage percentage |
Common Targets:
- Web page load: < 2 seconds
- API response: < 100 ms (p99)
- Database query: < 10 ms
- Batch job: < scheduled window
Trade-offs:
Definition: Protection of data and systems from unauthorized access.
| Principle | Description |
|---|---|
| Confidentiality | Data accessible only to authorized |
| Integrity | Data is accurate and unaltered |
| Availability | Systems accessible when needed |
| Non-repudiation | Actions are attributable |
Measurement:
- Time to detect breaches
- Number of vulnerabilities
- Compliance audit results
- Mean time to patch
Trade-offs:
Definition: Ease of modifying the system over time.
| Aspect | Description |
|---|---|
| Modularity | Components can change independently |
| Reusability | Components can be repurposed |
| Analyzability | Easy to understand the system |
| Modifiability | Easy to make changes |
| Testability | Easy to verify changes |
Measurement:
- Time to implement typical change
- Defect injection rate per change
- Code complexity metrics
- Documentation coverage
Trade-offs:
Use this template to make QAs measurable:
Source: [Who or what generates the stimulus?]
Stimulus: [What event occurs?]
Artifact: [What part of the system is affected?]
Environment:[Under what conditions?]
Response: [How should the system respond?]
Measure: [How do we know it succeeded?]
Scalability Scenario:
Source: Marketing campaign
Stimulus: 10x traffic spike
Artifact: Web application
Environment:Normal operation
Response: Auto-scale to handle load
Measure: Latency stays under 200ms at p99
Availability Scenario:
Source: Hardware failure
Stimulus: Database server dies
Artifact: Order processing system
Environment:Peak business hours
Response: Failover to replica
Measure: Recovery in < 30 seconds, no data loss
Security Scenario:
Source: External attacker
Stimulus: SQL injection attempt
Artifact: User authentication
Environment:Production
Response: Block attack, alert security team
Measure: Zero successful injections, alert within 5 minutes
The ISO 25010 standard defines 8 quality characteristics:
| Characteristic | Sub-characteristics |
|---|---|
| Functional Suitability | Completeness, correctness, appropriateness |
| Performance Efficiency | Time behavior, resource utilization, capacity |
| Compatibility | Co-existence, interoperability |
| Usability | Learnability, operability, accessibility |
| Reliability | Maturity, availability, fault tolerance, recoverability |
| Security | Confidentiality, integrity, non-repudiation, accountability |
| Maintainability | Modularity, reusability, analyzability, modifiability, testability |
| Portability | Adaptability, installability, replaceability |
| Decision | Improves | Hurts |
|---|---|---|
| Add caching | Performance | Consistency, complexity |
| Add replication | Availability | Consistency, cost |
| Use async processing | Throughput | Latency, complexity |
| Shard database | Scalability | Cross-shard queries |
| Add encryption | Security | Performance |
| Use microservices | Maintainability, scalability | Latency, complexity |
Before finalizing a design, verify:
| Tactic | Description |
|---|---|
| Horizontal scaling | Add more instances |
| Load balancing | Distribute traffic |
| Sharding | Partition data |
| Caching | Reduce repeated work |
| Async processing | Decouple components |
| Tactic | Description |
|---|---|
| Redundancy | Multiple instances of components |
| Failover | Automatic switch to backup |
| Health checks | Detect failures early |
| Graceful degradation | Reduce functionality vs complete failure |
| Geographic distribution | Survive datacenter failures |
| Tactic | Description |
|---|---|
| Caching | Reduce computation/IO |
| CDN | Serve content closer to users |
| Connection pooling | Reuse expensive connections |
| Compression | Reduce data transfer |
| Indexing | Speed up queries |
| Tactic | Description |
|---|---|
| Encryption | Protect data at rest and in transit |
| Authentication | Verify identity |
| Authorization | Control access |
| Audit logging | Track actions |
| Input validation | Prevent injection attacks |
| Business Requirement | Quality Attribute | Technical Implication |
|---|---|---|
| "Must handle Black Friday traffic" | Scalability | Auto-scaling, elastic capacity |
| "Cannot lose orders" | Reliability, durability | Replication, backups, transactions |
| "Always available" | Availability | Redundancy, failover, monitoring |
| "Fast checkout" | Performance | Caching, optimization, CDN |
| "Protect customer data" | Security | Encryption, access control, auditing |
| "Easy to add features" | Maintainability | Modular design, clean architecture |
| "Regulatory compliance" | Security, auditability | Logging, encryption, access control |
| "Global users" | Performance, availability | CDN, geographic distribution |
design-interview-methodology - Overall interview frameworkestimation-techniques - Quantify capacity requirementscap-theorem - Consistency/availability trade-offs (Phase 2)trade-off-analysis - ATAM and decision frameworks (Phase 5)architectural-tactics - Detailed tactics per attribute (Phase 5)/sd:analyze-nfrs [scope] - Analyze quality attributes in code (Phase 5)/sd:explain <concept> - Explain any quality attributetrade-off-analyzer - Evaluate design trade-offs (Phase 2)sre-persona - Reliability/observability perspective (Phase 5)security-architect - Security implications (Phase 5)Date: 2025-12-26 Model: claude-opus-4-5-20251101
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.