Viable within Constraints?

Viable requirements are those that are workable within the projectthey conform to the constraints set down for the project and the product. Constraints cover such things as the amount of time available to build the product, the anticipated workplace environment, the users of the product, constraints on the design of the product, and so on.

Constraints are described in section 4 of the Volere Requirements Specification Template in appendix B.

Each requirement is tested for viability within the constraints. This means you must consider each of the constraints, and ask whether the requirement contradicts it in any way.

For example, the users of the product can be considered a constraint. Whatever product you are specifying must be consistent with those users. The product must be easy for the user to operate, but sophisticated enough to provide the needed functionality. As an example, the following requirement for the IceBreaker product is not viable:

Truck drivers shall receive weather forecasts and schedule their own de-icing.

Truck drivers do not have the necessary information at hand to predict the time a road will freeze. They do not know which roads have been treated and which are in a dangerous condition. Coordinating a number of trucks treating multiple roads stretching over the whole of a county is a matter for centralized control.

You might also consider whether the organization is mature enough to cope with a requirement.

Do you have the technological skills to build the requirement? It is an easy matter to write a requirement, but it is sometimes a different, more difficult thing to construct a working solution for it. During the requirements activity there is little point in specifying a product that is beyond your development capabilities. This test is a matter of assessingunfortunately there can be no measurement herewhether the requirement is unachievable given the technical capabilities of the construction team.

Do you have the technological skills to build the requirement?

Do you have the time and the money to build the requirement? This test means estimating the cost of meeting the requirement, and assessing it as a share of the total budget. (The budgets should be listed as a constraint in section 4 of the requirements specification.) If the cost of constructing a requirement exceeds its budget, then the customer value attached to the requirement indicates how you should proceed: High-value requirements are negotiated, while low-value requirements are discarded.

Do you have the time and the money to build the requirement?

Is the requirement acceptable to all stakeholders?

Is the requirement acceptable to all stakeholders? This is simple self-defense. If a requirement is unpopular with some of the stakeholders, then history tells us that it is futile to include it in the product. Stakeholders have been known to sabotage the development of products because they disagree with part of the product. Users have been known to ignore and not use products because not all of the functionality was as they thought it should be.

Do any other constraints make the requirement nonviable? Do any of the partner applications or the expected work environment contradict the requirement? Do any solution constraintsconstraints on the way that a solution must be designedmake the requirement difficult or impossible to achieve?