Review

Review of SOA requirements

There are studies showing that as much as about 50% of the errors arise from the requirements. That is, if we can find the errors already at requirements work we can work much more efficiently. Moreover, it is much cheaper to find a fault as early as possible. An error found during requirements review takes much less resources to correct, perhaps only a minute. A bug found in operation that may take several days of work to correct. And given all the bugs that are found too late and that cost much to fix it is strange that companies do not spend more time on review.

One problem is that it is difficult to prove that it will be profitable with the proper requirements review, this particular project will of course not suffer from bad requirements. And the cost to implement the audit work is easy to point see, but the benefits are much harder to see. But the review work is very effective and should be implemented in all projects. Why is it done more often? An explanation as mentioned before is that project and those who ordered the development are not sure of the good results using a review. Another reason is that it is harder to do right from the beginning than to become acquainted with a program and click to locate errors. Another explanation is that lack of time also strikes against the test group. As pressure increases even the most zealous reviewer is being forced to focus on testing a delivery who had just arrived, instead of examining the requirements for a future version of the system.

Reasons to work on reviews include:
• Discover the errors early
By reviewing the requirements, may be already on the desktop stage, will let you detect many errors. And testers are the best reviewers. Testers are critical, used to examine the requirements and often have extensive knowledge of the system. And an experienced tester instinctively think on how the requirement will be tested in the test cases and what test data to use.

• Removing unnecessary requirements
Review of test cases not only detects errors early, it also shows when and where the demands are not important. What one wanted to solve with the requirement may be resolved with an existing function in the system.

• Information gaps can be reduced
When there are several sub-projects to deliver a solution, it is a high risk of information gaps. It is difficult to ensure that information is always communicated to everyone. Also, when the pressure starts to rise to the various projects focusing increasingly on its delivery it is easily tha case that they stop talk to the other projects. So in the end of the project it can often happen that you find that the different projects deliveries do no match. Examples would be:
Information about all parameters that the web interface needs have not been coomunicated to the Web service project and therefore needs to spend more time developing, or maybe even do some more functions.
Another example is when it turns out that there is a lack of functionality as the requirements in one project continued to evolve, but that the information never reached the second project.

To avoid information gaps, it is important that those who work with requirements at all times ensure that all projects are kept updated. It's easy to say but harder to implement in reality. Often IT projects are under tight deadlines and must manage changes and increased requirements within the same time. Here does not a master test plan help, but by letting the test group have control over multiple projects, it is possible that you can see where the gaps are and draw attention to this for project management. This indicates that there is often a good idea to let the test persons join and review requirements. They can often have a good overview and also critically examine the requirements.