Technical 

Non-functional requirements basics

Sree , ,

Non-functional requirements (NFRs) are as important as business/functional requirements of any systems we implement. They outline the system constraints like performance, scalability etc. and influence architectural decisions. Why should TPMs care about NFRs? I managed a couple of programs which consisted of creating applications for internal users and to get a minimum viable product (MVP) out and to showcase the business value, we deprioritized NFRs. It worked out well for one system, but it required us to revisit several design choices for another system. In hindsight, if I were to redo any of the programs, I would go through all the NFRs and make thoughtful choices for each of them by including the key stakeholders in the decision-making process.  

Your application user base is going to heavily influence NFRs. I am going to use the following two terms throughout this blog to refer to the user base:

  • “Internal application” refers to applications/systems used exclusively by your company employees/contractors. Example: System to track your vacation days.
  • “External application” refers to applications/systems that are used by your customers. Example: LinkedIn, Facebook etc.

I would highly recommend adding the NFRs as a checklist in the design document template if they are not already listed there. Here are some key NFRs:

1. Security

Security is of paramount importance. If it an external application think about authentication, authorization, encryption, and auditing requirements. If it is an internal application evaluate if the existing Single Sign On (SSO) within your company would suffice. If not, think about the type of information, the access level of employees etc. and incorporate security requirements accordingly.

2. Performance

Performance measures the responsiveness of the system/application. It is measured in terms of the following.

  1. Response time Response time is the total time it takes from when a user makes a request until they receive a response. Response time is measured in milliseconds.
  2. Latency is the delay incurred in communicating a message (the time the message spends “on the wire”) and is measured in milliseconds. Latency can either be measured as the Round Trip Time (RTT) or the Time to First Byte (TTFB):
    • RTT is defined as the amount of time it takes a packet to get from the client to the server and back.
    • TTFB is the amount of time it takes for the server to receive the first byte of data when the client sends a request.
  3. Throughput measures the quantity of data sent and received within a unit of time and is measured in bits per second (bps) in the form of megabits per second (Mbps) or gigabits per second (Gbps).
  4. Bandwidth  describes the maximum amount of data that can be transferred throughout your network. The maximum bandwidth of your network is limited to the standard of your internet connection and the capabilities of your network devices. Think of bandwidth as the limits of your network connection. In contrast, throughput is the actual data transfer rate that occurs on your network. Throughput is lower than bandwidth.

3. Usability

Determines how hard/easy it is for the user to interact/use your application. If the user interface is not intuitive, regardless of how much documentation you provide on using the application, users are going to turn away. Usability is equally important both for internal and external applications.

If you are developing an internal application and do not have a UI / UX engineer nor a Product Manager, it would be great for a TPM to step into that role and do some research around usability, create some mocks and do a usability study.

Ensure to measure both qualitative and quantitative metrics to measure usability. Here is a site that talks about measuring Usability.

4. Scalability

Scalability is the ability of the application to perform under increased loads. Example: If your application currently handles one million users can it handle 10 million users without performance degradation?

Scalability can be measured over multiple dimensions, such as:

  • Administrative scalability: The ability for an increasing number of organizations or users to access a system. Thinking through a couple of internal systems I worked on, both provided team-based dashboards and worked great for ~5 teams. The UI/UX proved unwieldy when we had to scale it to ~20 teams. If we had thought about scalability during the design phase about extending out to 20+ teams, we would have probably made different UI/UX choices.
  • Functional scalability: The ability to enhance the system by adding new functionality without disrupting existing activities.
  • Geographic scalability: The ability to maintain effectiveness during expansion from a local area to a larger region.
  • Load scalability: The ability for a distributed system to expand and contract to accommodate heavier or lighter loads, including, the ease with which a system or component can be modified, added, or removed, to accommodate changing loads.
  • Generation scalability: The ability of a system to scale by adopting new generations of components.
  • Heterogeneous scalability is the ability to adopt components from different vendors.

5. Reliability

Reliability is the ability of a system to function without failures under stated conditions over a period. Continuing with the example of the internal application that I worked on, in the rush to rollout an MVP we did not invest the time in creating a staging/test environment. It sounds super basic that we need to have a test environment however, the system was too complex to create and maintain a parallel test environment due to which we made that decision. We could afford to take a hit on reliability while we were trying to hit the ground running but eventually as the user base increased, we could not impact the reliability and we created a test environment.

Ways to measure reliability:

  • MTTR: Mean time to repair – time needed to bring back an application online either by fixing a bug or rolling back changes. Lower the MTTR the better.
  • MTBF : Mean time between failures – higher the MTBF the better.  

6. Availability

Availability measures the system uptime or how long the system is available to use for the customers. High availability systems are typically specified as 99.98%, 99.999% or 99.9996%. If it is an internal application you can have lower availability depending on when the typical users use that system. Evaluate if any users use the system during nights and weekends. You can define SLAs with your customers that you would ensure that the application is up and running during weekdays etc.

7. Maintainability

Maintainability determines how easy it is to maintain the application. Maintainability involves a system of continuous improvement – learning from the past in order to improve the ability to maintain systems, or improve reliability of systems based on maintenance experience. Measuring software maintainability is non-trivial as there is no single metric to state if one application is more maintainable than the other.

8. Supportability

It refers to the ability of support personnel to deploy, and monitor applications, identify exceptions in pursuit of solving a problem and restoring the application when there is a bug. You can improve supportability by creating automated alerts and monitoring. If you have Site Reliability Engineering team or DevOps, including them in the design discussions would help.

9. Documentation

While it doesn’t sound like a typical NFR, I have included here as we often miss out on including the effort estimates needed for documentation. Determine if any user manuals, or video tutorials need to be created and any training needs.

Based on my experience, these are the nine NFRs I would consider while creating any application. If I missed out on any other important NFRs, please leave a comment.

Sree

Sree is a PMP, PgMP, PMI-ACP certified Technical Program Manager (TPM)