Assuring Requirements Quality

April 27, 2018

So you wrote down and documented all the requirements needed for the creation of your software. You start thinking about all of the future design choices you can make to accomplish the objective of the project. One would think that after having all of your requirements documented and structured, you could start going through the designing aspect of your project, but it's not. Much like an essay that you finished completing, you have to make sure that what you have written down is actually useful and clear. You might have flaws or errors that your team or even the client made while perscribing the requirements. This is why quality assurance was made; to make sure that what was created, is actually up to snuff.

In order to do this, you must first plan how you are going to tackle the issue of doing said assurance. This is where you would determine reviewers to judge whether the requirements are correct or you might have to go back to the drawing board. Next, you would start to do the reviewing. This is where you have to specify what the actual reviewer will do. This can be from just telling the person "Hey, can you check me if what I have to do makes sense?" to "You as the user experience role, have to write down if your domain is involved in the requirement and why or why not it might be applicable.". These reviewers should be different people from the people who made the requirements because, like an essay, you might not be able to identify errors that you might have committed. After you found your defects, you now have to categorize those defects, analyze what causes them and see any recommendations in order to execute them later. This is how you make sure that your final product at the end is the intended, optimal solution to the problem you are trying to solve.