• Functional requirements specify what a software product should do:
  • Users must be able to log in.
• Non-functional requirements define how well it must accomplish these tasks under real-world conditions:
  • The login process should respond within two seconds under peak load.
  • All user credentials must be encrypted and stored securely.
• Non-functional requirements (NFRs) are as critical as functional requirements because they define a system's qualities and operational parameters.
• NFRs are essential for the following reasons:
  • Quality of Service: NFRs like response time, availability, and usability directly affect the user’s perception of quality.
  • System Stability: Requirements such as reliability, fault tolerance, and recoverability help maintain stable operation even when part of the system fails
  • Security and Compliance: Security-related NFRs dictate how data is protected, access is controlled, and audits are conducted.
  • Scalability and Performance: Requirements for throughput, capacity, and resource utilization ensure the software can handle growth in users or data.
    • Scaling can become prohibitively expensive or technically challenging if not addressed from the start.
  • Maintenance and Evolution: Maintainability, testability, and modularity requirements determine how easily bugs can be fixed and features added or adapted.
• NFRs are not mere “nice-to-haves” but essential components ensuring a software system meets user expectations and withstands real-world challenges.

Functional vs Non-Functional Requirements

• A payment system might have a functional requirement: “The system must allow a user to enter credit card details and process a payment.”
  • This requirement describes the “what” and outlines the essential functionality but does not detail the operational conditions under which this function must be performed effectively or securely.
• Non-Functional Requirements:
  • Ensure each payment transaction is processed within a 2-second response time under a load of up to 1,000 concurrent users.
  • Credit card data must be encrypted and compliant with payment industry regulations.
    • The system must enforce multi-factor authentication for administrator logins.
  • Design the payment flow to be intuitive, with minimal steps, and adhere to accessibility standards for visually impaired users.

Trade-Offs in Non-Functional Requirements

• Non-functional requirements (NFRs) are seldom isolated.
  • Optimizing for one often has a ripple effect on others.
  • This interdependency stems from finite system resources (time, memory, processing power, etc.) and design trade-offs (complexity, maintainability, etc.).
  • Enhancing a single non-functional aspect can harm others.

Encryption and Performance

• When an application adopts robust encryption algorithms for data at rest or in transit, it improves security by making unauthorized access or interception more difficult.
  • However, encrypting and decrypting data are CPU-intensive operations.
  • Under high concurrency, these operations can add noticeable latency to data read/write cycles or API requests.
  • If the infrastructure is not scaled or optimized to handle the extra load, response times may increase, affecting user satisfaction and overall throughput.
• Some strategies to balance this trade-off are as follows:
  • Hardware Acceleration: Use specialized hardware or CPU instructions for encryption/decryption to mitigate the performance impact.
  • Selective Encryption: Encrypt only the most sensitive data fields to reduce overhead.
  • Caching: Cache decrypted content or use secure sessions to minimize repeated encrypt-decrypt cycles but ensure proper key management to maintain security.

Low Latency and Resource Utilization

• For high-frequency trading or real-time analytics, systems are designed to respond in milliseconds, with near-zero delays.
• Achieving ultra-low latency often requires high-end hardware, faster network connections, and specialized architectures (in-memory databases and distributed caching).
• More sophisticated setups (like active-active deployments across multiple regions) can also introduce operational complexity and increased maintenance overhead.
• Some strategies to balance this trade-off are as follows:
  • Scaling vs. Optimization: Before scaling the infrastructure, optimize code paths, reduce unnecessary network hops, and implement efficient data structures.
  • Cost-Benefit Analysis: Quantify the return on investment for ultra-low latency.
    • For some use cases, a slight increase in response time (such as from 10ms to 50ms) may be acceptable if it substantially reduces costs.
  • Feature Trade-offs: Disable non-essential features or logging in high-throughput paths to minimize overhead.

Performance .vs Maintainability

• Sometimes, developers optimize software with low-level tweaks or non-standard data structures to maximize performance.
  • However, specialized code can become more challenging to read, test, and modify.
  • Developer onboarding takes longer, and routine changes might introduce regressions if the optimized sections aren’t well-documented or tested.