Getting what you ordered: user requirement specifications help ensure what you buy is what you want.

There is an art to specifying. Most of us take great care when specifying and qualifying items such as solder paste or components. High standards are achievable, but doing so is best accomplished via a properly documented requirement specification.

[TEXT NOT REPRODUCIBLE IN ASCII]

Specifying equipment or new processes requires care in a different way. A User Requirement Specification (URS) is perhaps the most accurate method of doing this.

[ILLUSTRATION OMITTED]

The cartoon (Figure 1) is old but a classic. Astoundingly, few companies adhere to its message and adopt proper specification procedures. Within a company, every staff member and each department has their own views about the needs for a new project, new equipment or new directions; sadly, not many document these needs as a user requirement.

[FIGURE 1 OMITTED]

The URS is a bit like looking at a mountain. The perception of the physically unchanging mountain changes from each angle of the 360 degrees around it. Each view can be described differently. If a requirement is for a mountain, then we must accurately define a mountain, and not a particular view of it.

The URS must be a complete document, covering all aspects of the proposed new piece of equipment or process. Therefore, aspects such as company safety standards or ergonomics must be included.

For a large project, a URS can be an equally huge document; if not written properly, many things can go wrong. The URS becomes the project's focal point, but that does not mean it can never be changed. It should be written to permit Change Note Procedures to be agreed on any time. While no standard way of writing a URS exists, Table 1 shows a typical URS index page, with the bare minimum of detail. All signatories have to commit to being available to sign off on any change notes that become necessary as new information arises. Yet changes can occur only after all change ramifications have been approved.

(Note that nothing described thus far defines a piece of equipment or a function. That is not the aim of the URS. The project team leader, or even suppliers at times, needs to write a Functional Design Specification, or FDS, that matches the URS, providing details about how the requirement can be met in reality. See below.)

Budgeting. One could, of course, define the requirement without any recourse to budgets, but there must be a balance between project cost and the true requirement. It is easy to define a maximum budget and declare that the budget cannot be increased, but the end result may not be exactly right. Budgets are important, but it pays to allow flexibility to get as close as possible to the desired result.

If a URS is written and approved properly, then the budget should be part of the specification, and the owner of the URS is advised to keep a contingency fund. It is also true that one or more suppliers may offer two solutions: one to fit the budget with possible repercussions on product quality or equipment life, and one to provide the ideal match to the specification.

A number of sources provide evidence showing that it does not pay to restrict the budget if the equipment function and quality will suffer. A buyer may claim, "I want x result, but I can afford only y." The supplier, if sensible, may reply, "For y I can achieve 0.9x, and the product will probably only just be capable of doing the job." The equipment may be ordered for y and will probably just perform for the first few months, but the likelihood is that it will be a weak design to fit the budget, and will soon require regular maintenance. Worse, it might fail altogether.

The teams. So, who should do this? Answer: It depends.

It depends on the project size, how long it might run, the number of departments it affects, and so on. Figure 2 shows a typical cross-discipline team. The wider the disciplinary approach, the greater the possibility of covering all eventualities. This is not the only team design, however. A one-person team can do the job but will either take time or will miss something fundamental. Another alternative is to employ external contract help each time.

[FIGURE 2 OMITTED]

The FDS. The idea behind the URS is to specify what the customer wants to achieve without any bias. The FDS should project the suppliers' ideas about how to solve the problem. In an ideal world, the FDS will contain few, if any, surprises but may contain novel approaches. Even if you think you know the format and design of the equipment needed, it is always best to write the URS as a description of what is needed rather than a description of how it might be achieved.

It could be that you may want to write the FDS yourself, but you must still apply discipline to use the principle of URS followed by FDS. It is usually easier to compare FDSs from a number of suppliers and work out the optimum scope for your needs. If you rely on a single supplier, risks such as insolvency, incompetence or incompatibility should be considered.

When initially specifying something, you will achieve better results if you write a quality URS and then match it to a sound FDS. You will then see how essential the URS/FDS connection is.

Table 1. Typical URS Index Page

Topic                     Some Expanded Detail

History                   Describes the rationale and historical buildup
                          to the project (why it was deemed necessary)

Acknowledgments           Sources of information from outside the
                          project team

Introduction              Introduce the team players and their expected
                          roles

Overview                  Define the expected scope of the project

Functions                 Define the detail of performance
                          expectations

Nonfunctional-Attributes  Some of the equipment derived as part of the
                          URS may have functions or features not
                          necessarily required by the project but could
                          be useful in the future

Standards                 Define all known standards that apply to the
                          equipment or process

Training                  Define for whom and for how long training will
                          apply

Support                   Define the level of support available

Glossary                  Any "jargon" or specific terms that may need
                          definition

Appendices                Additional and supportive documentation

Signatories               All those who have "bought into" the project
                          or wanted it in the first place must be
                          prepared to sign for its acceptance at
                          inception and again if there are any changes

Peter Grundy is director of P G Engineering (Sussex) Ltd. and ITM Consulting (itmconsulting.org); [e-mail]. His column appears bimonthly.