The first step in the requirement development process is to gather requirements data from key stakeholder, project objectives and already developed requirement. A number of typical sources used to gather requirements data are:

Once the requirements data has been gathered and processed, requirement need to be developed and recorder/documented. The requirements don’t have to be perfect at this step, just documented, prioritized, de-conflicted, and validated with all stakeholders. It’s critical to have all stakeholders approve that the current documented requirements meet their needs. Unexpected requirement add cost to any program as it gets further along in its development.

Recording Requirements
 As you gather requirements, use a form to capture them. This will help your requirements remain consistent in form and in terms of the information you capture for each. Basic information to collect:

  • a short title
  • a detailed description of the requirement
  • the person recording the requirement
  • the source of the requirement (a scenario, a user interview, the project proposal, etc.)
  • a rationale: why is this requirement necessary?
  • a list of the stakeholders most affected by this requirement
  • initial desired priority, according to the source of the requirement

Prioritizing
One characteristic of excellent requirements management is that the requirements are classified and prioritized. When customer expectations are high, timelines are short, and resources are limited, a program manager wants to make sure the system contains the most essential requirements. These requirements are expressed as:

Step 1 Checklist Items:
Below is an excerpt from the Requirements Checklist that can be used in this step.

  • Were all stakeholder requirements documented?
  • Was each requirement checked to see that it met all of the following?
    • Necessary [trace to a user need]
    • Concise [minimal]
    • Feasible [attainable]
    • Testable [measurable]
    • Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
    • Unambiguous [Clear]
    • Complete [function fully defined]

AcqLinks and References:

Updated: 7/28/2017

Print Friendly, PDF & Email