This article originally appeared in the January 2003 issue of The Rational Edge E-zine on-line magazine, copyright 2002-2003 IBM and Max Wideman.

The Rational Unified Process (RUP) is a rigorous software development process advocated by the Rational Software Corporation.

The downloadable PDF file of the paper on this site is the one prepared by the Rational Edge editorial staff with the special assistance of Ms Marlene Ellin.

Published here October, 2003.

PART IV | Recap | Progressive Acquisition Workflow
Specifying the Work | Selecting or Pre-Qualifying Suppliers
Making the Solicitation | Evaluating Submissions | Negotiating the Contract
Administering the Contract and Controlling the Supplier's Work
Terminating the Contract | Understand Progressive Acquisition
Appendix: Glossary of Terms for Progressive Acquisition

Specifying the Work

In general contracting practice, the information that defines or specifies the work of the contract can take one of several forms:

  • Functional Specification
  • Performance Specification
  • Technical Specification
  • Some combination of all three types of specifications -- provided that the instructions are not in conflict.

Please note that we are using these terms as they are used in the contracting industry; the terms functional, performance, and technical have a different meaning within the context of the Rational Unified Process. To avoid confusion, and to understand the general application of these three terms, here is a brief explanation of each.

Functional Specification. This is a document that describes how users will employ the product and the functional capabilities it must have. It stimulates suppliers to propose creative responses, possibly at lower cost. The supplier has the risk of performance, but as an acquirer, you may find it difficult to establish or enforce acceptance criteria.

Performance Specification. This document specifies measurable capabilities the product must achieve in terms of operation (sometimes referred to as "form, fit, and function"). As an acquirer, you can spell out acceptance criteria as objective tests the product must satisfy; otherwise you will reject the product. The supplier carries the risk of performance.

Technical Specification. This document describes in detail the elements and commercial products contained within the final product for delivery -- in other words, the programming language, platform, configuration or architecture, methodology if applicable, and so forth. It should include charts, diagrams, and tables that specify how to construct the product and prescribe the tests and observations that you, as the acquirer, intend to conduct to verify or ensure compliance. In this case, you -- as the acquirer -- take the risk of performance. However, if you demand a fixed price contract, then the supplier assumes the cost risk.

On the face of it, this may seem like a winning solution and, indeed, in the absence of contrary instructions it is the type most often chosen by procurement departments. Unfortunately, in the real world of software development, it is practically impossible to develop technical specifications with sufficient accuracy to enable a controversy-free basis for a fixed price contract. This is true even if you assume that the acquirers know exactly what they want, are technically knowledgeable, and are proficient in the RUP. For this reason, fixed-price contracts are also the type that lead most often to serious disagreements, unsettled claims, expensive legal actions -- and less than successful projects!

Progressive Acquisition Workflow  Progressive Acquisition Workflow

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page