Design patterns

Table of Contents

Requirements

Most projects incorporate requirements into their Systems Engineering (SE) model to support various processes (e.g. requirements analysis process, design process, verification process). In the project lifecycle, the wishes and needs of stakeholders are analyzed, resulting in a set of requirements. A solution (e.g., a structure of objects) is designed and integrated to meet the requirements, and the system is verified to comply with all the specified requirements.

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

Typically, the type property Name uses the data type of Single line text (to contain a brief title for identifying the requirement), and the type property Text uses the data type of Text (to hold the full description of the requirement using the SMART criteria). In many cases, projects enable the Draft state option for the type property Text to control the versions of requirement texts as they have an important legal value in the specifications.

Lifecycle

When monitoring the handling of 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 makes it easier to filter out irrelevant requirements.

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

Sources

The project members involved in requirements management benefit from insight into the origin of a requirement. This insight can be gained by adding a type relation to the model from Requirement to Document. We often see that a Requirement can only originate from one Document. Therefore, the cardinality of the relation is set to Single.

The source of a requirement does not always have to be a document. Requirements can be derived from multiple types of elements. This pattern describes the situation that a Requirement is derived from a Stakeholder Requirement.

Many construction projects recognize Stakeholder Requirements, which follow an acceptance process before being added to the definitive set of requirements. The project members involved in requirements management benefit from the insight from what Stakeholder Requirement the Requirement is derived. We often see that the cardinality of the relation between Requirement and Stakeholder Requirement is set to Multi. It is imaginable that multiple Stakeholder Requirements can lead to one Requirement. Also, this setting will help to manage that every approved customer requirement is translated into a requirement.

Scope

Many projects use different type elements for requirements, among the most common ones:

  • System requirements: Describe what should be created.
  • Process requirements: Describe how the work should be executed.

In the Relatics model, we distinguish between these types by adding a property Type for the type element Requirement. We categorize this property as a List data type with the values System and Process. The requirements appear in the same list; the value of the Type property indicates whether we are dealing with a system or process requirement, and can be used to, for example, filter on.

If the information needs of a system requirement and process requirement differ significantly from one another, or when it is desired that system and process requirements are managed in two different sets, consider splitting them by configuring two separate type elements instead of using a List property.

Separating the requirement types has the advantage that users will not be bothered with information only applicable to the other requirement type. Unlike the previous pattern, it is impossible to generate use cases or overviews in Relatics where all types of requirements are shown together. In conclusion, there are two common ways of distinguishing between process and system requirements; each option has their specific implications, and both can be legitimate depending on the project needs.

Categories

Within the MBSE methodology, various categories of system requirements are recognized. Some common ones are: functional requirements, aspect requirements and interface requirements. Functional requirements indicate what the system should be able to do, functionally. Aspect requirements are requirements regarding the performance of system aspects (availability, reliability, maintainability, safety) under certain conditions. Interface requirements derive from an identified Interface between multiple systems. These requirements are formulated to manage interfaces on a requirement level.

A List property named Category is added to distinguish the different categories of System Requirement. The values to choose from are Functional, Aspect and Interface. Projects often make it explicit to which aspect, interface, or function the system requirement is related to avoid information overload and to group system requirements. Therefore, we’ve added Multi relations from System Requirement to Interface and System Requirement to Function. Contrary to function and interface, a List property Aspect was added where the relevant aspect can be selected. We often see that an aspect requirement can be related to only one aspect, and that the list of aspects to choose from is usually fixed and rarely edited. Therefore, creating a type element Aspect with a relation from System Requirement to Aspect is unnecessary.

Allocation

Most MBSE construction projects allocate the requirements to structures like System Breakdown Structure and Work Breakdown Structure. This allocation is also essential for setting up a complete MBSE model in Relatics. It provides insight into the relationships between the structures and requirements and helps manage project progress and the execution of verifications. The allocation is also essential for a client when setting up a requirement specification.

A relation from System Requirement to Object is required to allocate the system requirements to objects. System requirements can often be set for multiple objects, so the relation’s cardinality has been set to Multi. Most projects use this allocation to indicate which System RequirementObject relations must be verified.

The same pattern as explained for the System RequirementsObjects relation applies to the Process RequirementsActivity relation. Most projects use this allocation to indicate which Process RequirementActivity relations must be verified.

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.