Setting up a Requirements specification with Relatics

One of the most popular processes managed in Relatics is requirements management. Requirements management is prominent in the MBSE methodology and has numerous connections and relationships with other MBSE processes. The way requirements management is conducted varies for Clients, Contractors, or engineering firms, as well as the type and scope of the project. This common practice outlines the steps a Client could take to develop a Requirement specification and how Relatics can support this process. This article will focus solely on the chapters of the requirement specification that are filled with data managed in Relatics. Chapters with static texts and specific project information are not considered. Also, this article will review various model choices encountered by Relatics consultants based on their experiences. It does not prescribe a single solution since Relatics is a customisable product tailored to the processes of a project or organisation.

Based on the experience of our consultants, several steps have been identified that a Client could take to develop a comprehensive Requirement specification. These steps will be examined one by one in this article:

Identifying Requirements

Stakeholder Analysis

The process of gathering requirements begins with a Stakeholder Analysis. In this article, a stakeholder refers to individuals or organisations that can influence the project or are affected by the achievement of project goals. Stakeholders may benefit from a project but also experience disadvantages if it causes disruptions. The SE guideline from Dutch Rail operator ProRail outlines three key steps in dealing with stakeholders: Identifying Stakeholders, Analyzing their interests and influence, and Managing stakeholders. These three steps together will form the Stakeholder Analysis.

The Stakeholder Analysis reveals stakeholders’ needs and requirements regarding the project’s realisation. Conducting a thorough Stakeholder Analysis is crucial. Without identifying the needs of all stakeholders, an optimal solution is not possible. The gathered stakeholder requirements ultimately result in two outcomes: either they are honoured and incorporated into the further Requirements specification or rejected and not included.

Identifying Other Requirements

Not all requirements originate from stakeholder requirements. By conducting a thorough context analysis, requirements can be identified. The context analysis involves:

  • Investigating the specifications of the interfaces with which the system must interact.
  • Understanding the environmental influences under which the system must operate.

Requirements can also be identified based on established project goals (e.g., the goal of environmentally conscious construction) or applicable laws and regulations.

Reusing Requirements

In practice, requirements are often reused. Those requirements are often derived implicitly from the minds and experiences of employees. With a library, these requirements are made explicitly available for an ongoing project as a kind of checklist, ensuring that important matters are not overlooked. Such libraries are populated from completed projects or applicable guidelines. Each new project can utilise the specifications and requirements contained therein. New insights, new regulations, or experiences from completed projects will cause further development of the library. On the project level, project members need to individually assess whether the requirements sourced from the library apply to their project. The most successful libraries we, as Relatics consultants, encounter are built on an effective management process with assigned responsibilities.

Types of Requirements

Previous Paragraphs discussed how requirements can be identified, but the various types of requirements were not considered. Most projects that we Relatics consultants encounter involve two types of requirements:

  • Technical requirements: Describe what needs to be created.
  • Process requirements: Describe how the work needs to be performed.

Both technical and process requirements can be identified through the previously mentioned methods.

Model

The visualisation of the SE model below describes a situation where one type element, Requirement, is created. The requirement type element relates to the Organisation type element to record which stakeholder initiated the requirement. In this situation, a single relation is chosen so that each requirement initiated by a stakeholder is recorded as a unique requirement in Relatics. The “Type” property on the Requirement element allows for indicating whether it is a Technical or Process requirement. Meanwhile, the “Status” property indicates the actual and deprecated requirements. The relationship from Requirement to Document records the source document where the requirement is described. Because of this relationship, it is possible to understand in which document the requirement is described; for example, this could be a specification or guideline.

In cases where a more extensive Stakeholder Analysis is conducted, it is desirable to isolate all requirements submitted by stakeholders and subject them to a separate honorarium process before they are included as requirements. In such cases, we introduce a new type element called “Stakeholder Requirement”. In the example below, multiple Stakeholder requirements can be captured in one Requirement. Once stakeholder requirements are translated into Requirements, it can be indicated whether it is a Process or Technical requirement. However, Requirements do not always need to originate from Stakeholder requirements. Earlier, we described multiple ways in which requirements can be identified. Not all of these requirements originate from stakeholders and must be evaluated first. These requirements can be directly created as instances from the Requirement type element.

We also briefly described the difference between the various types of requirements (Technical requirement & Process requirement). In the two previous examples Requirement, was used with a property “Type” that indicates the requirement type. If the information needed for a Process requirement significantly differs from that needed for a Technical requirement, consider making them different elements in the SE model. This results in the example below, where we recognise “Process Requirement” and “Technical Requirement”. In this case, we have further explored the situation where we recognise “Stakeholder Requirement” as a separate type element in the SE model. This option provides the opportunity to capture Stakeholder Requirements separately and subject them to their evaluation process. Subsequently, Stakeholder requirements can be translated into Technical or Process Requirements. As described earlier, requirements do not always originate from Stakeholders and can also be directly included as Technical or Process Requirements.

Requirements Analysis

After the identification and collection stage, the requirements are often subjected to a requirements analysis. The requirements analysis involves a critical assessment of the requirements and, where necessary, improving the quality (SMART, Format, Linguistic, Traceability, etc.) of the requirements. The requirements analysis process contributes to achieving a comprehensive, high-quality set of requirements. Ultimately, this will lead to a high-quality Requirement specification. Given the needed domain knowledge, individuals from multiple disciplines often conduct the requirements analysis process. Requirements are always assessed for quality and sometimes for design constraints. Design constraints can hinder innovation and the possibility of an optimal design.

Before conducting a requirement analysis, the project has to consider how detailed it wants to be. There are different levels of capturing the requirements analysis. For the examples below, we have used a model where only one Requirement type element is recognised. In this case, the requirements analysis process will be identical to Technical Requirements and Process Requirements.

The example below shows a model that only records whether the requirement is SMART with the possibility to provide an explanation. By using Relatics History in collaboration with the Draft state functionality on the Requirement Text property, it can be traced why, when, and by whom a Requirement Text was modified. The Draft state functionality on the Requirement Text enforces that a user must always enter a comment first, specifying the reason for the modification.

We often encounter cases where there is a need to handle the evaluation of requirements explicitly. In this case, it is insufficient to only add SMART and SMART Explanation properties. The task of analysing the requirement is specifically assigned to a person, who also needs the ability to indicate whether they accept the requirement and provide comments if the requirement is not accepted. The individuals assigned to the analysis often have the necessary domain knowledge. The model below illustrates this situation. Processing the comments from the analysis is not necessarily done by the person who placed the comment. This is often the responsibility of the requirements manager or the project Systems Engineer.

A third possible variant links requirements to a discipline instead of a person. Especially on large projects, it is not always clear who should assess the requirement, but it is known which discipline should have the responsibility of evaluating it. In this case, the requirement is linked to a specific discipline, and it is the responsibility of the discipline lead to ensure that all requirements related to that discipline are evaluated.

Requirements Allocation

Within the MBSE methodology, various types of Technical requirements are recognised, the most common ones are; functional requirements, aspect requirements, Interface requirements and design constraints. Functional requirements indicate what the system should be able to do. Aspect requirements are requirements regarding the performance of system aspects (availability, reliability, maintainability, safety) under certain conditions. Design constraints differ from functional and aspect requirements and limit the possible solutions that can be chosen for the system. Interface requirements derive from an identified Interface between multiple systems. These requirements are formulated to manage interfaces on requirement level.

The project benefits from clarifying in Relatics where the Technical- and Process requirements apply and in which category they belong. To gain this insight, correctly allocating requirements to different structures, such as the System Breakdown Structure (SBS), Work Breakdown Structure (WBS) & Functional Breakdown Structure (FBS), is crucial. The FBS is a functionally oriented structure of each function that the system must address. The SBS is a decomposition of the system into manageable system components. The WBS helps to clarify the Client’s and executing parties’ expectations and responsibilities.

Incorporating a Work Breakdown Structure into the Requirements specification can enhance the efficiency, transparency, and successful execution of the project by providing clarity, managing expectations, and offering a structured basis for planning and control. It provides a common language and a clear framework for discussing and aligning project-related matters. Unlike the Technical Requirements allocated to the SBS and FBS, we often encounter an allocation between the Process Requirements and the WBS. 

The result of allocating the requirements to the structures is a robust, well-integrated system that meets the specified requirements and is flexible enough to adapt to changing circumstances and requirements. For Relatics, allocation to the structures is also crucial because it provides insight into the relationships between the structures and requirements. Also, these relationships are important when publishing the requirement specification from Relatics. This will be explained in the latter part of this article.

Model

The model below shows a situation where we recognize Technical and Process Requirements. The Technical requirements are allocated to the FBS (Function) and SBS (System). Both elements are Hierarchical, so in Relatics, we can make a hierarchical decomposition of the Functions and Systems. We also notice a relation between System and Function. We, as Relations consultants, often encounter this relation to have a clear overview of which systems are needed to fulfil which functions. When a Technical requirement is influenced by one or more certain aspects, the relation between the Technical requirement and the aspect will be made.

As mentioned above, we often encounter an allocation of the Process requirements to the WBS. To make a solid Work Breakdown Structure in Relatics, we often choose a model including Work Packages and Activities. The Work Package can consist of multiple activities and is closed when all the work Package activities are completed. The work package element is hierarchical and the activity element is Hierarchical derived from Work Package, in Relatics we can then make a Hierarchical structure that consists of work packages and activities. This hierarchical structure can be seen as the WBS.

Requirement specifications that are published using Relatics often include the prescribed verification for each requirement. When setting up the requirements specification, the Client often already knows in what phase and by what method the requirements should be verified. This information can already be passed over to the Contractor by including it in the Requirement specification. The model below shows the same picture as before but with the prescribed verification included as Inner Derived elements for the Technical and Process Requirements. Because an Inner Derived element can only be derived from 1 element, we must create a prescribed verification element for each Requirement type. We have chosen to model the method as a property for the prescribed verification that also includes a relation to the Phase type element. In this model, multiple prescribed verifications are possible for each requirement.

Publishing the Requirement specification

Relatics allows users to create reports to share their project data. This allows others to view data in cases where they do not have access to Relatics or would rather view the data in a Word/PDF file. In order to generate a report, a predefined report template must be created. A predefined report template is a Microsoft Word document that contains one or more code blocks with Relatics Syntax. When a user generates a report, the code blocks in the template are replaced by the corresponding data stored in the workspace. A Requirement specification often consists of static texts and Relatics data. Therefore, in this example, we will show how to implement both. In the examples provided, the SE model below is taken into consideration. The article create reports describes the exact steps to take to create a report template.

Once the SE model has been well-designed and the mentioned steps have been completed, the project is ready to draft a Requirement Specification. The power user can initiate this process by creating a Microsoft Word document and formatting it according to the desired structure of the Requirement Specification. The formatting and layout, including aspects such as font, logo, page numbers, and cover page, are all predefined within the report template in Microsoft Word. If the layout and formatting standards of the project/organization are already established, the power user can simply replicate these within the report template.

The used example of the Requirement Specification will consist of the following chapters: Introduction, Functional Breakdown Structure (FBS), System Breakdown Structure (SBS), Work Breakdown Structure (WBS), Technical Requirements, and Process Requirements.

Most Requirement Specifications typically commence with an introduction following the cover page. This introduction does not contain data from Relatics and can thus be static text inserted directly into the Word template. In the example below, the structures are introduced in the report after the Introduction. In the example provided, the syntax should be structured to the depth of the lowest level of the Breakdown Structure, which, in this instance, is the 8th level. This example is worked out for the SBS but is applicable to all structures (SBS, FBS, WBS).

After the Introduction and the Structure chapters, the chapters regarding Technical Requirements and Process Requirements are introduced. We’ll begin by addressing the chapter on Technical Requirements. This chapter closely follows the SE model. Within the report, the data follows the structure of the SBS as based in Relatics. For each System, the requirements related to that particular system are outlined. Requirements are clustered per system based on requirement categories (aspect, interface, function, design constraint). The requirements are presented in tabular format, showcasing relevant requirement information.

In the selected example, the chapter on Process requirements follows the WBS as based in Relatics. This chapter aligns with work packages and their associated work package activities. In the SE model, process requirements are linked to work package activities. Therefore, in the report requirements are listed per work package activity in a tabular format. This table shows the relevant information needed for the Requirement specification. The same structure can be used in the report template as seen in the images above.

Once all chapters are properly formatted, the Word template is saved and uploaded into Relatics. From that point forward, generating the report is as simple as pressing a button. Depending on the contents of the report template, it will be filled with static text and data from Relatics. After generating the report from Relatics, users may choose to further edit or finalise the report in Microsoft Word. Additionally, it’s common to merge the report generated from Relatics with text from other documents to create a publishable document.

The described example is just one way of setting up a Requirement specification. In practice, we encounter different formats of Requirement specifications. We often see that the Requirement is split up into multiple Requirement specifications, such as one oriented on the Technical Requirements and one oriented on the Process requirements. Depending on the size and complexity of the project some Clients choose to split up their Requirement specifications per System or set of Systems. The project structure can motivate choosing this way of splitting the Requirement specifications. Some big integral projects consist of multiple subprojects that can be awarded to different Contractors.

Some Clients choose to attach a more data-oriented document, such as an Excel or XML file, to the Requirement specification. This way, the Contractors can use the data-oriented documents to quickly import the Requirements and structures into their own Relatics environment or database. This will save the Contractors time and can benefit the data delivery between Client and Contractor.

Relatics is the leading Model-Based Systems Engineering 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.

This article is a common practice and is the result of years of experience gained by our consultants in the field. Should you wish to implement this knowledge in 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.

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

Download the whitepaper

Please enable JavaScript in your browser to complete this form.

Download the whitepaper

Request a demo

Fill in the below information and we will contact you to schedule a demo.

Please enable JavaScript in your browser to complete this form.
We will use this information to contact you.
Please enable JavaScript in your browser to complete this form.
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.