第10组-Guidelines for Managing Requirements Rationales内容解读

[刘玉婷]

       在拿到这篇论文标题的时候我们第一时间去搜了rationales这个单词，各大翻译软件给我了如下解释：比如理论说明、基础理论、根据、理由或原因等，经过小组讨论将这个词定义为原理，所以requirements rationales就是需求原理的意思。在软件工程中，需求原理是指为什么一个特定的需求是必要的有意义的，包括功能或非功能需求等原理，我们很容易被庞杂的需求原理海倾覆，所以系统化需求原理的管理就变得至关重要，它可以帮助提高需求管理的效率和质量。

       所以本论文将围绕如何管理需求原理展开，即本论文标题——需求原理的管理指南，我们将分点为大家讲述：

 

一、需求原理管理指南概述

       首先，论文提到了系统化管理需求原理的优点：

       1、工程师需要在系统化管理需求原理的时候解释他们的隐性知识，这有助于提高需求的清晰度，发现隐含的可追溯性链接；

       2、增强创造力，并通过提供对先前决策的理解和避免死胡同来支持需求的发展。积极的需求原理管理至关重要。

 

       但是如果不对需求原理管理进行管理呢？系统开发可能会有以下影响：

       1、由于非系统决策和不明确的需求，开发人员可能会在与客户的谈判中同意高风险承诺；

       2、由于隐含的理由和不明确的需求，需求及其实施之间可能会出现不匹配；

       3、在系统演进或类似系统的开发过程中，由于缺乏原理，很可能会需求重构。

 

       在面对需求原理管理的优点和影响时，我们更要关注需求原理管理指南的应用场景，它适用于需要透明度和经过深思熟虑的决策的组织，而不适用于基于快速变化的决策的工作，这是因为决策组织数据非常耗时，如果用在决策快速变化的场景会导致需求原理管理无法适应需求变化。

       由于关于需求原理的管理指南很少。可用的指南侧重于软件设计，所以需求原理的管理方式就变的比较困难， 所以我们确定了需求原理的四个挑战并准备从此来入手对应的管理指南，相关挑战的介绍如下：

1. 如何捕获：我们可以采用文本解释决定和建模来来捕获需求原理，建模常用的方式为基于问题的信息系统（IBIS），其用于区分问题、选项、论据和决策，决策表示语言（DRL）扩展了这个方法，产生了20多个建模概念。为了获取原理，从业者用20到30个属性填充大型模板。尽管这样一种广泛的方法可以产生高的表现力和覆盖率，但它既乏味又繁琐。
2. 如何追踪：需求原理很难与需求区分开，当利益相关者更改需求时，很容易就会忘记更新对应的需求原理，所以需求原理也较难以维护，当一个原理影响到多个需求的时候，每变更一次就可能会导致整个需求的崩塌。
3. 如何重用：决定需求是很耗时的，所以为了提高开发效率，针对多个项目中对类似问题的重复执行，需求原理的重用就变得格外重要，一个好的重用可以帮助利益相关者从类似问题的领域知识和经验来确定替代需求和标准。
4. 如何维护：为了提供有关需求的最新推理，实现重用，并要求拥有良好的质量，如何维护变成了一个不衰的问题。

 

       为了应对这四个挑战，我们提出了对应的指南，在提到指南之前，我们需要引入一个新概念：灵活的元模型。通过使用灵活的元模型，能让从业者根据自己的需求选择概念，首先是组织可以调整特定的元模型，以便选定的概念在整个组织中都是明确的；其次元模型本身是灵活的，因此利益相关者可以省略不相关的概念。这样的元模型有两个关键的好处：第一，从业者可以根据自己的需求使用概念，而不仅仅是填写大型模板；其次，从业者不需要审查可用的需求原理模型来选择其中一个供组织使用。他们根据自己的需求定制元模型，并通过基于LoRQ的指导来增强基本原理捕获。

       在讨论完元模型这个新概念之后，我们继续回到应对需求原理挑战对应的指南上来：

       首先是确定我们要捕捉的内容是什么，此时使用灵活的的元模型对需求进行捕捉就成了应对该挑战的指南，灵活的元模型可以帮助我们处理不同的问题，这种轻量级的方式，让从业者在面对不同问题的时候可以较为专注关注真正相关的需求；其次要关注的是我们如何追踪需求，指南告诉我们在从需求中捕获原理的时候，要对原理和需求进行可追溯性建模，可追溯性的推理简要总结为如下的图，根据这个可塑性推理，我们就会建立元模型中各个元素之间的联系，最终可以达到互相之间的可追溯性，元模型的概念我们稍后再进行介绍。这个指南中需要注意的是一个原理工件可以影响到多个需求，所以在记录相应的可追溯性信息的时候，要将原理与需求分离，方便原理的重用同时减少捕获的工作量；当我们应对第三个如何重用的挑战时，指南提供了四种基本重用模式：①类似的问题②决策的参数变化③创造性的需求④新系统的知识转移，要求从业者尽可能的只关注一组预定义的重用模式，目的是方便从业者避免若干重复性的任务，减少了工作量和决策时间；最后的挑战是如何维护？在处理维护时，指南要求需求原理有较高的质量，高质量意味着更便于去重用，因为在重用时不会因为原理质量问题引入更多的问题

 

二、需求原理管理建模

       接下来我们来详细讲解需求原理管理的建模，也就是刚刚提到的元模型。

       元模型中包括问题、选项、标准、参数（论据）、结果和决策六个概念，除了问题和决策两个概念是所有元模型中必备的，从业者可根据自己系统的需求对可选概念选项、标准、参数、结果进行“筛选”，以便形成轻量级的供从业者专注于关键需求的模型。在该模型中我们可以看到不同概念之间的相互依赖关系：

概念	可选/必选	建议使用	基本原理方法	相互依赖关系
问题	必选	这个问题（要解决的问题）在所有情况下都应该是清晰和明确的。	所有	问题触发选项
选项	可选	在评估该问题的多个解决方案时斟酌选择。考虑多个选项可以减少决策者的偏见，并有利于选出最佳解决方案。	问题、选项、标准	可根据一组标准来评估选项
标准	可选	为涉及多个角色的主要问题设计标准（例如，非功能性需求或业务目标）。	所有	按照参数，可用标准来评估选项
参数	可选	参数必须从各个利益相关者的角度出发或针对一组标准来代表选项的利弊。在后一种情况下，每个选项都可以通过评级进行评估，例如，--、-、o、+或++。	所有	参数可被用来评估给定标准的选项
结果	可选	用结果来表示一个选项的影响	决策的表示语言	一个结果记录一个选项的影响，例如：选项的风险
决策	必选	一个已完成的问题必须有一个合理的决策。对于复杂的决策，这个选择是按照什么依据做出的必须清楚明了。	所有	一个决策解决一个问题，基于选项的子集

       为了更清晰的说明灵活元模型（和需求基本原理指南）如何让使用，我们给出一个具有四个用例的ATM系统作为示例：分别是查看余额、提取现金、以及新用例存入现金和将现金转入预付银行卡。具体流程如下图：

 

 

       这是银行为了响应客户需求而创建的。我们按照元模型六个概念从上到下的顺序来推导。因为创建了新用例，所以此时我们的好朋友——需求工程师jenny就会对应该用例提出问题——如何定义现金转移到预付信用卡？jenny提出问题之后，按照元模型概念，给出三个候选项来应对提出的问题，分别为：“为内部和外部客户转移”、“仅为内部客户转移”和“支持收取额外费用”。从业者将从这三个选项中进行选择，jenny对选项引出了参数，“支持收取额外费用”会增加对第三方系统的依赖，而“为内部和外部客户转移”这个选项还会增加开发的费用，这是因为该选项不仅包含本银行的业务还要联合其他银行一起开展业务。接下来，jenny引入了两个标准：银行监管条例和客户满意度，并能看到分别对应的评级（加一点对评级的描述）。根据推理我们得到该问题的结果：需要其他银行会计系统的接口以便联合其业务。好朋友jenny将该推导整合成一个原理矩阵中横为对应的标准和参数，纵列为提供的三个不同的选项，根据刚才的对应的评级填入矩阵中，我们的新朋友kim将会审查该矩阵并做出决策“为所有用户提供转账服务但是要对外部用户收取额外费用”，jenny根据kim的决策创建行动项目并得到了两个新的从属用例：“与其他银行会计系统接口”和“向预付信用卡转账费用。

       该元模型将需求与原理分开，更能方便得到原理概念之间的关键可追溯性。例如问题和利益相关者的可追溯性、问题和系统-模型元素的可追溯性、问题和问题的可追溯性等，此时更能方便捕获需求原理并减小工作量。

 

三、原理问题列表LoRQ

       LoRQ根据上面的原理概念对问题进行分组，然后在不同问题之间进行引导。例如，前六个问题引出了在指定问题时考虑的信息。在“Leads to this concept”列中有一个条目的问题可以帮助LoRQ用户从这些问题导航到下一个概念。例如，“选项是什么？”帮助用户从问题转到选项。同样，“这个选项的预期后果是什么？”引导用户从选项到结果。此外，通过在“可追溯性链接到”列中用条目回答问题，用户可以识别可追溯性关系。

       LoRQ还帮助需求工程师实施指南“捕获与需求分离的理由，并具有可追溯性”。“可追溯性链接”栏中的条目问题要求提供可追溯性相关信息，以支持该指南的实现。例如，通过回答“是什么引发了这个问题？”和“谁负责？”问题“如何定义预付费信用卡的现金转账”，Jenny确定了引发这个问题的要求和负责任的利益相关者。

       LoRQ让利益相关者获得高质量的理由，这鼓励了他们的重用；也就是说，LoRQ对“遵循基本原理重用模式”这个指南产生了积极影响。正如我们之前所概述的，利益相关者也可以使用LoRQ来审查原理，这支持指南“保持原理的重用质量”。例如，Jenny在她的审查模板中包含问题，以确定原理中的差距。

 

四、DOORS

       接下来我们来介绍面向动态对象的需求管理系统DOORS，DOORS提供了通用的概念来支持任意的元模型元素，他可以让需求条目文档化展现，在向DOORS中导入一个需求文档建立元模型，并对模型进行命名（命名一般是文档名称）、描述、加前缀等操作后，DOORS的解析器根据文档的编号段落等对内容进行分类并条目化。

       通过将需求文档链接到统一的存储中心，平滑地将文档与数据库的优点统一起来，从而达到基于数据库的需求信息统一管理的目的。DOORS提供了现成的标准属性和属性值，如优先级、难度和状态等，同时可以帮组团队轻松自定义，以支持团队的需求处理过程和术语，当需求变更时，所做的每一个修改都会被捕获跟踪并全部存档于DOORS中。需求审核跟踪将把谁，什么，为什么和什么时候修改的需求进行存档，帮助需求管理团队分析它对整个项目的影响，并对不同操作过后的条目进行标记，比如：红色代表尚未保存到更改，黄色表示更改已经保存到数据库，蓝色以为这自导入后从来没有变更过的内容。

       DOORS还提供了有效的团队欧通，通过集合变更管理工具，优化团队围绕需求的沟通和协作，开发人员在修改程序代码时会自动弹出ClearQuest的变更请求窗口，并强制开发人员将此次修改与特定的变更请求相关联，这样一来，开发人员在程序代码提交时可以清楚的知道哪些修改过的程序代码是对应哪些任务的，整合人员可以准确的了解到某次建立到底整合进来哪些变更请求，项目经理可以轻松的定位变更请求和哪些改动相关。

       除此以外，DOORS还设置用户权限保证安全性、自动记录需求来源保证可追溯性、提供改动次数的波形图来预测风险保证需求的稳定性、提供邀请客户加入项目的需求这一可协作性等等，是一个功能强大、符合需求原理管理指南的软件。

       以上就是我们小组对该论文的解读。