Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

ARCH.108 Define acceptance criteria for non-functional requirements

Goalhigh-level statement of the engineering objective being addressed, including reference to standards/legislation if that is relevant
Requirements met by this process stepEN 50126-1 7.6.1
Inputs

list of all input information needed for this process step to be carried out; for model views, add a hyperlink to the model view description; documents, published info, websites, knowledge from particular roles are all admissible.


Outputslist of all output artefacts this process should produce; for model views, add a hyperlink to the model view description; for documents, add a link to the document template or to the document publication area if it is directly generated from Confluence;
Methodology

Only a summary of an initial investigation:

  • Acceptance criteria are used to comply with DIN EN 50126 phase 5 (7.6.1.d, Abnahmekriterien). These criteria are defined in order to proof RAMS requirements are satisfied.
  • Acceptance criteria are conditions the product must satisfy in order to be accepted by the customer.
  • Acceptance criteria help to avoid unexpected development results.


  • Acceptance criteria can be provided in different formats: scenario oriented or rule oriented.
    • Scenario oriented Acceptance criteria are written in the Given/When/Then format. Under Given conditions, when specific action is performed, then the required outcome of the scenario is provided.
    • Rule oriented Acceptance criteria are simply a list of verifiable criteria that are required to satisfy a specific user story
  • Rules for acceptance criteria:
    • Document them before development starts
    • Do not add technical details
    • Acceptance criteria must be achievable
    • Acceptance criteria must be testable
    • Acceptance criteria must be understandable for everyone
    • Acceptance criteria must be written from User perspective
Tools and non-human resources

Capella for Teams

Cardinality

state how many times this process step is expected to be carried out - e.g.

  • one-off
  • once per <model element>
  • once per baseline

etc.

Completion criteria

state the conditions that must be TRUE before this process step can be considered complete.

These should be inserted in the Acceptance Criteria of a Jira ticket for this process step to be done.

Design reviewLink to the corresponding design review where the completion of this activity is evaluated.
Step done by (Responsible)

Identify the role that is responsible for organising this process step and producing the output;

This is the Assignee in Jira.

Provides input to/assists (Contributes)

Identify the roles that assist in the work or provide input information

Uses outputs (Informed)

Identify the roles and/or process areas that make use of this information outside of the ARCH process area;