Lately I have been assisting a number of customers in developing formal documentation directly from the engineering design repository in CORE™. Use of the Formal Documentation features in CORE is topic of particular interest to users during delivery of the training class. Over my next several blog posts, I will cover several unique abilities and tips to help you manage development of the formal documentation.
Most programs or projects have to develop a Documentation Tree to provide understanding of what system design documentation will be provided. The document tree is easily constructed and managed in CORE using the DOCUMENT class and relations between different elements in the class. [more]
In the DOCUMENT Class there are three relations used within the class to relate a particular DOCUMENT element to another DOCUMENT element. These relations are: “references / referenced by,” “refines / refined by,” and “traced from / traces to.” A brief description of each of these relations follows.
“references / referenced by” – identifies the applicable or reference document for the subject document. You can use this relation for documents generated by the model as well as other documents, such as standards, which are used in the system design. In formal documentation, this relation is used to build the Applicable Document section of a document.
“refines / refined by” – identifies the parent or children of a document. This relation is used in formal documentation to build the documentation tree.
“traces from / traces to” – identifies a higher-level document from which the requirements in the subject document should be associated. This relation is used to develop the requirements traceability matrix.
To develop a Document Tree then, make relations between DOCUMENT class elements using the “refines / refined by” relation. For example, if we have an Original Source Document, which has been imported and analyzed to create the System Level SSS, the Original Source Document is “refined by” the System Level SSS. As the design continues, System Level SSS is “refined by” each Subsystem Level SSS.
To develop a traceability diagram, create a custom hierarchy using the “refined by” relation and give the hierarchy a unique name, something like “Document Traceability.” If you desire specific information in each ICON in the hierarchy tree, create a custom Icon Template. For example, many users like to have the Document Number and Name in the Icon.
The end result is a Document Hierarchy similar to the following:
Document Number is an attribute in the DOCUMENT class and this number is customizable to meet the user needs, it does not have to follow the rules for hierarchy number. Many projects have a specified document numbering scheme and this attribute allows to follow the project numbering format. You can further customize the Icon by adding Revision Number, Document Date, and/or Contract Line Item Number; all of which are attributes on a DOCUMENT class element.