Interface and Requirement Traceability

1
Interface and Requirement Traceability

• Dipl. Ing. Constantin Corsten
• Senior Systems Engineer
• Systems Engineering Support Services

2
Outline

• Introduction
• System Engineering Approach
• Databases
• Conclusion

3
Introduction

• A lot of time and effort can be spent on
  maintaining the project verification status and
  updating requirement sections in system
  documentation.
• Finding inadequacies in the verification process
  late cause delays and cost impacts.
• This presentation will describe a set of
  databases used at the Columbus Control Center to
  minimize resources for the tasks described above.

4
System Engineering Approach
5
Logical Model
6
Interface Repository

• Using an export tool the interfaces of the
  physical and logical models can be exported and
  then used to generate the interface repository

7
Interface Outputs

• Subsystem Interfaces
• Here all interfaces between the different
  subsystems are grouped and listed in order of
  subsystem. The report produces the interface
  section in the projects requirements documents,
  ADD and IDDs.
• External Interfaces
• The list of external interfaces is used as a
  direct input to generate the requirements within
  the External ICDs.

8
Traffic Model/Service Data Rates

• The traffic model is generated using the
  combination of different interfaces, services and
  the performance requirements. Once all
  information is collected within the traffic
  model, it is possible to estimate the required
  bandwidths between subsystems and remote centers.

9
System Specification Database

• Contains
• Customer provided functional requirements
• System requirements
• High level subsystem requirements
• Establishes tracing between customer requirements
  to system parent requirements and their
  subsystem child requirements
• Subsystems associated with each requirement
• Verification method of each requirement

10
System Specification DatabaseRequirement View

• For each requirement the requirement view lists
  the requirement, verification level and method,
  associated subsystems and the associated customer
  requirement.

11
System Specification DatabaseOutput for System
Spec

• Output
• Requirement Section of System Specification
• Linked to the System Verification Control Database

12
System Verification Control Database

• Linked to the System Specification Database
• Requirements
• Affected subsystems for each requirement
• Verification method
• Contains
• External ICD requirements.
• Information required for the close-out of the
  system level requirements.
• Associated subsystem requirements and the derived
  requirements within the subsystem specifications.
  
• Test cases and verification status.
• Subsystem requirement closeout information
• Open subsystem requirements can be caught early
  and either verified at the subsystem level or can
  be included in the system level closeout
  activities

13
SVCD Requirement View

• For each requirement the requirement view lists
  the requirement, verification level and method,
  assigned test cases and the related subsystem
  requirements.

14
SVCD System Verification Matrix

• Direct input to the system test specification.
• Lists the system requirements followed by their
  child subsystem requirements.
• Verification method and the associated subsystems
  are listed for each requirement.
• Assigned system test case for each system
  requirement.

15
SVCD Test Design View

• The test design view contains the common high
  level information for a group on test cases.

16
SVCD Test Case View

• The test case view contains specific details on a
  test as well as the detailed test procedure

17
SVCD Tools

• Test Case Mapping
• System Test Design Report
• Test Procedure Progress Table
• Test Notification Form
• System Verification Control Document

18
SVCD Test Case Mapping

• The test case mapping provides an overview of all
  system requirements which are currently open,
  which do not have a test case or subsystem
  requirement assigned, or which carry a waiver.

19
SVCD System Test Design Report

• At the beginning of the test phase, the report
  generates the test step section of the test
  procedures to be delivered and reviewed
• After the test the report generates the as-run
  test procedure which is to be included in the
  test report.
• The test design report is additionally used as an
  input to the system test specification,
  describing the details of the planned test
  designs and test cases.

20
SVCD Test Procedure Progress Table

• Status of every test procedure associated with a
  test case.
• Information when the procedure will be, or was,
  executed.

21
SVCD Test Notification Form

• The Test Notification Form enables the test
  conductor to select all subsystems and resources
  required to perform a test.
• The TNF is then used by the planning team to
  schedule the test and allocate the required
  resources

22
SVCD Verification Control Document

• Summary of the verification status of all the
  associated requirements.
• The document lists for each requirement the
  related test cases, test documentation numbers
  and verification status

23
Subsystem Verification Control Database

• The Subsystem VCD uses the same functions as the
  SVCD at subsystem level.
• Using an import function within the SVCD it is
  possible to extract the subsystem closeout status
  and import it into the System Verification
  Control Database.
• Requirements not closed during subsystem close
  out can be caught this way and will be closed a
  system level

24
Document/Database Relationship
25
Conclusion

• All information related to the requirements is
  maintained in the centralized databases and
  exported for use in system documentation, the
  time needed to verify the correctness and
  consistency of the requirements is minimized.
• Different views and queries always give an
  insight into the current verification status of
  the project.
• Inadequacies in the verification process can be
  discovered and corrected early on, thereby
  protecting the project from last minute impacts
  to the verification schedule.