Overview

This presentation describes the basic requirement model and view support in SystemWeaver.

Course Type

Suitable for class training or for self study.

Course Length

Approximately a one-day course.

Prerequisites


Meta Model Notation

In this presentation 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 types it inherits from
  • Abstract item types names are given 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 need to inherit from the Abstract item type Abstract Requirement with SID = 'RQ" for the test GUI:s to function.


Exercise 1:

Create the Meta model from the previous section in the SystemWeaver Architect. The result shall look like the below picture.


Exercise 2:

Build a structure according to the below picture using the SystemWeaver Client.



Adding a report

Using the reports feature we can now create a report of all features and feature requirements as described in the course Report Generation - Introductory Training.




Exercise 3:

Add the below report XML definition to the Feature level.

<Report>
  <ForEachPart type="FEATS">
    <DefObj>
      <Text font="Heading1">#{Name}</Text>
      <ForEachPart type="REQS">
        <DefObj>
          <Text font="Bold8pt">#{Name}</Text>
          <Description/>            
        </DefObj>
        <Text/>        
      </ForEachPart>    
    </DefObj>
  </ForEachPart>
</Report>


The output should look similar to the example in the previous section when having the Feature level selected.


Requirement ID:s

All objects in SystemWeaver have an ID. For items this can be seen in the Properties tab, as shown in the picture below.

However, for requirements it is often prefered to have a more human readable ID. In SystemWeaver there are different ways to create requirements IDs and here we will present two of those ways.


  • Unique ID
  • Identity



Unique ID:s

Unique ID is an attribute type that has some built in views. 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 in the requirements.


The Unique ID concept builds on two attributes:

  • Unique ID context

    - SID: AUIC- Type: Custom, Array

  • ID
    - SID
    - Type: Custom, Single

                                                                             


Attributes of type custom have special GUIs connected to them dependent on the SID. The attributes should 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





Exercise 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”)




Exercise 5:

Add an Identity to the feature requirements as shown above.


Exercise 6:

Add a function level that should detail the feature requirements.

The Meta Model in the SystemWeaver Architect.

Using the meta model in the SystemWeaver 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. 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 now 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.



Exercise 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 definies how the button should look by defining the name of the button, what group in the Ribbon the button should be a part of and the description that appears if the mouse hovers over the button.


<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 and the "TopItemType" is the name of the 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 the "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 Architect.


 


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.




Exercise 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 need 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 Shift -> opens it in the right part of the window 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 need to be in state work 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 the script language course) 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 Tables and Grids - Introduction Training for more details.


The final expressions filters 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.


Exercise 9: Meta Model


Adapt you 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.



Exercise 10: Updating the RM Plus Light


Add the following configuration to the RM Plus 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

This 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 owned by something else than the specification. This could be a supplier working with several different OEMs – then 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 architect 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” view is a standard view that aids in creating and getting an overview of this type of traceability.



Exercise 11: Coverage


Open the view configuration

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




Add this configuration to the view. Remember to 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 if the mouse hovers over


    <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 SWQL SystemWeaver Queary 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.