Traceability Setup - advanced


Introduction 

MatrixALM manages Design Input and Design Output in categories. It is possible to add links between items of different categories. This links can either be required or optional. Using traceability reports it is possible to analyse the project for broken links. 


You can also use smart links to link from one item to another item or a folder. In order to use smart links you just type the item ID of the target item into a rich text field. In reports and when not in edit mode, this smart link will be rendered and as hyperlink to the item.

Setup

Traceability rules can be setup in the administration client. They are specified in a JSON project setting, using the following syntax. For each category there is a rule. Each rule defines the following attributes

  • category: the category for which the rules applies
  • end_point: if the category must be covered by a executed test cases, this can be set to (usually) XTC. Test Configuration.
  • creates_end: if the category can be converted to an executed test case this must be set to true (usually TC and UC). See Test Configuration.
  • reporting: this contains information in which kind of reports the category should appear. See reporting filter definition. 
  • up_rules: rules for up traces. A collection of rules, each rule is evaluated:
    • message: message displayed if there is an error applying this rule
    • name: message used when mentioning that there is a certain rule
    • rule: can be must_have or can_have and indicates if an item can have or must have traces to the categories specified in the any_of:
    • any_of: the categories to which the rule applies
  • down_rules: rules down traces. A collection of rules, each rule is evaluated: 
    • same structure as up rules

Note: rules to and from XTCs are implicit (by the end_point) attribute and should not be added to the up_rules nor down_rules.


Traceability Configuration
{
  "rules": [
    {
        "category": "REQ", "end_point": "XTC", "creates_end": false,"expected":100,
        "reporting": [ "DesignInput", "Design" ],
        "up_rules": [ ],
        "down_rules": [ { "message": "there is no specification", "name": "must have a specification", "rule":"must_have", "any_of": [ "SPEC" ] }]
    }, {
        "category": "SPEC", "end_point": "XTC", "creates_end": false,"expected":100,
        "reporting": [  "DesignOutput",  "Design" ],
        "up_rules": [ { "message": "is not derived from requirement nor risk", "name": "must be derived from requirement or risk", "rule":"must_have", "any_of": [ "REQ", "RISK" ] } ],
        "down_rules": [ { "message": "there is no test case", "name": "must have test case", "rule":"must_have", "any_of": [ "TC" ] } ]
    }, {
        "category": "TC", "end_point": "XTC", "creates_end": true,"expected":100,
        "reporting": [  "DesignOutput",  "Design", "Test" ],
        "up_rules": [ { "message": "is not derived from specification", "name": "must be derived from specification", "rule":"must_have", "any_of": [ "SPEC" ] } ],
        "down_rules": [ ]
    }, {
        "category": "UC", "end_point": "XTC", "creates_end": true,"expected":100,
        "reporting": [ "DesignInput", "Design", "Test" ],
        "up_rules": [ ],
        "down_rules": []
    } , {
      "category": "RISK", "creates_end": false, "expected":100,
      "reporting": [ "Design", "Risk" ],
      "up_rules": [  ],
      "down_rules": [ ]
    },
    { "category": "XTC", "creates_end": false, "reporting": [ "ExecutedTest" ], "up_rules": [ ], "down_rules": [ ] },
    { "category": "DOC", "creates_end": false, "reporting": [ "Doc" ], "up_rules": [], "down_rules": []},
    { "category": "SIGN", "creates_end": false, "reporting": [ "Sign" ], "up_rules": [], "down_rules": [] },
    { "category": "REPORT", "creates_end": false, "reporting": [ "Report" ], "up_rules": [], "down_rules": []}
  ]
}

The configuration above specifies for example that

  • requirements (REQ) must be tested (there must be an executed test case for each requirement):  "end_point": "XTC"
  • requirements (REQ) have no up_rules, meaning there is nothing from which they are derived (like marketing requirements)
  • requirements are used as input for reports which rely on "DesigInput" and/or "Design"
  • there are an expected 100 requirements to be created and 200 specifications (for the progress report)
  • which categories have which reporting type, e.g. XTC shows in reports which included types of the "ExecutedTest"
     

Note if a requirement must have links to specifications and use cases, the down rules would look like this

alternative rule
"down_rules": [ { "message": "there is no spec", "name": "must have a specification", "rule":"must_have", "any_of": [ "SPEC" ] },
                { "message": "there is no use case", "name": "must have a use case", "rule":"must_have", "any_of":: [ "UC" ] },
                { "message": "there is no test case", "name": "can have a test case","rule":"can_have", "any_of": [ "TC" ] }]

Reporting

In order to see whether all rules are obeyed, you can create the Traceability Report Generic.

Search