In the previous chapter, we learned the importance of measurable and specific requirements, but what exactly does that mean? And why should we care? We’ll define these terms shortly, but let’s consider the second question. We should care that our requirements are measurable and specific because they act as a contract between you and the user/client. They outline what must, should, could, and won’t be developed, so if they are ambiguous, you and your user/client might have different opinions about whether or not you’ve completed the job as described.

Consider for example the following requirement for a simple application that keeps track of a company’s sales team (which records the employee ID, date of birth, social insurance number, first name, last name, address, phone number, email address, gender pronouns, and manager’s name), and the customers that each member of the team sells to (including their customer ID, company name, company address, company website, contact person’s first and last name, phone number, email address, gender pronouns, sales history, employee ID that manages the customer, and whether or not the customer is active):

Ask yourself the following questions:

• How is the list to be sorted? Alphabetically by company name or numerically by client ID, or perhaps some other way? Ascending or descending order?
• Does the system only sort in one way, or does the user have options? Could they, for example, sort their customers alphabetically based on the company name, and in descending order, then repeat the same query but in ascending order?
• Does the user see all customers in the list or just their own?
• If the list is incredibly long, is the full list returned to the user, or do they see only the first 20 (for example) results?
• If you aren’t quite sure what the answers to these questions are, or if you have multiple potential answers, don’t be alarmed. This requirement is not well written – as it is neither specific nor measurable.

Before we continue with the definitions, imagine you and your client agreed that this requirement described something the final system needed to have. You believe you’ve implemented the requirement because you’ve created a method for a sales team member to print a list of their customers sorted by the company name in ascending alphabetical order. The user/client, however, assumed that this meant that the user could also sort based on any of the available fields, either ascending or descending.

Since the requirement is neither specific nor measurable, both are correct. However, neither of you will likely be happy. They will not be happy because they will feel that you haven’t completed the job – and likely will ask you to complete it (without extra resources to do so). And you won’t be happy because suddenly a simple project has become a headache that requires further work and likely no money.

Specificity

A requirement is said to have specificity if it clearly describes the scope of the requirement, including any testable definitions of performance.

In plain language, a requirement is specific if it is unambiguous, and provides an obvious way to determine if it has been met. After you or someone on your team has done the work to implement a requirement, there should be no debate by you, your teammates, your manager, or your user and client as to whether or not you’ve successfully implemented it.

Further, we care that our requirements are measurable and specific because it helps to ensure they are easy to understand, verifiable, and aren’t open to interpretation by any of the people involved in the development process (i.e. you, your manager, and the user/client).

Measurability

A requirement is said to be measurable if it includes some method to determine if it has been implemented properly. That is, the method should provide some testable definition of performance. The method needs to be stated such that it will reasonably eliminate ambiguity regardless of whoever evaluates the implementation of the requirement.

Consider the following requirement. This requirement is more specific than the previous one we considered. It is also measurable.

Why is this a better requirement?

The requirement is more specific because we know that the results are to be sorted in ascending alphabetical order by company name. We also know that the results are to be displayed (i.e. not printed to a report, or output to a file, for example) and that the results will only include the sales team member’s active customers.

This requirement is also measurable because it is easily verifiable. We can easily check that at most 20 results are displayed in a paginated list and that the results are sorted accordingly. And we can also easily check if this is all done in 10 seconds or less.

When you begin drafting requirements, you will want to remove ambiguity as best you can by being specific and building in easily verifiable outcomes. This won’t guarantee that you won’t have disagreements with your team, the user, or the client. It will, however, reduce the likelihood that a disagreement occurs.

Beyond a single requirement, you can also reduce ambiguity by using several requirements. For example, the requirements listed below (in combination with our improved requirement on the last page) describe a phasing in of functionality; each specific and measurable. When combined, they set expectations better than any single requirement.

What do you notice about the won’t requirements?

Activity: Evaluating Requirements

Determine if the following requirements are specific and measurable. Rewrite those that aren’t specific or measurable so that they are.

The system must allow the user to search for a list of results.

The client must be able to use the system on their phone.

Review Questions