第八周作业

需求管理

定义

所谓需求管理就是为有效地控制和管理需求更改地所进行的一系列活动。

主要任务

开发人员在与提出更改的请求者（用户）协商的基础上，评估需求变更带来的潜在影响及可能的成本和费用，然后实施更改，以及有效地管理需求规格说明文档和跟踪更改需求的状态。

管理内容

控制对基准需求规格说明的变动；

保持项目计划与需求一致；

控制单个需求的更改和需求规格说明文档的更改；

管理需求和需求间的联系。以及需求与设计和实现等方面的依赖关系；

跟踪需求更改的状态，控制多个需求同时更改的复杂性。

需求变更控制

原因

在实际的软件开发中，对许多软件项目中，一些需求的更改是不可避免的，原因是市场竞争、业务过程和组织机构的变化、软件系统运行环境的变化等。但是不被控制的需求变更会使项目陷入困境，这是某些项目不能按进度执行或质量低劣的重要原因之一。

1.控制项目范围的扩展

所谓扩展需求是指在基准的需求规格说明已确定后，又要增添新的功能或进行较大的功能扩充。扩展需求使原来的软件项目范围变大，从而导致项目的风险变大。如何控制由于扩展需求而带来的变更范围的扩展呢？通常的方法有：
1）控制范围扩展的最初方法就是把新扩充系统的视图、范围和限制等文档化，并作为业务需求或功能需求的一部分，将其与项目原来的视图和范围相比较，然后对新增加的每个需求进行评估，以决定是否采纳这样的扩展需求。
2）利用原型化方法提供可能实现的扩充部分的预览，以帮助用户与开发人员之间进行交流和沟通，从而准确地把握用户的真正需求。
3）有时也要敢于说“不”。用户要更改需求是合乎情理的，但是，一旦按其意愿（包括不合理的情况）进行更改，软件开发就要付出下相当大的代价，特别是成本和时间。因此，在某些情况下，软件开发人员可以采取委婉地方式来说“现在不行”等，暗示在开发的下一版本系统中可以采取用户的这种更改，使用户不会太为难。

2.变更控制策略

1） 建立所有的需求变更所应遵循的过程（包括变更步骤）。按此过程，当一个变更需求在过程中某一步被拒绝后，则其后的步骤将不再予以考虑。
2） 对于未或批准的变更，除进行可行性论证外，不应再做其后的工作。
3） 对所提出的多个变更请求，应由项目变更小组委员会决定实现哪些变更，以及先后次序。
4）项目开发人员和用户应该能了解已变更需求的情况。
5）不准随意删除和修改与需求变更请求和实现相关的原始文档。
6） 每一个实施后的变更必须与一个经核准的变更请求相对应
在需求变更请求中，有大的变更请求和小的变更请求之分，这主要是根据实施需求变更所涉及的范围大小来决定的。对于所有的变更请求，不管其大小如何，都应通过控制过程来处理所有的变更。在实践中，可以将一些小的、具体的需求变更请求交由开发人员来决定。但设计2人或2人以上（特别是接口问题）的需求变更则应通过变更控制过程来处理。

3.变更控制的步骤

变更控制的步骤中，每步的工作任务明确，各步间是相互依赖的。
1）变更控制的启动。启动的条件是通过合适的渠道接受一个合法的变更请求。
2）确定角色与责任。列出参与变更控制活动的项目组成员，并描述他们的职责和分配角色。
3）影响分析与评估。评估变更请求的技术可行性、代价和资源限制等，提供对变更请求的准确理解，帮助做出信息量充分的变更批准决策。为了帮助评估员理解一个需求变更的影响，可以设计一个由一些问题组成的问题清单和受影响的软件元素清单。从事影响分析的评估员在分析过程中根据问题给出量化的评估值，然后通过求和就可得到变更请求的综合评估值。该综合评估值为评估员决定是否实施变更提供了判断的依据。当 评估员决定实施变更请求时，他们还必须估计变更对项目进度和费用的影响，为项目负责人和变更小组负责人提供判断依据。
4）实施变更。当需求变更请求被采纳后，开始对涉及的软件系统实施更新。在实施更新的过程中，因具体情况不同，可能需修该一部分文档或代码，如需求规格说明文档、设计文档和测试文档等，以及更改某些数据库或文件等。
5）验证。主要是通过检查来确保更新后的需求规格说明的正确性。一些用例、分析模型或测试用例等均能正确反应变更的各个方面，可以通过这些方法来支持验证的工作。有时还可通过对软件系统进行测试来验证变更工作。
6）变更控制的结束。

需求规格说明文档的版本控制

版本控制是需求管理的一个必要方面，也是容易忽视和出错的方面。在变更实施过程中，需求规格说明文档需要修改，并建立新的版本。这就存在版本的控制问题，如稍不注意，就会导致软件的开发和维护工作出错。实际上，原程序的版本变更及多版本的管理也存在与此例类似的问题。因此，需求规格说明的每一个版本必须统一确定，并保证开发人员必须知道和得到新的需求规格说明版本。为了有效地实施版本控制，可以遵循寻如下的版本控制策略。
1）为了减少困惑、冲突和不一致，只能允许指定的专人来更新和修改需求规格说明文档。
2）每一个公布的需求规格说明文档的版本应该包括修改版本的历史情况，如已修改的内容、修改的日期、修改人的姓名及修改的原因等。
3）根据修改工作量的大小，手工标记需求规格说明版本的每一次修改。
4）每个版本的需求规格说明必须是独立说明的，以避免新旧版本的混淆
版本控制的策略有很多，应该根据具体情况进行控制。此外，有的还可借助于一些版本控制工具来实现版本管理。

需求变更状态的跟踪

对于一个大型而复杂的软件系统的需求规格说明，可能会面临多个需求变更的情况。变更控制过程不可能同时对每个需求给予处理，故在长时间内，掌握和了解多个需求变更处理的情况，以及是否已完成更改的情况等，这在软件开发过程和维护过程中是很重要的。为了便于管理和控制需求变更，对于一个变更请求可用状态图来描述其在不同时间所处的状态，以使各类人员知道更改的进度。

需求跟踪

所谓需求跟踪是指编制每个需求与系统元素之间联系（即可跟踪信息）的文档，其中，系统元素包括：其他需求、体系结构、设计部件、测试文档等。可跟踪性就是指需求跟踪的内容。为了实现可跟踪性，必须统一地标识出每一个需求，以便能明确地进行查阅。

1.可跟踪信息分类

此处根据需求系统元素之间联系的类型把可跟踪性信息粗略分为如下几类：

需求-源可跟踪性：把需求与说明该需求的人或文档相链接。

需求-理由可跟踪性：把需求和说明为什么需要该需求的描述相链接。

需求-需求可跟踪性：把需求与其他依赖于该需求的需求相链接。

需求-体系结构可跟踪性：把需求与实现该需求的子系统相链接，这对于由不同的开发人员开发子系统来说特别重要。

需求-设计可跟踪性：把需求和用来实现需求的系统中的特定组件相链接，这些组件可能是软件或硬件组件。

需求-用户界面可跟踪性：把需求和提供该需求的外部系统界面相链接。

2.需求跟踪技术

有两种技术可用于维护可跟踪信息：需求跟踪表和可跟踪性表。

表示需求和系统元素之间联系的最普遍的方式是使用需求跟踪表。需求沿水平方向给出，系统元素沿垂直方向给出，两者之间的关系标识在表格的单元中。需求和系统元素可分别用编号表示。

可跟踪性表是需求跟踪表的简化形式。对每一个需求，可以只列出与该需求相关的需求。这样比需求跟踪表更加简洁，也易于管理。

除了上述的需求跟踪技术外，还可使用一些需求跟踪工具。这样的工具较多，提供的功能各不相同。

随着软件工程技术的发展，需求管理的任务越来越繁重，迫切需要研制需求管理工具来自动化地管理需求，提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borland CaliberRM等都是目前比较流行的需求管理工具，可以帮助团队有效地管理软件需求。