通过RUP用例进行需求管理的可跟踪性分析资料.docx
- 文档编号:6522936
- 上传时间:2023-01-07
- 格式:DOCX
- 页数:24
- 大小:108.10KB
通过RUP用例进行需求管理的可跟踪性分析资料.docx
《通过RUP用例进行需求管理的可跟踪性分析资料.docx》由会员分享,可在线阅读,更多相关《通过RUP用例进行需求管理的可跟踪性分析资料.docx(24页珍藏版)》请在冰豆网上搜索。
通过RUP用例进行需求管理的可跟踪性分析资料
4.1图解符号
可追踪性类型及其可追踪性关系显示为统一建模语言(UML图表。
下图说明了如何解析在此
环境中UML的使用。
为了充分理解该图,在实施RequisitePro中的定义时了解所用的实施映射是有用的。
下表解释了图解符号如何映射到RequisitePro项目上。
图解符号RequisitePro映射
类/可追踪性类型需求类型
关系RequisitePro“追踪到”关系聚合关系分层需求
泛化关系
通过添加一个附加的“子分类”属性,对需求超类型进行的分类
注意:
RequisitePro允许将任何可追踪性项都追踪到任意其他项。
可追踪性策略定义的是有意义的可追踪性链接,这些链接将成为项目需求管理策略的核心。
4.2支持的可追踪性类型4.2.1说明
在本节中,我们定义了一个支持性可追踪性类型集,它可用于支持所选的任意可追踪性策略。
4.2.1概述
注意:
这些支持的可追踪性类型可追踪至所选可追踪性策略包含的任何其他可追踪性类型。
4.2.3可追踪性类型可追踪性类型说明
词汇表术语
这一可追踪性类型定义代表词汇表术语及其定义的可追踪性项。
它包含在支持的可追踪性类型集中,因为不管选择采用哪个可追踪性策略,词汇表都是必需的。
问题
这一可追踪性类型允许添加代表在RequisitePro内需跟踪的问题的可追踪性项。
随后这些问题与受其影响的可追踪性项联系起来。
追踪与词汇表术语有关的问题就是使用问题可追踪性类型的一个示例。
如
果定义未确定,或者定义有争议,问题就会出现,并包含在RequisitePro
中。
这就确保了问题不会被遗忘,并允许建立一个视图,报告所有与未解决的问题有关的词汇表项。
另一个使用这个可追踪性类型的典型示例就是,在复审用例和其他开发工件时跟踪出现的问题。
假设
这一可追踪性类型允许跟踪所作的假设。
随后这些假设可与受其影响的任意可追踪性项联系起来。
支持文档
这一可追踪性类型允许向可追踪性分层结构添加任何需要的文档。
这在将那些预先存在的、用于澄清另一个可追踪性项的意义或目的的示例或文档
包含在该类型时特别有用。
RequisitePro灵活的可追踪性机制允许将支持文档与任何类型的任何可追踪性项关联关系起来。
使用支持文档类型的一个示例就是,将详细的EDI消息规约作为词汇表的支持信息,或者作为使用消息的用例附录包含进来。
4.2.4基本可追踪性可追踪性链接
说明
词汇表术语到词汇表术语此关系允许我们使用单个可追踪性类型同时捕获词汇表术语及其定义。
支持性可追踪性类型到其他任何可追踪性类型这些支持的可追踪性类型可追踪至所选可追踪性策略包含的任何其他可追踪性类型。
4.3无用例模型4.3.1说明
在这种情况下不存在用例模型。
需要产生了产品特性,而产品特性依次产生了记录在正式软件需求规约里的软件需求。
“我不能没有讨厌的用例模型!
”项目经理们的话一语中的。
4.3.2特征特征值
注释
明确的可追踪性高
实施需求管理技术但不使用用例的项目往往在可追踪性类型之间维持着高级的显式可追踪性。
信任低可说明性高正式性高
完整性低很难评估传统软件需求集的完整性。
文档集
大
衡量文档集通常用英尺而不是英寸。
重点合同
需求捕获流程的重点在于,在客户和开发员之间建立一个在法律上可强制实施的合同,而不是对有待解决的问题和所提出的解决方案取得一致理解。
可理解性
低用户群体和开发人员通常无法访问需求文档。
需求文档由许多单独的线
项组成,线项按类型或者功能范围进行分组,给复审人员的环境提示很少。
流程典型瀑布式
传统需求获取技术常常作为瀑布式开发流程的一部分实施。
由于缺乏环
境以及评估需求的任何子集的完整性存在困难,这都不利于采用迭代式和递增式的开发流程。
开发风格
功能分解在将需求转变为解决方案时,需求按类型或功能范围分组常常导致连续的功能分解。
4.3.3可追踪性概述
4.3.4可追踪性类型需求类型说明
需要为了证明购买或使用的合理性而必须解决的业务或运作问题(机会)。
也称之为目标或目的。
产品特性直接满足某一需要的系统功能或特征。
通常理解为系统的“公开优点”。
软件需求
正在构建的软件必须符合的条件或具备的功能。
4.3.5可追踪性摘要可追踪性链接说明
需要追踪至产品特性每一种需要由一个特性集实现。
这种关系允许追踪每个特性的业务利益。
产品特性追踪至软件需求
每个特性由一个软件需求集实现。
这种关系允许追踪每个软件需求的业务利益,并在产品特性级别进行软件需求规模管理。
4.3.6优点和缺点正面:
-容易理解
-对法定合同有好处(请看许多与已交付软件满足/无法满足指定需求有关的法庭案例)。
-是许多标准流程所推荐的。
-允许有详细的、低级别的正式可追踪性。
-不会由于引进“惊世骇俗”的新思想而扰乱了现状。
反面:
-难以完成需求捕获-非常容易停滞在需求阶段。
-难以理解以这种形式表达的需求。
-难以评估需求变更所带来的影响。
-单个需求没有相关环境。
-维护成本高。
由于缺乏隐含的可追踪性,项目必须承担维护大量显式可追踪性关系的高成本。
-由于缺乏相关环境,确定有意义的需求子集难免存在困难。
这又使得规模管理以及产品的递增式交付更加难以进行。
4.3.7示例
需求可追踪性的无用例模型方案广泛应用在许多业务领域的诸多项目中。
很多组织都要求有一个正式的传统软件需求规约作为正式合同谈判的基础。
这就导致他们认为传统的需求管理方案是适用于项目的唯一方案。
4.4唯用例模型4.4.1说明
“用例模型是我的需求。
”客户和开发人员之间的紧密联系和高度信任通常是采用这种方案的项目的特点。
该方案一般用于内部可说明性低的项目。
在这些项目中,开发人员希望通过与客户一起开发用例模型(或经用户批准进行开发),展示或取得对需求的清晰理解。
在这种情况下,用例模型是系统需求的唯一声明。
用例模型、词汇表和补充规约形成了系统需求的完整声明。
4.4.2特征特征值
注释
明确的可追踪性低不要求有明确的可追踪性。
用例驱动方案所提供的隐含可追踪性就足够了。
可能不维护显式可追踪性,因此不使用需求管理工具。
信任高缺乏任何需要或特性级别的分析意味着涉众给予用例模型的开发者高度信任,相信他们能交付正确的系统。
可说明性
低正式性低
完整性低尽管用例模型本身有利于建立软件需求规约的完整性,但缺乏到涉众需要的可追踪性通常导致生产出来的系统不完整或者过于精细。
文档集小该方案包含最小的文档集。
重点用户用例模型表达用户观点。
可理解性高
用例模型容易为项目中的所有涉众所理解。
流程
典型的迭代式和递增式
用例把软件需求放在有利于迭代式和递增式开发的环境中(用例提供一个优秀的交付单元)。
用例还可以与瀑布式开发流程一起使用。
开发风格
典型的面向对象
尽管用例可以使用任何开发风格,但通常用于驱动面向对象的软件开发。
如果不采用面向对象的模式,则要求具有高级别的显式可追踪性。
4.4.3可追踪性概述
4.4.4可追踪性类型可追踪性类型说明
用例
此可追踪性类型定义代表用例的可追踪性项。
用例段
利用此用例段能够将用例段包含在可追踪性分层结构里。
它还允许我们追踪到单个流以及构成用例的其他属性。
子段分层关系的出现允许我们获取各个段的独立部分。
例如,它可以让我们确定组成前置条件段的前置条件。
注意:
在某些情况下,确定用例事件流内的单独软件需求是可以的(这种情况下段非常小),但除非用例本身已经稳定,否则不要进行这样的尝试。
主角
此可追踪性类型定义代表主角的可追踪性项。
4.4.5可追踪性摘要可追踪性链接说明
用例至用例段每个用例由一个用例段集组成。
这种关系允许我们追踪哪些用例段组成了
哪一个用例。
用例段至用例段
一些更为复杂的用例段包含许多子段。
例如,事件流可能包括许多子流,
而前置条件段则由许多前置条件组成。
用例至主角这种关系允许我们查看哪一个用例包含哪些主角。
主角至主角
这种关系允许我们使用单个可追踪性类型同时捕获主角及其简要说明。
4.4.6优点和缺点正面:
-文档集最小
-需求管理所涉及的工作量最小
-很好地支持规模管理、影响分析和递增式开发。
-用例易于理解。
反面:
-没有追溯回涉众需要的关系。
在开始制定解决方案之前没有实际尝试分析问题。
-许多人认为仅仅基于一个用例模型还难以接受合同。
-如果不进行任何需要分析,就很难知道用例模型本身何时描述了一个合适的解决方案。
在编写用例的时候,想象力容易失控。
-如果执行定期发布,在没有任何比用例本身级别高的信息的情况下,难以管理产品和持续管理涉众期望。
4.4.7示例
这种方案通常用于小规模的非正式内部项目。
在这些项目中,开发人员和用户的合作密切。
【大中小】【收藏到我的CSAI】【进入社区】
相关文章
·软件可靠性保证的新进展[3](2010-9-9·软件可靠性保证的新进展[2](2010-9-9·软件可靠性保证的新进展[1](2010-9-9·需求的管理[3](2010-9-1·需求的管理[2](2010-9-1·需求的管理[1](2010-9-1
·需求分析人员和用户的合作关系[2](2010-8-31·需求分析人员和用户的合作关系[1](2010-8-31·需求分析的原则[2](2010-8-31·需求分析的原则[1](2010-8-31
关于我们专家加盟工作机会希赛顾问版权所有©2001-2010湘ICP备05000276号错误报告联系我们
2010/10/31
通过RUP用例进行需求管理的可追踪…
可追踪性类型说明
需要其定义见“无用例模型”用例
其定义见“唯用例模型”
4.5.5可追踪性摘要可追踪性链接说明
需要至用例
在这种情况下,需要直接追踪到用例。
假设用例在产品和规模管理中可以
扮演产品特性的角色。
4.5.6优点和缺点
这种方案与“唯用例模型”策略很相似。
除了以下补充说明和警告之外,其余优点和缺点完全相同。
正面:
-在这种情况下,用例模型与涉众需要有关,这有助于评估用例模型的适用性。
反面:
-在项目的初期阶段,从表面上看用例定义了系统特性,但随着项目的成熟,两个概念将产生分歧。
-用例不是特性-一个从表面上看能节省时间和劳动的策略将很快成为无法维护的废物。
4.5.7示例
尽管据观察,在小型内部项目内有过使用这种可追踪性策略的尝试,但由于其升级性和长期的产品演进问题,我们不推荐使用。
如果用例模型准备用回溯至涉众需要的可追踪性加以完善的话,建议采用“特性驱动用例模型”策略。
4.6特性驱动用例模型4.6.1说明
“用例模型和补充规约形成了我的SRS。
”这是RUP拟定并推荐使用的策略。
需要和产品特性记录在前景文档中,并追踪至用例。
如果它们未在用例模型中反映出来,则将它们追踪至补充规约。
在这种情况下,用例模型作为软件需求的主要声明。
它通过补充规约加以完善,补充规约包含了用例本身不易表达的软件需求。
4.6.2特征特征值注释
明确的可追踪性中
除了用例模型的明确可追踪性之外,我们必须明确地维护需要、特性与用例模型之间的可追踪性。
信任中可说明性高
正式性中向用例模型添加需要和产品特性,将产生一个比仅仅维护用例模型更为正式的需求管理流程。
完整性高软件需求兼有特性和用例观点,这使得在获取和区分软件需求的优先级方面就有可能达到高度的完整性。
文档集
中现在我们有了一个包含需要和特性的前景文档,一个用例模型和一个补充规约。
重点
用户、涉众和项目经理向用例模型添加需要和特性,拓宽了需求活动的重点,使活动更积极地把产品经理及其他所有涉众和用户包含进来。
特性是一个管理涉众期望的强大工具,它对软件需求的用例观点作了很好的补充。
可理解性
高需要和特性的定义以及用例模型和补充规约,共同提供了一个容易为项目中所有涉众所理解的需求模型。
流程
典型的迭代式和递增式与唯用例模型相同。
开发风格
典型的
面向对象
与唯用例模型相同。
4.6.4可追踪性类型可追踪性类型说明
需要其定义见“无用例模型”产品特性其定义见“无用例模型”用例其定义见“唯用例模型”
软件需求适用于整个系统或不容易适合用例的任何软件需求。
其中软件需求是正在构建的软件必须符合的条件或具备的功能。
用例段其定义见“唯用例模型”
主角
其定义见“唯用例模型”
4.6.5可追踪性摘要可追踪性链接说明
需要至产品特性其定义见“无用例模型”
产品特性至用例可选的可追踪性链接。
产品特性可直接追踪至用例。
这一选项允许在编写用例段之前为用例分配产品特性,在产品特性级别对用例模型执行影响分析,反之亦然。
产品特性到用例段*产品特性追踪至用例段。
它允许在特性的基础上管理用例模型的规模,并有利于在比用例本身更合适的级别上进行特性集与用例模型之间的影响分析。
追踪至用例的所有产品特性还必须追踪至用例段之一。
产品特性到软件需求*产品特性还追踪至补充规约里的软件需求。
没有追踪至用例模型的所有产品特性必须追踪到补充规约中的至少一个软件需求。
用例至主角其定义见唯用例模型用例至用例段
其定义见唯用例模型。
*每个产品特性必须追踪到至少一个用例段或一个补充软件需求。
否则它将不包含在软件之中。
4.6.6优点和缺点
这种方案最大限度地利用了用例和传统需求管理方案所提供的好处,同时尽量减少它们的缺点。
正面:
-容易理解
-RationalUnifiedProcess推荐使用。
-允许有详细的低级别的正式可追踪性。
-软件需求持产品特性和用例的观点有利于完成需求获取-最大限度地减少停滞在需求获取和捕获活动的机会。
-软件需求以容易理解的形式表达。
-此可追踪性策略有利于需求变更的影响分析-可清楚理解未实现一个特性或用例段所造成的影响。
-单独的需求包含用例和(或)产品特性提供的环境。
这使得确定有意义的需求子集更加容易。
这又使得规模管理以及产品的递增式交付更加容易进行。
-完整的文档集最小。
-最大限度减少需求管理包含的工作量。
-该解决方案的缩放性很好。
如果执行定期发布,则在特性和用例级别上都能进行规模管理,从而允许所有涉众在任何他们认为合适的详细级别上追踪项目进展。
-在这种情况下,用例模型通过产品特性与涉众需要相关,这有助于涉众评估用例模型的适用性。
反面:
-并非所有组织都接受
-尽管许多组织已经成功地根据主要作为用例模型表达的软件需求编写合同,但还是有一些人认为很难完成。
4.6.7示例
这种方案适用于用例被接受作为一种表达大部分软件需求的恰当形式的所有项目。
【大中小】【收藏到我的CSAI】【进入社区】
相关文章
·软件可靠性保证的新进展[3](2010-9-9·软件可靠性保证的新进展[2](2010-9-9·软件可靠性保证的新进展[1](2010-9-9·需求的管理[3](2010-9-1·需求的管理[2](2010-9-1·需求的管理[1](2010-9-1
·需求分析人员和用户的合作关系[2](2010-8-31·需求分析人员和用户的合作关系[1](2010-8-31·需求分析的原则[2](2010-8-31·需求分析的原则[1](2010-8-31
关于我们专家加盟工作机会希赛顾问版权所有©2001-2010湘ICP备05000276号错误报告联系我们
4.7.4可追踪性类型可追踪性类型
说明需要其定义见“无用例模型”产品特性其定义见“无用例模型”软件需求
其定义见“无用例模型”
用例其定义见“唯用例模型”主角其定义见“唯用例模型”用例段其定义见“唯用例模型”
词汇
表术语其定义见“唯用例模型”补充需求
适用于整个系统或不容易适合用例的任何软件需求。
这些软件需求不必通过原始的软件需求集重新说明,但它们可能只是那些无法追踪到用例模型的规模软件需求。
4.7.5可追踪性摘要可追踪性链接说明
需要至产品特性
其定义见“无用例模型”产品特性到软件需求
其定义见“无用例模型”软件需求至用例
功能性软件需求追踪至用例。
非功能性软件需求的一个子集也追踪至用例。
这种关系允许根据用例的需求和业务利益对用例模型进行高级规模规划和评估。
注意:
所有局部功能需求必须追踪至用例或词汇表。
如果无法以该方式将它们反映出来,那么它们将得不到实施。
软件需求至用例段
追踪到用例的软件需求必须还能够追踪至用例的用例段之一。
这种关系允许根据对用例提出的需求验证用例的用例段。
追踪至用例的所有软件需求必须由用例内其中的一个段实现。
双重可追踪性
允许我们在考虑所需的用例段之前对用例段进行验证,并为用例本身分配软件需求。
某些段可能没有与之匹配的软件需求。
注意:
追踪至用例的所有功能性需求必须还能够追踪到用例的某一
个段。
如果无法以该方式将它们反映出来,那么它们将得不到实施。
软件需求至词汇表术语功能性和非功能性需求可追踪至词汇表中的项。
对于确定系统所包
含的实体的属性和关系的“静态需求”而言,情况尤其如此。
如果一个词汇表术语能够从软件需求进行追踪,那么该术语必须用于其中一个用例,否则它不可能被带入设计模型中。
用例至主角其定义见“唯用例模型”用例至用例段其定义见“唯用例模型”
软件需求至补充需求
补充需求可以重新声明适用于整个系统或不能很好适应用例模型的补充需求。
另一个备用方案就是将所有未追踪至用例模型的局部软件需求看作补充需求,这样就避免了对它们的重复说明。
4.7.6优点和缺点
十分坦率地说,这个方案比最前面提到的方案要略胜一筹。
它只适用于那些用传统SRS来说明的项目,但这些项目又希望使用用例建模技术来获得对所提供的需求的理解并促进用例驱动方案的使用。
正面:
-允许有非常详细的、低级别的正式可追踪性。
-软件需求以容易理解的形式表达。
-此可追踪性策略有利于需求变更的影响分析-可清楚理解未实现某个特性、软件需求或用例段所造成的影响。
-单独的需求包含用例和(或)产品特性提供的环境。
用例模型的存在使得我们容易确定有意义的需求子集。
这又使得规模管理以及产品的递增式交付更加容易进行。
-在这种情况下,用例模型最终通过软件需求和产品特性同涉众需求联系起来,这有助于涉众评估用例模型的适用性。
-大多数组织都接受(有警告)-这种方案对所有人都是一样的。
这种方案经常在初始用例项目上使用,作为并行需求流程的一种形式(即项目同时以新旧两种方式运作),或者用于隐藏开发者正在使用用例的事实。
-在组织首次采用或试验用例时,有助于减少破坏。
外界不断看到传统的SRS允许使用标准程序和合同。
反面:
-不好理解-许多人对传统需求声明和用例模型的共存疑惑不解。
-同时拥有传统软件需求规约和用例模型使您容易在需求活动的两个地方陷入困境。
在哪一个应该成为完整的软件需求规约的问题上很容易引起困惑。
-非常大的文档集必须要进行维护。
-副本太多,造成需求管理流程复杂化。
由于用例直接根据需求变更进行更新,因此传统的软件需求可能就废弃不用。
-这是一个高成本/高维护的方案。
4.7.7示例
这种方案对使用用例驱动开发技术的开发公司有用,并且传统软件需求规约是他们的合同的组成部分。
用例的引进使得开发公司能够展示它们对需求的理解,并以迭代和递增方式交付软件。
在将用例技术引入一个使用传统需求获取技术但又反对转向用例驱动方案的公司时,这种方案也是一个很有用的策略。
在这种情况下,目的在于向开发组织证明用例的价值。
在对用例的信心增长以后,逐步淘汰传统的软件需求规约。
这是转向“特性驱动用例模型”方案的第一步。
4.8用例模型调和多个传统软件需求集4.8.1说明
“用例模型是对来自于多个源的正式SRS的解释,并提供单个通用系统的规约。
”
这是对“用例模型是对软件需求规约的一种解释”的另一种说法。
除这种情况外,多个独立的涉众集提供多个传统的SRS解释。
在软件公司开发单个应用程序以满足许多不同的、独立的、相互之间没有联系的客户需求时,这种情况经常出现。
在这种情况下,用例模型是开发者对系统需求的综合视图,而单独的SRS则是独立的涉众对他们自己需求的视图(没有集成或者不反映其他涉众的需求)。
在多个独立需求集和用例模型之间进行追踪允许开发人员评估他们在执行估计各个涉众的需求时情况好坏。
4.8.2特征
这种策略是前面“用例模型是对软件需求规约的一种解释”方案的一个变种。
我们在讨论这种方案时只注意了它们之间的少数区别。
特征值
注释
明确的可追踪性
很高与“用例模型是对软件需求规约的一种解释”相同。
信任很低与“用例模型是对软件需求规约的一种解释”相同。
可说明性
很高
在这种情况下,我们在客户各自的SRS中保留了所有独立客户的观点。
正式性很高与“用例模型是对软件需求规约的一种解释”相同。
完整性很高与“用例模型是对软件需求规约的一种解释”相同。
文档集很大在这种情况下,我们拥有所需系统的多个规约,它们在一个用例模型中进行调和。
重点管理多个独立的客户。
这一方案的重点在于管理多个独立的、可能相互矛盾的需求源,这些需求源在政治、地理或者组织上无法紧密合作。
可理解性中
与“用例模型是对软件需求规约的一种解释”相同。
流程
典型的迭代式和递增式。
在这种情况下,开发人员使用用例模型作为他们的SRS。
请参见“唯用例模型”
开发风
格
典型的面向对象
在这种情况下,开发人员使用用例模型作为他们的SRS去驱动软件开发。
请参见“唯用例模型”
4.8.3可追踪性概述4.8.4需求类型需求类型说明
需要其定义见“无用例模型”产品特性其定义见“无用例模型”软件需求其定义见“无用例模型”用例其定义见“唯用例模型”用例段其定义见“唯用例模型”词汇表术语其定义见“唯用例模型”
补充需求适用于整个系统或不能很好适应用例的任何软件需求。
4.8.5可追踪性摘要可追踪性链接说明
需要至产品特性其定义见“无用例模型”产品特性至软件需求其定义见“无用例模型”
软件需求至用例与用例模型是对SRS的解释相同软件需求至用例段与用例模型是对SRS的解释相同软件需求至词汇表术语
与用例模型是对SRS的解释相同
在这种情况下,软件需求必须在支持用例模型的补充规约里重
软件需求至补充规约新声明,以便为生成一个单一一致的竞争SRS,从多个独立涉
众SRS汲取开放信息。
4.8.6优点和缺点
该策略是前面“用例模型是对软件需求规约的一种解释”方案的一个变种,优点和缺点大致相同。
这种方案区别于其他方案的优点在于,它具备让独立的涉众以各自正式单独的SRS形式处理并保留自己观点的能力。
它也有另一个缺点,即产生了更大的需要维护和跟踪的文档集。
4.8.7示例
英国的一家软件公司正在开发一个支持保险经纪人的系统,该系统允许保险公司通过电子途径发布新产品。
这个项目涉及22个涉众,其中约三分之二是经纪公司,三分之一是保险公司。
这些涉众的需求多种多样,在很多方面,保险公司的需求与经纪人的需求完全矛盾。
在这种情况下,该公司决定为每家涉众公司制定一个软件需求规约,详细说明它们具体的需求,使他们能够轻松维护各自的观点。
用例模型用于向所有涉众介绍系统的综合前景。
从初始SRS到用例模型的可追踪性能让涉众精确看到系统将满足他们的哪些需求,并验证系统是
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 通过 RUP 进行 需求 管理 跟踪 分析 资料