Three Types of Requirements for Testing


Requirements for software are usually grouped into a bewildering array of categories. Functional and nonfunctional requirements are on top, and a huge number of subcategories are underneath. Here, Clint Hoagland boils it down to three categories, differentiated by the way they should be tested.

Let’s say you’re a new tester. You start your first day on the job, you are introduced to the team, and you are shown to your desk. You boot up your computer and meet your adversary: the software you are meant to test. Accompanying that software is a set of requirements that will guide you in your task.

A quick Internet search for “types of requirements” brings up various systems for categorizing requirements, including Hewlett-Packard’s FURPS+ model and the one advanced by the IEEE. These models can be helpful to those who gather requirements, but they’re not all that useful to a tester. For testers, I propose a different, much simpler system in which requirements are categorized by the way they should be tested. For testers, there are really only three categories: explicit, implicit, and latent requirements.

Explicit Requirements: The Things You Wrote Down
Our first type of requirement is the explicit requirement. This is the simplest type and the easiest to test. Explicit requirements are most commonly found in documents communicated by stakeholders to the development team. They might take the form of an elaborate design specification, a set of acceptance criteria, or a set of wireframes.

Is the software what was described by the explicit requirements? If so, that’s good. If it’s not, then that’s bad—log a bug. Simple, right?

What about in the cases where there isn’t a thorough specification? How do you know whether something is a bug or not?

The first thing to remember is that even in the cases where there isn’t an explicit design document, there will always be explicit requirements lying around somewhere. Look for explicit requirements in the form of claims—that is, communications to end users about things the software can do. These can typically be found in user documentation or in marketing materials.

The other thing to remember is that explicit requirements are only a piece of the puzzle.

Implicit Requirements: The Things Your Customers Will Expect
Implicit requirements are the second type. These are all the things that users are going to expect that were not captured explicitly. Examples include performance, usability, availability, and security. Users expect that their password will not be stored in plain text; that requirement need not be written down by anyone.

Consider a cloud-based storage product that lets you store your files online. The product gets a new explicit requirement: Users should be able to share private content to other users via URL, using a share button. However, while testing it is discovered that by modifying a value in the generated URL, it’s possible for other users to view all of the sharing user’s private content. This violates an implicit requirement that only shared content should be accessible to other users, resulting in a show-stopping bug.

Implicit requirements are sometimes called “nonfunctional” requirements, although I find that usage confusing. It’s certainly possible to capture business expectations about any of those “nonfunctional” areas explicitly, at which point they can be treated like any other explicit requirement.

Latent Requirements: Things That Will Delight Your Customers
Lastly, we have latent requirements. Latent requirements represent behaviors that users do not expect based on their previous experiences but which will make them like the software more. An example: My bank has an animated transition when I transfer money between accounts. I didn’t expect it to do that, but it does help me understand that I was successful, and it looks cool, so I’m delighted. Another example would be cloud-sync in gaming: When video games started allowing users to access their saved game files on any computer, users were surprised and delighted by that feature.

Some websites will auto-complete your username when you start to log in. Some will not. This is an example of a latent requirement that is, over time, becoming an implicit requirement.

User Comments

Kathy Iberle's picture

The FURPS and IEEE models can be very useful in test planning, because they provide a heuristic for finding those implicit requirements.  A list of possibly relevant attributes helps the test planner be both fast and thorough.  Many experienced testers have a favorite list, some based on requirements models and others based on a very similar concept often called "test types". 

Here's an example:

The same article is at: but the sidebar about test types isn't there.

May 3, 2016 - 1:22pm

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.