Until a few years ago, the requirements definition process was only briefly discussed in books that addressed project management, systems engineering, and software engineering. Many texts assume that the requirements are a given and show the requirement definition process as a single step on a waterfall chart.

Most college curricula never even address the subject of requirements, much less the requirement definition process. Books devoted to requirement definition finally began to appear in the early 2000s. Some outlined complex requirement definition processes, but more complex is not necessarily better.

Most, if not all, of the benefits of a complex requirement definition process, come from a few key steps. Overly complex processes use significantly more resources than simple ones do without significant incremental gain.

Setting up the requirements definition process.

Use what you have in the process of requirements

In your search for a suitable requirement definition process, do not overlook your own organization. If you are in a large organization, a good requirement definition process may already be in use somewhere in the company. If so, adopting it will capitalize on experience in your own organization and make management across projects easier. It is possible that a requirement definition process from another part of your own company is already tailored to your product or project needs.

Nine Steps to Requirements Definition Process

If your organization does not have a requirement definition process already in place, then here is a simple starting point.

Below is a practical, nine-step process for defining requirements for your project or product:

  • The scope of the project or product by defining the needs, goals and objectives, mission or business case, high-level operational concepts, customer requirements, constraints, schedules, budgets, authority, and responsibility.
  • Develop operational concepts-scenarios for how your project or product might be used by the end user. Expand the concepts to cover all phases of the product or project lifecycle.
  • Identify interfaces between your project or product and the rest of the world, clarifying boundaries, inputs, and outputs.
  • Write requirements to guide product design toward what your customers need and want.
  • Capture rationale (the reasons for the requirement's existence) behind each requirement and expose potentially dangerous assumptions and incorrect facts.
  • Level requirements according to system and system sub-divisions, ensuring that all requirements are written at the right level and can be traced back to their origins.
  • Assess verification of each requirement, identifying the verification technique and facilities and equipment required.
  • Format requirements and supporting documentation to ensure that you have included each of the appropriate types of requirements and that your development team members can find all of the requirements they must meet.
  • Baseline requirements after validating that they are correct, complete, consistent, meet the project scope, and do not add unnecessary functionality or features not covered by the original scope.

Note: Information for this article was derived from the book “Customer-Centered Products” by Ivy Hooks and Kristin Farry.