References To Other Documents

References in requirements to information in other documents should be accurate. For example, if the system is required to accept data in a format specified in Appendix C of the Interface Control Document (ICD), there must be an Appendix C in the ICD. If the ICD appendices are renumbered, the requirement must be updated.

In the example of the ICD above, putting the details of an interface in the ICD reduces the changes needed to baselined requirements and allows developers to have a single document to work on. The baselined requirement will say system A has to interface with system B. If the details of the interface, which will be documented later in the effort, are added to the baselined requirements, each time the details change, the changes will have to go through configuration management procedures. On the other hand, only one change is needed to make the baselined requirement refer to the ICD. The ICD can be updated and changed as needed during its development until it is also accepted and baselined. The separate document can be used easily by both system owners.

References should also be specific. A requirement is meaningless if the reference is to an entire document or such large parts of it that is is impossible to determine which information actually applies. If the numbering or pagination of the document being referred to changes, the requirement must be updated.

Referencing Another Requirement

Requirements may be cross-referenced when they are related but are located in different areas of the requirements repository or document. A reference to another requirement should use the unique requirement identifier so that the specific requirement can be located. If the other requirement changes, the requirement may need to be updated. (As a result, it is helpful if the referencing traces forward and backward between the requirements.)

Avoiding Errors

Referencing is an important tool, but it can increase the potential for errors, especially if there is no configuration management. Change control can manage changes to requirements and documents internal to an organization or project.

External documents can change without notice. Common examples are changed page numbers and content. When content changes, requirement meaning can be altered. One way to control these changes is to include copies of referenced external documents in the project/organization document repository.

Page updated 4/4/2005
Ludwig Consulting Services, LLC