Incorrect, or Incomplete, Requirements

Most software development projects are overwhelmed by requirements from stakeholders of the project. The deluge of requirements may make it seem impossible that any requirements that are critical to the success of your project could be missed, but it is possible to miss them! Remember that requirements will differ from your Scope Statement, or SOW, in that they are the details of how the goals and objectives will be built. Your requirements are like the blueprints for a building or bridge. The requirements must capture all the elements implied in the Scope Statement or SOW, otherwise your project can’t meet those goals and objectives.

You may be capturing so many requirements that you get requirements that conflict. You need to be discerning when capturing the requirements. Requirements that are in conflict with one another cannot be delivered. One, or both, of the requirements is bogus and should be dropped. Requirements that don’t support the stated goals and objectives of the project are unnecessary overhead and will add to the expense of the project without delivering any business benefit. Building a software system is a business venture, not a popularity contest so some project stakeholders will be disappointed in the system. Your job is to ensure that you deliver a system that meets your customer’s/client’s/sponsor’s expectations.

It is a myth that most projects have budget constraints. All projects have budget constraints. Completion of the project within the committed budget may not be the Number 1 project priority but the project must deliver within some budget, otherwise we wouldn’t set budgets at all. Another area where project managers often struggle is the delivery of the required functionality within the budget. The people that you select to define requirements for the project are not concerned with a budget, that’s your job. To deliver your project within budget you will need to ensure that a stated requirement delivers the functionality required to meet an expectation, not exceed it. Telephone carriers actually install redundant systems in their equipment offices to ensure that there is no loss of service should one or the other system experience a problem. They do this because providing service is mission critical. Installing redundant order systems, duplicating all the servers, terminals, and databases involved in the system to provide a 99.9999% availability rate for the system, would be overkill and hugely expensive. Not all "gold plating” requirements are that clear, but they don’t need to be in order to blow your project budget and/or schedule baselines.

Requirements may be within the stated scope of the project, and be as pared down as it is possible to make them, but if they are notclearly understood by the analysts and testers who will read them and make design decisions based on them, you will encounter trouble. Many a project has started out with a great set of requirements – the requirements needed to deliver all the project goals and objectives within the budget and schedule baselines, only to founder when those requirements were not built and tested as intended. Correcting these misunderstandings after the system is delivered to a QA or User Acceptance Test (UAT) group is the second most expensive way of correcting the error, with the first being having a customer in the field identify the error.

Avoidance Strategies

You can guard against the overwhelming deluge of requirements by choosing a requirements gathering method that suits your team and project, then engaging the right number of stakeholders to state requirements. Educate your stakeholders in the proper use of the method and what is expected of them so that time isn’t wasted in education when you are trying to elicit requirements. Gathering requirements for a function or business unit from one stakeholder will eliminate conflicting requirements. Workshops can be used where it isn’t possible to limit input to just one stakeholder per function or business unit. You will need to review the requirements yourself, or with a business analyst, where you can’t use these methods to reconcile the requirements.

Features that are used to support several functions or business units are another source of conflict. For example, your log on feature should be used to provide log on facilities for everyone that will use your order entry and tracking system. Accepting requirements from everyone that will log on to the system is almost certain to cause conflict. You will be better off to identify a stakeholder or SME who is a security specialist and have that person supply the requirements for the log on feature.

Each requirement that you gather must support a deliverable in your SOW or goal or objective in your Scope Statement. Requirements must be captured in a document that relates it to the Scope Statement or SOW. That means that you need to start with a Scope Statement or SOW where each deliverable has a unique identifier. Any requirement that cannot be directly tied to a deliverable, goal, or objective must be questioned. The requirement should be ignored if you aren’t satisfied that the requirement will deliver some functionality that directly supports something in the Scope Statement or SOW.

Cost each requirement as it is captured. You don’t have to provide a monetary estimate for the requirement, or even an effort estimation (although an ROM effort estimation would be valuable). You can simply rate the feature as large, medium, or small, in terms of cost. You’ll have to have a development SME do this for you, unless you are knowledgeable to do it yourself. You may also want to assess the complexity of the feature, e.g. complex, intermediate, simple. My example is an ordinal system, but you can use a cardinal system if that is your preference. Question any requirements that are large and complex (you may want to set a threshold for this exercise). Is there another way to state this requirement that will be less costly to deliver? Empower your business analysts and programmers to identify opportunities for simplifying a requirement so that it delivers the required business function but for less cost.

Requirements should also be prioritized. The purpose of this is to facilitate de-scoping the project during the construction phase, should your initial estimates prove too aggressive. Use an ordinal system for the purpose, for example: high, medium, low. The combination of rating systems for size, complexity, and priority, will allow you to quickly reduce the scope of your project should you need to.

Requirements should be stated in plain language. If you are collecting requirements in a workshop, other workshop attendees should be able to understand the requirement even if they aren’t from the same functional area or business unit. Where you are collecting requirements using a polling method, you should be able to understand the requirement as stated. You may also want to use another team member, from any area other than the person who submitted the requirement, as a sounding board to ensure that the requirement is stated clearly.

Ask the stakeholder to describe how they would go about testing the system to ensure their requirement has been met. You don’t need your stakeholder to completely define a test case, but they should be able to describe a test scenario to you. Capturing their description in the requirements document will go a long way to eliminating misunderstandings between the stakeholder, business analyst, developer, and tester. Your last line of defense will be the stakeholders; the stakeholders should be willing to contribute to system quality during the UAT phase.

The tips and tricks described in this article are intended to help the project manager using the best practices promoted by the PMI. Project managers who are certified have already implemented those best practices. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.