| Revision History | ||
|---|---|---|
| Revision 1.0 | 26 September 2000 | |
Requirements management (RM) is simple in principle but difficult in practice. The Software Engineering Institute's (SEI) Capability Maturity Model (CMM) spells out RM in basic terms. RM means to:
1. Establish a common understanding of the requirements with the customer
2. Document that understanding
3. Make changes in an organized manner
How could anything be simpler?
As usual, the problems with RM come with people. Software projects are run by technical people. Technical people like to work on technical problems; we avoid or botch other problems.
Requirements analysis is a technical problem. Technical people gather information, draw diagrams (use-case, data-flow, etc.), and analyze them to prepare for design. Requirements analysts use all their technical skills and apply themselves whole-heartedly. In contrast, RM is a management problem. It involves having meetings, reaching agreements face-to-face, and keeping detailed records. Technical people see RM as a clerical job and hate it. (They don't say they hate it, but they do.)
Regardless of how distasteful RM might be, it must be done. So, what can a manager do to ensure that project managers do RM? The answer is, once again, simple in principle but difficult to do. The answer is one word -- help.
Upper management must provide real help to project managers in the RM area. Real help is not threats to "do it right or else." Real help is realizing that RM probably won't be done well and providing the project manager with resources and direction.
Real help can take several forms. The simplest help is to appoint a full-time requirements manager. This is a person who understands technical issues but likes and is good at managing things. The requirements manager performs all the face-to-face and detailed record-keeping tasks. This person has the personality and temperament to keep the customer happy and the technical people out of trouble.
Another form of real help is to define clear responsibilities. There should be a poster in the project area that states precisely who is responsible for what on the project. This includes who represents the customer (if it is a large project, it could state who represents the customer's user interface issues, who represents the database issues, etc.). This reduces the amount of changing directions to try to satisfy everyone you bump into in the hall.
A third way to help in RM is in the area of review boards. Any proposed change to a set of requirements should be reviewed by a group of "outsiders." These outsiders, a review board, provide a needed perspective on changes. It is unfortunate that most review boards are too slow, don't understand the project well enough, and generally become such a hindrance to the project that the project manager tells little white lies to avoid the review board. The review board is necessary and must operate in a way that does not hinder the project. The review board members must be familiar with the project, be available now, and go out of their way to help the project.
RM is necessary and difficult. Project managers usually disdain it as clerical work. Upper managers must acknowledge the necessity of RM and provide real help to people so that it is performed as needed.
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He recently wrote *The Software Project Manager's Handbook, Principles that Work at Work* (http://www.cutter.com/consortium/index_books.html ), published by the IEEE Computer Society. He can be reached at d.phillips@computer.org.