The SystemWeaver Requirements Management solutions provide powerful tools to support the entire requirements process. This article presents the basic Requirements model and view support in SystemWeaver and how to configure it. The model can be customized to meet the needs of your organization's processes. Examples and exercises are provided as well.

Prerequisites

Meta Model Notation

The following notation is used to describe meta models.

  • Item types are boxes with the item type SID in the top-right corner
  • Part types are arrows. The part type SID is written on the arrow
  • Item type inheritance is illustrated with the item type residing inside the item type it inherits from
  • Abstract item type names are written in italic

Requirements in SystemWeaver

Requirements in SystemWeaver are used to document the properties and functionality of a system. This is done on several different abstraction levels, ranging from feature requirements down to detailed design requirements. Between these abstraction levels, responsibility is distributed between hundreds of engineers.


The Basic Requirements Meta Model

A very basic requirements meta model is shown here. This meta model contains a Feature level that holds all the Features. The Features are described more in detail through Feature requirements.



Note: All requirements must inherit from the Abstract item type Abstract Requirement with SID = 'RQ" for the test GUIs to function.

Configuring Reports


Using the Reports view, users can generate reports of all features and feature requirements. How to configure reports is described in Report Generation - Introductory Training.



Tip: Find out how to configure a menu button for users so that they can easily access a defined report definition with one click.

Requirement IDs

All objects in SystemWeaver have a SystemWeaver ID. For items, this can be seen in the Properties view, as shown below.


However, for requirements, it is often preferred to have a more recognizable ID. In SystemWeaver, there are different ways to create requirement IDs:

Unique IDs

Unique ID is a Custom type of attribute that has some hard-coded requirements views associated with it. It uses a context and an ID that is, in part, built from context. For our Feature model, the Feature level could be the context, and IDs are added to the requirements.

The Unique ID concept actually builds on two attributes:

  • Unique ID context
    • SID: AUIC
    • Type: Custom, Array

  • ID

    • SID: AUID

    • Type: Custom, Single

                                                                             


Attributes of type Custom have special GUIs connected to them that depend on a specific SID being used. The attributes must be added to the correct item types.





To start using Unique ID in SystemWeaver:

  • First create a context on the Feature level.
  • All requirements under the context will get IDs prefixed with the context added here.


Adding IDs to requirements


Bildresultat för exercise icon freeExercise 4


Add an Unique ID to the feature requirements as demonstrated above.

Identity

Identity is a type of attribute that creates a counter in the database. Each time an attribute of the type is created, the counter will be increased and automatically set.

Identity in SystemWeaver:

  • Creating a new feature requirement the attribute will be automatically set.
  • The value chosen is unique for the counter/sequence defined when creating the attribute (in this case “REQ”)

Bildresultat för exercise icon freeExercise 5


Add an Identity to the feature requirements as shown above.

Bildresultat för exercise icon freeExercise 6

Add a function level that should detail the feature requirements.

The meta model in the SystemWeaver swArchitect.

Using the meta model in the SystemWeaver swExplorer client.


Traceability

Establishing traceability between feature and function requirements includes two steps:

  • Allocation/distribution of feature requirements on functions.
  • Requirements traceability from function requirements to feature requirements.



Allocation/Distribution of Requirements:

  • The first step is distributing the features, together with the requirements to the functions that should detail them.
  • The reason for distributing requirements is to divide and conquer the entire problem into smaller parts. The function owner should only need to be concerned with the features that they are responsible for.


Allocation/distribution of requirements:

  • The meta model for handling allocation/distribution of requirements includes a part from function to feature called “Realizes”


Allocation/distribution of requirements:

  • In the SystemWeaver client, it is possible to connect Features to Functions by copying the feature and pasting it on the function.
  • The “Realizes” part indicates that the function should detail and handle the requirements part of the feature.



Allocation/distribution of requirements

  • Using the standard functionality in SystemWeaver (copy-paste) does not provide a good overview of how features are allocated to functions.
  • Views can be set up to get a better overview of how features are allocated to functions.
  • The Coverage: item->item view is a standard view that aids in allocating items and getting an overview of the allocation.

Bildresultat för exercise icon freeExercise 7 - Coverage: item > item 


Open the view configuration.

  • File > Configure the Explorer
  • Find the “Coverage: item->item” and click “Edit configuration”



  • Add this configuration to the view:
<CoverageViewConfigs>
  <CoverageViewConfig id= "unique_id">
    <ViewSettings>
      <Caption>Distribute Features to Functions</Caption> 
      <RibbonGroup>Features</RibbonGroup>
      <Description>This view aids in distributing features to functions</Description>
    </ViewSettings>
    <Mappings>
      <Mapping fromType="FUN" partType="REAL" toType="FEAT"/> 
    </Mappings>
    <TopItemType itemType="SPEC"/>
    <RightSide>
      <ContextTree>
        <Context>
          <AddParts owner="main" sid="FELS" part="FeatureLevels" defobj="FeatureLevel"/>
          <AddParts owner="FeatureLevel" sid="FEATS" part="Features" defobj="Feature"/>
        </Context>
        <Tree startGroup="FeatureLevel">
          <Case group="FeatureLevel" go="/Features"/>
        </Tree>
      </ContextTree>
    </RightSide>  
    <LeftStructureTree partTypes="FULS;FUNS"/>
    <AdditionalLeftItemAttributes sids=""/>
  </CoverageViewConfig>
</CoverageViewConfigs>


Note: Observe that you need to activate the view and restart the client before the configuration will take effect.


After the restart is done, there is a new view in the SystemWeaver client named "Distribute Features to Functions" when selecting the "Specification architecture".


Analyzing the Code: Coverage item -> item

The first part of the XML defines how the button should look by defining the name of the button <Caption>, what group in the Ribbon the button should be a part of <RibbonGroup> and the description that appears if the mouse hovers over the button <Description>.


<CoverageViewConfig id= "unique_id">
    <ViewSettings>
       <Caption>Distribute Features to Functions</Caption>
       <RibbonGroup>Features</RibbonGroup>
       <Description>This view aids in distributing features to functions</Description> 
    </ViewSettings>


  The second part defines what items are to be mapped to one another through a specific part <Mappings> and <TopItemType> defines the item type SID that the view should be active on.


<Mappings>
      <Mapping fromType="FUN" partType="REAL" toType="FEAT"/> 
</Mappings>
<TopItemType itemType="SPEC"/>


The third part describes the right side of the tree using a context and then describes how the tree should be visualized starting with the top level that is set in <Tree startGroup>.


<RightSide>
      <ContextTree>
        <Context>
          <AddParts owner="main" sid="FELS" part="FeatureLevels" defobj="FeatureLevel"/>
          <AddParts owner="FeatureLevel" sid="FEATS" part="Features"  defobj="Feature"/>
        </Context>
        <Tree startGroup="FeatureLevel">
          <Case group="FeatureLevel" go="/Features"/>
        </Tree>
      </ContextTree>
    </RightSide>


The final part describes what part SIDs shall be represented in the left-side tree.


    <LeftStructureTree partTypes="FULS;FUNS"/>


When features have been allocated to functions, each function knows what incoming requirements it should handle. Now we can create traceability between function requirements and feature requirements.

Meta Model for Traceability

The simplest model for requirement traceability would be for the function requirement to have a part pointing to the feature requirement as seen in the example below.



With this meta model, function requirements can point to feature requirements and there is formal tracing between these.

However, this meta model becomes inflexible when considering the life-cycle perspective. When the feature requirements are released and new versions are created, the only way to get correct requirement traceability from the function requirement is to create a new version of the function requirement and connect it to the new version of the feature requirement, even if there is no change impacting the function requirement.


One way to make changes to feature requirements impact the function level less while still having formal traceability is by moving the ownership of traceability higher up in the hierarchy. When creating a part type, there is a DefObj which is the type that the part points to. There is also a RefObj which enables pointing to two item types with one part type. The RefObj cannot be created or changed without specialized views which are found inside the SystemWeaver Architect.



DefObj can be part types as well as item types but these cannot be created or changed without specialized views which are found inside the SystemWeaver swArchitect.



Having part types that point to parts is restricted in the sense that an item can only use a part to point to a part it owns. There is no way to point to parts that belong to other items.



The benefit of using parts that point to another part is when there is a change in version. When the item that the part points to(in this case the function requirement) changes version, the part pointing to the part does not need to change.


Combining these two patterns, we can move the ownership of the requirement traceability from the requirement to the item having the requirements (in this case the function).



In the SystemWeaver architect, the model looks like this.


Bildresultat för exercise icon freeExercise 8 - Traceability

Implement the meta model as seen above with traceability.


Note: In the SystemWeaver client, this part type cannot be created correctly this far. A view needs to be used to correctly create the part type with RefObj pointing to a part (in our case the part is named Requirements with the SID FREQS).


Configuration: RM Plus Light

Open the view configuration.

  • File > Configure the Explorer
  • Find the “RM Plus Light” and click “Edit configuration”



Add the following code to the RM Plus Light configuration.

<RequirementsViews> 
   <RequirementsView id=" Unique_id ">
        <ViewSettings>
            <Caption>Feature trace</Caption>
            <RibbonGroup>Function</RibbonGroup>
            <Description>This view supports creating traceability to feature requirements</Description>
        </ViewSettings>
        <ContextItemType>FUN</ContextItemType>
        <RequirementContainerItemType>FUN</RequirementContainerItemType>
        <RequirementItemType>FUREQ</RequirementItemType>
        <RequirementsPartType>FREQS</RequirementsPartType>
        <BaselineItemType>SPEC</BaselineItemType>
        <PathToBaseline>FULS;FUNS</PathToBaseline>
        <SidsToFollow>TRAC</SidsToFollow>
        <TracedItemType>FREQ</TracedItemType>
        <TraceabilityPartType>TRAC</TraceabilityPartType>
        <PathToContextRequirements>/REAL/REQS</PathToContextRequirements> 
        <AddGridXML>
          <Grid>
            <Options>
              <Grouping groupBy="1"/> 
            </Options>
            <Parameters>
                <Parameter caption="xxx" name="pSelected" >
                    <Values>
                            <AddValue/>
                    </Values>
                </Parameter>
            </Parameters>
            <Variable name="alreadyTraced" select="/part::TRAC[/refobj::/defobj:: in $pSelected]/defobj::" as="Items"/>           
            <Columns>
              <ItemNameColumn width="200" objectName="Feature"/>
              <ItemNameColumn width="200" objectName="Req"/>
            </Columns>
            <ForEachPart type="REAL">
              <DefObj>          
                <RowObject name="Feature">
                  <ForEachPart type="REQS">
                    <DefObj>
                      <RowObject name="Req">
                        <If test="not AncestorHandle in $alreadyTraced.Select(AncestorHandle)">
                          <Row/>               
                        </If>
                      </RowObject>
                    </DefObj>        
                  </ForEachPart>   
                </RowObject>
              </DefObj>            
            </ForEachPart>             
            </Grid>
        </AddGridXML>
    </RequirementsView>
</RequirementsViews>


Note: Remember to activate the view and restart the client. 


In the SystemWeaver Client, there should now be a view called “Feature trace” when selecting function requirements.



Note: The view works best if opened when holding down the Shift key. This way it opens as a secondary view to the right so that the requirement text can be viewed at the same time as the traceability.


When clicking on Add traceability link, the feature requirements of the features allocated/distributed to this function are shown.



Now the traceability of a released requirement can be changed since it is only the function that owns the traceability that needs to be in "Work" status to be able to change the traceability.

Understanding the code: RM Plus Light

The first part of the XML defines how the button created should look and includes:

  • Name of the button-What group in the Ribbon should the button be part of
  • Description that appears if the mouse hovers over



         <ViewSettings>

            <Caption>Feature trace</Caption>

            <RibbonGroup>Function</RibbonGroup>

            <Description>This view supports creating traceability to feature requirements</Description>

        </ViewSettings>


ContextItemType is the SID of the element that represents what the requirements should describe. For this example the function is the context


        <ContextItemType>FUN</ContextItemType>


The third part creates relations between items: 


        <RequirementContainerItemType>FUN</RequirementContainerItemType>

        <RequirementItemType>FUREQ</RequirementItemType>

        <RequirementsPartType>FREQS</RequirementsPartType>

        <BaselineItemType>SPEC</BaselineItemType>

        <PathToBaseline>FULS;FUNS</PathToBaseline>



  • RequirementContainerItemType is the SID of the element owning the requirements. In this example it is the function.

  • RequirementItemType is the SID of the requirement type.

  • RequirementsPartType is the SID of the part type from RequirementContainerItemType to RequirementItemType.

  • BaselineItemType is the SID of the element representing the baseline. In this example this is the Specification architecture.

  • PathToBaseline is the SIDs to follow from the Context to get to the Baseline.


The next part establishes which requirements are traced:


        <SidsToFollow>TRAC</SidsToFollow>

        <TracedItemType>FREQ</TracedItemType>

        <TraceabilityPartType>TRAC</TraceabilityPartType>

  • SidsToFollow is the SIDs from the context to find all traced requirements. In this example all traced feature requirements are found by following the traceability part type.

  • TracedItemType is the SID of the requirements that are traced to.

  • TraceabilityPartType is the SID of the part that holds the traceability.


        <PathToContextRequirements>/REAL/REQS</PathToContextRequirements>

  • PathToContextRequirements is a path expression (see SystemWeaver Path Query Language) to find all requirements from the context that it should be possible to trace to. In this example, the function should be able to trace to all feature requirements that have been allocated/distributed to the function.


After this comes the grid definition which defines what should be displayed when clicking on "Add traceability link".

<AddGridXML>
          <Grid> 
            <Options>
              <Grouping groupBy="1"/> 
            </Options>
            <Parameters>
                <Parameter caption="xxx" name="pSelected" >
                    <Values>
                            <AddValue/>
                    </Values>
                </Parameter>
            </Parameters>
            <Variable name="alreadyTraced" select="/part::TRAC[/refobj::/defobj:: in $pSelected]/defobj::" as="Items"/>           
            <Columns>
              <ItemNameColumn width="200" objectName="Feature"/>
              <ItemNameColumn width="200" objectName="Req"/>
            </Columns>
            <ForEachPart type="REAL">
              <DefObj>          
                <RowObject name="Feature">
                  <ForEachPart type="REQS">
                    <DefObj>
                      <RowObject name="Req">
                        <If test="not AncestorHandle in $alreadyTraced.Select(AncestorHandle)">
                          <Row/>               
                        </If>
                      </RowObject>
                    </DefObj>        
                  </ForEachPart>   
                </RowObject>
              </DefObj>            
            </ForEachPart>             
            </Grid>
        </AddGridXML>


See the Configuring Tables and Grids for more details.


The final expressions filter all feature requirements that are already traced from the selected requirement.


<Variable name="alreadyTraced" select="/part::TRAC[/refobj::/defobj:: in $pSelected]/defobj::" as="Items"/>


  • alreadyTraced will contain all feature requirements traced from the selected function requirement.


<If test="not AncestorHandle in $alreadyTraced.Select(AncestorHandle)">


  • The if statement filters out feature requirements that already have traceability from the selected function requirement.


Drawbacks: RM Plus Light

One drawback with this pattern for handling requirements traceability is that the model is not easily understandable in the tree.

  • The feature requirement ends up under the function in this example.

To make it easier to understand, it can be a good idea to set a specific icon on the traceability part.



Another drawback is that it is hard to get information of the traced requirements without opening each requirement.

This can be solved by creating a report giving information of all traced requirements.

Adding a report similar to this on the function requirement shows information about all traced requirements for the selected requirement.

<Report>
<Parameters>
  <Parameter caption="Function" name="p1" hintContextPath="FREQS">
    <Values>
    <ForEachPathReference path="FREQS">
        <AddValue/>            
    </ForEachPathReference>
    </Values> 
  </Parameter>
</Parameters>
<Variable name="pSelected" select="." as="Items"/>
<ForEach select="$p1/part::TRAC[/refobj::/defobj:: in $pSelected]/defobj::">
    <Text font="Bold8pt">#{Name}</Text>
    <Description/>
    <Text/>
</ForEach>
</Report>



Often, user do not only want to add requirements in a long list, but they want to structure them in some way. In these cases, requirements containers structuring the requirements can be used.

The meta model with requirements containers added for the functions looks like this:



Since the traceability part points to a part type the traceability part need to be moved from the function to the requirement container. The “Sub container” part type enables users to build structures of containers.

Bildresultat för exercise icon freeExercise 9 - Meta Model


Adapt your meta model to look like the one in the example above.

The major changes needed to the meta model:

  • Add “Requirement container” item type
  • Move the “Traceability” part type from “Function” to “Requirement container”
  • Move the “Requirements” part type from “Function” to “Requirements container”


The resulting meta model in the SystemWeaver Architect should look similar to this:


Updating the view: RM Plus Light

In the SystemWeaver client it should now be possible to create requirements containers with requirements. The traceability view does however not work for these requirements.


Adjusting the RM Plus Light view is essential since new items were added. This how it is done: 

  • RequirementContainerItemType is now the requirement container.
  • SidsToFollow must now include the part types to traverse the requirement containers.

Bildresultat för exercise icon freeExercise 10 - Updating the RM Plus Light


Add the following configuration to the RM Plus Light View:

<RequirementsViews>
   <RequirementsView id="PartReq">
        <ViewSettings>
            <Caption>Feature trace</Caption>
            <RibbonGroup>Function</RibbonGroup>
            <Description>This view supports creating traceability to feature requirements</Description>
        </ViewSettings>
        <ContextItemType>FUN</ContextItemType>
        <RequirementContainerItemType>CONT</RequirementContainerItemType>
        <RequirementItemType>FUREQ</RequirementItemType>
        <RequirementsPartType>FREQS</RequirementsPartType>
        <BaselineItemType>SPEC</BaselineItemType>
        <PathToBaseline>FULS;FUNS</PathToBaseline>
        <SidsToFollow>CONTS;SCON;TRAC</SidsToFollow>
        <TracedItemType>FREQ</TracedItemType>
        <TraceabilityPartType>TRAC</TraceabilityPartType>
        <PathToContextRequirements>/REAL/REQS</PathToContextRequirements> 
        <AddGridXML>
          <Grid>
            <Options>
              <Grouping groupBy="1"/> 
            </Options>
            <Parameters>
                <Parameter caption="xxx" name="pSelected" >
                    <Values>
                            <AddValue/>
                    </Values>
                </Parameter>
            </Parameters>
            <Variable name="alreadyTraced" select="/part::TRAC[/refobj::/defobj:: in $pSelected]/defobj::" as="Items"/>           
            <Columns>
              <ItemNameColumn width="200" objectName="Feature"/>
              <ItemNameColumn width="200" objectName="Req"/>
            </Columns>
            <ForEachPart type="REAL">
              <DefObj>          
                <RowObject name="Feature">
                  <ForEachPart type="REQS">
                    <DefObj>
                      <RowObject name="Req">
                        <If test="not AncestorHandle in $alreadyTraced.Select(AncestorHandle)">
                          <Row/>               
                        </If>
                      </RowObject>
                    </DefObj>        
                  </ForEachPart>   
                </RowObject>
              </DefObj>            
            </ForEachPart>             
            </Grid>
        </AddGridXML>
    </RequirementsView>
</RequirementsViews>


The traceability view should now work in the SystemWeaver client.

Coverage View

So far, the examples have covered internal development where there is seldom a problem that the traceability is owned by the specifications that are being developed (in this case the function or requirement container). If the traceability is to external sources that should not influence the specification that is being developed, the traceability needs to be owned by something other than the specification. An external source could be a supplier working with several different OEMs. The functions should not be contaminated with traceability to all customers. For these cases, the ownership of the traceability can be moved even higher in the hierarchy. In this example, the requirements traceability will be owned by the specification architecture.


The meta model with the Specification architecture owning the traceability looks like this:


The “Traceability” item type holds the traceability between feature requirements and function requirements:


The meta model in the SystemWeaver swArchitect looks like this:



In the SystemWeaver client, it should now be possible to create traceability items holding feature and function requirements:

Using the standard functionality in SystemWeaver (copy-paste) does not provide a good overview of this traceability. Views can be set up to get a better overview of the traceability of feature and function requirements. The Coverage (mapping item) view is a standard view that aids in creating and getting an overview of this type of traceability. The example below is for versions prior to R33. For R33 or later versions, see Configuring the Coverage (Mapping tem) View or Coverage (Mapping Item) View Examples for examples.

Bildresultat för exercise icon freeExercise 11 - Coverage


Open the view configuration.

  • Navigate to File > Configure the Explorer
  • Find the view with the Name “Coverage” in R32 or earlier versions or the view named "CoverageNoContext" for R33 or later versions and click Edit configuration.



Below is an example for pre-R33 versions. Set up the example and activate the view. Restart the client.

<Configs>
  <Config id= "unique_id">
    <ViewSettings>
       <Caption>Traceability Function to Feature reqs</Caption>
       <RibbonGroup>Features</RibbonGroup>
       <Description>This view aids in creating traceability between function and feature requirements</Description>
    </ViewSettings>
    <TopItemType>SPEC</TopItemType>
    <Context name="context1">
      <AddParts owner="main" sid="FELS" part="FeatureLevels" defobj="FeatureLevel"/>
      <AddParts owner="FeatureLevel" sid="FEATS" part="Features" defobj="Feature"/>
      <AddParts owner="Feature" sid="REQS" part="FeatureReqs" defobj="FeatureReq"/>
       <AddParts owner="main" sid="FULS" part="FunctionLevels" defobj="FunctionLevel"/>
       <AddParts owner="FunctionLevel" sid="FUNS" part="Functions" defobj="Function"/>
       <AddParts owner="Function" sid="CONTS" part="ReqConts" defobj="ReqCont"/>   
       <AddParts owner="ReqCont" sid="SCON" part="SubConts" defobj="+ReqCont"/>        
       <AddParts owner="ReqCont" sid="FREQS" part="FuncReqs" defobj="FuncReq"/>            
  </Context>
    <PrimaryGroupName>FeatureReq</PrimaryGroupName>
    <SecondaryGroupName>FuncReq</SecondaryGroupName>
    <PrimaryContextPartName>FeatureReqs</PrimaryContextPartName>
    <SecondaryContextPartName>FuncReqs</SecondaryContextPartName>
    <Mappings>
      <MappingItemType itemType="MAP" partType ="MAPS" />
      <PrimaryMapping itemType= "FREQ"  partType = "MFEA" />
      <SecondaryMapping itemType= "FUREQ" partType ="MFUN" />
    </Mappings>
    <AdditionalPrimaryColumns/>
    <AdditionalSecondaryColumns/>
    <ShowStructure>
      <Visible>True</Visible>
      <ContextGroup>FeatureReq</ContextGroup>
      <ShouldShowPartTypes>
        <PartType>FELS</PartType>
        <PartType>FEATS</PartType>
        <PartType>FeatureReqs</PartType>
      </ShouldShowPartTypes>
    </ShowStructure>
    <UIMessages>
      <UIMessagePrimaryItemName>Feature requirement</UIMessagePrimaryItemName>
      <UIMessageSecondaryItemName>Function requirement</UIMessageSecondaryItemName>
      <UIMessageNotMapped>Not mapped</UIMessageNotMapped>
      <UIMessageNotInPrimary>Not in feature</UIMessageNotInPrimary>
      <UIMessageNotInSecondary>Not in function</UIMessageNotInSecondary>
      <UIMessageVersionInconsistency>!Version</UIMessageVersionInconsistency>
    </UIMessages>
  </Config>
</Configs>


Coverage: Traceability

In the SystemWeaver client there should now be a view called “Traceability Function to Feature reqs” when selecting the Specification architecture.

This view now enables creating the “Traceability” items that holds the traceability between function and feature requirements.

Coverage: Understanding the Code

The first part of the XML defines how the button created should look:

  • Name of the button. What group in the Ribbon should the button be part of?
  • Description that appears as mouse hovertip.
    <ViewSettings>
       <Caption>Traceability Funtion to Feature reqs</Caption>
       <RibbonGroup>Features</RibbonGroup>
       <Description>This view aids in creating traceability between function and feature requirements</Description>
    </ViewSettings>


TopItemType is the SID of the item type the the view should be active for. The TopItemType needs to have the two types that should be traced as children.


<TopItemType>SPEC</TopItemType>


There is a context in the script as well. How context works is covered in the SystemWeaver Query Language Introductory Training.

  

<Context name="context1">
      <AddParts owner="main" sid="FELS" part="FeatureLevels" defobj="FeatureLevel"/>
      <AddParts owner="FeatureLevel" sid="FEATS" part="Features" defobj="Feature"/>
      <AddParts owner="Feature" sid="REQS" part="FeatureReqs" defobj="FeatureReq"/>
      <AddParts owner="main" sid="FULS" part="FunctionLevels" defobj="FunctionLevel"/>
      <AddParts owner="FunctionLevel" sid="FUNS" part="Functions" defobj="Function"/>
      <AddParts owner="Function" sid="CONTS" part="ReqConts" defobj="ReqCont"/>   
      <AddParts owner="ReqCont" sid="SCON" part="SubConts" defobj="+ReqCont"/>        
      <AddParts owner="ReqCont" sid="FREQS" part="FuncReqs" defobj="FuncReq"/>            
  </Context>


The following part indicates the two types that should be traced in terms of defined context.

    <PrimaryGroupName>FeatureReq</PrimaryGroupName>
    <SecondaryGroupName>FuncReq</SecondaryGroupName>
    <PrimaryContextPartName>FeatureReqs</PrimaryContextPartName>
    <SecondaryContextPartName>FuncReqs</SecondaryContextPartName>


The following section includes three different parts:

  • MappingItemType is the item type SID of the item that holds the mapping as well as the part type to it.

  • PrimaryMapping is the item type SID of the item that should appear in the left tree.

  • SecondaryMapping is the item type SID of the item that should appear in the right tree.


    <Mappings>
      <MappingItemType itemType="MAP" partType ="MAPS" />
      <PrimaryMapping itemType= "FREQ"  partType = "MFEA" />
      <SecondaryMapping itemType= "FUREQ" partType ="MFUN" />
    </Mappings>


Then the left side of the tree is defined.

<ContextGroup>FeatureReq</ContextGroup>
      <ShouldShowPartTypes>
        <PartType>FELS</PartType>
        <PartType>FEATS</PartType>
        <PartType>FeatureReqs</PartType>
      </ShouldShowPartTypes>
    </ShowStructure>


Lastly, the UI message are defined in the view.

<UIMessages>
      <UIMessagePrimaryItemName>Feature requirement</UIMessagePrimaryItemName>
      <UIMessageSecondaryItemName>Function requirement</UIMessageSecondaryItemName>
      <UIMessageNotMapped>Not mapped</UIMessageNotMapped>
      <UIMessageNotInPrimary>Not in feature</UIMessageNotInPrimary>
      <UIMessageNotInSecondary>Not in function</UIMessageNotInSecondary>
      <UIMessageVersionInconsistency>!Version</UIMessageVersionInconsistency>
    </UIMessages>


Many of the concepts, patterns and views shown here can be used for other use cases. Requirements solutions are often integrated into other solutions such as design solutions.