Specificity And Measurable Requirements

In the previous chapter, we discussed the importance of writing requirements that are both specific and measurable.

But why does this matter?

The short answer is that requirements act as a shared understanding between the software team and the people who will use the system.

When requirements are clear, everyone involved has a common understanding of what is expected.

When requirements are vague, people often fill in the missing details differently.

This can lead to misunderstandings, frustration, delays, and additional work.

In many ways, requirements function as an agreement between designers, developers, clients, and users. They help establish what the system is expected to do, what is considered complete, and what is outside the scope of the project.

For this reason, specificity and measurability are not simply technical concepts. They are communication tools.

When Requirements Are Too Vague

Consider the following requirement for a system used by a company’s sales team:

The user must be able to sort a list of their active clients.

At first glance, this requirement may seem reasonable.

However, take a moment to think about the questions that immediately arise.

• How should the list be sorted?
• By company name?
• By customer ID?
• By sales volume?
• In ascending or descending order?
• Can the user choose different sorting methods?
• Does the list include all customers or only those assigned to that employee?
• If there are hundreds of customers, are all results displayed at once?
• Is the information displayed on screen, exported to a report, or both?

If different people answer these questions differently, then the requirement is not sufficiently clear.

The problem is not that the requirement is wrong.

The problem is that it leaves too much open to interpretation.

The Cost Of Ambiguity

Imagine that a client approves the requirement:

The user must be able to sort a list of their active clients.

You interpret this requirement as:

Display a list of active customers sorted alphabetically by company name.

The client interprets the same requirement as:

Allow users to sort active customers by any available field in either ascending or descending order.

Both interpretations seem reasonable.

The difficulty is that they are not the same.

After weeks of development, you may believe the requirement has been completed successfully, while the client may believe important functionality is missing.

Neither side intended to create a problem.

The misunderstanding emerged because the requirement was ambiguous.

Good requirements reduce the likelihood of these situations occurring.

What Makes A Requirement Specific?

A requirement is specific when it clearly describes what is expected and leaves little room for interpretation.

In practical terms, a specific requirement:

• Defines the scope of the functionality;
• Uses clear and unambiguous language;
• Identifies any important constraints; and
• Provides enough detail that everyone understands what success looks like.

When a requirement is specific, there should be little debate about whether it has been implemented correctly.

The software team, the client, and the users should all reach the same conclusion when evaluating the final system.

Specificity helps create shared understanding.

What Makes A Requirement Measurable?

A requirement is measurable when it provides a clear way to determine whether it has been satisfied.

In other words, it includes some testable definition of success.

If a requirement is measurable, different people evaluating the same implementation should reach the same conclusion about whether the requirement has been met.

Consider the following requirement: A member of the sales team must be able to query the system to display at most the first 20 results in a paginated list of their active customers sorted by company name in ascending alphabetical order, in 10 seconds or less.

This requirement is both specific and measurable.

Why Is It Specific?

The requirement tells us:

• Who is performing the action;
• What information is displayed;
• Which customers are included;
• How the results are sorted;
• How many results may appear at once; and
• That the results are displayed in a paginated format.

There is very little room for interpretation.

Why Is It Measurable?

The requirement also provides clear criteria that can be tested.

We can verify:

• That no more than 20 results appear on a page;
• That only active customers are displayed;
• That results are sorted correctly; and
• That the operation completes within 10 seconds.

Because these conditions can be tested directly, the requirement is measurable.

Reducing Ambiguity Through Multiple Requirements

Sometimes a single requirement cannot fully describe the desired behaviour of a system.

In these situations, it may be better to create several related requirements rather than trying to force everything into one statement.

Consider the following additional requirements:

Requirement A

A member of the sales team should be able to query the system to export a CSV-formatted table of their active customers sorted by company name in ascending alphabetical order in 60 seconds or less.

Requirement B

A member of the sales team could be able to query the system to export a CSV-formatted table of their active customers sorted by the contact person’s last name in ascending alphabetical order in 60 seconds or less.

Requirement C

The system won’t support exporting customer records to PDF.

Requirement D

The system won’t support bulk customer imports from CSV.

Together, these requirements establish a much clearer understanding of what the system should and should not do.

Rather than leaving assumptions open to interpretation, they define the boundaries of the solution.

The Importance Of “Won’t” Requirements

Many students initially focus only on the features a system must include.

However, defining what a system will not do can be equally important.

“Won’t” requirements help establish scope.

They communicate features that have intentionally been excluded, postponed, or determined to be outside the needs of the project.

This can prevent future misunderstandings and help teams avoid spending time developing functionality that was never intended to be part of the solution.

In many projects, clearly defining what is out of scope can be just as valuable as defining what is in scope.

Writing Better Requirements

As you begin developing requirements, ask yourself the following questions:

• Is the requirement clear?
• Will different people interpret the requirement in the same way?
• Does it describe one specific piece of functionality?
• Is there a clear way to test whether it has been implemented correctly?
• Does it establish meaningful boundaries for the system?

If the answer to any of these questions is “no,” the requirement likely needs revision.

Remember that the goal is not to create lengthy requirements.

The goal is to create requirements that are clear enough that everyone involved shares the same understanding of what is expected.

Specific and measurable requirements help transform vague ideas into actionable design goals. They reduce ambiguity, improve communication, support planning, and make it easier to determine when a project has successfully met its objectives.

Activity: Evaluating Requirements

Consider the following requirements.

For each one, determine whether it is specific and measurable.

If it is not, rewrite it so that it becomes both specific and measurable.

Requirement 1

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

Requirement 2

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

As you revise each requirement, think about what information is missing and how someone might verify that the requirement has been satisfied.

Remember: if different people can interpret a requirement differently, it probably needs more work.