The Wabe → Personal Notebook → Requirements Management

Requirements Management, Documentation, and the Commitment Process

(or, How to be an asshole for fun and profit)

Please, people, please: Learn to say no!

Recently, while skimming over my copy of Kenneth Dymond's Guide to the CMM, I came across a section enticingly titled “The Commitment Process.” Commitment, as described by Humphrey, is simply “an agreement by one person to do something for another” (Managing the Software Process, 1989). Sounds reasonable? For many, Commitment is an anathema, because one of the drawbacks about Commitment is Responsibility.

But there is a hidden benefit to enforcing Commitment: because the engineer is required to commit to something, he is also (implicitly) given the right to refuse to commit to something. Just as the cliché states, with power comes great responsibility: the engineer must judge if the the commitment is indeed detrimental to the health of the project before refusing.

The ability to refuse commitments is the engineer's greatest weapon in establishing a well-defined requirements management process, and to save himself hours of wasted effort.

Documentation out of synch with the software? How did that happen?

Ideally, documentation should reflect the state of the software, and be in full agreement with the requirements. The software should have been written with the requirements completely in mind, and when implementation of requirements became difficult or impossible, the requirements should have been changed in a controlled and documented manner:

Figure 1

In the real world, however, often the software and the requirements change so quickly documentation falls by the wayside. This is often the case where the engineers are fully responsible for the documentation and QA is not empowered to enforce synchronization:

Figure 2

This is still a recoverable situation, although a lot of extra time will be needed to sort out the details. It is when the requirements are uncontrolled and come from a hodgepodge of sources that the project is in serious trouble:

Figure 3

Since the origins of the uncontrolled requirements are unknown, the responsibility for the inaccurate documentation falls upon the shoulders of the engineer who wrote the code. What started out as a simple “Yes” to avoid a confrontation has turned into a major effort to reverse-engineer the code and determine its behavior.

With a recognized Commitment Process, the best advice to an engineer who wants to avoid this kind of debacle is to...

“Just say No!”

This is actually much more difficult than it sounds, as it involves maintaining a delicate balance between aggressiveness and politics. There are many reasons why an engineer may feel obligated to accept a feature request outside of the specification.

The Coolness Factor

A lot of creeping featurism comes from the need to add whiz-bang gadgets to a complex software system. This is most common with young freshman programmers that have never worked on an industrial project before. Used to the freewheeling attitudes of college where software maintenance does not exist, they feel that the need for requirements management is simply a method of crushing their creativity. Here, the person that the engineer needs to say “no” to is himself.

The Ego Factor

Many managers, in a misguided attempt to improve performance out of their team, often use excessive flattery to coax additional features from the programmers. Programmers in general tend to be an introverted lot and take the praise at face value. Unwilling to upset their friend the manager, they subvert the process and add the additional feature.

The Political Factor

This is the most insidious of the factors. Sometimes, in the hope of “streamlining” the effort, the company representative will give a direct channel of communication to the engineer. This is incredibly dangerous tightrope for the engineer to walk: on the one hand, he cannot deny the customer's request; on the other, the engineer cannot add new features without endangering the rest of the project. The best thing would be to tell the representatives to release only a limited number of authorized communications channels; if one does leak out, the engineer must cut the unauthorized communication short and transfer the customer to a responsible party.

“Put it in writing!”

Even if the engineer becomes a primary contact for new requirements, the situation is still salvageable. Brooks suggests keeping a telephone log of all calls made and the topic covered. Most—if not all—companies do not follow this practice; but there is an alternative that is popular, easy-to-use, and has the added benefit of providing an automatic transcription and authentication service: e-mail.

Using e-mail to track requirements requests alleviates a lot of the aforementioned problems. If a new requirement is sent directly to the engineer, he can (without insulting the customer) forward the request off to the requirements management team for review. No mess, no fuss, everyone's happy.

Last Modified: 2005/03/27 04:38:54 GMT
(Send problems to Rob Menke)
Page style: Classic | Cyan | Dark