When projects seek to closely monitor the permit-issuing process, permits are often integrated into their Systems Engineering (SE) model. One of the major benefits commonly experienced is the traceability of objects and activities subject to a permit, as well as the requirements derived from it.
Based on observations at projects, the basic model consists of a type element named Permit, which includes type properties to store the Reference number, Name, Applicable law, Application date, Valid from date, and Valid to date.
Typically, the type property Reference number has the data type Single line text (to store the identification number of the permit provided by the competent authority), the type property Name has the data type Single line text (to provide a brief title for recognizing the permit), and the type property Applicable law has the data type List (to tag it to a law from a preset list). Additionally, the type properties Application date, Valid from date, and Valid to date have the data type Date, corresponding to various milestones of the permit.
Finally, it is common to have a type relation, has competent authority, between the type elements Permit and Organization to specify which organization granted the permit. In most projects, the cardinality of this relation is set to Single, as a permit is typically granted by a single organization.
Scope
In many cases, permits describe aspects of a project that are part of the SE-model. Type elements commonly used as the subject of a permit include an Object and an Activity. For example, a building permit for constructing, modifying, or demolishing a bridge can be related to the object Bridge. Another example is an activity, Excavating, related to an environmental and planning permit.
Typically, in the model, a type relation must be granted for is created between the type element Permit on one hand and the type elements Object and Activity on the other. In practice, the type relation is set to Multi because the scope of a permit may involve multiple objects and/or activities. Finally, it may be useful to set the range of the type relation to Collection when the meaning of the type relation is the same for both the object and the activity within the permit context.
Categorization
Projects that want to categorize a permit typically extend the Permit type element in the model by adding a Type type property with the data type List.
Examples of list values include Environmental permit, Water permit, Building permit, and others. This model pattern enables users to quickly filter similar permits.
Lifecycle
When tracking a permit’s progress over time is necessary, it is often decided to add a Status property to the model with the data type List. Examples of list values include Initialized, In procedure, Cancelled, and others. This helps users filter relevant permits.
When it is anticipated that some permits may become irrelevant to the project over time, it is beneficial to configure the Status type property as a Lifecycle property for the Permit type element. This can be done by setting the Lifecycle property of the Permit type element to the Status type property.
Additionally, by enabling the Auto archive setting and selecting the relevant archive values (e.g., Cancelled), only relevant permits will be displayed by default in the views.
Responsibility
When multiple organizations are involved in the project and can hold a permit (e.g., client versus contractor or contractor versus subcontractor), it is important to know which organization is responsible for follow-up.
To track a permit’s ownership, projects often add a type relation has holder between the type elements Permit and Organization. In practice, it is advisable to set the cardinality of this type relation to Single to avoid a situation where none of the involved organizations feels responsible or takes appropriate action.
Source
Various files and documents are typically involved in sharing and communicating permit-related information, from sending an application by email to receiving the approved permit document. Adding or referencing the actual file helps users quickly access more detailed information about the permit.
Documents
A common way to track related files is to link a permit to documents stored in a Document Management System (DMS). This enhances the permit’s traceability, allowing users to verify its existence and access more detailed information.
Typically, in the model, a type relation has source is established between the type elements Permit and Document. In most cases, the cardinality of the relation is set to Multi since multiple files can be exchanged over time. Common properties for a document include Title and Hyperlink. Typically, the type property Title has the data type Single line text (to store the original filename of the document), and the type property Hyperlink has the data type URL (to store the URL pointing to the actual file in the DMS).
TIP: By setting the ownership of the type element Document to External application, you can work with external data. In this example, the set of documents in Relatics can be automatically synchronized with the list of documents in the project’s DMS.
Attachments
Alternatively, when a DMS is not (yet) available for the project, related files can be temporarily stored in Relatics.
In the model, a derived type element Attachment is created for the type element Permit. Typically, the cardinality of the derived element is set to Multi, as multiple files can be exchanged over time. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a full overview of attachments regardless of the permits, an attachment is generally considered an inner type element.
Common properties for an attachment include File and Description. Typically, the type property File has the data type Attachment (to upload the actual file), and the type property Description has the data type Text (to store an optional comment or note about the attached file).
Result
Permits are often the source of other type elements in the model, such as requirements derived from permits. This supports the traceability of these elements, helping to justify their existence and locate additional information.
Typically, in the model, a type relation is derived from is created between the type elements System Requirement and Permit. The same applies to the type element Process Requirement. In practice, the cardinality of these type relations is set to Multi, as multiple permits can serve as the source of a requirement.
Notes
The model is often updated to support notes on permits. Notes are typically used to store internal comments, thoughts, ideas, or issues from users regarding a permit, usually in the form of a log.
For the type element Permit, a derived type element Note is created in the model. Typically, the cardinality of Note is set to Multi to allow users to create multiple notes for a permit. Additionally, the setting Act as inner element is enabled for the derived type element. Since most users are not interested in seeing a full overview of notes for all permits, a note is usually considered an inner type element. A common property for a note is Description, with the type property Description having a data type of Text (to store the full description of the note). Finally, a type relation is created by is established between the type elements Note and Person. In practice, the cardinality of this type relation is set to Single, as notes are typically entered by individual users.
TIP: By setting the type element Person as the Type of elements to link with users (optional) and enabling the option Element linked to current user as default to element for the type relation, notes created by users are automatically linked to the corresponding person connected to the logged-in user.