Traceable Constraints

Roger Costello

Click arrow key () to navigate to next page

Traceable Constraints are Important

• Traceability of constraints from implementation to requirement is very important.
• Traceability ensures that:
  • spurious constraints are not introduced,
  • the successful implementation of requirements can be ascertained, and
  • requirements that have unworkable ramifications can be identified.
• For a large system, a non-traceable constraint is a loose cannon.

Business Analyst vs Programmer

• "Above and beyond any question of which language(s) you use for data validation is the question of who checks that the validation rules have been implemented correctly? A not uncommon situation is that a business analyst is responsible for writing (some of the) validation rules in some format, and a programmer is responsible for writing an implementation. However, this leads to the problem of who is capable of checking that the programmer has correctly implemented what the business analyst asked for. Neither is fully qualified for the job." [Anthony B. Coates]

Example

• Consider this XML instance document:

1. <?xml version="1.0"?>
2. <Document classification="secret">
3. <Para classification="unclassified">
4. One if by land, two if by sea;
5. </Para>
6. </Document>

• Suppose the requirements are stated in this document: security.html
• Continued on next slide ...

Example (cont.)

• In section A.1.3.4.5 of security.html it states the requirement:
  • Requirement: For an instance document to be valid the value of each classification attribute must be one of these values:
    • top-secret
    • secret
    • confidential
    • unclassified

Schematron "see" attribute

• The assert element has an optional "see" attribute, which may be used to link an assertion to the requirement it implements, e.g.

1. <sch:pattern name="Classifications">
2. <sch:assert test="@classification='top-secret' or
3. @classification='secret' or
4. @classification='confidential' or
5. @classification='unclassified'"
6. see="http://www.example.com/military/security.html#A.1.2.3.4.5">
7. The value of a classification must be one of top-secret,
8. secret, confidential, or unclassified, because of MILSPEC
9. XXXX (1999) section A.1.2.3.4.5
10. </sch:assert>
11. </sch:rule>
12. </sch:pattern>