E-mail Ralph YoungLinksBiographyReusable ArtifactsPublicationsGood BooksGood ArticlesConferences

Requirements Process

Why is a Requirements Process Needed? It's generally acknowledged by system and software engineering practitioners (and even accepted by most managers) that having a documented process provides a standard way of accomplishing a set of actions in support of a needed business activity or function, and this is a good thing. Having a documented process permits performance of the process in a repeatable manner throughout an organization. Performing a process in a repeatable manner permits reuse, which saves time and money, because:

  • Performers have a better understanding of what to do and how to do it.
  • Performers can move from one organization or project to another and already be familiar with what to do.
  • Potential improvements to the process can be identified, suggested, implemented, and deployed.
  • Training can be provided to describe improvements that are applicable to all.

In short, by having a documented process, the work force is empowered to achieve the benefits described above.

Among the major contributing factors for poor results in the systems and software engineering industry are a lack of user input, incomplete requirements, and changing requirements. A requirements process that incorporates effective requirements practices addresses these deficiencies by including steps and methods to address weaknesses. Moreover, there is leverage in making improvements to the requirements process because the requirements provide the basis for all of the follow-on activities in the project. The fact that requirements errors are the largest class of errors typically found in a project lends support for expending more time and effort on the requirements process. And the situation that the cost of rework is typically 45% of project costs suggests that reducing rework can pay for needed process improvements.

The data indicating the types of non-clerical requirements errors suggest that with improved requirements analysis, these can be avoided. Ivy Hooks advises that a 30% change in the requirements during the development process will double the cost of the program. And we wonder why projects wind up exceeding their budgets by factors of two to ten. It's troublesome that managers are not committed to the organization's developed and documented processes. This suggests that the exigencies and pressures of the moment are more important to them than the benefits of having a process and being committed to process improvement. Sadly, this seems to be true in many situations.