Missing data are the most common problem in requirements. It is very difficult to detect them in the process of re-reviewing requirements, because they are simply invisible! The following techniques allow us to identify missing requirements.
NB! Beware of the paralysis of the analytical process: do not spend too much time identifying requirements, trying not to miss any of them. You never reveal them all at once!
- Make sure that all user classes provide you with information and that at least one role is assigned to each use case.
- Be ready to document in detail which functional requirements are based on system requirements, use cases, event-response lists, and business rules. This will allow you to be sure that the analyst has described all the necessary functionality.
To spot missing requirements, check the boundary values.
Suppose one demand says: “If the cost of an order is less than $ 100, the shipping cost will be $ 5.95, and in another – “If the order value exceeds $ 100, the shipping cost is 5% of the total order value.” And what if the cost of the order is exactly $ 100?
This is not stipulated, therefore, there is no corresponding requirement. Penetration testing service is extremely useful when you want to keep private information secure, inaccessible to any outsider. Prevent your organization from collapse.
- Use a variety of forms to provide information about requirements. It is difficult to read a large amount of text and notice that something is missing. Analysis models visually represent the requirements on a high level of abstraction – the forest, rather than individual trees.
- Considering the model, you can notice that there should be an arrow from one block to the next; this is also a missing requirement. This kind of error is easier to see in the figure than in the long list of requirements that merges before the eyes.
One of the exact ways to spot the missing requirements is to create a CRUD matrix (Create, Read, Update, Delete). It allows you to correlate the actions of the system with data elements (individual or their collections) and as a result you get an idea of where and how each data element is created, read, updated and deleted.
Some add the letter L to the matrix name, indicating that the data item is a List. Depending on how you analyze the requirements that you use, you can explore different types of correspondences.
Comments are closed.
