Nonfunctional Requirements are Product features and dictate System design
Building quality products is a pride factor of most engineers.
How do you determine that your software product is actually meeting the quality bar?
Unfortunately, with ever changing technology innovation, customer needs and competitive landscape, quality is not a stagnant state. Often engineers who take pride in building to product requirements are surprised on how quickly the product doesn’t stand the test of time.
Over my journey in the last 20 years in leading engineering organizations, I have observed that often both product and engineering teams discount nonfunctional product requirements in favor of quick delivery.
What are nonfunctional product requirements?
Functional requirements represent the basic functionality of a product and its features and capabilities that deliver value to one or more customer needs.
Nonfunctional requirements ensure the adoption, retention, trust and longevity of the product life cycle with customers.
Would a customer be drawn to using a website that searches the products he/she desires with high accuracy but takes over 5 seconds to respond? Or would the same customer be more comfortable to using a website that delivers results quickly within 2 seconds with lesser accuracy?
Nonfunctional requirements given insight into the customer’s psychology behind the basic need which in the above instance is to just find relevant products from a catalog.
Below are the nonfunctional requirements to be considered with most software product designs.
Speed & Scalability: Does my search page need to respond with results, to a peak customer load of 1000 or 10,000 users and within 2 or 5 seconds?
Reliability (Precision) & Availability: Does my search page need to be available 99% of 24x7 or 99.9% or 98% or 95%? What is acceptable to customers? Does my search page provide results reliably when it is available?
Accuracy & Recall (Consistency): Are my search results accurately representing the customer keywords and customer intent? Are my search results predictable with repeatable searches?
Security & Privacy: Is my customer’s information like device information, IP addresses and other customer profile information secure? Does my customer feel that his/her product search history is secure and private?
Usability & Localization & Accessibility: How many clicks does my customer need to take to get to the product results? How are the results ranked and paginated? Is my customer searching for products that are global or locally available? Is my customer sensitive to the language of product search and display pages? Is my customer a privileged user, which means do the search and results pages need to support customers with disabilities like hearing, color blindness, complete blindness etc.?
Compatibility and Portability: Can my customers launch the search and results pages on any browser on desktop, laptop, or mobile devices? Will my customers download a separate search app on their mobile devices? Will this search app be compatible with other apps on their devices? Will this product search page work on different versions of chrome, safari, internet explorer?
How do these impact engineering design and build?
Speed & Scalability: Knowing expected response times and average & peak usage along with load distribution across a day dictates underlying architectural design.
It allows engineers to think deeply on:
a. What are the constraints and limitations of the dependent systems?
b. Where is my data store and do I cache my page rendering metadata and the product catalog data?
c. How will I distribute my loads to support the peak usage, and do I need to partition my data to attain the scalability?
d. What are my bottlenecks and how will work around these and monitor these?
Reliability (Precision) & Availability: Availability dictates load distribution of requests, maintenance windows and how code will be deployed and how much downtime is acceptable. Reliability dictates eventual consistency or real-time consistency and determines on how the system is designed to support balance between speed, scalability, reliability and availability.
Accuracy & Recall (Consistency):
Are my product search results accurately representing the customer keywords and customers intent? Are my product search results predictable with repeatable (recall) searches?
Trade-offs between the above non-functional requirements dictate the system design patterns adopted in the engineering builds.
Few examples are below:
a. Command and query responsibility segregation pattern (CRQS) — Separates read and update operations and helps maximize for performance, scalability, and security.
b. Asynchronous Request-Reply pattern — Decouples the backend processing from frontend display and this can be leveraged if precision & consistency can be eventual.
c. Bulkhead pattern — In case of a page being loaded using multiple services, an excessive load a service shouldn’t impact all consumers of the services and thus consumers can be isolated into pools.
d. Cache strategy — Trade-offs between data accuracy and consistency of recall determine when and where to use cache and what data elements are to be cached and how cache is populated (cache aside or cache write through) and cache eviction and refresh frequencies.
e. Throttling & Retries & Circuit Breaker — Usage patterns of customers determine if there is a need to control consumption especially if there is a cost associated to search results. Throttling customers per application or session etc. is required to meet a certain service level agreement. Customer or Client retries and how to exponential back-off retries in case of heavy system loads and where to design the circuit breaker to avoid stalling the entire system.
f. Sharding/Partioning and geo-distribution of data — This can improve scalability when storing and accessing large volumes of data. What data should be partitioned and how? Are we partitioning to accommodate for growing storage space or for computing power needs or for geo distribution?
Usability & Localization & Accessibility: These directly impact the presentation of the applications. Knowing the usage clicks and pagination patterns, sorting and filters and ranking of data and if different use cases will use similar UI designs and will need localized content and accessibility measures is crucial. These will help engineers design the presentation layer in a unified reusable fashion to ensure that UI code is extensible and also modular and flexible to meet the needs to geo-expansion. These determine the design principles of the presentation layers, i.e., server-side or client-side rendering or use web page module federated logic.
Compatibility and Portability: If the page is accessible from different devices, then the code design can modularize the data rendering layer from the presentation logic. If the page is accessible across multiple browsers and versions, then the client-side rendering scripts may need to be designed differently to scale widely.
Security & Privacy: What data is private to the customer and how to transport and store this is in a secure fashion? How customers can view and change this data and how their data is shared with other downstream and third-party systems? What are the encryption protocols to be used for storing and also for transporting data between external to internal components and within internal components? What data can be logged into the application log files and what data is visible to engineers and who can triage and troubleshoot issues?
How can engineering teams’ approach these during requirements gathering?
- Ask repeated questions to your product partners and develop a checklist to collect their inputs in a standardized format.
2. Review the current system architecture and bottlenecks and identify learnings from current usage patterns and production incidents.
3. Think big and ahead: Is this an experiment? Do you want this system scale for 5x-10x load and 5x-10x regions? Will I require significant tech-debt and re-designing of the architecture to support this in near future?
Finally: Identify trade-offs jointly with Product partners much ahead on before implementing to determine an optimum design approach.
