I don’t know of any way to be absolutely certain that you have not missed any requirements during elicitation. This makes it hard to know just when you can declare your set of requirements—whether for the full product or just the next iteration—complete. Even though you can’t know for sure if you’re done, at some point you need to define a requirements baseline and move ahead with the project work. In this article, adapted from my book Software Requirements, 2nd Edition, I propose several techniques for helping you find requirements you might have overlooked, as well as some ways to judge whether your elicitation process is sufficiently complete.
Finding Missing Requirements
Missing requirements are among the most common requirement defects. They’re hard to spot during reviews because they’re invisible! The following techniques will help you detect previously undiscovered requirements.
- Decompose high-level requirements into enough detail to reveal exactly what is being requested. A vague, high-level requirement that leaves much to the reader’s interpretation will lead to a gap between what the requester has in mind and what the developer builds. Imprecise, fuzzy terms to avoid include support, enable, permit, process, and manage.
- Make sure that all user classes have provided input.
- Make sure that each use case has at least one identified actor.
- Trace system requirements, use cases, event-response lists, and business rules into their detailed functional requirements to make sure that the BA derived all the necessary functionality.
- Check boundary values for missing requirements. Suppose one requirement states, “If the price of the order is less than $100, the shipping charge is $5.95” and another says, “If the price of the order is more than $100, the shipping charge is six percent of the total order price.” But what’s the shipping charge for an order with a price of exactly $100? It’s not specified, so a requirement is missing.
- Represent requirements information in multiple ways. It’s difficult to read a mass of text and notice that something isn’t there. An analysis model visually represents requirements at a high level of abstraction—you’re looking at the forest, not the trees. You might study a diagram and realize that there should be an arrow from one box to another; that missing arrow represents a missing requirement. This kind of error is much easier to spot in a picture than in a long list of textual requirements that all blur together.
- Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. They might be missing an ELSE condition, for example. If a combination of logical conditions has no corresponding functional requirement, the developer either has to chase down an answer or make his best guess at what the system should do in that case. Instead of just writing out the requirements in natural language, represent complex logic using a decision table or a decision tree to make sure you’ve covered all the possible situations. See Chapter 11 of Software Requirements, 2nd Edition for more about decision tables and decision trees.
A rigorous way to search for missing requirements is to create a CRUD matrix. CRUD stands for Create, Read, Update, and Delete. A CRUD matrix correlates system actions with data entities (individual data items or aggregates of data items) to make sure that you know where and how each data item is created, read, updated, and deleted. Some people add an L to the matrix to indicate that the data item appears as a List selection. Depending on the requirements analysis approaches you are using, you can examine various types of correlations, including:
- Data entities and system events
- Data entities and user tasks or use cases
- Object classes and system events
- Object classes and use cases
Figure 1 illustrates an entity/use case CRUDL matrix for a portion of an application called the Chemical Tracking System. Each cell indicates how the use case in the leftmost column uses each data entity shown in the other columns. The use case can Create, Read, Update, Delete, or List the entity. After creating a CRUDL matrix, see whether any of these five letters do not appear in any of the cells in a column. If a business object is updated, but never created, where does it come from? Notice that none of the cells under the column labeled Requester (the person who places an order for a chemical) contains a D. That is, none of the use cases in Figure 1 can delete a Requester from the list of people who have ordered chemicals. There are three possible interpretations:
- Deleting a Requester is not an expected function of the Chemical Tracking System.
- We are missing a use case that deletes a Requester.
- The “Edit Requesters” use case is incorrect. It’s supposed to permit the user to delete a Requester, but that functionality is missing from the use case at present.
We don’t know which interpretation is correct, but the CRUDL analysis is a powerful way to detect missing requirements.
Figure 1. Sample CRUDL matrix for the Chemical Tracking System.
How Do You Know When You’re Done?
No convenient green light comes on to indicate when you’ve completed requirements elicitation. As people muse in the shower each morning and talk with their colleagues, they’ll generate ideas for additional requirements. You’ll never be completely done, but the following cues suggest that you’re reaching the point of diminishing returns on elicitation of a particular set of requirements.
- If the users can’t think of any more use cases or user stories, perhaps you’re done. Users tend to identify use cases and stories in sequence of decreasing importance.
- If users propose new use cases, but you’ve already derived the associated functional requirements from other use cases, perhaps you’re done. These “new” use cases might really be alternative flows for other use cases that you’ve already captured.
- If users repeat issues that they already covered in previous discussions, perhaps you’re done.
- If suggested new features, user requirements, or functional requirements are all out of scope, perhaps you’re done.
- If proposed new requirements are all low priority, perhaps you’re done.
- If the users are proposing capabilities that might be included “sometime in the lifetime of the product” rather than “in the specific product we’re talking about right now,” perhaps you’re done, at least with the requirements for the next release.
Another way to determine whether you’re done is to create a checklist of common functional areas to consider for your projects. Examples include: error logging, backup and restore, access security, reporting, printing, preview capabilities, text and field editing, and configuring user preferences. Periodically compare this list with the functions you have already specified. If you don’t find gaps, perhaps you’re done.
Despite your best efforts to discover all the requirements, you won’t, so expect to make changes as construction proceeds. Remember, your goal is to make the requirements good enough to let construction proceed at an acceptable level of risk. Watch out for the dreaded analysis paralysis, spending too much time on requirements elicitation in an attempt to avoid missing any requirements.
To begin tuning up your requirements elicitation approaches, you might think about missing requirements that were discovered late on your last project. Why were they overlooked during elicitation? How could you have discovered each of these requirements earlier? This sort of simple retrospective analysis is a great way to make sure your next project runs more smoothly than the last one.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.