Knowledge Versus Specification

Before plunging into how to write requirements and assemble them to make a specification, it is worth spending a few moments to consider the knowledge or information you accumulate as you progress through the requirements process. By understanding this knowledge, you make better decisions on how the requirements specification is written, published, and distributed.

Let us start with the requirements knowledge model (Figure 10.2). Think of this model as a conceptual filing system, containing your requirements information. You can also think of it as an abstract way of looking at the contents of the template. Each rectangle in Figure 10.2 represents a class of requirements information. The way in which you store this information is not important, nor should you be too concerned about its format. The information is the crucial aspect of this conceptual model. Think facts, not documents or databases.

We are suggesting for convenience that most of this information can be contained within a specification. To that end, the numbers on the classes provide a cross-reference to the specification template.

The lines represent necessary associations between the classes. For example, the classes Work Context, Project Purpose, and Stakeholder have an association between them because this association has a meaning to your project. Recall from Chapter 3 the trinity of scope, stakeholders, and goals. These three had dependencies on one another, so it is appropriate to model each dependency as an association we call Business relevancy.

Think of the knowledge model as an abstract representation of the requirements information you accumulate, manage, and trace. When your team has a shared understanding of their knowledge model, you are in a position to decide how you will format and store this knowledge. You decide what combination of automated and manual procedure you will use to record and keep track of the content. Typically projects use a combination of spreadsheets, word processors, requirements management tools, modeling tools, and manual procedures to manage the information represented by the knowledge model.

You should also consider the information contained by the knowledge model, and decide which parts of which classes are to be published in which documents. For example, Figure 10.2 includes an association called Product Tracing between the classes called Product Use Case and Requirement. An asterisk appears at both ends of the line, which means each product use case is made up of a number of requirements, and each requirement is potentially used by a number of product use cases. If you are keeping track of your requirements knowledge according to the model, you have a number of options for publishing it. You could select a specific product use case and publish it together with its associated requirements. Alternatively, you could select a particular requirement and produce a summary of all the product use cases that contain the requirement. When you have a well-organized knowledge model you can choose which parts of it should appear in which documents, and provide stakeholders with the information they need.

For more details on building your own tailored requirements knowledge model, see Robertson, Suzanne, and James Robertson. Requirements-Led Project Management: Discovering David's Slingshot. Addison-Wesley, 2005.