Projects implementing stakeholder management often refer to stakeholder or customer requirements, which encompass 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 projects adopting MBSE, the terms stakeholder requirement and customer requirement are often used interchangeably. For clarity and simplicity, the term stakeholder requirement will be used hereafter.
The basics
Based on observations from projects, the basic model consists of a type element called ‘Stakeholder Requirement,’ which includes type properties to store the name, text, and status. Typically, the type property ‘Name’ uses the data type ‘Single line text’ (to contain a brief title for identifying the stakeholder requirement), the type property ‘Text’ uses the data type ‘Text’ (to hold the full description provided by the stakeholder), and the type property ‘Status’ uses the data type ‘List’ with the ‘Life cycle property’ setting enabled (to manage the lifecycle of the stakeholder requirement).
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
In systems engineering 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 systems engineering 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 type 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 it has been created. As a result, this model pattern is rarely used in projects.
Sources
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 called ‘has source’ between the type 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 in its systems engineering model, it is common practice to add a type 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.
Subjects
Sometimes, stakeholders specifically address certain 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.
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 the typical model, a type relation called ‘is derived from’ is used between the type 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 include 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.
