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.

CategoryDescription
PerformanceSpeed, latency, throughput
ReliabilityAvailability, fault tolerance
UsabilityLearnability, accessibility
SecurityConfidentiality, 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 TypeDescription
Vertical ScalingIncreasing capacity of a single node
Horizontal ScalingAdding more nodes to distribute load
Elastic ScalingDynamic 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 requests

Challenges 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.