This blog post was written with Karl Wiegers based on our Software Requirements, 3rd Edition book.

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation. This article, adapted from our new book Software Requirements, 3rd Edition, offers some suggestions for closing gaps caused by missing, implied, and assumed requirements.

Missing Requirements

Missing requirements constitute a common type of requirement defect. Missing requirements are hard to spot 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.
• Ensure that all user classes have provided input. Make sure that each user requirement has at least one identified user class who will receive value from the requirement.
• Trace system requirements, user requirements, event-response lists, and business rules to their corresponding functional requirements to make sure that all the necessary functionality was derived.
• Check boundary values for missing requirements. Suppose that 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 6 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, or at least poorly written.
• Represent requirements information in more than one way. It’s difficult to read a mass of text and notice the item that’s absent. Some analysis models visually represent requirements at a high level of abstraction—the forest, not the trees. You might study a model and realize that there should be an arrow from one box to another; that missing arrow represents a missing requirement.
• Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. If a combination of logical conditions has no corresponding functional requirement, the developer has to deduce what the system should do or chase down an answer. “Else” conditions frequently are overlooked. Represent complex logic by using decision tables or decision trees to cover all the possible situations.
• 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, and configuring user preferences. Periodically compare this list with the functions you’ve already specified to look for gaps.
• A data model can reveal missing functionality. All data entities that the system will manipulate must have corresponding functionality to create them, read them from an external source, update current values, and/or delete them. The acronym CRUD is often used to refer to these four common operations. Make sure you can identify functionality in your application to perform these operations on all of your entities that need them.

Watch out for the dreaded trap of analysis paralysis: spending too much time on requirements elicitation in an attempt to avoid overlooking any requirements. At some point you need to establish a relatively stable requirements baseline that describes what you’ll be implementing in the next release or iteration. But expect to perform some additional elicitation throughout the course of the project, no matter what life cycle the project is following.

Assumed and Implied Requirements

I once encountered a development team that was implementing a content portal that was intended to do many things, including upload, edit, and publish content to a website. There were approximately 1,000 pieces of existing content, organized in a hierarchy. The content management team assumed that users would be able to navigate the hierarchy to quickly find a specific piece of content for editing. They did not specify requirements regarding the user interface navigation. However, when the developers implemented the user interface to navigate to content, they organized all of the content in a single level, not hierarchically, and showed only 20 items per screen. To find a specific piece of content, a user might have to navigate through as many as 50 screens. A little more specification and dialogue between developers and the content management team could have avoided considerable rework.

You will never document 100 percent of the requirements for a software system. But the requirements you don’t specify pose a risk that the project might deliver a solution different from what stakeholders expect. Two likely culprits behind missed expectations are assumed and implied requirements.

Assumed requirements are those that people expect without having explicitly expressed them. What you assume as being obvious might not be the same as assumptions that various developers make. Implied requirements are necessary because of another requirement but aren’t explicitly stated. Developers can’t implement functionality they don’t know about. Assumed and implied requirements both rely on a certain amount of telepathy and clairvoyance, which are not strong technical foundations for a software project.

To reduce these risks, try to identify knowledge gaps waiting to be filled with implied and assumed requirements. Ask, “What are we assuming?” during elicitation sessions to try to surface those hidden thoughts. If you come across an assumption during requirements discussions, record it and confirm its validity. People often assume that things have to be the way they’ve always been because they’re so familiar with an existing system or business process. If you’re developing a replacement system, review the previous system’s features to determine whether they’re truly required in the replacement.

To identify implied requirements, study the results of initial elicitation sessions to identify areas of incompleteness. Does a vague, high-level requirement need to be fleshed out into more detail so the stakeholders all understand it? Is a requirement that might be part of a logical set (say, saving an incomplete web form) lacking its counterpart (retrieving a saved form for further work)? You might need to re-interview some of the same stakeholders to have them look for missing requirements. Also, think of new stakeholders who know the topic and can spot gaps.

Read between the lines to identify features or characteristics the customers expect to be included without having said so. Ask context-free questions, high-level and open-ended questions that elicit information about global characteristics of both the business problem and the potential solution (see Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg, Dorset House Publishing, 1989). The customer’s response to questions such as “What kind of precision is required in the product?” or “Can you help me understand why you don’t agree with Miguel’s reply?” can lead to insights that questions with standard yes/no or A/B/C answers do not.

We all know that you’re not going to discover and document every single requirement for a software system of any size. If you keep your eyes open for missing, assumed, and implied requirements, though, you’ll close a lot of the gaps that otherwise might cause development headaches farther down the road.