Attainability is a requirements development issue that is commonplace on many projects.   Defining requirements without adequately assessing attainability places projects at risk of significant cost overruns, schedule delays, and performance shortfalls.

Mandatory characteristics for any requirement is that it is Needed, Verifiable, and Attainable.  I call these the NVA characteristics.  In previous blogs “Do we really need all these requirements?” and “Is the requirement verifiable?”  I addressed the “Needed” and “Verifiable” aspects of good requirements.  In this article, I will focus on “Attainable”.

Rhetorical question – why would anyone ask for something when it is not attainable in terms of cost, schedule, and technology?

I have yet to find the answer to this question but I have found there to be a number of reasons for the existence of unattainable requirements in a requirement set.

1. Failure to do the upfront work to define a feasible system concept to meet stakeholder needs during scope definition.
2. Failure to access the attainability of a requirement in terms of cost and schedule before adding it to your requirement set.
3. Basing the ability to meet a given performance on an immature technology.
4. Failure to manage change after the requirements have been baselined.

1.  Failure to do the upfront work to define a feasible system concept to meet stakeholder needs during scope definition.

Before writing requirements, you need to develop a set of stories, scenarios, and use cases to define system concepts that address the views of all the stakeholders.  Failing to define a feasible system concept (within your cost, schedule, and technology boundaries) that meets your stakeholder needs can result in the stakeholder expectations not being met.  If your system concept cannot be implemented within the allowable cost and schedule, you are setting up your project for failure from the beginning.  If you base your system concept on an immature technology, your system may not be able to meet the stakeholder expectations for performance.

2.      Failure to access the attainability of a requirement in terms of cost and schedule before adding it to your requirement set

Too often, organizations accept requirements from stakeholders without evaluating for attainability.  Do not fall into this trap.  Access the attainability of each requirement, individually and as a complete set, in terms of cost, schedule, and technology before adding a requirement to your requirement set.

3.      Basing the ability to meet a given performance requirement on an immature technology.

Engineers, scientists, and marketing personnel often tend to be overly optimistic as to their ability to meet performance requirements that go beyond state-of-the-art.  Because of this, they tend to define requirements based on technologies that are not mature enough to be included in a product’s development plans.  This often causes cost and schedule overruns due to the need to fix problems later in development or failure of the system or product to meet stakeholder expectations.

4.      Failure to manage change after your requirements have been baselined.

Accessing the attainability of your requirement set is especially important after you have baselined your requirements and started design.  Requirement creep is a significant factor in failed projects.  Key questions to ask for each change include:

• How does the change impact cost and schedule? If a big hit or unacceptable risk of increases, then don’t accept the change.
• Can the requirement be implemented given the maturity of the technology to do so? If no, don’t accept the change.
• Does this change result in an increase in the risks to the project being successful? If yes, is the increased risk worth the perceived benefit?  If not, don’t accept the change.

Avoiding unattainable requirements

1. Communicate, Communicate, Communicate.  To minimize the risk of writing unattainable requirements, it is essential that requirement writers work with the stakeholders to ensure that their wants, needs and expectations are achievable in the context of cost, schedule, and technology.  Unattainable expectations need to be reset.  Don’t be afraid to push back when customers or other stakeholders provide you with unattainable requirements.
2. Develop use cases, stories, scenarios to define system concepts.  Do the analysis needed to ensure the system concept is achievable prior to writing your requirements.
3. Practice continuous requirement validation as part of your process.  Continuous requirement validation is when the requirement development team reviews each requirement for goodness, completeness, correctness, consistence, need, verifiability, and attainability as they are being written rather than waiting until you have a “big, bad, requirement spec”  full of defective requirements.  If a requirement is not achievable, do not add it to your requirement set.
4. Involve the developers and verifiers during elicitation and requirement writing.   If they feel the requirement is not achievable, do not accept the requirement.
5. Start planning for verification early.  Make the “verification method” (i.e., test, analysis, inspection, demonstration, etc.) a mandatory attribute that is captured for each requirement.  Just thinking about the method you would use to verify a requirement can expose requirements that are unattainable and thus need to be rewritten.
6. Define risk as an attribute of each requirement.  Attainability is often not a black/white determination.  Access the risk of not meeting a requirement as part of your attainability assessment.  This will provide management a tool to manage the product development activities and to put risk mitigation steps in place before problems occur.
7. Control change. To retain control of your project, you must manage change or change will take control of your project.

Allowing unattainable requirements will place your project at risk of significant cost overruns, schedule delays, performance shortfalls, and project failure.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.