软件需求习题集

习题二：

2-2、说明客户与开发人员之间是什么关系？客户与用户是一样的吗？

答：通常意义下，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出 要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者 (stakeholder)或是获得产 品所产生的结果的人。

他们能说清楚要使用该产品完成什么任务和一些非功能性 的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

2-3、什么是业务需求、什么是用户需求？

答：业务需求应说明客户、公司和想从该系统获利的风险承担者或从系统中取得结果的 用户所要求的目标。业务需求为后继工作建立了一个指导性的框架。其它任说明都应遵从 业务需求的规定，然而业务需求并不能为开发人员提供多开发所需的细节说明。

用户需求 —必须从使用产品的用户处收集。因此这些用户（通常称作最 终用户），构成了另一种软件客户。他们能说清楚要使用该产品完成什么任务和一些非功能性 的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

说明业务需求的客户有时将试图替代用户说话，但通常他们根本无法准确说明用户需求。

2-4、客户与开发人员之间是什么关系？

答优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人 员之间有效的交流与合作。：

只有当双参与者都明白要成功自己需要什么，同时也应知道要成功合作需要什么时， 才能建立起一种合作关系。

2-5、简述软件客户需求权利书。 答：客户有如下权利：

1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。

3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。

5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。 6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允重用已有的软件组件。

9. 当需要对需求进行变更时，对成本、影响、得失（ trade-off）有个真实可信的评估。

10. 获得满足客户功能和质量要求的系统，并且这些要开发人员同意的。

2-6、叙述一下客户需求的权利与义务？ 答：客户有下列义务：

1. 给分析人员讲解业务及说明业务面的术语等专业问题。

Word 资料

.

2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。

5. 要尊重开发人员的成本估算和对需求的可行性分析。 6. 对单项需求、系统特性或使用实例划分优先级。 7. 评审需求文档和原型。

8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。

2-7、软件客户的权利与义务法案？

答：参见书上，2.2.1和2.2.2中的条例即可。

2-8、“签约”意味着什么？

答： “签约”意味着什么应该吧它作为项目的里程碑。对于签字之前应进行哪些活动，以及签字对将来变更的影响，各应形成明确一致的理解。

在需求上签约是终止需求开发过程的正确法。然而，参与者必须明白他们的签约 意味着什么。

2-9、为什么说“不要把“签约”当成武器”？

答：多组织在需求文 档中使用“签约”这个概念来作为客户同意需求的标志行为。故要让所有需求参与者都真正 明白“签约”的意思。这样的态度都是不对的，不可能在项目早期就了解所有需求，而且毫无疑问需求将会出 现变更。

2-10、什么是需求协议的基线？ 答：可参看2-11的答案。

2-11、怎样设置基线？

答：设置基线是很有意义的，它能给所有主要的涉众带来信心：

• 客户管理层相信项目的围不会过度膨胀直至失控,因为客户掌握了围变更的决定权. • 用户代表有信心开发团对会跟他们一同努力开发出符合需求的系统,即便他们不能在系统开始构建之前想到所有的需求. • 开发管理人员有信心，因为开发团队有了业务伙伴。业务伙伴能够保证项目的中心工作集中在业务目标上。他们将与开发人员一起在进度、成本、功能和质量之间做出平衡。

• 需求分析员也充满信心，因为他们可以有效地管理项目的变更，将变更引起的麻烦减至最小。

用明确的协议来结束前期是需求开发活动，能够帮助客户和开发人员形成合作伙伴关系，携手走上项目成功之路。

2-12、什么是需求变更？

答：在需求管理中有解释（后面章节）

2-13、什么时候客户和开发人员之间容易产生摩擦？

Word 资料

.

答：更为重要的是签名是建立在一个需求协议的基线上，因此在需求规格说明上的签约应该 这样理解：“我同意这份文档表述了目前我们对项目软件需求的了解。进一步的变更可在此基 线上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成 本、资源和项 目工期任务等”。

2-14、设置基线的意义？

答： 关于基线达成一定共识会易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误 差或市场和业务的新要求等。给初步的需求开发工作画上双都明确的句号会有助你形成一 个持续良好的客户与开发人员的关系，为项目的成功奠定了基础。

2-15、为什么说““签约”要把它作为项目的里程碑。”

答：“签约”意味着什么应该吧它作为项目的里程碑。对于签字之前应进行哪些活动，以及签字对将来变更的影响，各应形成明确一致的理解。

习题一：

1-0、系统项目涉众？

答：• 客户：投资项目或购买产品的部门或人员。 • 开发人员：设计、实现和维护该产品。 • 用户： 使用该产品的部门或人员。

• 测试人员：确定产品的行为是否与预计的相一致。 • 需求分析员：负责编写需求并传达给开发团队 。

• 文档编制人员：负责编写用户手册、培训资料和系统帮助。 • 项目经理：制定项目计划并带领开发人员获得成功。 • 法律人员：确保产品符合所有相关法规。 • 生产人员：制造包含该软件的产品。

• 市场营销、技术支持及其他与产品和客户打交道的人员。

1-1、什么是软件需求？

答： IEEE软件工程标准词汇表（ 1997年）中定义需求为：

（1）用户解决问题或达到目标所需的条件或权能（ Capability）。

（2）系统或系统部件要满足合同、标准、规或其它正式规定文档所需具有的 条件或权能。

（3）一种反映上面（ 1）或（ 2）所描述的条件或权能的文档说明。

1-2、什么是需求中的二义性，有什么危害？ 答：并没有一个清晰、毫无二义性的“需求”术语存 在，真正的“需求”实际上在人们的脑海中。任文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述我们需要确保所有项目风险承担者在描述需求 的那些名词的理解上务必达成共识。 危害的解释，请参看1-11的解释。

1-3、什么是系统的行为、特性和属性？

答：所谓特性 (feature)是指逻辑上相关的功能需求的集合，给用户 提供处理能力并满足业务需求。

Word 资料

.

1-4、软件需求包括哪些主要层次？

答：软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。

1-5、什么是业务需求、用户需求和功能需求？

答：业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它 们在项目视图与围文档中予以说明。

用户需求 (userrequirement) 文档描述了用户使用产品 必须要完成的任务，这在使用实例（ use case ）文档或案脚本（ scenario）说明中予以说明。

功能需求 (functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们 的任务，从而满足了业务需求。

1-6、什么是需求特性、什么是软件系统的外部行为。

答：所谓特性 (feature)是指逻辑上相关的功能需求的集合，给用户 提供处理能力并满足业务需求。

1-7、什么是软件需求规格说明？

答：软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规和合约；外部界面的具体细 节；性能要求；设计或实现的约束条件及质量属性。

1-8、什么是产品必须遵从的标准、规和合约。 答：参看上题的解释。

1-9、需求与软件项目开发中的哪些环节有关系？哪些开发环节关系不大？

答：项目也有其它面的需求， 如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要， 但它们并非本书所要讨论的。

1-10、什么是不适当的需求过程所引起的风险？ 答：不适当的需求过程所引起的一些风险 • 用户不多导致产品无法被接受。

• 用户需求的增加带来过度的耗费和降低产品的质量。 • 模棱两可的需求说明可能导致时间的浪费和返工。

• 用户增加一些不必要的特性和开发人员画蛇添足 (gold-plating)。 • 过分简略的需求说明以致遗漏某些关键需求。 • 忽略某类用户的需求将导致众多客户的不满。

• 不完善的需求说明使得项目计划和跟踪无法准确进行。

1-11、什么是模棱两可的需求和不必要的特性？ 答：模棱两可是需求规格说明中最为可怕的问题 (Lawrence 1996) 。它的一层含义是指诸多读 者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个式来解释某个

Word 资料

.

需 求说明.

模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而 浪费时间，并且使测试者与开发者所期望的不一致。

模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。 处理模棱两可需求的一种法是组织好负责从不同角度审查需求的队伍。

1-12、项目开发中的返工会给项目开发带来哪些影响？ 答：参看上题的解释。

1-13、什么是高质量的需求？ 答：实行有效的需求工程管理的组织能获得多面的好处。最大的好处是在开发后期和整个 维护阶段的重做的工作大大减少了。正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多风险承担者的 积极努力。

1-14、什么是优秀需求具有的特性？ 答： 需求说明的特征

1. 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

2. 正确性 每一项需求都必须准确地述其要开发的功能。做出正确判断的参考是需求的来源，

3. 可行性 每一项需求都必须是在已知系统和环境的权能和围可以实施的。

4.必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。

5. 划分优先级 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。

6.无二义性 对所有需求说明的读者都只能有一个明确统一的解释， 7. 可验证性 检查一下每项需否能通过设计测试用例或其它的验证法。

1-15、什么需求规格说明的特点？

答：1. 完整性 不能遗漏任必要的需求信息。遗漏需求将很难查出。

2. 一致性 一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。 3. 可修改性 在必要时或为维护每一需求变更历史记录时，应该修订 SRS。 4. 可跟踪性 应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链，

1-16、需求开发活动包括那几面？

答:需求开发可进一步分为：问题获取（ e l i c i t a t i o n ）、分析 ( a n a l y s i s ) 、编写规格说明 （specification）和验证（ verification）四个阶段（ Thayer and Dorfman 1997 ）。这些子项包括 软件类产品中需求收集、评价、编写文档等所有活动。 需求开发活动包括以下几个面： • 确定产品所期望的用户类。 • 获取每个用户类的需求。

• 了解实际用户任务和目标以及这些任务所支持的业务需求。

Word 资料

.

• 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 法和附加信息。

• 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 • 了解相关质量属性的重要性。 • 商讨实施优先级的划分。

• 将所收集的用户需求编写成规格说明和模型。

• 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说 明之前将问题都弄清楚。

1-17、什么是需求基线？ 答：参看有关章节的解释，

1-18、需求开发与需求管理他们之间的关系及区别？

答：

1-19、需求管理活动包括那几面？ 答：通常的需求管理活动包括：

• 定义需求基线（迅速制定需求文档的主体） • 评审提出的需求变更、评估每项变更的 可能影响从而决定是否实施它。

• 以一种可控制的式将需求变更融入到项目中。 • 使当前的项目计划与需求一致。

• 估计变更需求所产生影响并在此基础上协商新的承诺（约定）。

• 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。

Word 资料

.

• 在整个项目过程中跟踪需求状态及其变更情况。

1-20、为什么说软件项目中百分之四十至六十的问题都是在需求分析阶段埋下的“祸根”。 答：不适当的需求过程所引起的一些风险 • 用户不多导致产品无法被接受。

• 用户需求的增加带来过度的耗费和降低产品的质量。 • 模棱两可的需求说明可能导致时间的浪费和返工。

• 用户增加一些不必要的特性和开发人员画蛇添足 (gold-plating)。 • 过分简略的需求说明以致遗漏某些关键需求。 • 忽略某类用户的需求将导致众多客户的不满。

• 不完善的需求说明使得项目计划和跟踪无法准确进行。

1-21、为是要把软件需求，作为一门重要的课程来学习？说明原因。 答：根据自己学习中的体会、感受，做出解答。

习题14

14-1、设定需求优先级有什么作用？

答：建立每个功能的相对重要性有助于你规划软件的构造，以最少的费用提 供产品的最大功能。如果你正在做时间盒图或者进行渐增式开发，那么设定优先级就特别重 要，因为在这些开发中，交付进度安排很紧迫并且不可改变日期，你需要排除或推迟一些不重要的功能。 一个项目经理必须权衡合理的项目围和进度安排、预算、人力资源以及质量目标的约 束。一个实现这种权衡的法是：当接受一个新的高优先级的需求或者其它项目环境变化时， 删除低优先级的需求，或者把它们推迟到下一版本中去实现。如果客户没有以重要性和紧迫 性来区分它们的需求，那么项目经理就必须自己作出决策。由于客户可能不赞成项目经理所 设定的优先级，所以客户必须指明哪些需求必须包括在首发版中，而哪些需求可以延期实现。 当你有很多选择可以完成一个成功的产品时，应尽早在项目中设定其优先级。

14-2、需求优先级中有哪些规则？

答：在设定优先级的过程中典型的参与者有：

• 项目经理、他指导全过程，解决冲突，并且在必要的时候调整其它参与者的案。 • 重要的客户代表，例如产品的代表者，他可以提供受益和损失程度。 • 开发者代表，例如开发组的技术指导者，他提供了费用和风险程度。 你必须遵循如下步骤来使用这个优先级设定工具：

1) 在一个平面中列出你要设定优先级的所有 需求、特性或使用实例；

2) 估计每一个特性提供给客户或业务的相关利益，并用 1~9划分等级， 1代表可忽略的利 益， 9代表最大的价值。

3) 估计出如果没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。

4) 总价值栏是相对利润和相对损失的总和。

5) 估计实现每个特性的相对费用，使用 1（低） ~9（高）划分等级。

6) 类似地，开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用 1~9划分 等级。

Word 资料

.

7) 一旦把所有的估算写入平面图，你就可以利用如下公式计算出每一特性的优先级：

价值% 优先级 = （费用 %×费用权值） +（风险 %×风险权值）

8) 按计算出的优先级的降序排列表中的特性。

14-3、优先级中的等级有什么作用？

答： 一个项目经理必须权衡合理的项目围和进度安排、预算、人力资源以及质量目标的约 束。一个实现这种权衡的法是：当接受一个新的高优先级的需求或者其它项目环境变化时， 删除低优先级的需求，或者把它们推迟到下一版本中去实现。如果客户没有以重要性和紧迫 性来区分它们的需求，那么项目经理就必须自己作出决策。由于客户可能不赞成项目经理所 设定的优先级，所以客户必须指明哪些需求必须包括在首发版中，而哪些需求可以延期实现。 当你有很多选择可以完成一个成功的产品时，应尽早在项目中设定其优先级。

14-4、为什么要根据价值、成本和风险来设定优先级？

答：客户和开发者都必须为设定需求的优先级提供信息。客户总是让可以给他们带来最 大利 益的需求享有最高优先级。然而，一旦开发者指出费用、难度、技术风险，或其它与特定需 求相关的权衡时，客户可能会觉得他们最初所想的需求似乎变得不必要了。开发者也可能认 为在早期阶段必须先实现那些优先级较低的功能，因为它们会影响系统的体系结构。设定优 先级意味着权衡每个需求的业务利益和它的费用，以及它所牵涉到的结构基础和产品的未来 评价。

14-5、你学会了用电子数据表（矩阵）模型设定需求优先级了吗？ 答：参见书上的容。

练习15:

15-1、为什么说需求确认是需求开发过程的第四个阶段，那么前3个分别是什么？

答：需求验证是需求开发的第四部分（其余三个为获取、分析和编写规格说明） 。验证决定了开发成的产品 是否能满足开始时所确定的需求（即正确完成任务）。

15-2、需求确认活动应包括那几点？

答：我采用 IEEE的术语“验证”。所包括的活动是为了确定以下几面的容： • 软件需求规格说明正确描述了预期的系统行为和特征。 • 从系统需求或其它来源中得到软件需求。 • 需完整的和高质量的。

• 所有对需求的看法是一致的。

• 需求为继续进行产品设计、构造和测试提供了足够的基础。

15-3、需求确认活动的特征？

Word 资料

.

答：需求验证确保了需求符合需求述（ requirement statement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）并且符合需求规格说明的良好 特性（完整的、一致的、易修改的、可跟踪的）。当然，你只能验证那些已编写成文档的需求， 而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。

使用不同的技术有助于你验证需求的正确性及其质量。

更好的需求将会带来更好的产品质量和客户更 大的满意程度，这可以降低产品生存期中的维护、增强和客户支持的费用。在需求质量上的 投资可以使你节省更多的。

15-4、什么是需求评审？ 答：需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、 那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的 “需求”。

需求评审也为风险承担者们提供了在特定问题上达成共识的法。 不同种类的技术评审具有不同的称谓。

15-5、非正式评审法有哪些？ 答：非正式评审法包括：

。同级桌面检查 这种法是请某一位同事检查工作产品。 。轮查 这种法是同时请若干同事分别检查可交付产品。

。走查 这种法是可交付产品的作者向评审人员描述该产品并请求做出评论。

15-6、非正式评审与正式评审有什么不同？

答： 非正式评审可以根据个人爱好的式进行评审，而正式评审则遵循预先定义好的一系列 步骤过程。正式评审容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完 整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小 组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责， 正式技术评审的最好类型叫作审查。

15-7、审查过程大致包含那几些容？ 答：参见15-8的解释，

15-8、对需求文档审查的标准有哪些？

答：下面列出一些对需求文档开始审查的建议性标准： 。文档遵循标准模板。 。文档已经进行拼写检查。

。作者已经检查了文档在版面布局上所存在的错误。

。已经获得了审查员检查文档所需要的先前文档或参考文档。

。在文档中标上了行序号，这样可以便于在审查会上对待定位置的存进行查阅。 。所有未解决的问题都要标记为TBD(待确定）。

。仲裁者对具有代表性的需求例检查10分钟后，找不出3个以上的重大缺陷。 需求文档审查的标准：

• 文档符合标准模板。

Word 资料

.

• 文档已经做过拼写检查和语法检查。

• 作者已经检查了文档在版面安排上所存在的错误。

• 已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明。 • 在文档中打印了行序号以便在审查中对特定位置的查阅。 • 所有未解决的问题都被标记为 TBD（待确定）。 • 包括了文档中使用到的术语词汇表。

相似地，在调解者宣布审查结束之前，你应该定义所满足的退出审查的标准。这里有一些关于需求文档的退出标准：

• 已经明确阐述了审查员提出的所有问题。 • 已经正确修改了文档。

• 修订过的文档已经进行了拼写检查和语法检查。 • 所有 TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期 和提出问题的人。

• 文档已经登记入项目的配置管理系统。

• 检查是否已将审查过的资料送到有关收集处。

15-9、需求评审面临的困难有哪些？

答： 1) 大型的需求文档 审查一份几百页的软件需求规格说明是令人畏惧的。 2) 庞大的审查小组 多项目参与者和客户都与需求有关系， 3) 审查员在地域上的分散 越来越多的公司正通过地域上分散的开发组进行合作开发产品。

15-10、什么叫测试用例和测试路径？

答：1) 业务需求 该系统的一个主要业务动机可以用如下的需求来描述； 2) 使用实例 与这个业务需求相一致的一个使用实例；

3) 功能性需求 以下是关于让用户选择可用的化学制品的一些功能，而不是向外部供应商 发送订单；

4) 对话图（ dialog map） 使用实例中关于这一功能 的部分对话图。

5) 测试用例（ test case） 由于这个使用实例有多可能的执行路径，所以你可以想出 多测试用例来阐明普通过程、可选过程和例外。

15-11、为什么说需求与测试是一种协作关系？

答：验收测试重点应该测试用例的主干过程，而不应该是那些不常使用的分支过程，或系统是否对每一种异常条件都作了恰当的处理。

用户验收测试并不能取代基于需求的全面的系统测试，因为系统测试既覆盖了正常路径，也覆盖了异常路径，而且是通过各种数据组合来进行测试的。

15-12、什么是测试需求？ 答：验收测试也该测试非功能性需求，这些非功能性测试可以确保产品是否在所有平台都达到了其性能目标、系统是否遵从了易使用性标准，以及提交的全部用户需否都已实现等。

15-13、用例与测试用例有什么区别？

Word 资料

.

答：在开发过程中，用户越早编写验收测试，就能够越快地发现需求中的缺陷和要实现的软件中的缺陷。测试用例是为了测试系统编写的用例，而用例一般指在需求分析过程中编写的用例。

15-14、怎样制定验收标准？

答：让客户开发验收标准为确认最重要的需求提供了另一种机会。这是一种角度的转移，即从需求获取阶段提出“你想让系统做什么？”转移到了“如判断系统是否满足你的需求？”如果客户并不能表达出如评估系统是否满足某一特定的需求，那么就说明这条需求述得还不够清晰。

仅编写需求还不够，还需要确保所编写的需恰当合理的需求，而且这些需求可以为后续的设计、构造、测试和项目管理奠定良好的基础。验收测试计划、非正式评估、软件需求规格说明审查和需求测试等技术，都有助于我们更快速更廉价地构建出高质量的系统。

15-15、验收测试的重点是什么？

答：验收测试的重点应该是测试预期的使用场景。在决定如评估软件的可接受性时，关键的用户应该考虑那些最常用的和最重要的用例。验收测试重点应该测试用例的主干过程，而不应该是那些不常使用的分支过程，或系统是否对每一种异常条件都作了恰当的处理。

习题18：

18-1、需求管理强调：

• 控制对需求基线的变动。 • 保持项目计划与需求一致。

• 控制单个需求和需求文档的版本情况。

• 管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。

• 跟踪基线中需求的状态。

18-2、项目的响应式有多种： •推迟实现优先级低的需求。 •增派人手。

•短时间的突击加班，最好是有偿加班。 •为了满足新功能，推迟产品的交付日期。

•保持产品交付日期不变，但在质量上打些折扣。

这也是需求变更之后项目通常采取的反应式，虽然这样做并不可取。 18-3、

Word 资料

.

18-4、需求基线定义：

Word 资料

.

18-5、CMM

答：过程能力成熟度模型（ Capability Maturity Model ，CMM）

18-6、需求管理的目标 ：

答： 1) 把软件需求建立一个基线供软件工程和管理使用。 2) 软件计划，产品和活动同软件需求保持一致。 需求管理的关键过程领域不涉及收集和分析项目需求。

18-7、软件开发计 划是基于已确认的需求。

答： 开发团队在向客户、市场部或经理们作出承诺（ commitment）之前，应该确认需求和确 认约束条件、风险、偶然因素、假定条件。也不得不面对由于技术因素或进度原因而不现 实的需求作出 承诺。但是，决不要承诺任无法实现的事。

18-8、版本控制

关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时能 知道在开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规的式来统 一需求变更，并且基于业务和技术的因素来同意或反对建议的变更。当在开发中修改、增加、 减少需求时，软件开发计划应该随时更新以与新的需求保持一致。不反映现实的计划于事无 补。

18-9、通过如下法 能使项目反映最新的或变更过的需求。 • 暂时搁置次要需求。

• 得到一定数量的后备人员。 • 短期带薪加班处理。

• 将新的功能排入进度安排。

Word 资料

.

• 为了保证按时交工使质量受些必要的影响（通常，这是缺省反应）。

由于项目在特性、进度、人员、预算、质量各个面的要求不同，所以不存在一个放之四海皆准的模式。

18-10、需求管理步骤（过程） 答：

• 用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。 • 建议、处理、协商、通告新的需求和变更给有关的功能域的法。 • 如制定需求基线。

• 将使用的需求状态，并且是谁允作出的变更。 • 需求状态跟踪和报告过程。

• 分析已建议变动的影响应遵循的步骤。

• 在种情况下需求变更将会怎样影响项目计划和约定。

18-11、需求规格说明的版本控制

答： 版本控制是管理需求的一个必要面。需求文档的每一个版本必须被统一确定。组每 个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发 所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允指定的人来更新需求。

18-12、需求属性

答： 除了文本，每个功能需求应该有一些相关的信息或称之为属性与之相联系。这些属性在 它的预期功能性之外为每个需求建立了一个上下文和背景资料。属性值可以写在一纸上， 存储在一个数据库或需求管理工具中。商业工具除由系统产生一些属性外，还可以由你自己 定义各种数据类型的其它属性。这些工具允过滤、排序、查询数据库来察看按选择的需求 属性的需求集。

在你的每个需求文档中考虑明 确如下的属性： • 创建需求的时间 • 需求的版本号 • 创建需求的作者

• 负责认可该需求的人员 • 需求状态

• 需求的原因或根据（或信息的出处） • 需求涉及的子系统 • 需求涉及的产品版本号

• 使用的验证法或接受的测试标准

• 产品的优先级或重要程度（例如高、中、低或把你能定义的属性来表示成本书第 13章所 描述的优先级的四个面：收益、损失、成本、风险）

• 需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）

18-13、跟踪需求状态

答：在整个开发过程中，跟踪每个需求的状态是需求管理的一个重要面（ Caputo 1998）。在 每一可能的状态类别中，如果你期性地报告各状态类别在整个需求中所占的百分比将会改进项目的监控工作。假如你有清晰的要求，指定了允修改状态信息的人员和每个状态变更

Word 资料

.

应满足的条件，跟踪需求状态才能正常工作。工具能帮你跟踪每次状态改变的日期。

18-14、需求管理的下列活动的效果： • 提出需求变更和已建议的新需求。

• 评估已建议的变更，包括影响分析。 • 变更控制委员会活动。 • 更新需求文档或数据库。

• 在涉及人员或团队中交流需求的变更。 • 跟踪和报告需求状态。

• 定义和更新需求跟踪能力信息。

习题19：

19-1、变更控制应注意的事项？ 答： • 应仔细评估已建议的变更。

• 挑选合适的人选对变更做出决定。 • 变更应及时通知所有涉及的人员。

• 项目要按一定的程序来采纳需求变更。

只有项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导致与目标的差距。

当你不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。

19-2、控制项目围的扩展

答：扩展需指在软件需求基线已经确定后又要增添新的功能 或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较 大的影响。要是每个建议的需求都被采纳，对于项目出资者（ sponsor）、参与者与客户来说项 目将永远也不会完成—事实上，这是不可能的。所以必须进行项目围的控制。

管理围扩展的第一步就是把新系统的视图、围、文档化并作为业务需求的一部 分， 控制需求扩展的另一个有效的技术是 原型法， 控制围的扩展的法是要敢于说“不”。

19-3、变更控制过程

答： 一个好的变更控制过程给项目风险承担者提供了正式的建议需求变更机制。 通过变更控制过程来跟踪已建议变更的状态，确保不会 丢失或疏忽已建议的变更。 你确定了一个需求集合的基线，你应该对所有已建议的变更 都遵循变更控制过程。 变更控制过程并不是给变更设置障碍。

控制需求变更同项目其它配置管理决策紧密相连。

19-4、需求变更的策略

答：• 所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程 不再予以考虑。

• 对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。

Word 资料

.

• 简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（ CCB）决定实现哪 些变更（本章将讨论 CCB）。

• 项目风险承担者应该能够了解变更数据库的容。 • 绝不能从数据库中删除或修改变更请求的原始文档。

• 每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求。 •包含的每一个变更必须都能追溯到一个已获得批准的变更请求。 • 对批准或否决每一个变更请求的理由都要进行记录。 19-5、变更控制步骤 答：a. 绪论 a.1 目的 a.2 围 a.3 定义 b. 角色和责任 c. 变更请求状态 d. 开始条件 e. 任务

e.1 产生变更请求e.2 评估变更请求 e.3 作出决策 e.4 通知变更人员 f. 验证 g. 结束条件

h. 变更控制状态报告 附录：存储的数据项

19-6、变更控制委员会及组成？

答：软件开发活动中公认变更控制委员会或 CCB（有时也称为结构控制委员会）为最好的策 略之一（McConnell 1996）。变更控制委员会可以由一个小组担任，也可由多个不同的组担任， 负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用。 变更控制委员会的组成？ • 产品或计划管理部门。 • 项目管理部门。 • 开发部门。

• 测试或质量保证部门。 • 市场部或客户代表。 • 制作用户文档的部门。

• 技术支持部门。

• 帮助桌面或用户支持热线部门。 • 配置管理部门。

19-7、变更控制委员会总则 答：1. 制定决策

制定决策过程（程式）的描述应确认：

• 变更控制委员会必须到会的人数或作出有效决定必须出席的人员数。 • 决策的法，例如：投票、一致通过或其它机制。

Word 资料

.

• 变更控制委员会是否可以否决 CCB的集体决定。 2. 交流情况

一旦变更控制委员会做出决策时，指派的人员应及时更新数据库中请求的状态。 3. 重新协商约定

变更总是有代价的。即使拒绝的变更也因为决策行为（提交、评估、决策）而耗费了资 源。

19-8、变更控制工具 答：变更控制工具

挑选工具时可以考虑以下几个面： • 可以定义变更请求的数据项。

• 可以定义变更请求生存期的状态转换图。

• 可以加强状态转换图使经授权的用户仅能 做出所允的状态变更。 • 记录每一种状态变更的数据，确认做出变更的人员。

• 可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。 • 可以根据需要生成标准的或定制的报告和图表。

习题20：

20-1、需求跟踪能力矩阵

答：手工创建需求跟踪能力矩阵是一个应该养成的习惯，即使对小项目也很有效。一旦确立 使用实例基准，就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构 造、测试开发的进展不断更新矩阵。例如，在实现某一功能需求后，你可以更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。 表示跟踪能力信息的另一个法是通过矩阵的集合，矩阵定义了系统元素对间的联系链。

Word 资料