软件需求习题集3

习题二：

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

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

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

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

答：业务需求应说明客户、公司和想从该系统获利的风险承担者或从系统中取得结果的 用户所要求的目标。业务需求为后继工作建立了一个指导性的框架。其它任何说明都应遵从 业务需求的规定，然而业务需求并不能为开发人员提供许多开发所需的细节说明。 用户需求 —必须从使用产品的用户处收集。因此这些用户（通常称作最 终用户），构成了另一种软件客户。他们能说清楚要使用该产品完成什么任务和一些非功能性 的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

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

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

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

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

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

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

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

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

9. 当需要对需求进行变更时，对成本、影响、得失（ trade-off）有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

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

1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 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、什么时候客户和开发人员之间容易产生摩擦？ 答：更为重要的是签名是建立在一个需求协议的基线上，因此在需求规格说明上的签约应该 这样理解：“我同意这份文档表述了目前我们对项目软件需求的了解。进一步的变更可在此基 线上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成 本、资源和项 目工期任务等”。

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

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

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

习题一：

1-0、系统项目涉众？ 答：? 客户：投资项目或购买产品的部门或人员。 ? 开发人员：设计、实现和维护该产品。 ? 用户： 使用该产品的部门或人员。

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

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

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

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

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

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

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

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

1-2、什么是需求中的二义性，有什么危害？

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

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

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

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) 。它的一层含义是指诸多读 者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需 求说明.

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

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

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 ）。这些子项包括 软件类产品中需求收集、评价、编写文档等所有活动。 需求开发活动包括以下几个方面： ? 确定产品所期望的用户类。 ? 获取每个用户类的需求。

? 了解实际用户任务和目标以及这些任务所支持的业务需求。 ? 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息。

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

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

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

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

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

答：

本文来源：https://www.bwwdw.com/article/x66v.html