The Devil is in the Detail

Requirements Management is the nose to the grindstone part of Analysis. It is the writing down of things that a system must do. It is also the writing down of what the system is for, and who will use it, and some of the ways in which they will use it (better still, write down all the ways in which they will use it) and also if there are other systems with which it must interact, and if it must perform in a certain way, et cetera, et cetera, et cetera.

Requirements Management gets to be a big mess. Frequently, no one really wants to deal with it. Shortcuts are taken. Shortcuts are the downfall of every system that was ever built.

Many times, an e-mail thread is the only documentation a system or a change request ever gets. Many programmers hate the grind of formal documentation and requirements gathering, but the lack of those things is also an evil thing.

Without a reasonably structured documentation of requirements, design, and support, systems mutate like fruit flies in a Chernobyl apple orchard. The systems grow strange features that are beyond the institutional knowledge, and become hated and shunned by users and programmers alike.

Requirements Management can be unglamorous and boring, and is certainly frustrating, but it can yield great rewards when done with care and enthusiasm. (Bringing enthusiasm to a boring task is the hard part, and I'm not sure yet what to tell people who seem incapable of doing that.)

So What Do I Do?

The good thing about requirements management is that it is not difficult to begin, and there are many, well-documented examples of what you should do. Here is the recipe:

• Follow a Robust Guideline
• Work Hard on the Use Cases
• Involve Everyone

Requirements are Never Done

Take note that getting the requirements approved is not part of the recipe. Requirements were meant to be changed, which is why we need to manage them, but a formal approval is as old-fashioned as COBOL written on punched cards. People should be involved in the capture of the requirements, and are, in fact, the review process. The only reason to ask them to sign an approval of the requirements is when you can't get them to read the damn thing any other way.

So Let's Get Started!