Requirements

Guest post by Jennifer Bedell

Everyone knows it is less costly to identify defects early in the project lifecycle, but how early can we go?

Typically, we create a project plan that allows for testers to become involved before the actual testing phase.  This gives them an opportunity to review the requirements and create test cases that will be executed during the testing phase.  But, what happens when the tester discovers gaps in the requirements?  Sure, they will ask for clarification and update their tests accordingly, but is this tracked?

A major reason for project overruns is unclear or incomplete requirements. Yet, we still have difficulty justifying additional analysis time.  People want to see results early so we move too quickly into the development phase.

If we track the questions asked about the requirements the same way we track defects that are discovered with the software, we will likely find that the root cause of many ”defects” is the requirements and not the code.  But, it is the code that needs to be fixed because it was based on requirements that may not have been complete.

By reporting on the root cause of defects, we can identify the ratio of requirements defects to code defects.  This data can then be used to demonstrate the importance of allowing adequate time for analysis, formal walkthroughs, and requirements reviews.

At first, this may appear to slow down the progress, but the advantage of discovering potential defects early will decrease re-work later in the project lifecycle.

{ 5 comments }