Skip to content

Requirements Specification in QMS feature file#

Note

This document outlines the key points of the process for building a feature file according to the QMS Operating Model.
For detailed information about the QMS Operating Model, please refer to the following document:
QMS Operating Model Documentation

Feature File Template
QMS Operating Model Documentation

Quote

  • We use feature files (*.feature) stored in our Git repository to describe our changes. An IT change can span multiple feature files.
  • Feature files contain a "Feature" part which together constitute our requirements.
  • Some requirements are marked as "URS", i.e. requirements which determine if the IT Infrastructures is fit for intended use or reflects risk controls from the IT Risk Assessment.
  • Feature files contain one or more "Scenarios" which are our exhaustive test cases for requirements and specify the desired behaviour.
  • Traceability between requirements and their corresponding verification test cases is implicitly given by the boundary of the feature files, since test cases for a given requirement will be located in the same feature file as the feature representing the requirement.
  • Scenarios (i.e. test cases) are automated (implemented as code) when feasible, but can be manual.

For activities where the implementation of the requirements is complex, the requirements are numbered using the notation [X-A], [X-B], [X-C], et cetera. The “X” is a unique prefix for each activity to ensure uniqueness (for details refer to QMS Operating Model Documentation):

Activity Unique prefix for requirements
Identify intended use IIU
Register IT infrastructure service/system RIS
Assess supplier N/A
Assess IT infrastructure risk RA
IT change management CM
Specify requirements RS
Build B
Verify V
Operate O
Retire N/A
Documentation and approvals DA

The requirement numbers are then referenced from the implementation section to clarify how each requirement is implemented. For example, the first requirement for the "Identify intended Use" activity is given the number [IIU-A] and is subsequently referenced in the corresponding implementation section. No prefix is given for the “Assess supplier” and “Retire” activities, as these activities are not covered by the operating model.

Feature File Template: 

    [@URS, @Non-URS] @[URS_id]
    Feature: [Descriptive title]
        As a [role]
        I want [feature]
        so that [benefit]

    [@IV, @pIV, @PV] [@Manual] [@ReviewByException]
    # If @ReviewByException is chosen, add rationale for why this is
    # considered sufficient.
    Scenario: [Descriptive title]
        Given [Preconditions]
        When [Trigger]
        Then [Outcomes]

Quote

  • Feature files consist of two parts:
  • The "Feature" part, which contains the requirement itself, including:
    • A unique identifier, e.g. “@o2AuditTrail”
    • A descriptive title.
  • The wording of the requirement in the form "As a role, I want feature, so that benefit".
  • Features representing requirements which cover aspects that determine if the IT infrastructure can be deemed fit for intended use or reflects risk controls from the IT Risk Assessment must be tagged with "@URS".
  • Features representing other requirements can be tagged with "@Non-URS" (or at least must not be tagged with "@URS").
  • The "Scenarios" part, which is an exhaustive list of test cases (scenarios) for the requirement. Each such scenario contains:
    • One or more tags:
      • Test cases which verify that the solution has been correctly installed in the validation environment are tagged with "@IV".
      • Test cases which verify that the solution performs according to the requirements in the validation or production environments must be tagged with "@PV".
      • Test cases which verify that the solution has been correctly installed in the production environment are tagged with "@pIV".
      • Test cases which must be executed manually are tagged with "@Manual".
      • Test cases which rely on the "Review by Exception" verification method are tagged with "@ReviewByException".
    • A rationale for why "Review by exception" is considered a sufficient verification method if the scenario is tagged as such.
    • A descriptive title.
    • Prerequisites, steps, and expected outcomes in the form of Given-When-Then.