In the previous section we learned that we want to draft requirements that are both measurable and specific, but what exactly does that mean? And why should we care? We’ll define these terms shortly, but let’s first consider the second question. We should care that our requirements are measurable and specific because they act as a sort of contract between you and the user/client. They outline what must, should, could, and won’t be developed, so if they are ambiguous for any reason, 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 own customers alphabetically based on the company name, and in descending order, then repeat the same query but in ascending order?
• Does the user get to see all of the customers in the list or just their own?
• If the list is incredibly long, is the entire 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 that the final system needed to have. You believe you’ve completed the implementation of 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 would be able to sort based on any of the available fields, either ascending or descending.

Since the requirement is neither specific nor measurable, both of you are correct. However, it is very likely that neither of you will 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 turned into 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, this means that a requirement is specific if it is unambiguous, and provides some obvious way to clearly determine if the requirement has been met. That is, 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 members of your team, the user, or the client as to whether or not you’ve implemented the requirement to their expectations. It will, however, reduce the likelihood that these sorts of disagreements will occur.

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