Design patterns

Table of Contents

Stakeholder requirements

Projects implementing stakeholder management often refer to stakeholder or customer requirements, encompassing the needs, expectations, problems, and opportunities expressed by stakeholders. For instance, it is common practice for clients to gather stakeholder or customer requirements, which serve as inputs for the project and form the basis for deriving other requirements (e.g., system requirements). In Systems Engineering (SE) models of projects, the terms stakeholder requirement and customer requirement are often used interchangeably. For clarity and simplicity, the term stakeholder requirement will be used hereafter.

Based on observations at projects, the basic model consists of a type element named Stakeholder Requirement, which includes type properties to store the name and text.

Typically, the type property Name has a data type of Single line text (to contain a brief title for identifying the stakeholder requirement), and the type property Text has a data type of Text (to hold the full description provided by the stakeholder).

Additionally, it is common for a stakeholder requirement to have a type relation called has initiator to the type element Stakeholder, clarifying which organization or person provided the requirement. In most projects, this relation has a cardinality of Single, which encourages the creation of separate stakeholder requirements for similar needs expressed by different stakeholders. A key advantage of this approach is that the separate stakeholder requirements can be refined later based on stakeholder feedback, ensuring that the expressed needs of each stakeholder remain fully traceable.

Scope

When relevant, stakeholders address particular objects in a stakeholder requirement, such as when they encounter problems with existing objects that are part of the project’s scope. To capture this, a Multi-type relation called has subject can be added to the model between the type elements Stakeholder Requirement and Object.

One advantage of this relation is that knowledge can be reused when a derived system requirement is later linked to the stakeholder requirement. In such cases, it may be decided to relate the same object to the system requirement.

Categorization

In Systems Engineering (SE) theory, a distinction is made between a stakeholder need and a stakeholder requirement. However, projects often face challenges in determining whether and how this distinction should be reflected in their SE model.

Stakeholder requirement with property Category

Projects that aim to categorize a stakeholder requirement typically extend the model by adding a type property called Category with the data type List, containing the values Need and Requirement.

This model pattern helps prevent redundancy and offers flexibility to change the category of a stakeholder requirement at a later stage.

Stakeholder need versus stakeholder requirement

Alternatively, projects sometimes consider creating separate elements for stakeholder needs and stakeholder requirements. However, in practice, the disadvantages outweigh the advantages. While this model allows for the separation of stakeholder needs from stakeholder requirements, a major drawback is the significant redundancy it creates, as most stakeholder requirements are essentially copied from the stakeholder needs. Furthermore, the model does not allow for easy toggling between a need and a requirement once created. As a result, this model pattern is rarely used in projects.

Lifecycle

When tracking stakeholder requirements over time, it is often beneficial to add a Status property to the model with the data type List. Examples of list values include Actual and Rejected. This allows for filtering out irrelevant stakeholder requirements.

If some stakeholder requirements are expected to become irrelevant over time, it is advisable to configure the Status property as a Life cycle property for the Stakeholder Requirement type element. This can be done by setting the Life cycle property of the Stakeholder Requirement type element to the Status property. Additionally, by enabling the Auto archive setting and selecting the relevant archive values (e.g., Rejected), only relevant stakeholder requirements will be displayed by default in the views.

Source

Most projects place a high value on the traceability of stakeholder requirements. Knowing the source of a stakeholder requirement enables validation to ensure that the correct information is included.

Source document

A model pattern widely adopted by projects involves a type relation has source between the elements Stakeholder Requirement and Document. This relation allows users to link stakeholder requirements to meeting reports, emails, and other documents that capture stakeholders’ input.

Typically, the cardinality of this relation is set to Multi, as multiple documents can serve as sources for a single stakeholder requirement.

Stakeholder meeting

If a project chooses to track stakeholder meetings, it is common practice to add a relation called is identified during between the type elements Stakeholder Requirement and Stakeholder Meeting. A stakeholder meeting in the model can support a periodic process of identifying and clarifying stakeholder requirements with stakeholders.

Additionally, the relation to a stakeholder meeting can serve as an extra or complementary source that justifies the existence of the stakeholder requirement.

Result

Projects often use stakeholder requirements as a source for deriving system requirements. Based on stakeholder input, one or more stakeholder requirements can lead to the creation of a system requirement. Typically, a form of control, such as approval of the stakeholder requirement, is used to derive a system requirement.

System requirement

In a typical model, a relation called is derived from is used between the elements System Requirement and Stakeholder Requirement. From the perspective of the system requirement, this relation supports both traceability and validation.

While the text of a stakeholder requirement directly reflects the stakeholder’s input, the text of the system requirement is further refined to describe the technical aspects of the related object (e.g., functional, aspect, or interface).

Approval

In practice, all stakeholder requirements are validated to determine whether they align with the project’s scope and goals. The approval of a stakeholder requirement typically signals the green light for deriving a system requirement from it. In the model, the type element Stakeholder Requirement often includes an inner derived type element called Approval, which includes type properties to store the decision and the explanation. The advantage of using a derived type element, rather than a type property, is that by organizing the details on the detail view, it can be positioned right before the relation to System Requirement. This optimally supports the decision-making process.

Typically, the type property Decision uses the data type List (with values such as Approved and Disapproved), while the type property Explanation uses the data type Text (for example, to store an optional description in the case of disapproval). Additionally, a single type relation called has reviewer is often created between the type elements Approval and Person to trace which individual made the decision.

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, approvals created by users are automatically linked to the corresponding person associated with the logged-in user.

Notes

The model is often updated to support notes. In this case, a derived type element called Note is created, which includes a type property Description to store a textual description and a type relation is made by linking to the type element Person. The cardinality of Note is usually set to Multi to allow users to create multiple notes for a stakeholder requirement. 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 across all stakeholder requirements, a note is typically treated as an inner type element. Notes are generally used to store internal comments, thoughts, ideas, or issues from users regarding a stakeholder requirement, in the form of a log.

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 person associated with the logged-in user.

Relatics is the leading Model-Based Systems Engineering (MBSE) software application for construction projects. It is the comprehensive tool that gives professionals access to all project information and offers insight into the growing number of dependencies between all disciplines in today’s projects.

The aim of this article, part of a series of articles, is to provide you with basic knowledge about Systems Engineering elements and its application within the Relatics 6 software. Should you wish to proceed with Relatics 6 on your own projects and require assistance, please do not hesitate to contact us. Our consultants are ready to provide you with the support you need. If you miss an SE pattern in this series, please let us know.

Pioneers in Systems Engineering [book]
Insights from 50 professionals from the Dutch construction industry.

Download our free whitepaper with 7 success factors for implementing Systems Engineering on your project.

Download our free whitepaper to discover why construction projects still struggle with failure costs.

Request a demo

Fill in our form and one of our colleagues will contact you as soon as possible to schedule a demo.

Please enable JavaScript in your browser to complete this form.
Please enable JavaScript in your browser to complete this form.

Download the whitepaper

Please enable JavaScript in your browser to complete this form.
Addresss

Get in touch

Fill in our form and one of the Relatics members will contact you as soon as possible. Do you prefer contact by phone? Please call us at +31 180 413 047.
Please enable JavaScript in your browser to complete this form.