This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Scenario T5 - Qualification activities are planned

Motivation

This scenario addresses the planning of requirement qualification activities (i.e. verification and validation activities, of which 'test' is one category). These activities can support qualification of the requirement and design development process (i.e. down the 'left leg of the V', addressing whether lower level requirements and designs discharge higher level requirements) or qualification of the built system (i.e. 'across the V').

Effective planning of qualification activities is needed in any development activity. In some cases (especially high integrity systems), there may be an explicit obligation on developers to demonstrate why their qualification plans will deliver sufficient confidence that requirements have been met.

Note that, to some extent, this scenario is already covered in Requirement Scenario A and also in the Quality Management scenarios. These scenarios do not, however, address the recording of qualification planning rationale.

Note also that Quality Management Scenario B could be interpreted as presuming that there is a given requirement only needs a single test case. In reality, the relationship between requirements and test cases is many-to-many (i.e. one requirement will typically require more than one test case to qualify it, and one test case will typically support qualification of more than one requirement).

Pre-conditions

A requirement exists for which qualification activities are to be planned. This requirement is referred to as the 'root requirement'.

Scenario

  1. Alternative qualification strategies are considered and (optionally) recorded. If recorded, this may be:
    1. as a separate argument artefact that is linked to the root requirement, or
    2. as a property of the root requirement.
  2. Existing qualification cases are reviewed to identify candidates that could potentially be used to qualify the root requirement.
  3. Any issues (missing information, risks, etc) are identified, recorded, and linked to the root requirement (or argument artefact, if it exists).
  4. Any supporting evidence for the qualification strategy (reference documents, test coverage analyses, etc) is identified, recorded, and linked to the root requirement (or argument artefact, if it exists).
  5. A final qualification strategy is chosen and (optionally) recorded in the argument.
  6. Existing qualification cases that support the chosen qualification strategy are linked to the root requirement.
  7. New qualification cases needed to support the chosen qualification strategy are created and linked to the root requirement.
  8. Outstanding issues are 'worked' until they are closed.
    1. Closure of issues may require changes to artefacts (qualification cases, arguments, supporting evidence), creation or deletion of artefacts, or changes to traceability.
    2. Issue artefacts should include a status property.

Post-conditions

The root requirement is supported by a collection of appropriate qualification cases. Rationale for the suitability of this set of qualification cases is (optionally) recorded, and supported by relevant evidence. Issues affecting completion of the qualification planning process are closed.

Notes

-- SimonWills - 05 Feb 2010

Topic revision: r6 - 27 May 2010 - 14:22:11 - IanGreen
Main.RmQualificationPlanned moved from Main.QualificationPlanned on 22 Feb 2010 - 17:18 by IanGreen - put it back
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback