确定要使用哪些工作产品以及如何使用它们。除了确定要使用哪些工作产品之外,定制要用于满足项目需求的每个工作产品也很重要。
下表指定了建议使用哪些需求工作产品以及认为哪些工作产品是可选的(即只能在某些情况下使用)。关于更多的定制注意事项,请参阅工作产品描述页的定制部分。
工作产品
|
目的
|
定制(可选,建议使用)
|
工作产品:用例模型 (工作产品:参与者,工作产品:用例,工作产品:用例包)
|
用例用于定义功能需求。
|
建议大多数项目使用。
用例是用来获取功能需求的建议方法。
|
工作产品:故事板
|
如果项目具有并未真正得到理解的行为需求,则应考虑以演示图板为方式来引发需求。
|
可选
可以使用其他需求引发技术。
|
工作产品:词汇表
|
确保参与项目的每个人都在使用共同的词汇表。
|
建议大多数项目使用。
|
工作产品:需求属性
|
需求属性数据库有助于确保正确地对需求排列优先级、进行跟踪和跟踪。
|
可选
但是,对于需求相对较少的项目,并不一定严格要求有需求属性数据库。
|
工作产品:需求管理计划
|
描述要收集的信息和要用于评估、报告和控制产品需求变更的控制机制。如果需求管理的复杂性或客户可视性都证明有必要,则需要一份单独的文档。
|
可选
需求相对较少的项目可以采用轻量级的需求管理方法,该方法可以直接记录在软件开发计划中。
其他项目可以选择和遵循更严格的方法,但几乎或完全不生成正式描述。例如,要收集的需求属性集可以隐式地通过工具的配置进行记录。
|
工作产品:软件需求规范
|
用来收集所有需求的集合,并记入正式文档提供给客户。
|
可选
对于较不正式的项目,可能不需要正式文档。
|
工作产品:项目干系人请求
|
获取项目中提出的所有请求,并了解如何解决这些请求。
|
建议大多数项目使用。
为了构建一个满足项目干系人需要的系统,征求并复审他们的请求是重要的。
许多项目将项目干系人请求只作为变更请求的一个类别进行管理。其他项目可能只是非正式地获取项目干系人请求。
|
工作产品:补充规范
|
用来获取非功能需求。
|
建议大多数项目使用。
|
工作产品:远景
|
获取非常高级的需求和设计约束,以使读者理解要开发的系统。
|
建议大多数项目使用。
|
决定要使用哪些报告,这将取决于可供项目使用的报告工具。如果报告生成工具可用,则建议为面向模型的工作产品或面向数据库的工作产品(例如用例和参与者)生成报告。RUP
配置中的现有报告是在工作产品描述页面中提供的,并按照树形浏览器中的相关工作产品分组。
这一部分只在正式合同、标准或规范文档在向需求管理工作施加需求的情况下适用。它被称为“输入需求规范”。
在需求工作期间,您在以下文档中记录需求:工作产品:远景、工作产品:项目干系人请求、工作产品:用例模型、工作产品:补充规范。
决定是否要维护输入需求规范。当您发现需求不当、错误或不完善时,您会回头更新输入需求规范吗? 您还必须确定如何维护输入需求规范与工作产品:用例之间的跟踪或引用。
选择以下策略中的一个或一种组合:
-
不更新输入需求规范。让用例和补充规范指定系统随后将做什么。
-
不更新输入需求规范,但维护从用例回溯到输入需求规范的可跟踪性。
-
以所有涉及到的工作和成本更新输入需求规范。
-
让输入需求规范发展为包含需求的补充规范。功能输入需求只是转换为用例。
在多数项目中发现不当、不完善或错误需求的数量很大,以致维护原始输入需求规范没有意义。 很少有项目能让客户愿意为使用在用例建模期间展现的新信息更新输入需求规范的工作付费。
不要过早强调此主题。在项目开始时,人们仍信赖初始需求规范,但在经过某一用例的问题域之后,大多数人会对初始需求规范有截然不同的看法。
决定如何核准用例。通过限制必须由客户进行正式复审的用例的数量,可以节省大量时间。
也许对客户而言,仅仅正式复审所有用例中的一小部分是可以接受的。
选择以下策略中的一项或多项:
-
所有用例都必须通过项目以外代表的正式外部复审。
-
有些辅助用例可以简化方式,通过非正式复审或内部正式复审进行核准。
辅助用例对于系统是必需的,但对于主要用户的任务则不是必需的;例如,关于系统管理和维护的用例(诸如向系统添加用户、更改他们的权限以及进行备份)。 没有这些用例,系统将无法工作,尽管重要用户对它们基本上不感兴趣。
您使用的策略取决于您与客户的关系。客户相信您在没有正式核准流程的情况下也能正确地提供支持用例吗? 尽管这可能会节省相当多的时间,但您能达到用例模型的恰当质量标准吗?
注意:该问题的解决方案可能会让客户介入需求工作。 通过让客户代表介入,代表们将能核准建议或提供建议给其他客户;而且通过让客户介入,项目的可信性得到提高。
关于复审级别的更多信息,请参阅指南:复审级别。
|