Requirements

Requirements is an art and science unto itself. It has single-handedly created the position of the “business analyst”. In short though, “requirements” means: document the wants the customer expects to have in the finished project product, get sign-off from all parties involved, and put them (the requirements) under version control.

The requirements phase is more a discrete activity in software development projects than infrastructure projects. Requirements for infrastructure are non-functional and difficult for the lay person to articulate. Usually business people simply state they want the infrastructure to run and to perform in a timely manner.

On the other hand, software is typically created to automate a business process, so requirements are functional and numerous and usually take an extended time to gather. In fact, requirements solicitation, elicitation, and management can take up to many days and weeks of time and produce reams of documentation. Over the years, practitioners have put forth several methodologies to standardize requirements activities and specifications. I am most familiar with the Volere methodology, out of the UK. Volere is detailed in the book, Mastering the Requirements Process.

Unfortunately, the whole concept of requirements makes more sense in theory than in practice. Requirements grow, morph, mutate, and change. Keeping them current and relevant is a tall order. A database is by far the best tool to maintain requirements, but I rarely see it used. Usually, requirements for a software product are represented by a 4-inch binder on a shelf. Some larger organizations have the luxury of a requirements management tool, like IBM’s Rational. In many cases, such tools result in the other extreme, where requirements management requires a support team and an operational budget item just to keep the application running. Faced with these two opposing ends of the spectrum, organizations frequently let requirements management fall by the wayside. Documented requirements for infrastructure projects get even less attention.

On some projects, I have seen an artifact called “Conditions of Satisfaction” which describes how and which requirements will be satisfied. Alternatively, there may only be some type of design document that represents requirements doc. The concern here is that there may be no clear delineation between requirements requested and fulfilled. In many projects, particularly infrastructure-related, requirements information is communicated via the statement of work. Regardless of the mechanism, there should be some established formality around requirements, design and scoping.

Another useful artifact is the RTM, or “requirements trace matrix”. Here requirements are itemized, given an unique ID, and tracked through the project to the finished project and noted where they are, in fact, fulfilled. The expensive tools like Rational do this elegantly, but even a manual spreadsheet can be an effective if cumbersome RTM.