2.15 Turning Requirements into Specifications

< Day Day Up >

If requirements are the project's "what," then specifications are the "how." In our ISDN requirements review, it was noted that how systems linked, how they were coded, and on what platform they ran were irrelevant from a requirements perspective. As we completed the design work, it was time to specify how to link our new system to legacy databases, and whether to base the new system on local area network (LAN)-attached personal computer (PC) workstations to the mainframes using client-server technology, or go "3270" all the way.

Building the right requirements makes the specifications process far easier. We are not going to go into much detail on this, because the process is highly dependent on the technology involved, whether you build it in-house or outsource it, and so on. There are a couple of general points I would like to make, however. As you go through this process, the following dynamics can be anticipated to impact one or more of your deliverables.

When a requirement is analyzed, it may turn out to be too costly, risky, disruptive, resource intensive, or take too long to implement given other pending events, such as corporate mergers, server operating system upgrades, or year-end accounting closes. In other words, a feasibility review could lead to scope tweak or schedule changes.
The best specification may be out of step with corporate standards. Suppose rolling out browser X to twenty thousand desktops fits your project's requirements better than browser Y. The trouble is browser Y is the standard on 100,000 desktops throughout your organization. A lot of existing applications are compatible with Y, but might require customization to perform as well on your project-preferred browser X.
Suppose UNIX boxes from Vendor A are better suited to your requirements than Vendor Bs, but the corporation sources all central processing units (CPUs) from Vendor B, who is firmly entrenched in your information technology (IT) culture.
Chances are that standards exist, whether or not they are documented, for all technologies in your environment. Somewhere out there, possibly in procurement or product management, lurk the "standards police." Their mission is to keep you from buying anything "out of spec." The trend in today's business world appears headed toward more standards with ruthless and inflexible enforcement. We will examine this subject in greater detail in the next chapter.

The significance of existing standards is the potential divergence from them with your solution. This can happen because the designers select products they find compelling for whatever reason, and are content to let you handle any compliance issues the standards police may choose to raise. Although this may sound awkward, and can be, it is also the way a lot of folks do business.

When there is a standards conflict, common sense and possible political considerations will dictate whether or not you fight the standards police or your own designers. Before you take on the possibly Herculean task of requesting an exemption from the standards police, ask yourself whether your experts have thought everything through, and beyond, their own parochial interests. I have had the pleasure of overcoming that many times, as well as enduring designers' adamant refusals to acknowledge what even I could divine - that their proposal introduced unacceptable implementation or operational risk. Because of standards, compatibility, and politics, it is not always practical to have requirements drive specifications, but that should be your goal. Make exceptions only when necessary. When specifications are made without validating requirements, bad things will happen.

< Day Day Up >