Most projects use a dedicated system or application to store document files, for example, in a Document Management System (DMS) or shared network drive. It is common practice for projects to include a type element Document in the Systems Engineering (SE) model. As only a list of document names, including additional metadata, are stored in Relatics (and thus explicitly not the document files), the documents in the Relatics workspace can be seen as “pointers” to the actual document files stored in the DMS or network drive. The added value is traceability, as for various type elements in the SE model the documents in the Relatics workspace provide meaningful context. For example, sometimes a document is a source of another type element (e.g., requirements, permits), and sometimes a document is a proof for another type element (e.g., verifications, tests).
Based on observations at projects, the basic model consists of a type element named Document, which includes a type property to store the name. Typically, the type property Name has a data type of Single line text (to contain a title or filename for recognizing the document).
Optionally, projects consider adding other type properties to the model when the corresponding metadata is essential for filtering or reporting needs. Examples of types properties commonly used for documents by projects:
- Date with a data type of Date
- Version with a data type of Single line text
Reusability
In construction projects, it is common for documents to be reusable. For example, a specification document can serve as the source for many requirements. Consideration must be given to how the documents are used.
Document as attachment
In cases where a document does not need to be reused and serves a single purpose, it can be used as a property of a type element, such as a Resumé under the type element Person, as seen in the example image. This type property is of the data type Attachment.
In this case, the resumé document is not intended for reuse with other persons or elements, but is instead associated with a single person. Additionally, the resumé document does not have its own relations within the model.
Note that by using a type property, only one file can be uploaded for a person, which is appropriate for this use case.
Another common use of the attachment property is for adding a figure, for example as proof for a verification. In this case it is often necessary to allow multiple figures in the model as proof.
When needing the ability to insert multiple figures as proof, a derived element can be used. This allows the user to add multiple figures.
Document via relation(s)
When a document needs to be reusable, we often see a Document type element in the model.
As a type element, the document can have various type relations added to other elements. In this example, you can see some of the common relations we frequently encounter.
Document usage
Contract documents
When documents serve as the source of a requirement, they sometimes have different relations, properties, and/or user rights compared to regular documents.
As a result, these types of documents may be assigned their own element, such as Contract Document, allowing them to have a separate network within the model.
Documents that must meet requirements
It is common for requirements to be imposed on documents as well. For example, documents may need to meet layout requirements specified in the Project Management Plan.
In some cases, these documents are created within Relatics even before the physical documents exist. This approach allows users to prepare work in advance.
This relation can, of course, also be verified using the middle element Verification.
Referencing
Since Relatics is not a document management system (DMS), we often refer to the physical documents themselves. As explained in this document, a physical document file is just one part of the document element in Relatics. In most cases, project documents are stored and managed in a DMS.
The most common approach is to continue managing the documents within the DMS while making them available in Relatics, allowing users to relate the documents to other elements within the model.
To use these (DMS) documents within Relatics, there are two levels of ambition:
- Source (DMS Link) property
- Application integration
Source (DMS Link) property
Using a property that allows users to insert a link to the corresponding document in the DMS is a common approach. This way, users can utilize Relatics functionality as needed, while the physical document continues to be managed within the DMS.
In this case, the type property Source is of data type URL.
Advantages:
- Minimal effort required to set up
- No extra copies of the original file
Disadvantages:
- No data is retrieved from the DMS
Application integration
By setting up an Application integration, you enable Relatics to display documents with their metadata directly and in real-time from the DMS inside Relatics.
The connection synchronizes data every 5 minutes, copying a small amount of metadata such as Name and Version. This data stays up-to-date through the synchronization. Additionally, a preview of the document can be shown inside Relatics.
Advantages:
- No extra copies of the original file
- Always the latest version available
- Document preview inside Relatics