软考错题集需求工程

（ ）是关于需求管理正确的说法。

软件能力成熟度模型（CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件处理能力的 5个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有 6 个关键过程域 KPA（Key Process Areas）。故A选项错误。

除了文本，每一个功能需求应该有一些相关的信息与它联系，我们把这些信息称为需求属性。对于一个大型的复杂项目来说，丰富的属性类别显得尤为重要。例如，在文档中考虑和明确如下属性：创建需求的时间、需求的版本号、需求的作者、负责认可该软件需求的人员、需求状态、需求的原因和根据、需求涉及的子系统、需求涉及的产品版本号、使用的验证方法或者接受的测试标准、产品的优先级或者重要程度、需求的稳定性。故B选项错误。

需求的变更遵循以下流程：

（1）问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。

（2）变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。

（3）变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。

某软件公司承担了某金融公司财务管理系统的建设。在需求分析阶段，公司分析人员整理出一些相关的系统需求，其中“登陆用户的密码，30天需要修改一次，而且不能使用最近5次的密码，以提高系统的安全性”属于 （ ） ，“要求采用国有自主知识产权的数据库”属于 （ ） ，“在凭证录入时对往来款项进行详细的信息录入”属于 （ ） ，“用户在凭证录入界面录入信息后，点击保存按钮后，客户认为一般能在3秒钟内保存到数据库中” 属于（ ） 。

需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

（1）业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。

（2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求。

（3）系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。

质量功能部署（Quality Function Deployment，QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

（1）常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。

（2）期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

（3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。

需求获取是确定和理解不同的项目干系人的需求和约束的过程，需求获取是否科学、准备充分，对获取的结果影响很大。在多种需求获取方式中，（ ）方法具有良好的灵活性，有较宽广的应用范围，但存在获取需求时信息量大、记录较为困难、需要足够的领域知识等问题。（ ）方法基于数理统计原理，不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户，并可以减少数据收集偏差。（ ）方法通过高度组织的群体会议来分析企业内的问题，并从中获取系统需求。

用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过1对1（或1对2，1对3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难。例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。

采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。

软件需求规格说明书（SRS）中，约束的类型包括 （ ） 。

SRS包括功能需求、非功能需求和约束，其中约束分为：

① 设计约束：限制系统设计（如“必须使用Java开发”）。

② 过程约束：限制开发过程（如“需遵循ISO 9001流程”）。

组织信息化需求通常包含三个层次，其中（ ）需求的目标是提升组织的竞争能力，为组织的可持续发展提供支持环境。（ ）需求包含实现信息化战略目标的需求、运营策略的需求和人才培养的需求三个方面。技术需求主要强调在信息层技术层面上对系统的完善、升级、集成和整合提出的需求。

一般说来，信息化需求包含3个层次，即：战略需求、运作需求和技术需求。

一是战略需求。组织信息化的战略需求的目标是提升组织的竞争能力、为组织的可持续发展提供一个支持环境。从某种意义上来说，信息化对组织不仅仅是服务的手段和实现现有战略的辅助工具；信息化可以把组织战略提升到一个新的水平，为组织带来新的发展契机。特别是对于企业，信息化战略是企业竞争的基础。第一空选择A选项。

二是运作需求。组织信息化的运作需求是组织信息化需求非常重要且关键的一环，它包含三方面的内容：一是实现信息化战略目标的需要；二是运营策略的需要；三是人才培养的需要。第二空选择B选项。

三是技术需求。由于系统开发时间过长等问题在信息技术层面上对系统的完善、升级、集成和整合提出了需求。也有的组织，原来基本上没有大型的信息系统项目，有的也只是一些单机应用，这样的组织的信息化需求，一般是从头开发新的系统。

需求管理是一个对系统需求变更、了解和控制的过程。以下活动中，（ ）不属于需求管理的主要活动。

需求管理的活动包括：

1、变更控制

2、版本控制

3、需求跟踪

4、需求状态跟踪

以下关于敏捷方法的叙述中，（ ）是不正确的。

敏捷方法是面向对象的，而非面向开发过程，故A选项错误。

极限编程是著名的敏捷开发方法

敏捷型方法是“适应性”而非“预设性”

敏捷开发方法是迭代增量式的开发方法