By Clint Hoagland
Summary:
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.
|