How to Discover Missing Requirements

Non-functional requirements are easy to overlook. This is most likely because stakeholders often assume that these requirements are given and go without saying. Missing requirements are harder to spot during requirements evaluation than poorly specified requirements and are usually detected further down the line when the system is in the testing phase or has already been deployed to thousands of users. They become even more expensive to fix if they are architecturally significant. For example, It is often difficult to include performance, safety and security features to an existing architecture

- Donald Firesmith, Software Engineering Institute, U.S.A.

Missing requirements are a common problem with writing specifications. How can you ever be sure you’ve included all the requirements essential to delivering a working solution? While missing a couple of requirements may not cost you your job, missing critical requirements that introduce project delays, scope creep and extra project costs is definitely not a recipe for success. Looking out for missing requirements is an essential quality check that should be performed following the analysis of requirements.

One of the qualities of a well-written requirement is completeness. According to BABOK V2, “The entire set of requirements should represent all relevant requirements. Also, each individual requirement should be self-contained without any missing information.”

While one can argue that some requirements are so implicit that they do not need to be explicitly stated, like having an “x” button to close a window, most requirements need to be explicitly stated and clearly defined for implementation in the final solution.

So, how exactly can one discover missing requirements? Here are some ideas to get you started:

Expressing requirements in different formats can help you find missing requirements. The mere act of drawing paper prototypes to communicate requirements can reveal requirements that have not been explicitly stated. Prototyping can reveal the need to include requirements you may have missed while writing textual requirements. The trick is to combine different specification models that tell different stories. For example, studying use cases can reveal missing stakeholders or system functionality while studying data flow diagrams can provide information on missing sources of data as well as processes/requirements you may not have thought of while documenting user requirements in a textual form. Always check for elements mentioned in one model but not in another.

When I’m unsure of having covered all the relevant requirements, I look at similar systems in use.  You can draw a minimum set of requirements from existing systems for a start, and then throw in the peculiar requirements of your stakeholders. This “minimum set” of requirements will of course, have to be validated with the users before effort is spent on developing or delivering features that end up on the shelf.

Scenarios can also help you uncover missing requirements. Think of how a user would interact with a system under different circumstances. Have you missed any requirement that might prevent the user from completing each scenario? Walking through each process from the beginning to the end, with the aid of business process models that indicate triggers, conditions and exceptions, can also help to identify the minimum requirements necessary for the user to complete each process.

Structured Walkthrough: Reviewing requirements with stakeholders can help to identify missing requirements. When stakeholders are invited to discuss a list of requirements or prototypes, they tend to propose new/additional requirements. Take advantage of such discussions to check for completeness. Including the technical team from the onset can also shed light on critical non-functional requirements that business people are unlikely to have explicitly requested for.

Search for omission indicators: These are words in your requirement documents that indicate something might be missing. For example words like: tbd, etc, and so on, not limited to and as a minimum indicate that there’s still some information your document has not covered. The challenge often lies in finding a balance between too much and too little information.

Clarify your assumptions and risks. Have you clarified your assumptions and stated any associated requirements where necessary? Have you identified the risks to the system and developed measures of mitigating them? These measures are potential candidates for developing critical requirements that need to be included to ensure delivery of the right solution.

The CRUD Technique can also help in identifying missing requirements; CRUD stands for Create, retrieve, update and delete and it works like this:

• Find all the entities in the data model
• Identify the actors
• Record the details on the CRUD table as shown below
• Identify which action(s) all the actors carry out and find out what is missing by looking at the process

Let’s use this process as an example:

1.    The sales manager (actor) reads a report on sales (entity) and creates the customer account (entity)

2.    The warehouse personnel (actor) review the orders (entity), assemble the pens (entity) for shipment and update the inventory system (entity)

View fullsize

Finding missing requirements with the CRUD Technique

Looking at the column “sales report” can help you identify what’s missing. For example, do you need requirements to cover creating, updating and deleting the report?

In a similar vein, the table above only contains a record of creating customer account – would it be necessary to create requirements to review, update or delete customer accounts? Questions like these can reveal missed requirements.

Techniques like interface analysis and business rules analysis can also help to uncover missing requirements you may not have thought of from scratch.

What other techniques do you employ to discover missing requirements?