Capturing Requirements

In March 1996, Frank McGrath addressed the problem of capturing requirements at a meeting of the Project Management Association in Tysons Corner, Virginia. In summary, McGrath pointed to the software community as being simply arrogant in starting development work without having requirements nailed. By example, he pointed to the building trades. What general contractor would start construction of a building with a requirement that states, "It will be a big building with offices inside?" What does that mean? What is the requirement for a manufacturing plant in which airplanes will be made or a skyscraper where many businesses will reside?

McGrath continued using the general contractor example, pointing to the fact that the general contractor finds out not only what type of building, but also what materials need to be used in the construction of the building. The general contractor then finds out what tolerances are needed in the materials and so on and so forth. Given some thought, it is easy to see how important clarifications are in defining requirements in the building trades. They are no less important in the software business, but all too often software developers wrongly feel that they deal in the creative zone where it is far more difficult to articulate and capture requirements effectively.

It may not be as hard as it seems. Software developers must first remember that they are capturing people's dreams, not what they need — though they may need it — not what they want — though they may want it. Software developers are capturing their dreams, their true desires. In this respect it is very personal for each person participating in the requirements definition process. They may argue over minor points and fail to communicate what is going on in their mind. A leader of the requirements definition process can overcome this by:

1. Conducting regularly scheduled meetings with a previously distributed agenda so that the right people attend and the attendees know what will be covered and what is expected of them.

2. Structuring each meeting to ensure that previously identified requirements are documented for review and analysis, allowing new requirements to be submitted and recorded for review at a future meeting and making sure that requirements that are out-of-scope for a specific project or release of a project are identified and tabled.

3. Making sure that each person at the meeting has an opportunity to speak and be heard without criticism or fear of being laughed at or made to feel dumb or stupid.

4. Spending time to make certain the information communicated as a requirement is meaningful; that is, make sure everyone understands that the big building is a tall skyscraper and not a warehouse or a manufacturing plant.

Although it may appear that a significant effort is being spent to capture and review requirements, there is a big pay-back if the requirements are identified correctly up front. The cost of correcting software for missing or incorrect requirements goes up significantly the later in the development process the error is found.

These unattractive and very costly statistics can be brought down significantly when the ambiguities common enough to everyday conversation and exaggerated by the separate areas of expertise brought to the table by the customer and the developers are eliminated. Use the helpful hints and techniques proven over time by software professionals such as Donald Gause and Gerald Weinberg, who are noted in the field of requirements definition. The result will be a negotiated understanding of the customer's desire and a certainty that everyone involved in the project is working toward completion of the same system. Start by removing ambiguities at the statement level.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment