需求可追踪性
需求可追踪性（Requirements traceability）也称为需求可追溯性，是需求管理中的一部分，和软件开发及系统工程有关。IEEE Systems and Software Engineering Vocabulary有定义通用的可追溯性（Traceability）[1]，定义如下
- 在开发过程中二个或是多个产品相关性的程度，特别是两者之间有先后关系或主从关系的产品[2]
- 在产品层次结构中，工作产品的向上路径及向下路径的识别以及[3]
- 在软件开发产品中，有关每一个元件存在原因的说明
- 在二个或是多个逻辑实体中（例如需求、系统元件、验证、任务）建立可以识别的关联性。
若要定义需求可追踪性，可以定义为：“描述以及追踪一个需求的生命周期的能力，追踪可能会往前追踪，也可能会往后追踪（追踪其来源、其开发过程及对应规格、到最终的布署及使用，以及过程中每一个周期中相关的细化及迭代。）”[4][5]。在需求工程的领域中，可追踪性是明了高阶的需求（目标、目的、期望、需求）如何转换为低阶需求的过程，主要关注的是不同资讯层（或开发产物）之间的满足关系[6]。不过，可追踪性也可以用文件建立任何种类开发产物之间的关系，例如需求、规格叙述、设法、测试、型号以及所开发的元件[7]。例如在进行展示时，常常需要找到验证的关系，来确认某一个需求可以由特定的测试所验证。
在开发安全关键系统时，特别会强调可追踪性，因此在许多安全标准中也会提到，例如DO-178C、ISO 26262及IEC 61508。这些指引中的常见要求是关键需求必须经过确认，且验证过程要可以通过可追踪性来展现[8]。
需求之前及需求之后的可追踪性
编辑- 需求前的可追踪性（Pre-requirements traceability）[4]：需求会来自不同的来源，例如订购产品的商务人士、行销经理或是使用者。这些人会有对产品不同的需求。利用需求可追踪性，在进行需求引发时可以将要实施的机能追溯到提出需求的人员或是团体。在开发过程中要决定各需求优先级，判断各需求对特定用户的价值时，即可配合需求前的可追踪性进行。若在产品布署后，若要确认在使用者研究中为何找到了一些未使用的机能，也可以用到需求前的可追踪性。
- 需求后的可追踪性（Post-requirements traceability）[4]：需求本身需要追踪，也需要追踪所有因为需求产生，与其有关的开发产物，例如型号、分析结果、测试用例、测试结果以及所有相关的文件。甚至也要追踪和需求有关的人或是团体。需求需要实现为设计产物、实作，而且最后确认通过。开发后期产生的开发产物也要可以追溯到其原始的需求。这多半会透过需求追踪矩阵来进行。
要将需求可追踪性连结到设计、实现及验证的开发产物可能会相关困难[9]。例如在实现软件需求时,需求可能是在需求管理软件中，而设计产物可能是在MagicDraw、Mathworks Simulink、Rational Rhapsody或Microsoft Visio等工具软件中。而最后实现的开发产物可能是以源代码的形式出现。验证产物可能是由内部测试或是型式验证工具（像是LDRA Testbed suite、Parasoft DTP或SCADE）所产生的结果。
在维护动态系统的可追踪性时，存储库或工具堆栈的整合工具也可能是一大挑战。
追踪资讯的用途
编辑可追踪性的资讯，特别是对应开发工具各阶段产物的需求后的可追踪性，有以下的好处[10][11]：
- 变更影响分析：若需求改变，可以透过追踪资讯找到有关及受影响的产物。因此可以确认各产物，若有需要时也可进行调整。可以减少未确认相关产物的风险。
- 覆盖率分析：可追踪性可以确保需求中没有遗漏的项目，特别是在验证安全相关产品时，需要确认所有的需求都已实现。
- 专案状态分析：可以用需求可追踪性来追踪专案的状态。分析可追踪性资料可以看到需求的完成情形。若需求没有对应的连结，或是没有连结到完整的工具链（例如需求有对应的实现，但没有测试结果），代表还有工作需要进行。缺少的连结表示少了某一个产物，需要实现该产物。
- 复用产品的组件：可以针对需求以及相关产物加以结构，形成一个模组。之后可以将模组用在不同的产品中。
- 持续性的关系：专案或是产品的知识多半只存在特定人员们的大脑中。利用需求可追踪性可以看出不同开发产物之间的关系，可以保留部分知识。就算有人员异动，仍可以保留这些知识。
- 测试最佳化：在连结需求、源代码、测试用例及测试结果后，若测试失败，可以识别可能是哪一段程式影响的。甚至可以找到多余的测试，进而删减该测试。
有些文件会进一步讨论需求可追踪性可以支援的开发工作，以及彼此之间的关系[12]。
对专案的影响
编辑许多研究指出了需求可追踪性的效果，不过也提到确认相关资讯的困难度：
- 需求可追踪性可以加速开发工具，而且可以提升成果：有一个针对71个群体进行的研究，其中有些在修改源代码时有使用需求可追踪性的资讯，有些没有，结果可以看出可追踪性的好处。配合可追踪性的资讯，开发者完成任务的速度快了24%，而且正确性提升了50%[13]。
- 越完整的可追踪性，越可以减少软件中的错误：在一个针对24个中型及大型开源专案的分析中，发现可追踪性的完整性和所开发软件代码的错误率之间有显著的统计关系。软件模组的可追踪性越完整，所发现的软件错误越少[14]。
- 要实现符合规范的可追踪性非常困难：2013年美国食品药物管理局针对医疗器材软件上市前测试的分析发现：在处方和归档的可追踪性资讯之间有很大的差距[8]。若要实施符合规范的可追踪性，最后往往会出现“大冻结”。会让公司不再进行后续旳开发，因为重新认证需要花上大量的资源及心力[15]。
需求可追踪性的视觉化
编辑可追踪性的目的之一是让让各产物之间的关系可以视觉化。当追踪连结变多，复杂性变高时，就需要导入可追踪性视觉化的技术。视觉化可以包括有关各产物的资讯（产物型态、元资料及属性）以及连结（连结种结、元资料、连结强度）等[16]。
常用的需求可追踪性视觉化资料包括有矩阵、图、列表及超链接等。
- 可追踪性矩阵：类似表格的表示方式，将某一种类的产物（例如需求）放在栏，另一种类的产物（例如源代码）放在列。两者有若关连，表格的每一格都有标记，若没有关连，则维持空白[16]。可追踪性矩阵的好处是在产物不多时，，可以一眼看出两类产物连结的概况。可追踪性矩阵适用于管理任务[16]。不过在产业中，专案可能会包括上千个产物，若全部列出，表格会非常大，而且不容易阅读[17]。
- 可追踪性图（Traceability graph）：是以节点表示产物的表示方式。若二个产物之间有可追溯性，且二个产物的结点都存在的话，各节点之间就可以用边连接。图特别适合用在开发任务，可以探索性的浏览各个边，其资讯比较容易理解[16]。通过浏览图形，很容易找到遗漏的连结，可以视为后续要建立对应产物的提示。
- 列表：列表可以列出一个进入点的可追踪性连结。此进入点可以有关来源、目的产物及属性的资讯。若需要针对许多不同的产物进行批量操作时，此方式特别适用。筛选器以及排机制有助于整理及显示资讯。不过相较于上述的视觉化方式，列表比较不适合用在专案的管理、开发或是测试工作[16]。
- 超链接：超链接可以连结二个产物，可以从来源产物跳到目标产物。此视觉化方式适用于需要有关产物细节资讯的情形，也允许在其原生环境内浏览相关产物[16]。只使用超链接的缺点是超链接在视觉上不够紧凑，为了要追踪连结的状态，需要花许多的心力浏览各连结。
各视觉化的方式都有其限制，因此可以结合多种视觉化的方式，可以克服各方式的限制。
实现方式
编辑人工建立可追踪性
编辑可以用人工或是简易工具辅助（例如试算表或是Excel）的方式建立可追踪性。此方式广为使用，但作法非常的麻烦，容易出错，而且会因为各开发工具的问题，而且要追踪的产物很多，可追踪性资讯的品质会比较差[18]。
工具辅助的可追踪性
编辑工具辅助的可追踪性需要散布在开发工具链上的开发资讯可以同质化，并且可以聚合。以下是一些可以达成此条件的作法：
- 透过应用程序生命周期管理（ALM）工具，将工具环境同质化：ALM工具可以包含系统的整个生命周期，以全面的作法来管理开发过程中产生的所有产物。像是在分散式的环境中，已成功的使用以Volere需求模版实现的问题追踪器。此作法的好处是配合ALM工具的专门软件，产物的同质化会让管理以及分析变简单。缺点是要实现整个ALM工具链。若引入了，很很难更换工具链中的特定软件。
- 透过代理需求将资料同质化：专案管理（RM）工具可以储存、组织及管理系统规格内的所有需求，一般会整理成规格树，将每一个需求连结到较高级规格的父需求]。有支援可追踪性的专案管理商业软件有3SL Cradle、CASE Spec、IRise、GatherSpace、IBM Rational RequisitePro、IBM DOORS、Visure Requirements[19]、CaliberRM、QFDCapture及Matrix Requirements Medical。免费工具有FreeMind及Concordion[20]。依照记录追踪资讯的典型分析功能有完整性检查（也就是检查所有系统层级的需求都有对应到设备层级的需求，可能有修改或是没有修改）、评估各一层对于需求的调整、并且显示验证的状态。为了确保需求之前产物的可追踪性，专案管理工具多半可以将需求之前的产物汇出为代理需求（surrogate requirements），可以用工具的需求追踪方式来追踪。例如，Simulink模型的元件可以汇入到Rational DOORS的代理模组，和需求关联。此作法的缺点是会针对不同的产物有不同的转接器或是转换器，需要有一均的版本以及资料格式。若是使用应用程序生命周期管理（ALM）工具，会自动处理一致性的问题。
- 用专用追踪工具达到资料的均质化：专用追踪工具的基本定义包括以下三个基本步骤：
- 定义资料模型，也就是可追踪性资料模型（Traceability Information Model、TIM）[21]。此模型可以标示产物的种类（例如风险承担者的需求、软件需求、整合测试、系统模型元件）以及连结的方式。
- 所有工具中相关资料的定义映射（definition of mappings），工具是工具链中的一部分，以及这些资料如何映射到可追踪性资料模型。
- 矩阵以及分析函数是由TIM所定义，不是由特定工具上的资料所定义。
相关条目
编辑参考资料
编辑- ^ Systems and software engineering – Vocabulary. 2010-12-01: 1–418. ISBN 978-0-7381-6205-8. doi:10.1109/IEEESTD.2010.5733835.
|journal=被忽略 (帮助) - ^ IEEE Guide for Developing System Requirements Specifications. 1998-12-01: 1–36. ISBN 978-0-7381-1723-2. doi:10.1109/IEEESTD.1998.88826.
|journal=被忽略 (帮助) - ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. 1998-12-01: 1–24. ISBN 978-0-7381-1407-1. doi:10.1109/IEEESTD.1998.89424.
|journal=被忽略 (帮助) - ^ 4.0 4.1 4.2 Gotel, O.C.Z.; Finkelstein, C.W. An analysis of the requirements traceability problem. April 1994: 94–101. CiteSeerX 10.1.1.201.7137
. ISBN 978-0-8186-5480-0. doi:10.1109/icre.1994.292398 （美国英语）. |journal=被忽略 (帮助) - ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan. Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea , 编. Software and Systems Traceability
. Springer London. 2012-01-01: 3–22. ISBN 9781447122388. doi:10.1007/978-1-4471-2239-5_1 （英语）.
- ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick. Requirements Engineering (Second Edition). Springer. 2005: 9–13, 131–151. ISBN 978-1-85233-879-4.
- ^ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
- ^ 8.0 8.1 Mäder, P.; Jones, P. L.; Zhang, Y.; Cleland-Huang, J. Strategic Traceability for Safety-Critical Projects. IEEE Software. 2013-05-01, 30 (3): 58–66. ISSN 0740-7459. doi:10.1109/MS.2013.60.
- ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li. Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg. 2008: 100–111. ISBN 978-3-540-79587-2.
- ^ Wiegers, Karl. Requirements Traceability: Links in the Requirements Chain, Part 1. jama. 2013 [2016-12-14]. （原始内容存档于2018-06-13）.
- ^ Wiegers, K.; Beatty, J. Software Requirements. Microsoft Press. 2013.
- ^ Bouillon, Elke; Mäder, Patrick; Philippow, Ilka. Doerr, Joerg; Opdahl, Andreas L. , 编. Requirements Engineering: Foundation for Software Quality . Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2013-04-08: 158–173. CiteSeerX 10.1.1.659.3972 . ISBN 9783642374210. doi:10.1007/978-3-642-37422-7_12 （英语）.
- ^ Mäder, Patrick; Egyed, Alexander. Do developers benefit from requirements traceability when evolving and maintaining a software system?. Empirical Software Engineering. 2015-04-01, 20 (2): 413–441. ISSN 1382-3256. doi:10.1007/s10664-014-9314-z （英语）.
- ^ Rempel, Patrick; Mäder, Patrick. Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality. IEEE Transactions on Software Engineering. 2016-01-01, PP (99): 777–797. ISSN 0098-5589. doi:10.1109/TSE.2016.2622264.
- ^ open-DO | Toward a cooperative and open framework for the development of certifiable software. www.open-do.org. [2017-04-15]. （原始内容存档于2021-02-25） （美国英语）.
- ^ 16.0 16.1 16.2 16.3 16.4 16.5 Li, Y.; Maalej, W. Which Traceability Visualization Is Suitable in This Context? A Comparative Study.. Springer. 2012: 194–210.
- ^ Lerche, Felix. 5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH. 2019 [2020-05-27]. （原始内容存档于2021-03-04）.
- ^ Kannenberg, Andrew; Saiedian, Hossein. Why Software Requirements Traceability Remains a Challenge (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering. 2009 [2020-05-27]. （原始内容 (PDF)存档于2019-05-28）.
- ^ Visure Requirements. [2020-05-27]. （原始内容存档于2021-05-25）.
- ^ Laplante, Phillip A. Requirements Engineering for Software and Systems. CRC Press. 2009.
- ^ Traceability Information Model. [2020-05-27]. （原始内容存档于2019-04-03）.
- ^ Eclipse Capra. [2020-05-27]. （原始内容存档于2020-10-26）.
- ^ Reqtify (german page). [2020-05-27]. （原始内容存档于2021-03-04）.
- ^ YAKINDU Traceability. [2020-05-27]. （原始内容存档于2021-01-23）.
