This feature has been implemented to help companies to manage a big set of requirements and certifications by allowing users to create a “Master-Follower” copy of requirements. In this context, users can keep the Master copy of all requirements in a single project and Follower copies on projects where these requirements are applicable. With that setup, if a change needs to be made on all copies, the modification can be done once in the Master copy and the changes can be propagated to the Followers.
The propagation of changes is unidirectional i.e it can be done from Master to follower and not vice versa. The attributes that can be currently and copied are detailed in Reuse Requirements page.
When you create a Master requirement, the crown icon shown below will be displayed by the side of the requirement icon.
When the Follower requirement is up-to-date with the Master requirement, it will display this green icon:
If some change in the Master requirement still needs to be approved and propagated, the following icon will be shown:
The blue pencil icon will appear when a change in the Master requirement was rejected (therefore not propagated) or a change was done directly on the Follower requirement.
Creating Master-Follower Copy
In this use case, we are copying the payload’s requirements of a satellite Valisat to another satellite Valisat_2 as both are designed for the same mission objective and are using the same payload ‘Synthetic Aperture Radar’- SAR to achieve it. To create a Master-Follower connection, select the set of requirements to be copied. In the action column, you can find the Reuse icon, click it, and select “Master-Follower Copy”
The Reuse Wizard appears, with ‘Master-Follower Copy’ type of copy selected. Next the destination of the follower can be selected. Once the destination is set, the user can then review the requirements to be copied and their identifier. Next comes the selection of which fields should be copied and synced. Finally click “Create Copy” to finalize the creation of the follower.
The below gif gives an illustration of the process
Further details on the Copy Wizard can be found in → INCLUDE_CHAPTER_FROM_WIZARD:
Acceptance of Follower requirement
Once the creation of the Master-Follower is concluded, the follower requirement will be available at the selected destination but in a “read-only” mode.
To enable the follower requirement for editing, it’s required to perform a “Follower Entrance Review” in the destination (Specification or Section). That can be done for a single follower or to a group of requirements as shown in the figures below.
Change in the requirement
Furthermore, if there is any change in the data of the master requirement, the change can be propagated to the follower. The change will be notified to the follower and the user can decide if the change has to be accepted or ignored manually. When there is a change in the ‘Master’ requirement, the follower requirement ‘Propagation changes’ icon (1) appears in the Action column of the particular requirement.
Also, the modified requirement will have a yellow box to highlight the change. When you hover over the box, a pop-up appears (2) where the user can choose to propagate the changes as well.
Only the owners of the requirement will be able to propagate the changes through “Apply” or “Dont Apply”. If a owner is not specified to the requirement, the users with “Read & Write” access will be able to apply or reject the propagation.
Apart from the owners, the users with admin rights and manage level permissions can propagate these changes from Master to Follower.
Clicking on the propagation change icon, a popup appears in which you can either apply, don’t apply, or edit the change implemented in the Master. The user can select the required action accordingly and save it.
The below gif displays the complete process:
If the user accepts the change then the circular arrow turns green. If the change is not accepted or edited, a blue edit symbol appears on the identifier icon.
Rather than discarding a connection completely and losing its link to the master, the user can select the disconnect option. It will disconnect the follower from its master but will allow the user to reconnect it later if needed. This option can be found by clicking on the three dots in the requirement’s row.
Creating Master-Follower Link
Another way of connecting requirements with a Master-Follower relations is by the “Master-Follower Link”. This allows the user to create this type of relations between objects that already existing in Valispace, without the need to generate new copies.
To do so, the user should select which requirement he wants to be the Master and next select, in the Reuse icon, the option “Master-Follower Link”.
There, the user will be able to select which requirements should be considered as followers for the selected Master.
Once the process is complete the user still needs to confirm the follower entrance
The gif below shows and example if this process.
Master follower requirements representation in Connections graph
Now, the user can see the Master-Follower connections in the connections graph of the requirements module. Each colored connection shows the state of the Master-Follower relations (1).
For example, the green connections show that the Master-Follower is the same while the yellow ones show that changes haven't been propagated by the owner of the requirements. If the connections are blue, that means the changes made in the Master were not applied to the Follower while the grey ones show that the Follower requirement is discarded/disconnected.
Apart from the colored connections, the user can now compare two different sets of specifications which can be within the same project or different projects. The main application of this feature is to compare the Master/Follower specifications or requirements. Within the connections graph, you can find the comparison tool (2).
This feature is helpful when various components have similar requirements and need not be added manually every time. The following example can be referred to for better understanding:
Case 1: Satellite subsystems
We have twin 3U satellites that have slightly different imaging devices as their payload
Consider twin 3U satellites which have the same design and mission objective except for their propulsion system. While the Vali_Cubesat_1A satellite has cold gas thruster, the Vali_Cubesat_1B uses ion thrusters. Hence, the requirement changes only for the propulsion system, and all other requirements can be defined for Vali_Cubesat_1A and then copied to Vali_Cubesat_1B.
Case 2: Wing anti-ice system requirements (ATA 30-11)
Let's consider you are the systems engineer for compiling the list of system requirements for the Wing anti-ice system for an aircraft. The company manufactures multiple models and all the models might have the same set of requirements for the wing anti-ice system. Instead of creating the same set of requirements/ specifications, the user can do the Master-Follower copy and to all the other model projects. Whenever there are changes in the system design, the system engineer can allow/disallow the propagation to other projects.