Introduction

Requirements management (RM) is the process of establishing, analyzing, tracking and controlling change of requirements through the lifecycle of a project. A requirement is the specification of attributes or functions necessary to fulfill a specific outcome or higher level requirement.

Requirements Management imposes structure and process on to what is written in engineering specifications. It provides traceability and context for design decisions and facilitates detailed analysis of individual requirements published in documents including in regard to type, ownership and safety. In addition, it also provides real time impact assessment of change through requirement linking and provides a framework for verification and validation (V&V).

The Taroko RM database is a platform designed by requirements engineers to meet the specific needs of requirements management. The database provides a feature rich set of pre-defined tools able to deal with almost any RM scenario.In addition the open architecture of Tarok RM means that tools can be modified and new tools added as the need arrises.

Features Overview

The Taroko RM database provides:

• One click linking

• Document import with automatic parsing

• Multiple view options with up to 5 levels per screen

• Enables requirement identification and traceability from top level input requirements (eg Contract) to detailed design, implementation and test.

• Provides documented, dynamic proof of compliance

• Provides a platform for independent verification

• Integrated assessment and auditing functions

• Integrated Hazard Log for direct linking of Hazard mitigations to design

• Tracks and verifies safety mitigations to design.

• Simplifies Proof of Safety Argument

• A practical implementation of EN/ISO standards.

• Secure segregated areas for confidentially, enables multi-contractor access without data sharing

• Adaptable to any business process from a simple contract compliance matrix to full end-to-end V&V

The Requirement Management Component of the Taroko Sigma Database

�

Page �2

General RM process

The basic process supported by Taroko RM is described as follows:

• Each requirement is entered into a database record. • The requirements are linked to other related requirements as either parents

(Input Requirements) or children (output requirements). • The links within the database provide Traceability across different levels of

documentation. For example from contract to SRS to document to test procedure.

• Verification is a separate process which checks that the lower level requirements satisfy the upper level requirement.

• A document reference is entered for each requirement. The document reference is linked to the relevant record in the document database. This allows automatic notification of revision changes etc. forcing engineering review of the linked requirements.

• Where necessary a requirement will be validated by test. In this case the test procedure reference and Validation Links is entered into the database.

System Architecture

The basic architecture of Taroko RM consists of two main tables, requirements statements and links. Working in a fully relational environment these two tables facilitate full many to many relational linking to as many levels as necessary. In addition, both requirements records and links may have any number of attributes associated with them as defined by the project.

The internal separation of links form requirements facilitates verification and validation attributes to be associated with each individual link.

�

Page �3

User Interface

Although requirements management with its many to many relationships is complex by nature, the Taroko RM database is able to present the data in a user friendly manner enabling easy manipulation and reporting. The Taroko RM database has multiple options for user interface. Specific layouts exist for data entry, requirement linking, verification etc. In addition specialised user interfaces have been developed for requirements assessment, parsing and other specialist applications.

Thanks to the open architecture of Taroko RM the GUI may be customised to match project needs. GUIs can be modified and new GUIs added to suite individual functions, attributes or security considerations. A sample of some of the user interface screens is shown below:

Status overview available on the RM Home Page

The Taroko RM Home Page provides access to all database tools, documents in the system and statistics overview.

�

Page �4

Link Manager The tool used for linking requirements. The document being linked to is on the left. By selecting a requirement from the list the existing parent and child links shown to the right. Now list are added by selecting requirements form the list in the link tool tab.

Detail View Provides full visibility of a requirements attributes, status and links. The requirement in focus is shown in the centre with the list of parent requirements above and the list of child requirement below.

�

Page �5

5 Gen Child Trace Provides an on screen view of multiple levels of requirements. Basic editing facilities are also provided via popovers on each requirement.

Child Link Verification View is the tool used to verify links. Both top level “satisfaction” verification and child link verification can be performed. Only users with appropriate verifier personalities are allowed to verify.

�

Page �6

Capture & Data Entry

There are three basic methods used for requirements capture and data entry:

1) Direct Entry Document is created and edited directly in the RM database using the

document builder tool. If the entire document is not needed then summary statements can be entered as compliance statements or reference parts of off line documents.

2) Document Import Document containing the requirements is produced independently and then

imported into the RM database using the document import function. The database records will be created based on either paragraph breaks or predefined requirement tags.

3) Import From Spreadsheet or other Database Through the use of predefined spreadsheet templates, requirements can be

managed externally then imported into the database. Likewise data originating on other requirement database system can also be imported.

Once entered the database applies a unique tracking ID to each requirement statement. A unique ID is necessary since documents often contain unnumbered clauses.

Document Builder Is the primary tool used enter data and set attributes. Following a document import the user is sent to the doc builder for editing and analyzing. Records can also be entered directly and if desired the entire document can be created in the document builder and can be exported for publication.

�

Page �7

Reporting

Status reporting of data entry, traceability, verification and validation status and data errors is crucial to any RM program. The Taroko RM database has a number of pre-defines status reports which can be run across various predefined data sets. The reports are typically document based but can also be run on other arbitrary sets of requirements. Reports can also be customised to suite specific tasks or project needs.

A few examples of predefined reports are shown below:

Traceability Report A matrix report based on a set of requirements (eg as contract specification) showing what it has been linked to. The linking displayed can extend through multiple levels down to individual test procedures and reports. Two types of Traceability report is available. The fixed column table traces on a single row from a top level requirement, and forces items into a column based on document phase. The full trace table shows actual requirement links in a true hierarchy regardless of project phase.

�

Page �8

Parent Link Status Report The parent link status report provides a detailed summary for each document entered into the RM database. Attributes reported include number of requirements entered for that document, unverified parent links, unverified child links, assessment status etc. Other attributes include document configuration status such as submission status and change status.

SRS Compliance Report A simple chart report showing the number of SSRS requirements which have been assessed, linked and verified. The report can be adapted to report on data errors, validation stats or any other SSRS attribute.

�

Page �9

Document Verification Report A report which is based on a specific document and lists the technical statements in the document and their parent links from which they were derived. The verification status is also displayed. The report may be printed with a certificate requiring signature by the design authority. Configuration control of child documents can also be maintained as any change to the input requirements can be tracked and acknowledged.

�

Page �10

Requirements Quality Assessment

Although the Taroko RM database has a rich set of automated reports, in order to truly assess the quality of the engineering, the work must be read by a human engineer and assessed. This is especially important in client or overall assessor roles.

Performing an assessment audit of RM work can be complicated and difficult to maintain consistency. In order to facilitate a structured approach to RM audit and assessment the Taroko RM database contains a requirements assessment tool. The tool provides a set of automated checks on linking, categorization, verification etc, as well as template with standardized comments for manual observation and free text area.

At the end of the process an overall acceptance code is applied and a report is generated based on the document. This report can then be included as part of the general design review process. All data entered by the assessor is retained by the database. Any modification an assessed record will result in an alert to the original assessor via the users tasks list or email.

�

Page �11

Hazard Management

The goal of Hazard management is to demonstrate mitigation of defined Hazards through identified design measures. Since the RM database contains the design measures it makes sense to include the Hazard as part of the system.

The capturing of the Hazards and proposed mitigations into the RM database facilitates direct linking and verification of existing design measures to the mitigations. All of the advantages of RM database are then applied to the hazard management process.

The Hazard Log Functionality includes: • Comprehensive set of Hazard

management attributes • Direct linking to design mitigations and

validation tests • Multi-tier approval process for multi-

contractor environments • History log for each Hazard • Automatic Risk Assessment based on

frequency/consequence values • ALARP assessment module • Flexible reporting tools

By directly linking design requirements to hazard mitigation requirements it is possible to clearly identify the safety related design and test requirements.

�

Page �12

Security

Basic database access is controlled through user accounts and privilege sets. Each account is configured with a user name and password. The account can be member of any one of a number of different privilege sets such as Requirements Engineer, Read Only, System Administrator etc.

The Taroko RM database distinguishes between the two main requirements engineer activities, that of Designer and Verifier.

The Designer is the person who transforms the high level requirements into a workable design. In requirements management context it is the Designer who populates the RM system with requirement records, creates the links between them and defines the categories and intention.

The Verifier is the person who reviews the requirements and their links and confirms that the lower level requirements satisfy the higher level requirements.

For each Requirements Engineer account a level of security is applied called the designer and verifier “personalities”. The personality determines which records the engineer can work on as designer and which links he is allowed to verify. The personalities are typically based on subsystem or subcontract.

History Logging & Baselining

Change history tracking is crucial to the integrity of the RM process. For the process to be credible all changes must be internally audited by the system. In addition the ability to rollback in a controlled from a set of changes is often required in the event of errors or unwanted data entry. The Taroko RM database has three levels of built in change logging:

Field Level Audit Logging The audit log is a real time log of all data entry changes in any field of a record detected by the system. That change itself is recorded along with the time, date and user account.

Record Daily History Each requirement record is baselined on a daily basis. All record which have undergone any change, including new links, is detected and recorded in the record history log. This allows a full change history audit to be performed on a requirement record. In addition the rollback function allows the record to be reverted back to any previous state.

Overall Baseline At any point in time a Baseline can be declared. This essentially takes a snapshot of the state of the database at that time. Each record in the database at that time is marked and logged as being a member of that baseline.

�

Page �13

Integration

Requirements do not live in isolation. There are several project activities which can affect a requirement’s life cycle. For example a requirement is published in a document. The document maybe modified or upreved and if the RM database is not aware of this a configuration mismatch will result. Likewise a change control process can affect requirements and must be accounted for in the RM database. In addition real world activities such as test results will need to recorded in the RM database.

As a member of the Taroko Sigma integrated suite of databases, the Taroko RM database can connect to and exchange information with any other Sigma module. This facilitates for example new revisions of documents to be automatically communicated to the RM database, approved contract changes are declared and user accounts are removed for retiring staff.

The Taroko RM open architecture also facilitates the exchange of information with other external databases. For example a document list can be synced daily with the project document management system. This is highly recommended in a document based design environment in order to ensure configuration control. In addition the RM database itself can be synced with other external RM databases such as DOORS or Comply Pro. This may useful if another less capable tool is mandated by a project but you require the detailed reporting available in Taroko RM.

�

Page �14

Minimum Configuration

Although the Taroko RM database is part of the Sigma integrated suite, it can be also be used as a stand alone system. Other functions which are unused are simply disabled and hidden. This allows the user to extend their use of the database to ther modules should the need arise in the future.

In order to carry out the basic functions of RM a minimum set of related data needs to be maintained. These include user account list and related metadata, as well as a master document list.

Software

The Sigma database including Taroko RM is developed in Filemaker pro. Filemaker pro provides a fully relational development platform including client server and web deployment options. Filemaker is a subsidiary of Apple Computer with an installed base of more than 20 Million users worldwide. For more information refer to www.filemaker.com.

The decision to use Filemaker pro was driven by the ease of use and rapid deployment features. This has huge benefits for a fast moving and evolving project environment where the demands of the project database are constantly changing and often unforeseen. New features and modifications can move from the development station to production use in minutes.

The basic Sigma license is an open source end user license agreement EULA. Use of the database is subject agreement of the EULA. The advantages of the open source model is self evident as innovations and improvements from other SIGMA installation are available for incorporation in any users installation. For more information refer to www.taroko.org.

Although the Sigma source code is free of charge, the database requires Filemaker pro to run. The Filemaker Pro platform is a commercial product and encompasses server, client software, development environment and web server engine.

The minimum system configuration for the Sigma database is a single machine running a client installation of filemaker pro. The software cost of the minimum configuration is typically less than US$500. The system is scaleable up to a full project wide deployment which would typically use Filemaker Advanced Server and up to 100 or more concurrent users.

The client server arrangement can be used within a LAN environment or remotely through the use of a virtualization system such as Citrix.