19阅读报告 towards reference models fo.docx
《19阅读报告 towards reference models fo.docx》由会员分享，可在线阅读，更多相关《19阅读报告 towards reference models fo.docx（18页珍藏版）》请在冰点文库上搜索。
19阅读报告towardsreferencemodelsfo
P2的第2.1节，P9的第3节，P10的第4节，P12的第5.1节，P18的第6.1节，P24的第7节，P34的第8节。
TowardReferenceModelsforRequirementsTraceability
2.1背景：
定义和追溯的使用
需求追溯性在文献中已经被识别作为一个重要的因素——一个典型特征是系统应该控制和包含作为一个非功能的需求【19】。
很多标准支配了系统的开发为US政府和MIL-STD-489代替它要求需求追溯性文档的开发。
Edwards和Howell定义了追溯性作为一种用来提供需求，设计，系统最后实施的关系的技术。
Palmer[22]陈述了追溯性提供了在理解软件需求，设计，和实施内部的关系的必要帮助。
这些关系允许设计者展示设计满足需求和帮助更早的识别那些设计出不满足的需求。
Palmer陈述了追溯性帮助确定系统开发产品如何和为什么满足项目关系人的需求（stakeholderrequirements）。
HamiltonandBeeby[23]把追溯性看作是发现系统每一个特性的能力。
GreenspanandMcGowan[24]陈述了允许任何人工需求，规格说明，实施改变的能力来在真个系统中被追溯是任何系统描述技巧的一个重要性质。
简而言之，追溯性是系统的一个典型特征，在其中需求被清楚地链接到它们的资源和基于这些需求的系统开发周期中产生的人工需求。
很多不同的项目关系人，工程赞助商，工程管理者，分析者，设计者，维护者和使用者涉及到系统开发生命周期中。
追溯性需要这些项目相关者不同根据他们的目的，优先权和起源于利益的追溯问题。
Stehle[26]从管理系统开发工作的透视中识别了一些标准。
追溯性帮助论证了每一个需求都被满足了。
而且，它帮助保证每一个系统组成部分满足一个需求避开了ªgold-platingº[27]。
在需求工程中，一个主要的挑战是链接基本原理和资源到需求中。
追溯性有助于涉及到工程中来减少问题的需求的交流。
需求管理能够被促进通过不活必要的信息来理解需求演变和确认[28]。
再设计过程中，追溯性允许设计者和维护者来追溯在系统被重新设计之前变化需求被实施会发生什么【21】。
追溯性是有帮助的如果它能够链接设计者和辩护者（justifications），重要决定和它们之后的决定，和设计解决方案达到的内容。
系统进化要求对需求的更好理解，这只能通过追溯资源来达到【29】。
追溯性提供了能力来在规格说明书和设计说明书项目的相互参照项目【30】。
因此，伴随着完全的追溯，更准确的话费和变化的时间表能够被决定，而不是依赖于工程师或者程序员来了解这些变化引起的所有区域。
最后，相当重要部分是，测试过程，如果追溯需求或者设计，能够被改进当错误被发现【31】。
3.ASIMPLEMETAMODELOFREQUIREMENTSTRACEABILITY需求追溯的一个简单模型
在下面的三节，我们展示我们研究产生的参考模型。
我们假设追溯参考模型将会被实施在一些追溯仓库中（手工的或者电脑化的）。
很广泛的被接受这样的仓库至少包含三个层：
●变化模型定义追溯模型能够被定义的语言。
●一系列的参考追溯模型在被变化模型定义的范围内能够被自定义。
●实际追溯的一个分布式的数据库，在选择的模型下被记录。
我们采用我们表示节点元的规则（convention）通过小的大胆组合平台软件和他们的实例通过不大胆的小的组合平台软件（caps）。
相似的，链接元被表示通过大胆的粗斜体，通过标准斜体的特别链接类型。
实践者和第一阶段的主要研究中的讨论小组证实了追溯性的最重要方面能够在最简单的元模型中被捕获。
图一中，提供了更细节的分类和描述追溯模型的基本语言实体。
在元模型中的每一个实体和链接能够被专门化和实例化来创造组织或者工程特别追溯性模型。
元模型能够被用来表示下面的追溯信息大小（表四展示）：
●什么信息被表示—包括显著属性或者信息特点吗？
在模型中，objects代表系统开发过程的输入和输出。
各种类型的objects中的例子包括REQUIREMENTS,ASSUMPTIONS,DESIGNS,SYSTEMCOMPONENTS,DECISIONSRATIONALE,ALTERNATIVES,CRITICALSUCCESSFACTORS等等。
这些表示了在不同生命周期阶段追溯性被维护的主要概念元素。
Objects被不同的组织化任务创造。
任务的例子包括系统分析和设计活动。
这些信息能够被表示作为objects的一个分支。
在不同objects之间的追溯性被traces-to链接表示，例如，两个对象之间的depends-on链接能够被表示作为一个trace-to链接的特殊化。
●谁是项目关系者，他们在创造，维护和各种objects的使用和追溯链接中扮演不同的角色？
这模型中，项目关系人代表了在项目开发和维护生命周期或动中涉及到的代理商。
项目关系人的例子包括工程管理者，系统分析员，设计者等等。
这些项目关系人有不同的角色或者能力在实施和使用不同概念的objects和追溯链接的时候。
●哪里被表示——在文档追溯信息的资源中？
所有的objects都被sources文档化，这可能是无力的媒体例如文档或者无形的东西例如参考人或者没有文档化的规则或者程序。
Source的例子包括REQUIREMENTSPECIFICATIONDOCUMENTS,MEETINGMINUTES,DESIGNDOCUMENTS,MEMORANDA,TELEPHONECALLS和参考不同的项目关系人使用它们的电话号码，邮件地址等等。
项目参与者管理资源。
●这些信息是如何被表示的——通过正式和非正式的方式和它如何和其他的追溯性组成部分相关系？
这些资源，正如上面提到的能够使物理的或者非物理的。
而且他们能够在不同程度下被表示。
一些资源例如需求规格说明可能被表示用不同的格式，例如表盒或者文本。
●为什么某一个概念的objects被创造，修改，进化。
在创造，修改，进化不同概念的objects之后的基本原理能够被表示作为元objects的一个规格说明。
然后，它能够被链接到概念实体中。
更加复杂的基本原理模型，包括事件，可选条件，参数支持和反对也能够被表示作为我们模型中OBJECT-TRACES-TO-OBJECT关系的规格说明。
●何时信息被捕获，修改和进化？
在我们的模型中关于任何实体或者链接的相关临时信息能够被表示作为分支。
例如，频率或者时间/持续，在其中需求或者设计被创造，评估，修改或者证明被某个基本原理能够被表示在这个图表中。
元模型的三个节点粗略的对应Pohl[15]中提出的需求工程的三个维度，在其中他们发现理解目标，同意项目关系人和物理表示的几个方面。
然而，注意到他们没有讨论需求过程本身，而是创造和追溯的使用。
4.追溯性的低端使用
典型的低端用户的追溯性工作模型是在表二中提供。
目标的名字和这里表示的链接是我们的实际中什么被观察的解释。
很多组织仅仅使用追溯性表来链接信息的各个部分没有明确的识别这样关系的语义。
低端用户建立追溯性链接来模拟需求依赖，需求分配到系统组成部分，符合性验证和改变控制。
接下来，回忆起我们用小型大写字母斜体（italicsmall-caps）表示追溯性链接，它们连接的组成部分表示大写字母。
模型中的每一个链接相反的部分能够被定义。
典型的低端用户把需求追溯性看作是从斜体需求到真实的系统组成部分提供的一个链接来满足那些需求。
然而，首先，高级别的需求必须被分为一个更精细的级别。
在这个递归过程中，低级别的需求被从高级别系统需求中导出。
典型的，这个信息被捕获在一个相关的数据库中，和以追溯性矩阵的形式被使用。
原始的和导出的需求被分配给系统组成部分。
一个分配表是普遍的机制被使用来维护信息。
这简化了需求之间的双向绘图，同时系统组成部分通常被用来保证在系统中有组成部分来满足所有的需求。
通过捕获哪个组成部分满足各个需求和哪个需求被映射到不同的组成部分中，设计者能够核实所有需求都被系统编址。
在系统开发的符合性验证阶段，低端用户使用需求数据库，它包含系统验证过的最当前版本，来开发系统CVPS，例如测试或者模拟。
为每个需求开发的CVPS通常被维护在REQUIREMENTS-and-TESTS追溯性映射中。
如果在需求中改变应该发生，然后追溯链接能够识别必须修改或者重新开发的CVPS。
CVPS是预先形成的在系统组成部分中来验证组成部分满足需求。
测试的结果被用来验证系统工作和它满足所有的需求。
一个系统组成部分可能依赖其他部分也可能和外部系统相接触。
这个信息被用来评估需求是如何通过系统组成部分被满足的。
尤其在捕获基本原理中低端用户是缺乏的。
在需求管理中，例如，涉及信息的需求事件，他们如何解决的，和决定的基本原理是很少被捕获的。
同样的，相似信息在设计和实施阶段是缺少的。
5.1需求管理子模型
追溯性，当被正确的实施了，可能很大的对需求管理，促进需求理解，捕获，追踪和核实有益。
接下来是图三中需求管理模型的讨论
系统被建立主要是满足组织需要。
这些需要可能是长期的数据需要或者及时的可选择需要，正如IS-A映射表示的。
这两个需要互相支持，同时被细节的描述预期使用或者系统目的在SCENARIOSDESCRIBING中。
系统尽量满足的目的，SYSTEMOBJECTIVES，必须被验证或者被组织。
项目关系人，例如顾客，程序管理者，程序赞助商等等指定了SYSTEMOBJECTIVES。
由于复杂系统和大量的需求关联到,决定那些对工程成功的重要因素和管理需求基于他们如何作用于这些因素是非常重要的。
项目关系人涉及到识别ORGANIZATIONALNEEDS也识别（IDENTIFY）这些重要的成功因素（CRITICALSUCCESSFACTORS（CSF））。
像Cost,Time,Weight,Voltage这类型资源是CSFS的例子。
系统的资源被这些CSFS管理。
例如需求的任务限定（criticality）能够被用来分类和监测需求。
相似的，CSFS例如重量在航天系统或者开发的总成本中能够被用来跟踪和监测需求。
作为项目关系人之间的谈判的一部分，很多权衡被作出来决定系统依赖于对CSFS的影响的范围和功能。
这样的决定决定了是否首先是别的需求是可行的，花费成本的或者令人满意的。
在重要性和危机长度长不是所有的需求都是平等的，需求能够被追诉在整个生命周期中在不同级别的粒度或者细节方面为了最优化资源分配。
可能是不惜要的或者不令人满意的，考虑到在维护追溯性时的日常管理费（overhead），为了维护每一个需求之间和每一个在系统设计过程中的输出之间的链接。
CSFS可能被用来决定何时是必要的来追溯需求在细节方面和何时精细的追溯是没那么重要的。
需求可以被追诉在整个生命周期中来提供项目关系人了解和评估系统是否支持这些CSFS。
而且，需求也能够基于STANDARDS,POLICIES,和PROCEDURES。
维护需求，资源之间的链接和需求将会帮助理解和正确的解释他们。
CONSTRAINTS可能被作为需求的一个类型被追溯。
几个焦点小组陈述了约束怎样变为硬需求因为它们设置限制和系统在这些限制之下被开发。
5.1.1演变
在管理大的，复杂的系统的最大挑战是由于需求是不断地演变和改变的。
每一个焦点小组注意到，为了准确的反映这个变化，需求追溯项目应该帮助文本和理解需求的演变。
变化的两个主要来源是：
1.需要固定系统的不足，期间做识别，用组织需求的方式表示操作或者测试。
不同的项目参与人修改SYSTEMOBJECTIVES基于改变的ORGANIZATIONALNEEDS。
在有很长生命周期的项目中，例如军事应用，不仅系统需求的本质需要是动态的，而且甚至ORGANIZATIONALNEEDS（missionandoperational）和SYSTEM
OBJECTIVES也是一直在演变中的。
然而，是不可能放弃所有的调查在这样的系统中和开发新的系统来满足现在的需求。
缺少全面的追溯是不能够识别链接到不同的目标和修改它们来满足现在需求的组成部分的主要原因。
追溯性链接是在需求之间需要来在不同级别的细节方面得到特别说明，因为它们涉及到开发生命周期的不同阶段。
我们模型中的需求之间的递归链接证明是有用的在提供需求的历史记录，演变过程，和需求到它的资源的绘图，从而促进需求来自哪里的完全理解。
5.1.2导出的需求
低级别的需求是从高级别的需求中导出的，通常这是基于项目关系人的假设得到的。
导出需求需要被认真的追溯因为它们很可能是主要的冲突的重大事件的来源，同时从属于假设的改变在他们之后通常是没记录的。
需求从细节中导出。
追溯性帮助清楚地识别导出需求。
而且，这种追溯信息是有用的在管理需求数量的突增方面。
一些需求是被其他需求合成的（ELABORATED），为以后的解释或者说明提供条件。
这增加了细节的理解需求之后的假设和它们是如何被解释的。
需求也依赖于其他的需求。
例如，使用某个软件平台的需求可能依赖于使用某个硬件平台的需求。
识别这些需求是重要的，尤其当需求改变的时候，以便改变对整个系统的影响能够被确定。
复杂需求通常被分解为它们的组成部分，识别简单的需求来形成部分的复杂需求。
这些链接帮助理解不同部分的需求如何组装在一起和对于需求可能包含几个相互依赖部分的大的，复杂的系统是尤其重要的。
需求之间的IS-A链接表明的父，子的分层关系。
IS-A分层关系能够被用来表示需求说明之间的关系，需求说明是为了整个被使用的硬件和为某个类型的硬件组成部分的硬件。
6.1需求管理
追溯性计划用于需求管理采用了高端需求管理模型和在SLATE中北实施，在表七中展示了。
尤其，他表示了需求，命令需要，系统目的，关键的成功因素之间的链接。
它也包括基本模型的组成部分来表示需求之后的基本原理。
命令需要。
根据这个追溯模型，系统开发活动的第一步是确定命令需要来证明系统目的。
命令需要在一个叫做命令需要陈述的文档中被提供。
这个文档，部分在表八中展示，属于slate数据库中活动的文档。
MNS文档包含了“大图”需求为了SurfaceCombatantship，是ECS的主题。
它提供了命令，功能，设计和结构限制，人为限制的基本的指引。
它也提供了一些操作限制。
每一个命令在MNS中需要被识别的是在SLATE中表示了作为一个限制块。
例如，图九中，展示了命令需要被限制块7所表示，它也被定义作为一个定义对象。
相反的，第五行识别了一个顺从对象，也就是系统视图。
这事实上代表了系统对象。
相关部分的系统对象的追溯和陈述在MNS中展示在了表7中使用的是JUSTIFIES链接。
工程赞助商涉及到系统对象的定义，它们建立这些链接来说明基于它们和更高级别命令需要的关系来说明每一个对象。
例如，提供ªbackwardtraceabilityº给需求的起源。
在讨论系统不同功能的基本原理时，追溯性将是有价值的。
例如，系统分析员能够使用这些信息来首先得到顾客需要系统做的和为什么做的bigpicture。
需求识别。
开发系统的第二步是需求识别。
正如在表7中展示的，需求是从系统对象中产生的。
ECS的原始需求文件包含了被维护作为一个活动的文件在SLATE中的被动需求。
SLATE实用工具被叫做需求识别部分文档为了识别满足用户定义标准的为了使用关键词识别需求的识别陈述。
在我们的案例分析中，按照工程标准，包含“shall”的句子被作为不同的需求被识别。
分析文档后来变成了需求对象。
在SLATE术语中，这些REQUIREMENTSOBJECTS依从（COMPLYwith）SYSTEMOBJECTIVES。
需求基本原理。
图11描述了关于特别需求3-3的信息。
它识别了宽带品质因素（figureofmerit）用几何平均数表示频率在无线电频率宽带对一些级别的目标中。
需求3-3有到资源文件段的链接，从这里面它被定义。
资源段被识别作为一个定义对象。
在SLATE中，RATIONAL能以节点的方式能够被附加到需求中。
用户定义NOTE类型叫做RATIONALE被使用为了这个目的。
在我们的例子中，需求3-3被RATIONAL节点支持。
这个RATIONAL定位了需要来达成足够宽监测范围对很可能潜在的威胁的品质因素（FigureofMerit（FOM））。
需求3-3也也连接到来自生成它的系统对象的表中。
7.支持追溯链接
总结低端和高端用户追溯性的不同点，我们观察到后者大部分以两个扩展为特点：
●它们使用更丰富类型的系统为了产品相关的对象和链接种类，因此授权更容易的检索和更精确的推理对于追溯。
●它们更强调过程相关的分类，确实，长期案例学习作为作为工作的部分被执行（conducted）。
从低端到高端追溯的步骤被SEI成熟度的强烈增加跟随。
大数量的不同连接类型阻止了单独的个别对待。
然而，正如在7.1段表示的，我们可以分组在参考模型中发现的连接类型到一个新的基本分类中。
我们然后返回到经验研究为了识别为每一个类基本的工具支持，和指出在商业或者强调这个议题的研究文学的建议书。
相反地，这个讨论也能够提供一个解决方案计划书分类为了追溯性工具服务。
7.1追溯性链接的基本分类
正式的说，追溯性系统能够被定义作为一个语义网络在其中节点代表对象，在这些对象之间追溯性被通过不同类型和强度的链接来实施。
最简单的追溯性工具是完全的相关的同时没有系统的区分不同的节点和连接类型。
其它的，例如RDD-100，使用基本的实体关系结构来区分节点和链接和允许用户不同类型节点和链接之间引入区分。
然而，这回避了（begsthequestion）哪个节点和连接类型应该被定义的问题。
在软件信息系统的文献中，很大数量的连接类型被提出，它们的很多也对于和、追溯性很重要。
基本的组织和抽象机构，追溯性的独立在【39】中细节介绍。
在本质（NATURE）项目中，综合的文学研究包含18个不同类别的依赖在追溯性文本中【11】。
他们被分组为五个群叫做：
condition,contents,documentation,evolutionary，abstractions。
作为分类我们经验观察的出发点，我们采用简单的具有四个类型追溯性链接的系统，在表17中展示。
第一组的追溯性链接和结构能够被叫做related因为他们描述设计对象不依赖于它们如何被建立的本质和关系。
在表17中，高级别的对象定义一些类型的限制或者应该被低级别的对象满足的目的。
满足通常是一个必须被符合性验证证实的要求。
分享的约束或者目标被满足也意味着低级别的对象的依赖。
概括的和聚合的抽象是特别类型的依赖。
因此我们有两种类型的产品相关的追溯性链接，满足链接和依赖链接。
低端追溯性使用者倾向于以基本上依赖于这两个连接类型为特征。
第二组的追溯性链接叫做processrelated因为它只能被查看过程中动作的历史捕获不能够从单独的产品关系中恢复。
如果我们用这四种追溯性链接类型加强表1的追溯性元模型我们可以得到元贝型（onion-shell）的追溯性元模型，像表18中展示的。
反映了我们的经验研究，低端追溯用户使用的模型倾向于集中在模型内部核心，更高级用户倾向于过程相关议题和更加明确资源和项目关系人管理的冒险方面。
作为这些观察的证据，表6总结了高端模型的连接类型根据它们是如何和在哪里被使用的和它们属于的连接类型。
7.2实施追溯性连接类型的议题/争论点
除了不同连接类型的分类我们研究的另一个目的就是识别在实施捕获和是用石头工程实践时的争论。
对于我们讨论的四种类型的链接，我们首先提出我们的经验研究参与者提出的问题然后讨论文献中提出的解决方案。
综合结果是本地的解决方法存在为了所有的识别问题，然而，如何形成如此单独的解决方法来可使用和更加功能强大的追溯工具比起现在在市场上的问题依然是开放的。
7.2.1满足链接
集中讨论组提出了三个组要的关于支持满足链接的问题：
●导出链接。
需求追溯的一个重要使用就是保证系统满足最新的使用需求设置。
表示这些信息被认为是关键的在工程管理方面。
这通常通过建立需求集合和满足他们的系统组成部分集合之间的连接来实现。
这些链接也可能被直接的导出。
研究参与者的一个重要考虑是缺少在很多连接自动识别方面的支持。
●多资源支持。
当一系列的需求可能被一些列的组成部分满足时，需求的状态可以被确定基于是否相关的系统组成部分集合满足目的。
大部分的工具没有提供一种方法来表示可选方法可能存在来满足需求这个事实。
目的树是一个为了回答关于如何墓地被实现和为什么他们被尝试的一个很好表示【42】。
在系统工程的情况下，目的能够符合需要被满足的需求，需要解决热点问题，复杂的决定需要被作出。
我们模型中的每一个对象能够被一个目的树表示。
目的树的节点有两种类型：
OR节点表示选择。
AND节点表示同时的子目的必须有兼容的解决方法。
●满足度。
在系统开发过程中，工程管理想要确定他们能够不大程度的满足需求。
在复杂系统中不能够完全的满足。
通常，设计者感兴趣最大化需求被满足的度。
所有三个问题——导出链接，多支持和满足度，能够以结合的方式出现。
当一个需求被一系列的组成部分满足的时候，为了满足组合这些证据的机制必须被开发。
例如，如果所有的证据在一个方向上（正面的），需求被满足的度可能被当做它得到的最小支持。
在需求得到正面和负面支持在不同度情况下出现了严重的问题。
除了在理论计算机科学方面的研究和在操作研究方面，识别不同类型的倾向于追踪的依赖关系的方案已经在文献中提出。
这个方案能够被适应和扩展来管理下面的依赖关系：
●需求之间的依赖链接常常是目的依赖。
例如,软件需求可能可能依赖某个硬件的需求.当两个这样需求之间的目的依赖存在的时候,推理过程监测是否依赖需求被满足时必要的。
●普遍依赖于任务建立的对象之间的依赖叫做建立任务依赖。
设计对象常常有任务依赖。
这里，相对应的手工操作必须实施来更随某个方法。
如如果对象是用任何其他的过程产生的两个组成部分之间的相对应关系可能不会是期待的。
当两个对象之间任务依赖存在的时候，监测任务程序使用某个程序是必要的。
●资源依赖可能实际到物力资源或者信息方面的资源。
导航系统控制可能是资源依赖与雷达输入。
当这样的依赖存在的时候，数量，质量，依赖频率和传送资源的接口必须被识别。
当资源依赖存在的时候，监测依赖提供按照某个频率提供期望的数量和质量的资源是必要的。
识别谁负责资源和资源传送以来的情况是必要的。
●临时的依赖在行动关系到某个临时顺序做的对象的时候存在。
临时顺序可以被指定通过之前，之后，期间或者同时发生的操作。
依赖的强度。
和维护依赖信息相关的另外一个问题是所有的依赖被同等重要的看待。
我们的研究识别了没有能力精确地识别依赖链接的强度是使用这种追溯性信息的一个重要问题。
HauserandClausing[46]提出了一个方案为了分配定性的和定量的链接权重。
YuandMylopolous[7]在非功能需求框架中使用这种方案。
基于这个，对依赖重要的度是对涉及到依赖链接重要的。
这是衡量一个对象对另一个有多大的影响。
它可以定性的和定量的进行测量。
以来的强度将也会很大的影响推理过程类型和监视必要性来保证加强各种类型的依赖。
依赖的网络例如这张讨论的能够在不同程度被定义。
最基本水平，链接仅仅识别两个对象之间以来的存在。
作为包含在文中的唯一信息（Astheonlyinformationcontainedinsucharepresentation）是一个对象和另外一个对象有关系，潜在的自动化推理是有限制的，甚至依赖的类型是识别出的。
管理基本原理的大部分工具，例如gIBIS[48]和SYBYL[49]
升级会员 