Definition and Overview
Concept
Non functional requirements (NFRs): system attributes defining quality, constraints, or system behavior beyond explicit functionalities. Examples: performance, usability, security.
Distinction from Functional Requirements
Functional requirements specify what system does. NFRs specify how system performs or constraints under which functions operate. NFRs often cross-cut multiple functions.
Role in Requirements Engineering
NFRs guide architecture, design, implementation, testing, and maintenance. Integral in defining system acceptance criteria and user satisfaction.
"Non functional requirements are as critical as functional ones; they shape system success and user experience." -- Ian Sommerville
Classification of Non Functional Requirements
Quality Attributes
Categories: performance, reliability, usability, security, maintainability, scalability, availability, and portability. Each defines specific system qualities.
Constraints
Restrictions on system development or operation: legal, regulatory, technological, environmental constraints. Examples: compliance, platform limitations.
Domain-Specific NFRs
Industry or application-specific requirements: e.g., real-time constraints in embedded systems, privacy in healthcare software.
| Category | Description |
|---|---|
| Performance | Speed, latency, throughput |
| Reliability | Availability, fault tolerance |
| Usability | Learnability, accessibility |
| Security | Confidentiality, integrity |
Importance in Software Engineering
System Quality Assurance
NFRs ensure system meets user expectations: speed, safety, reliability. Direct impact on user satisfaction and system success.
Architecture and Design Influence
NFRs constrain architectural choices: e.g., security needs may dictate encryption, performance requirements influence caching strategies.
Risk Mitigation
Early identification and specification reduce project risks: cost overruns, project delays, system failures.
Performance Requirements
Definition and Metrics
Performance: system responsiveness and efficiency. Metrics: response time, throughput, resource utilization.
Specification Techniques
Quantitative statements: e.g., "Response time under 2 seconds for 95% of requests." Benchmarks and load testing define targets.
Optimization Strategies
Caching, indexing, parallel processing, code optimization. Trade-offs with other NFRs such as security or maintainability.
Reliability Requirements
Concepts
Reliability: system's continuous correct operation under stated conditions. Includes availability, fault tolerance, recoverability.
Measurement
Metrics: Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR), availability percentage.
Techniques
Redundancy, error detection and correction, failover mechanisms, backup and restore procedures.
Availability = (MTBF) / (MTBF + MTTR) * 100%Usability Requirements
Definition
Usability: ease of use and learnability of the system. Includes accessibility, user satisfaction.
Evaluation Methods
Usability testing, heuristic evaluation, user surveys, task completion rates.
Design Considerations
Consistent UI, clear navigation, error prevention, accessibility standards compliance (e.g., WCAG).
Security Requirements
Security Goals
Confidentiality, integrity, availability (CIA triad). Authentication, authorization, non-repudiation.
Specification Approaches
Threat modeling, risk assessment, security policies formalization.
Implementation Techniques
Encryption, access control, secure coding practices, intrusion detection.
Maintainability Requirements
Scope
Ease of system modification, error correction, enhancement over time.
Metrics
Modularity, code complexity (e.g. cyclomatic complexity), documentation quality.
Strategies
Modular design, coding standards, automated testing, version control.
Scalability Requirements
Definition
System’s ability to handle growth: users, data volume, transactions without performance degradation.
Types
Vertical scaling (adding resources), horizontal scaling (adding nodes), elasticity.
Design Patterns
Load balancing, distributed systems, cloud-native architectures.
| Scaling Type | Description |
|---|---|
| Vertical Scaling | Increasing capacity of a single node |
| Horizontal Scaling | Adding more nodes to distribute load |
| Elastic Scaling | Dynamic resource allocation based on demand |
Specification and Measurement
SMART Criteria
Specific, Measurable, Achievable, Relevant, Time-bound. NFRs must be quantifiable and testable.
Use of Metrics and Benchmarks
Selecting appropriate performance indicators and thresholds. Benchmarking against standards or competitors.
Documentation Formats
Use cases, quality attribute scenarios, formal templates (e.g., IEEE 830).
Quality Attribute Scenario:- Source of stimulus: user- Stimulus: login request- Environment: normal operation- Artifact: authentication module- Response: response time ≤ 1 second- Response measure: 95% of requestsChallenges in Elicitation and Validation
Ambiguity and Subjectivity
NFRs often vague (e.g., "fast", "secure"). Difficult to formalize and measure.
Conflicting Requirements
Trade-offs: e.g., security may reduce usability or performance. Prioritization needed.
Stakeholder Communication
Difficulties in understanding NFRs by non-technical stakeholders. Requires clear language and examples.
Best Practices for Implementation
Early Integration
Define NFRs early in requirements phase to guide design and testing.
Continuous Validation
Iterative testing against NFRs using prototypes, simulations, and real measurements.
Cross-Disciplinary Collaboration
Involve architects, developers, testers, users, and domain experts for comprehensive coverage.
References
- I. Sommerville, Software Engineering, 10th ed., Pearson, 2015, pp. 135-160.
- K. Pohl, Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010, pp. 105-130.
- J. Bosch, "Design and Use of Software Architectures," ACM Computing Surveys, vol. 46, no. 1, 2013, pp. 1-30.
- M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003, pp. 45-70.
- G. Booch, J. Rumbaugh, and I. Jacobson, Unified Modeling Language User Guide, 2nd ed., Addison-Wesley, 2005, pp. 200-230.