In this post, I will quickly explain what non-functional requirements are, and then discuss a technique I use to capture non-functional requirements.

What are non-functional requirements?

Solution Architecture must take both functional and non-functional requirements into consideration. While functional requirements describe how the system should behave (ex: display order info), non-functional requirements describe the expected quality of that behavior (ex: display within x seconds, display to managers only, displaying system should be available until 10pm, etc.). Non-functional requirements, also referred to as systemic qualities, are typically captured under the following areas: usability, security, response time, throughput, scalability, availability, fault tolerance, maintainability, flexibility, extensibility, portability, audit-ability, etc.

Capturing non-functional requirements

Take the example of a simple shopping cart web application. The functional requirements (i.e. how the web app is expected to behave) can be captured in a backlog list of user stories. Not all of them will be “architecturally significant” 1. Without getting into how we arrived at it, let us say the significant user stories are: (a) As a customer, I need to search and find items so that I can add them to my shopping cart (b) As a customer, I need to submit my order so that the items I bought can get shipped to me (c) As a sales manager, I need to see the list of orders made every day, so I can make inventory decisions (d) As a customer, I expect to be notified when my items are shipped, so I know when to expect them.

A non-functional requirements questionnaire can now be prepared to ask the following kinds of questions for each of these significant user stories: What is the maximum acceptable response time, what kinds of users should have access to this user story experience, how many such users are there, is there a specific time when they access it, how many times will they access it during the day, how much time do they spend on this user story experience once they access it, how much “think time” or “inactive time” is expected during this user story experience, how long can this user story experience be unavailable per day, should this specific user interaction be audited, how many more users do you expect in 1/2/3 years from now, how often does the underlying data (products, pricing, etc.) change, how easy should it be to change, and so on. This is only a sample list of questions. Once the high level functional requirements are known, it should be pretty straightforward to come up with a customized questionnaire.

I usually use a questionnaire spreadsheet with a separate sheet for each systemic quality area: security, audit-ability, response time, throughput, scalability, availability, maintainability, etc. I place the above questions in the appropriate sheets. Since it is very common for systemic quality requirements to be different for the different user stories, I create separate sections per significant user story within each of the sheets, and I ask similar questions for each user story. For example, the number of shoppers expected will be much larger than the number of sales managers…so the throughput requirements for user stories (a) & (b) are very different from the throughput requirement for user story (c). Similarly, the shopping cart UI needs to be very responsive while it is okay for a notification to arrive 5 minutes late…so the response time requirement for user story (a) is different from the response time requirement for user story (d). Displayed below are a couple of sample sheets.

Sample Response Time requirements sheet
“Search items” user story
what is expected average response time? 1 sec
what is the max response time that is acceptable? 5 sec
are there times during the day when slower response time is acceptable? Is so, what times? No
“Receive notifications” user story
how soon should the user receive a notification after an item is shipped? 1 hr
what is the longest acceptable delay in sending it? 12 hrs
 …  …

 

Sample Security requirements sheet
“Search items” user story
should the search functionality be secured? no
if so, how should the users be authenticated? n/a
are there different types of users accessing this functionality? explain? n/a
“Receive notification” user story
how should the notification be received by the user? email
should the notification sending mechanism be secured? no
are there guaranteed delivery expectations? explain? no

 

Quantifying the non-functional requirements

For most of the systemic quality areas, the business can provide easily quantifiable answers to questions. For example, desired response time can be captured in seconds or milliseconds, availability requirements can be captured in terms of minutes of downtime allowed per a 24 hour period, security requirements can be captured in terms of specific roles, and so on.

But for some systemic qualities like throughput and scalability, the business cannot provide direct answers, for example, in terms of “concurrent sessions”, or “TPS (transactions per second)”. These values need to be derived from the answers the business provides. I will cover that in my next post.

Summary

In order to implement an architecturally sound software solution, it is important to understand the non-functional requirements along with the functional requirements. These requirements can be captured from the business by asking questions designed to get quantifiable answers. The answers should be used as a key input into making architectural decisions.