Validating Requirements | When I review requirements, what questions should I ask?

Validating Requirements | When I review requirements, what questions should I ask?

As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity.

The requirements represented by the model are prioritized by the stakeholders and grouped within requirements packages that will be implemented as software increments.

Following questions:

Is each requirement consistent with the overall objectives for the system/product?

Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

Is each requirement bounded and unambiguous?

Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

Do any requirements conflict with other requirements?

Is each requirement achievable in the technical environment that will house the system or product?

Is each requirement testable, once implemented?

Does the requirements model properly reflect the information, function, and behavior of the system to be built?

Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

• Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?