FURPS is an acronym for requirements management, elaborated by Grady and Caswell decades ago. It stands for Functionality, Usability, Reliability, Performance, and Supportability. It helps to collect the complete set of requirements without overlooking essential non-functional needs and expectations of a customer and end-users. Many product owners and even whole teams often concentrate on functional requirements only, neglecting the rest.
FURPS has been widely used in old development processes such as RUP. However, now it seems to be forgotten by many or even unknown to the new generation of product owners.
Let’s consider the importance and goal of each part of the requirements. I typically use an elevator as an example.
“Functional” is the most critical part of the requirements. It tells us why the customer wants us to create the product, how the customer is going to use it, and, so, how the customer will decide that the product satisfies his or her needs. In our example, if the elevator does not move between the floors, it is utterly useless. We can tell the same about any other product. If the product does not solve customer problems or does not satisfy customer needs and expectations, then the whole work of the scrum team is pure genuine Muda or waste of time and resources.
At the same time, it is the most natural to describe for the product owner and the most engaging subject for discussions between the team and the customer. So it is typically the easy part of the job.
Along came the rest. Very boring, often unclear for the customer, often requiring specialized technical expertise. These are non-functional requirements.
Usability. If the elevator from our example moves between floors, but all (e.g., somebody put the control buttons on the ceiling) or some (e.g., there are no Braile markings for blind people), cannot operate it, the elevator remains useless.
Practically speaking, usability is about the ability of the expected user(s) to operate our product under the expected operating conditions. It helps to describe the users and the operating conditions and then distinguish them from the developers and the office environment during the development and the early stages of the testing. Operating conditions include:
- physical, mental (what he/she can), educational (what he/she knows), social (what he/she used to do) characteristics of the user;
- environmental conditions (such as the position of the user, light, available space, noise, whether operating the product is the primary function of the user, what else is the user doing when running the product, etc.);
- process conditions (such as operation velocity and cadence, distracting factors, price of error).
Reliability. If the elevator moves and our users can operate it, but it fails to do the job in 1 of 10 cases, somehow it is usable and even may be considered as a minimal viable product. At least 9 of 10 customers now ride the elevator instead of crawling the stairs.
When we speak of reliability, first of all, it is about durability, or, typically, the interval between failures or the maximum length of the interval between scheduled services.
Next, it is about the ability of the product to withstand rough conditions, such as unexpected or intentionally malicious user behavior, as well as 3rd party products and equipment failures. I always consider the detection and reporting failures as a part of reliability. Last but not least, reliability is about how fast and using which efforts the system must be able to recover after the crash.
Performance. Let say our elevator moves, the users can operate it, and it works whenever it is needed. Still, it moves slowly or consumes too much electricity. It typically satisfies the end-users but has an unacceptable economic performance. That’s an example of the performance requirements.
In most cases the performance is about:
- How fast the system should answer;
- How much resources the system is allowed to use (including processor time, memory, disk space and traffic, network traffic).
Supportability. Without supportability, our elevator would do its job correctly, conveniently, reliably, and fast, but it would be a nightmare for the service team. This part of the requirements does not affect the end-users at all. It is also impossible to discover these requirements by the analysis of the day-by-day usage of the system.
Supportability is about how the operation team on the customer side will build, distribute, install, configure, monitor, and update the product. It is also about how our or the other team will be able to modify or extend the product in the future.
“Thanks” to the SCRUM exam that forces you to answer that “end-user satisfaction is the primary goal for the team,” the last two kinds of requirements: performance and supportability are routinely ignored by the teams, leaving sponsors of the project routinely unsatisfied with the product performance. In the Rational Process, the product sponsors and support team participated in requirements collection as much as the end-users do.
It may look scary for the typical product owner if he or she does not engage the development team into backlog related activities or limits the development team participation to decomposition and estimation only. Non-functional requirements are a perfect opportunity to engage the developers into the requirements management, utilize their knowledge and experience, and to delegate this part of the job to those who can do it best.
I hope this article would help the product owners to facilitate the creation of better and more complete requirements as well as to promote collective ownership and everybody engagement on the product backlog.
My name is Nikolay Gekht, and I am the CTO of Gehtsoft USA, a salted project and product manager with 20+ years of experience in creating products and establishing development processed under Unified Process, Scrum and DevOps.
This article is a part of my course “Requirement Management using Object-Oriented Analysis and Elements of Unified Process”. I have been delivering this course for the past 15 years and prepared dozens of highly-qualified analysts and product owners.