Publishing the Requirements

When should you publish your specification? What should it contain? What form should it take? The Volere Requirements Specification Template is a container for organizing yourrequirements knowledge and one form for the arrangement of a published specification. Of course, there are other ways to arrange the requirements knowledge, and you will save time if you choose the one that best suits your situation.

Harking back to our previous discussion, a well-designed requirements managementtool makes it easier for you to publish the specification in different forms. But no matter which combination of tools you employ to maintain your specification, the important thing is that you understand the benefit for each class of requirements knowledge and each association that you maintain. If you maintain these associations, then you can publish the specification in whatever form best suits your purpose. In this section, we describe some publication versions that are typically useful in particular kinds of situations. We have annotated each part with the relevant sections of the requirements template.

Contractual Document

You have to publish a specification for an outsourcer who is responsible for building the product. This specification is the basis for your agreement with the outsourcer.

• Product constraints (sections 1.4).

• Definition of terms used in the specification (Section 5).

• Relevant facts and assumptions (Section 6).

• List of business events and work context diagram (Section 7).

• Product boundary diagram (Section 8).

• Class diagram or data model (section 9) conforming to the terms specified in section 5.

• Product use case list including a fit criterion for each use case (section 8).

• Individual functional and nonfunctional requirements clustered by product use case (parts of sections ).

• Estimate of size in function points or another recognized unit of measurement (Section 24).

See appendix C, Function Point Counting: A Simplified Introduction, for information onhow to use function points to estimate the size of of your product.

Management Summary

Sometimes you need to publish a version of the specification that provides a management checkpoint. The amount of detail you include depends on the reason for the management checkpoint, but here is a list of the contents typically found in such a document:

• Product constraints (section 4).

• Relevant facts and assumptions (section 6).

• Definition of terms used in the specification (section 5).

• Work context diagram (section 7).

• Business event list (section 7).

• Product boundary diagram (section 8).

• Product use case list including a fit criterion for each use case (section 8).

• Estimate of sizea count of what you know, at this stage, about each of the classes of requirements, such as the number of business events, number of use cases, number of functional requirements, number of nonfunctional requirements, or number of terms. Depending on how far you have progressed, you might be able to include the estimated numberof function points (section 24).

Marketing Summary

When your marketing department is working in parallel to make publicity plans, then you need to publish a version of the specification that focuses on what the product does for the customer.

• Product constraints(sections 4).

• Definition of terms used in the specification (section 5).

• Work context diagram (section 7).

• Business event list (section 7).

• Product boundary diagram (section 8).

• Product use case list including a fit criterion for each use case (section 8).

• If marketing is concentrating on a particular group of use cases, then include the detailed functional and nonfunctional requirements for those use cases (parts of sections 917).

User Review

When you publish the specification for users, you should focus on those parts of the specification that affect the users' work. The most common purpose for publishing this version of the specification is to verify the specified product is the one users are expecting. Another reason is to provide technical writers with the basis for the user manual.

• Work context diagram (section 7).

• Definition of terms used in the specification (section 5).

• Product boundary diagram (section 8).

• Product use case list including a fit criterion for each use case (section 8).

• Individual functional and nonfunctional requirements clustered by product use case. Limit these requirements to the use cases that are directly concerned with these users' work

Reviewing the Specification

When reviewing a specification, you need all sections of that specification. If you are reviewing individual product use cases, then group all of their requirements together. Quite a few requirements may be part of multiple product use cases. Although this grouping requires a little shuffling of the requirements, you should review each product use case to ensure the completeness of its functionality and to confirm it has the appropriate nonfunctional requirements. If you are reviewing one particular type of requirement, then arrange the requirements by type.