Symptoms

---

If detected early in development, dealing with missing requirements is as simple as adding them to the design and ensuring that they are taken into account at the appropriate locations. This means that detecting the absence of these requirements is particularly important to achieve early in the project. Let us look at symptoms that can indicate Requirement Deficiency.

Vagueness

The most general symptom is vagueness in one or more areas of the current requirements. While it can be used to spot possible missing requirements, this vagueness unfortunately has the opposite effect on many occasions. The small bit of mostly useless information can obfuscate the need for more detailed requirements about a topic.

For example, here are some vague requirements that can easily end up as the final requirements:

• The application must perform at a reasonable level.

• The application must use as little memory as possible.

• The application must be completely bug-free.

• The application must be ready for possible changes.

These requirements can easily make their way into the final requirements for a project, and only later will the important questions arise about what exactly these requirements mean. Not only are these requirements vague, but they leave plenty of room for interpretations that are very unrealistic for a developer to achieve.

If you immediately have questions about a requirement that are not answered anywhere else in the requirements, then it is likely that the requirement is too vague. The examples of vague requirements given earlier would quickly bring to mind several looming questions:

• What is a reasonable level of performance?

• Is there a particular limit to the memory that can be used?

• What does bug-free mean and what can be used as proof that no bugs exist?

• Will the application need to provide and answer to life, the universe, and everything?

Two important notes about this particular symptom deserve attention. First, while vague requirements can point to missing requirements, some missing requirements will be absent in their entirety. In these cases, this symptom will not appear to help in the diagnosis. Second, the relationship between customer and developer in addition to the developer’s handling of methodology can make some requirements implicit. While this can work and thus save some time in creating and managing these extra requirements, it is important to be very careful about proceeding with this methodology. Misunderstanding will arise and test the strength of the relationship; therefore, the relationship must be able to weather these times or come to a poor end for one or more parties involved.

Too Many Options

Having some flexibility in the implementation of an application is important and allows for improvements that would otherwise be impossible with purely rigid requirements. However, a programmer can easily find the number of options too abundant. Often in these circumstances, the developer will choose options based on some loose criteria that amounts to picking at random. Instead, it can be useful to look back at the requirements for the task and determine if there are any holes in the requirements.

This can easily lead to the discovery of missing requirements, which in turn can allow the programmer to collect these requirements and place them into the design. This provides the necessary added constraints to provide a much more solid basis for choosing among the possible implementations, and will lead to a greater chance of providing the needed functionality without performing several revisions.

While this symptom is useful for spotting unstated requirements, it does not usually become visible until it is time to implement the code. Spotting this symptom earlier can be achieved by considering the tasks at design time to get an idea if any of them have a large number of options. This can only be done if time is available, but keep in mind that details are not important at this stage. By considering only the general amount of possible options, without trying to choose among them or refine them in any way, the results can be achieved much faster at this stage.

History

Another useful technique for spotting missing requirements is related to the method used by regression testing. In regression testing, past results are compared against new results to ensure that no changes have been introduced that were not expected. Likewise, requirements for a new project can be compared against experience in past projects to ensure that the similar requirements have been covered in both. Obviously, just as intentional changes cause some regression testing to be ignored, differences in projects can cause some requirements to have no counterparts in the different projects.

Later in the section “Prevention,” we will look at some of the most commonly overlooked requirements. The absence of these common requirements is a symptom of Requirement Deficiency that can be derived from the history of many projects throughout the history of software development. As you progress through different projects, you should encounter other common requirements that you might want to add to this list, reflecting your own particular history.

Nagging Feeling

Although not very methodical in nature, it is nonetheless useful to mention that intuition can play a part in discovering absent requirements. As was mentioned in the last section, learning from history is important to spotting the symptoms of Requirement Deficiency. Not all of our development history will come to the forefront of our memories on demand, but might still provide guidance through the nagging feelings that our subconscious can generate.

This method of discovery is certainly not a replacement for more rigorous methods of requirements collection, but since it can only add new requirements that were missing, it deserves at least a modicum of attention and a small amount of time for investigation. It certainly would not be productive to spend weeks or months on a hunch, but an hour or two could lead to more information that confirms or denies the hunch in a more solid manner.

---