Requirements Engineering — Requirements Validation (Part 4)
The process of ensuring the specified requirements meet the customer needs.
This is a series of articles inspired by Software Engineering, 9th edition
Requirements Validation
It’s a process of ensuring the specified requirements meet the customer's needs. It’s concerned with finding problems with the requirements.
These problems can lead to extensive rework costs when they are discovered in the later stages, or after the system is in service.
The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or code errors. Because a change to the requirements usually means the design and implementation must also be changed and re-tested.
During the requirements validation process, different types of checks should be carried out on the requirements. These checks include:
- Validity checks: The functions proposed by stakeholders should be aligned with what the system needs to perform. You may find later that there are additional or different functions are required instead.
- Consistency checks: Requirements in the document shouldn’t conflict or different descriptions of the same function
- Completeness checks: The document should include all the requirements and constraints.
- Realism checks: Ensure the requirements can actually be implemented using the knowledge of existing technology, the budget, schedule, etc.
- Verifiability: Requirements should be written so that they can be tested. This means you should be able to write a set of tests that demonstrate that the system meets the specified requirements.
There are some techniques you can use to validate the requirements, and you may use one or more of them together, depending on your needs.
Requirements Reviews
A team of system customers; those who interact with the customer to gather requirements, and system developers start reading the requirements in the document and investigate in great detail to check for errors, inconsistency, conflicts, and any ambiguity.
Then they may negotiate with the customer on how to solve the problems and errors found.
Prototyping
We’ve discussed prototyping as one of the (non-standalone) software process methodologies which is used as part of a full methodology, and we’ve also mentioned it can be used in requirements engineering.
In this approach to validation, an executable model of the system is demonstrated to the customer and end-users to validate and ensure if it meets their needs.
Prototyping is usually used when the requirements aren’t clear. So, we make a quick design of the system to validate the requirements. If it fails, we then refine it, and check again, until it meets the customer's needs.
This definitely will decrease the cost as a result of having clear, understandable, consistent requirements.
Test-case Generation
As we’ve just mentioned, the requirements need to be testable. If the tests for the requirements are added as part of the validation process, this often reveals requirements problems.
If the test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered.
The term “tests” here doesn’t mean to write and run some code for every function. It means to write a textual description of the “inputs”, “expected value”, and “steps taken” to perform each function.
Here’s a template for a test case.
It’s difficult to show that a set of requirements does in fact meet a user’s need. Because users need to use the system in operation and imagine how that system would fit into their work. So, it’s inevitable that there will be further requirements changes.
References:
- Software Engineering, 9th edition, Chapter 4, Ian Sommerville — A highly recommended comprehensive textbook on software engineering.
