Non Functional Requirements: The Usual Suspects

Posted on Monday, April 20, 2009


In Part-I of this series we looked at what non-functional requirements were and how different people react to non-functional requirements.


Ask any team what do we mean by NFRs and most probable answer would be the following and most probably in the order mentioned below

  • Performance
  • Scalability
  • Availability
  • Security
  • Maintainability
  • Reliability

If you come up with a different list on your first pass when asked about NFRs, let me know.

The NFRs which would generally give the biggest bang for your buck are Performance, Scalability, Reliability and Availability. Once you have taken care of these I would recommend looking at the others like Security, maintainability, re-usability, usability etc.

So lets us look at them one by one

Performance – is usually gauged in terms of response time for a transaction or the number of MIPS (millions of instructions per second) at which a system functions. For web based systems the SLAs (Service Level Agreements) are defined in terms of the time spent in terms of getting a response for a request. For example one may say that the search should fetch results in < 2s under a load of 200 concurrent users. Here the load is very important as without the load performance numbers would not hold much meaning. The search could respond back in < 0.01 s if there is only one user on the system and has all the system resources like CPU, memory etc at his disposal.

Scalability – Is the ability of a computer application or product (hardware or software) to continue to function well when it (or its context) is changed in size or volume in order to meet a user need. An application cannot scale indefinitely. Within the given gamut of architectural and infrastructure constraints if the application is able to meet the desired Quality of service for an increased user load then the application is said to be scalable. However, if there is a degradation in performance with the increased user load and the application is not able to meet the QoS then the application needs to be modfied to make it more scalable. This enhanced scalability might come in terms of Vertical Scaling or Horizontal Scaling or a combination of both.

Reliability – Software Reliability is the probability of failure-free software operation for a specified period of time in a specified environment.This is different from System Reliability which depends on both hardware and software reliability. A software could be very reliable but if the underlying network is choked and prone to frequent outages then the System reliability takes a beating. There are various techniques used to measure software and hardware reliability. Some factors on which software reliability would depend can be divided into static and dynamic metrics. The static code metric is divided into three categories with measurements under each:  Line Count, Complexity and Structure, and Object-Oriented metrics.  The dynamic metric has two major measurements:  Failure Rate Data and Problem Reports.

Availability – Is defined as the amount of time the product is available for the end user to use.Availability is defined by uptime. I.e. the time between failures. It is dependent upon

  • Downtime and
  • Recovery Time

Downtime is the amount of time that the system is unavailable due to either failures or scheduled maintenance. Recovery time is the average time it takes to recover from failures. This includes time for detection, isolation and resolution. Hence to have high availability, you must have low downtime and low recovery time. Availability is usually defined in terms of nines i.e. 3 nines, 4 nines etc etc. If a system’s availability is defined as 4 nines ie 99.99% then 24×7 system can be down for approximately 53 minutes during an year. However, products define their availability based on the agreed hours of operation. Hence, instead of 24×7 the agreed upon SLA might be 20×6 for example.

In the next post we would see how each of these characteristics should be addressed at the time of User Story definition and requirement clarification.