DOCSLIB.ORG

EPRI TR 107330, "Requirements Compliance Traceability Matrix,"

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
EPRI TR 107330, HF Controls HF CONTROLS CORPORATION HFC-6000 Product Line U--Nuclear Qualification Project ERD 111 EPRI TR 107330 REQUIREMENTS COMPLIANCE TRACEABILITY MATRIX RR901-000-10 Rev C Effective Date: 12/14/2009 Author: Ivan Chow Reviewer: Jonathan Taylor Approval: Allen Hsu Copyright© 2009 HF Controls Corporation 1 of 66 ERD i 11 EPRI TR 107330 Requirement Compliance Traceability Matrix Revision History Date Revision Author Changes 2/3/05 A0 J Taylor Draft 3/1/05 A J Taylor Incorporate review comments 11/19/09 B I. Chow Resolved the inconsistencies about undetectable errors and remedial implementations in RR901-000-01 Rev. B and PP901-000-01 Rev. C SCR 2612, CR 2009-0540 12/9/09 C I. Chow Revised and based on new documented information from the qualification summary report and reconstructed requirement documentations. Table of Contents 1.0 Introduction ...................... ............................................................................... 3 2.0 Traceability M atrix ....................................................................................... 3 3.0 Glossary .................................................................................................... 3 3.1 Traceability M atrix Com pliance ................................................................ 3 3.2 .Abbreviations .............................................................................................. 4 4.0 R eferences .................................................................................................... 5 List of Tables Table 1 - EPRI TR 107330 Requirement Compliance Traceability Matrix Table ...... 8 RR901-000- 10 2 of 66 Rev. C ERD 111 EPRI TR 107330 Requirement Compliance Traceability Matrix 1.0 INTRODUCTION The following pages present a traceability matrix for compliance of the ERDI 11 project with EPRI TR-107330, Generic Requirements Specification for Qualifying a Commercially Available PLC for Safety-Related Applications in Nuclear Power Plants. The purpose of this project was to assemble an HFC-6000 control system and conduct the specified range of tests to demonstrate the functional capabilities and resiliency of the system design. 2.0 TRACEABILITY MATRIX The traceability matrix consists of a multi column table. The purpose and content of the material in each column is as follows: EPRI TR-107330 Reference Contains the section and paragraph number reference for each line of text in the specification. Summary of Requirement Contains either the paragraph heading or the summary of the content in the indicated paragraph. Compliance Indicates level of compliance achieved. (Refer to paragraph 3.0.) HFC Document Reference Identifies the HFC document that either accomplishes the specific requirement or provides the evidence for compliance. Refer to PP901-000-01, HFC-6000 Product Line Document Map for a list of document references. Comments Provides explanatory information about the level of compliance or the way in which compliance is accomplished. 3.0 GLOSSARY 3.1 TRACEABILITY MATRIX COMPLIANCE Comply The intent of the stated requirement was met in full by the indicated document. Exception The intent of the stated requirement was not met in some respect. The entry in the comments column indicates the nature of the deviations. N/A Not Applicable. Either the EPRI reference did not include any requirement, or the stated requirement is not applicable to the test specimen covered by this report. RR901-000-10 3 of 66 Rev. C ERD 111 EPRI TR 107330 Requirement Compliance Traceability Matrix . I 3.2 ABBREVIATIONS ADC Analog/Digital Converter Al, Analog Input AIC Analog Input Conversion AO Analog Output C Centigrade CD Compact Disk C-Link Communication Link CPC Communication Protocol Controller CPLD Complex Programmable Logic device CR Condition Report CRC Cyclic Redundancy Check CSM Control Switch Module DAC Digital/Analog Converter DB deci Bell DI Digital (Discrete) Input DIP Dual In-Line Package DO Digital (Discrete) Output EMI Electromagnetic Interference EWS Engineering Workstation FMEA Failure Modes and Effects Analysis FOT Fiber-Optics Transmitter FPC Flat Panel Controller FPD Flat Panel Display g acceleration of gravity HAS Historical Archiving System HFC HF Controls HIFR Host Interface Remote (HFC software utility) HMI Human-Machine Interface HPAT HFC Plant Automated Tester hr hour iaw in accordance with ICL Intercommunications Link I/O Input/Output JCRT Java CRT (HFC software utility for operator workstations) KHz Kilo Hertz LED Light Emitting diode M/A Manual/Automatic MA milli Ampere min minute ms millisecond NMI Non-Maskable Interrupt OBE Operating Basis Event PC Personal Computer PCB Printed circuit Board PLC Programmable Logic Controller PROM Programmable Read-Only Memory RR901-000-10 4 of 66 Rev. C " ERD 111 EPRI TR 107330 Requirement Compliance Traceability Matrix PVC Poly Vinyl Chloride QA Quality Assurance QAPM QA Program Manual RAM Random Access Memory RFI Radio Frequency Interference RH Relative Humidity RQ Designation for a remote data routing table RTD Resistance Thermal Detector ROM Read Only Memory sec second SLC Single Loop Controller SOE Sequence of Events S-SE Safety Shutdown Event TSAP Test Specimen Application (synthetic application program for test specimen) TTL Transistor-Transistor Logic v volt V&V Verification and Validation vac volt alternating current vdc volt direct current w watt 4.0 REFERENCES Document Number Description - Revision __ERD i 1/Current 400409-01 HFC-BPCO1-19, Hardware Design Spec. A/D 400419-01 HFC SBC06, Hardware Design Spec A/C 400434-01 HFC-AI1 6F, HW Design Spec. A/B 400454-01 HFC-DI161, HW Design Spec. A/B 400459-01 HFC-DO8J, HW Design Specification A/A 400464-01 HFC-DC33, HW Design Specification A/C 400469-01 HFC-DC34, HW Design Spec. A/C 400474-01 HFC-AO8F, HW Design Spec. A/B 51378-1 Wyle Report 700709-00 HFC-6000 Chassis Assembly A/A 700901-06 HFC-6000, 1O Requirements Spec. A/A 700901-09 ERD 1I1 TSAP Requirement Spec. A/A 700907-01 ERD 111 TSAP Wiring Schematic D/D 700907-02 Single Loop Controller C/C 700908-01 HPAT Wiring C/C 700909-01 FOT Wiring D/D 700910-01 TSAP Test Rack D/D 700912-01 TSAP System Assembly Drawing G/G 700915-00 I/O Module Wiring B/B 700916-01 Power Distribution, TSAP Configuration C/C 700916-02 Power Distribution, Single Loop Configuration D/D RR901-000-10 5 of 66 Rev. C ERDI 11EPRI TR 107330 Requirement Compliance Traceability Matrix Document Number Description Revision ,ERDI11./Current ADS0401 TSAP Design Description A/A ATP0402 Application Test Plan A/D DD0401 Test Specimen Design Description A/B DSOO1-000-01 Operating System Component Design Spec. C/C DS002-000-01 C-Link Protocol Design Spec. C/C' DS002-000-02 ICL Protocol Design Spec. E/E DS004-000-03 MCRT Design A/A DS901-000-01 SBC06 DPM06, Module Detailed Design Spec. B/D DS901-000-02 1O Board Module Detailed Design Spec. B/B DS901-000-03 DO8J, Module Detailed Design Spec. B/B DS901-000-04 D1161, Detail Design Spec. B/B DS901-000-05 DC33 Detailed Design Spec. A/D DS901-000-06 DC34 Detailed Design Spec. A/D DS901-000-07 AI16F Detailed Design Spec. D1/DI DS901-000-08 AO8F Detailed Design Spec A/E DS901-000-10 AI8L Detailed Design Spec. B/E DS901-000-11 AI8M Detailed Design Spec. C/C DS901-000-12 AI4K Detailed Design Spec. C/C MS901-000-01 SBC06 Module Design Spec. F/F MS901-000-02 1O Board Module Design Spec. C/C PP901-000-01 Topical Report A/C QAPM Quality Assurance Program Manual 5/H QPP 3.1 Design Control D/I QPP 3.2 Software Lifecycle and V&V Program 1/I QPP 6.1 Control and Distribution of Documents B/H QPP 12.1 Control of Measurement and Test Equipment C/G QPP 13.1 Handling, Shipping, Storage and Preservation of 0/C Materials, Parts and Components QPP 16.1 Corrective Action Program D/M QPP 16.2 Customer Feedback 0/E QPP 16.3 1OCFR Part 21 Report 0/B RR901-000-01 Failure Modes and Effects Analysis B/B RR901-000-04 Reliability and Availability Analysis Report A/A RS901-000-01 HFC-6000 Product Line C/F RS901-000-02 HFC-PSR06 Requirements Spec. D/E TN0401 Master Test Plan C/C TP0401 Integration Test Plan B/B TP0402 Operability Test Procedure C-E/F TP0403 Prudency Test Procedure C-E/F TP0404 Environmental Stress Test Procedure C/D TP0405 Seismic Test Procedure C-D/E TP0406 Surge Withstand Test Procedure C/D TP0407 EMI-RFI Test Procedure C/C TP0408 TSAP Validation Test Procedure A/B RR901 -000-10 6 of 66 Rev. C ERD 111 EPRI TR 107330 Requirement Compliance Traceability Matrix Document Number Description Revision ERD 11/Current TP0408B Test Specimens Validation Test Procedure A/B TP0409 ESD Test Procedure C/C TP0410 Bum-in Test Procedures B/C TP0411 Isolation Test Procedures B/B TROO1-000-02 Application Object Test Plan B/B TS901-000-22 ERD 111, Baseline Tegting Summary Report B/B TS901-000-23 Environmental Test Report B/C TS901-000-25 EMI Test Report B/C TS901-000-28 Isolation Test Report B/C TS901-000-29 Post Qualification Report B/B TS901-000-30 Summary Report for Bum In Setup, TSAP B/B Validation. TS901-000-34 Seismic Retest In House Test Report B/B TS901-000-35 HFC6000 Seismic Retest Report B/B UG004-000-01 EWS User's Guide E/E UG004-000-02 OIS User's Guide E/E UG004-000-04 Onestep Software User's Guide D/D UG004-000-05 Software Installation Guide, Version 1.14 or 2.0 D/D UG004-000-07 Site Planning and Installation Guide H/H UG004-000-08 Maintenance, Troubleshooting and Diagnostics F/F UG004-000-10 WCRT Setup User's Guide A/A VV0414 Master Configuration List A/A WI-DOC-001 Document Distribution B/G WI-ENG-003 Configuration Management 1/E WI-ENG-006 PCB Assembly Order Requirement List 2/A WI-ENG-008 Software V&V Procedures 0/VV-001 WI-ENG-020 Software Security 0/B WI-ENG- 100 Engineering Processes 0/D WI-ENG-206 CMS Library SW Source Code Control A/A RR901-000-10 7 of 66 Rev.
Load more

Recommended publications
  • A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J
    A System Model for Managing Requirement Traceability Matrices via Statistical Artifact Change Analysis Benjamin J. Deaver and LiGuo Huang, Southern Methodist University, Dallas Introduction and Motivation Requirement Traceability Matrix – Gantt Open Source Software Project The Value of the Requirements Traceability Matrix The system Requirement Traceability Matrix (RTM) is primarily used for ensuring Our initial dataset for evaluation is taken from the Gantt Open Source PROCEDURE Kannenberg et al identify the underlying necessity of the Requirements Traceability Matrix and the underlying effect on that all requirements are fulfilled by the system artifact deliverables and the Software Project (http://www.ganttproject.biz). The initial trace data 1. Identify the taxonomy of change for a given domain (Systems Engineering, project management, process visibility, verification and validation, as well as project maintainability. Over time, the management of change to deliverables with respect to impact on other systems. In has been provided to us by Dr. Alexander Egyed at the Institute for SoS Engineering, Software Engineering). the systems engineering and system of systems (SoS) engineering landscapes, the Systems Engineering and Automation at Johannes Kepler University. Requirements Traceability Matrix provides significant insight in to the internal workings of the relationships between RTM is a tool that is useful at time of creation, but requires constant maintenance in Additional traces of requirements to code for subsequent Gantt versions 2. Identify and classify changes between static versions of the product. requirements and deliverable artifacts. a frequently changing landscape to maintain the original level of validity. The are being created using similar methods to the original collections 3. Generate Requirements Trace Matrixes for each static version of the product dynamic nature of systems and SoS engineering landscapes requires that a RTM be performed by Dr.
    [Show full text]
  • Traceability Establishment and Visualization of Software Artefacts in Devops Practice: a Survey
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 10, No. 7, 2019 Traceability Establishment and Visualization of Software Artefacts in DevOps Practice: A Survey D. A. Meedeniya1, I. D. Rubasinghe2, I. Perera3 Dept. of Computer Science and Engineering, University of Moratuwa, Sri Lanka Abstract—DevOps based software process has become the artefacts in the SDLC [2][3]. There are different forms of popular with the vision of an effective collaboration between the relationships between the homogeneous and heterogeneous development and operations teams that continuously integrates software artefacts. Some artefacts may be highly coupled, and the frequent changes. Traceability manages the artefact some may depend on other artefacts in different degrees, consistency during a software process. This paper explores the unidirectionally or bidirectionally. Thus, software artefacts trace-link creation and visualization between software artefacts, consistency management helps to fine-tune the software existing tool support, quality aspects and the applicability in a process. The incomplete, outdated software artefacts and their DevOps environment. As the novelty of this study, we identify the inconsistencies mislead both the development and maintenance challenges that limit the traceability considerations in DevOps process. Thus, artefact management is essential such that the and suggest research directions. Our methodology consists of changes are accurately propagated to the impacted artefacts concept identification, state-of-practice exploration and analytical review. Despite the existing related work, there is a without creating inconsistencies. Traceability is the potential to lack of tool support for the traceability management between relate artefacts considering their relationships [4][5]; thus, a heterogeneous artefacts in software development with DevOps solution for artefact management.
    [Show full text]
  • Requirements Traceability Practices Guide
    CDC UNIFIED PROCESS PRACTICE GUIDE REQUIREMENTS TRACEABILITY Document Purpose The purpose of this document is to provide guidance on the project management practice of Requirements Traceability and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Requirements traceability is an activity that is one part of an overarching requirements management practice and extends from requirements definition through to implementation. Requirements tracing is used to ensure that each step of the product’s development process is correct, conforms to the needs of prior and next steps, and conforms to the defined requirements. Requirements tracing is a technique that helps to ensure that the project delivers what stakeholders expect. If applied correctly requirements tracing is a practice that can greatly increase the quality and reliability of a project’s final product while minimizing costly rework resulting from requirements errors. Requirements tracing defines the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through each step of the entire product’s life cycle. This is done by documenting and tracking traceability relationships between requirements. A traceability relationship is a dependency relationship between project and/or product elements. Similar to the way a dynamic project schedule may react to a change in one task, a change to a requirement element may also have a rippling effect on other elements. A well documented traceability relationship clearly defines requirement dependencies and allows for analysis of how changes in requirements affect other requirements and the project as a whole.
    [Show full text]
  • Systems Engineering Guided Tour
    Systems Engineering Guided Tour Copyright © 1993–2007 Vitech Corporation. All rights reserved. No part of this document may be reproduced in any form, including, but not limited to, photocopying, translating into another language, or storage in a data retrieval system, without prior written consent of Vitech Corporation. Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7013. Vitech Corporation 2070 Chain Bridge Road, Suite 100 Vienna, Virginia 22182-2536 703.883.2270 FAX: 703.883.1860 Customer Support: [email protected] www.vitechcorp.com CORE® is a registered trademark of Vitech Corporation. Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies. Revised Date: August 2007 ii Table of Contents Creating External Systems ................................ 32 ................... 1 1 Getting Started with CORE Defining the Context Component ...................... 34 The Benefits of CORE ....................................... 1 Adding Detail to the External Systems .............. 35 Installing CORE................................................. 2 Viewing a Physical Hierarchy ............................ 36 Overview of the CORE Product Family ............. 2 Creating Function Elements .............................. 37 Key Concepts .................................................... 3 Establishing
    [Show full text]
  • Managing Project Requirements
    MANAGING PROJECT REQUIREMENTS Course Materials The causes of the majority of failed IT projects can be traced to poor definition and understanding of requirements. Changing requirements causes more delays than any other cause. If you want to improve project performance you must improve the way you define and manage requirements. Requirements must be a clear description in a common language. They are the bridge between the customer who will describe, pay for, and use the solution and the technical community who will specify and provide the solution. Requirements must be unique, normalized, linked, complete, consistent, bounded, modifiable, configurable and granular. Participants will cultivate the skills needed to elicit full business information from the right stakeholders and, learn structured techniques to identify and present business requirements clearly and effectively. Table of Contents Lesson 1: Introduction to Requirements Management ......................................................................... 1 Topic 1: Requirements Definition ....................................................................................................... 2 Exercise 1.1 Evaluating Requirements ............................................................................................... 5 Topic 2: The Project Environment ...................................................................................................... 6 Topic 3: Understanding the Project Charter .....................................................................................
    [Show full text]
  • Verification and Validation
    Requirements Verification and Validation In4Mtx 113 February 2010 Agenda Definitions of V&V Why do we care? Verification Methods VCRMs Verification Techniques Success Criteria Early Verification Planning in the RE Process What Makes Requirements Verification Difficult 2 Definitions Verification: The process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase. Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. These definitions are taken from : Verifying and validating software requirements and design specifications. Boehm, B W IEEE Software. Vol. 1, no. 1, pp. 75-88. 1984 3 Basically… Verification: "Am I building the product right?" Validation: "Am I building the right product?" 4 Why do we care? Outputs Data/Models In Requirements Database Directly Drives Verifies 5 Remember this process? Inspection Individual Defect evaluation RD planning reviewing at review meetings consolidation Figure 5.1 – Requirements inspection, review, and consolidation Your testers are key stakeholders 6 Verification Methods Industry accepted methods are: Test Analysis Demonstration Inspection S Any guesses to the “S” in T.A.D.I.S? 7 VCRM Verification Cross Reference Matrix Supplemental to the RD This will be required on any RD you’ll ever produce. Guarantee it: 100% Can be combined with the Requirements Traceability Matrix 8 Sample VCRM Req ID Requirement Verification Allocation Success Criteria Method 1 The train doors shall remain D, T Controller SW Once ground speed >= 1mph, closed during all operational train doors lock and remain activities. closed.
    [Show full text]
  • Software Requirements Specification (SRS) Tailoring Standards
    CS 330 Software Engineering Software Requirements Specification (SRS) Tailoring Standards The following description provides the basic document organization, and required information (see the Document Style Guidelines and Standards for information about format). The main thing to remember is that the SRS must contain a Requirements Traceability Matrix (RTM). Each requirement is uniquely identified (using a number) in the body of the document and must be called out in the RTM. Each requirement will use the verb “shall.” Otherwise the statement shall not be considered a requirement. Each item below should be considered required as a major element or section in the SRS. The standard referred to here is IEEE Std. 830-1993. Title Page Abstract1 Frontmatter 1. Introduction (see section 5.1 of the standard for details) 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 1.4. References 1.5. Overview 2. Overall description (see section 5.2 of the standard for details) 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 3. Specific Requirements (see section 5.3 and/or appendix A of the standard for details) 4. References Appendixes Definitions, Acronyms and Abbreviations Requirements Traceability Matrix Schedule (with a description of milestones and deliverables) Walk-through Check List Coding Standards Special Purpose Items: Description of the external items pictured in context diagram Other Special Purpose Items (e.g. JAVA / C++ API; Screen Shots of a GUI) Index (optional) 1 Include in the abstract a complete overview of the product (purpose, goals, and design constraints) including your chosen design methodology, any exceptions to the stated requirements.
    [Show full text]
  • ALS V&V Plan
    Westinghouse Non-Proprietary Class 3 ALS V&V Plan 6002-00003-NP Rev. 8 January 2013 APPROVALS Function Name and Signature Author Simon Lowenfeld* Fellow Engineer, Independent Verification and Validation II Reviewer Jim Pak* Principal Engineer, Independent Verification and Validation I Approver Marci Maher* Manager, Independent Verification and Validation I *Refer to Release Record for Electronic Approval WESTINGHOUSE NON-PROPRIETARY CLASS 3 © 2013 Westinghouse Electric Company LLC All Rights Reserved ALS V&V Plan LIST OF CONTRIBUTORS Revision Name and Title 7 Marci Maher Acting Manager, Independent Verification and Validation I 7 Secil Karaaslan Senior Engineer, Independent Verification and Validation I 7 Jeff Vance Senior Engineer, Independent Verification and Validation I 7 Jim Pak Principal Engineer, Independent Verification and Validation I 8 Marci Maher Manager, Independent Verification and Validation I 8 Warren Odess-Gillett Fellow Engineer, Licensing 8 Marsha White Senior Technical Writer, Technical Communications Template Version 2.2 6002-00003-NP Rev. 8 i Westinghouse Non-Proprietary Class 3 ALS V&V Plan REVISION HISTORY RECORD OF CHANGES a, c , , e 6002-00003-NP Rev. 8 ii Westinghouse Non-Proprietary Class 3 ALS V&V Plan REVISION HISTORY (cont.) RECORD OF CHANGES (cont.) DOCUMENT TRACEABILITY & COMPLIANCE Created to Support the Following Document(s) Document Number Revision N/A OPEN ITEMS Item Description Status None 6002-00003-NP Rev. 8 iii Westinghouse Non-Proprietary Class 3 ALS V&V Plan TABLE OF CONTENTS Section Title Page
    [Show full text]
  • Traceability in Agile Software Projects
    Traceability in Agile software projects Master of Science Thesis in Software Engineering & Management VUONG HOANG DUC University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering Göteborg, Sweden, May 2013 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Traceability in Agile software projects VUONG.HOANG DUC VUONG. HOANG DUC, May 2013. Examiner: CHRISTIAN.BERGER University of Gothenburg Chalmers University of Technology Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 ABSTRACT Context: Software applications have been penetrating every corner of our daily life in the past decades. This condition demands high quality software. Traceability activities have been recognized as important factors supporting various activities during the development process of a software system with the aim of improving software quality.
    [Show full text]
  • On Human Analyst Performance in Assisted Requirements Tracing: Statistical Analysis
    On Human Analyst Performance in Assisted Requirements Tracing: Statistical Analysis Alex Dekhtyar∗, Olga Dekhtyar†, Jeff Holden∗, Jane Huffman Hayes‡, David Cuddeback∗, and Wei-Keat Kong‡ ∗ Department of Computer Science, Cal Poly, San Luis Obispo, CA, USA Email: {dekhtyar, jholden}@calpoly.edu, [email protected] †Department of Statistics, Cal Poly, San Luis Obispo, CA, USA. Email: [email protected] ‡Department of Computer Science, University of Kentucky, Lexington, KY, USA. Email: [email protected], [email protected] Abstract—Assisted requirements tracing is a process in what tests to rerun. With all the advantages that tracing could which a human analyst validates candidate traces produced offer to NDFC, why are they not using such a tool/process? by an automated requirements tracing method or tool. The First, many organizations undertake manual tracing, per- assisted requirements tracing process splits the difference between the commonly applied time-consuming, tedious, and haps with the assistance of a word processing tool or error-prone manual tracing and the automated requirements spreadsheet. Such a process is boring, tedious, and time- tracing procedures that are a focal point of academic studies. consuming. As a result, it is also error prone [11]. Second, In fact, in software assurance scenarios, assisted requirements once traceability is established for a project, the project arti- tracing is the only way in which tracing can be at least partially facts quickly change, thus necessitating traceability updates. automated. In this paper, we present the results of an extensive 12 month study of assisted tracing, conducted using three Third, there is a lack of an industry-accepted tracing tool.
    [Show full text]
  • 5 Tips on Traceability to Skillfully Control Change and Improve Quality
    INNOVATION IN ACTION Connect the Dots: 5 Tips on Traceability to Skillfully Control Change and Improve Quality. Overview Traceability Helps You Stay Connected, Manage Change & Improve Quality. Yes! What is traceability? It sounds complicated. Why do teams do it? It sounds like a lot of work. Is it really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important: Change happens. If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If managed skillfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the full history, keep everyone in sync and (deep breath) consistently improve the quality of the products being built – every project, every release. Sign me up. In some industries, traceability isn’t an option, it’s mandated. Did You Know? “Companies We’d recommend that regardless of the industry you’re in or the process you use – whether you’re building components for with mature requirements commercial airplanes using waterfall or designing the next management and traceability killer iPhone app using an agile method –traceability is a best practice that will benefit your team greatly. processes achieve 75% higher In this paper, our goals are to demystify traceability and its success rates.” – IAG, Business related concepts, and provide five practical tips to help you Analysis Benchmark, 2009 take control and keep everyone in sync. The Five Tips for Mastering Traceability: 1. Create relationships to connect everyone and everything together with Trace Relationships 2. Ensure you have proper coverage using a Traceability Matrix 3.
    [Show full text]
  • Requirements Traceability Matrix Template
    Connecticut Department of Social Services Enterprise Program Management Office Requirements Traceability Matrix Purpose of the Requirements Traceability Matrix The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols. The traceability matrix is a tool both for the validation team to ensure that requirements are not lost during the validation project and for auditors to review the validation documentation. Information to Include The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Requirements Specification). As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested. How the RTM is used A requirements traceability matrix is used to check if the current project requirements are being met or to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks. Change Impact Analysis – if a requirement is changing, trace links inform about related and dependent artifacts. These artifacts can easily be verified and if required, be adjusted. The probability to overlook related artifacts is reduced. Coverage Analysis – Traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized. Project Status Analysis – Tracking of the project status is possible: analyzing the traceability data allows the project manager to see the completion status of the requirements.
    [Show full text]