1、信息系统项目管理师-需求管理及答案解析(总分：6.00，做题时间：90 分钟)一、lilist-style-type:n(总题数：1，分数：6.00)信息系统需求分析的任务不应包括U U 6 /U /U。进行需求分析可使用多种工具，但U U 7 /U /U是不适用的。（分数：6.00）(1). A.问题分解 B.可靠性与安全性要求 C.结构化程序设计 D.确定逻辑模型（分数：1.00）A.B.C.D.(2). A.数据流图(DFD) B.判定表 C.PAD图 D.数据词典（分数：1.00）A.B.C.D.(3).以下关于需求管理的描述中，不正确的是U U /U /U。 A.在获取用户需求完毕后
2、，才能分析用户需求 B.通过原型向用户提供可视化的界面，用户可以对需求做出自己的评价 C.需求验证是为了确保需求说明书准确、完整地表达必要的质量特点 D.当完成需求说明书后，需求的变更是不可避免的（分数：1.00）A.B.C.D.(4).下面关于需求变更的叙述，不正确的是U U /U /U。 A.控制需求变更就是要拒绝用户提出的需求，以保证工程实现核心目标 B.只有建立了基线才能很好地实施变更 C.需求变更应以规定格式提出，并统一提交到变更控制委员会 D.应定期评估需求变更对项目进度、成本、质量等绩效的影响（分数：1.00）A.B.C.D.(5).在各种不同的信息系统需求中，U U /U /U
3、描述了用户使用产品必须要完成的任务，可以在用例模型中予以说明。 A.业务需求 B.非功能需求 C.用户需求 D.功能需求（分数：1.00）A.B.C.D.(6).信息系统需求说明书是需求分析阶段的成果，U U /U /U不是其应包含的内容。 A.数据描述 B.功能描述 C.系统结构描述 D.性能描述（分数：1.00）A.B.C.D.信息系统项目管理师-需求管理答案解析(总分：6.00，做题时间：90 分钟)一、lilist-style-type:n(总题数：1，分数：6.00)信息系统需求分析的任务不应包括U U 6 /U /U。进行需求分析可使用多种工具，但U U 7 /U /U是不适用的。
4、（分数：6.00）(1). A.问题分解 B.可靠性与安全性要求 C.结构化程序设计 D.确定逻辑模型（分数：1.00）A.B.C. D.解析：(2). A.数据流图(DFD) B.判定表 C.PAD图 D.数据词典（分数：1.00）A.B.C. D.解析：解析 信息系统需求分析的目标是深入描述系统的功能和性能，确定系统设计的约束和信息系统同其他系统元素的接口，定义系统的其他有效性需求。也就是说，信息系统需求分析的任务是要解决“信息系统做什么”的问题，而不是解决“如何做”的问题，因此不包括程序设计。在需求分析中，可使用的工具主要有数据流图(DFD)、数据词典(DD)、结构化语言、判定表及判定树
5、等。PAD 图(问题分析图)主要用在信息系统设计过程中。(3).以下关于需求管理的描述中，不正确的是U U /U /U。 A.在获取用户需求完毕后，才能分析用户需求 B.通过原型向用户提供可视化的界面，用户可以对需求做出自己的评价 C.需求验证是为了确保需求说明书准确、完整地表达必要的质量特点 D.当完成需求说明书后，需求的变更是不可避免的（分数：1.00）A. B.C.D.解析：解析 在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需
6、求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动： (1)以图形表示的方式描述系统的整体结构，包括系统的边界与接口： (2)通过原型、页面流或其他方式向用户提供可视化的界面，用户可以对需求做出自己的评价： (3)系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等： (4)以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。 需求验证是为了确保需求说明书准确、完整地表达必要的质量特点。这里需要强调的是，在需求验证过程和评审过程中，客户的参与是非常重要的。对需求
7、文档进行正式审查是保证产品质量的有效方法，组织一个由分析人员、客户、设计人员、测试人员等组成的小组，对其进行仔细的检查和评审。如果有必要的话，还可以组织公司外的、行业内的专家评审。 一般的评审分为用户评审和同行评审两类。用户和开发方对于项目内容的描述，是以需求规格说明书作为基础的：用户验收的标准则是依据需求规格说明书中的内容来制定，可见，评审需求文档时用户的意见是第一位的。而同行评审的目的，是在项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。 当完成需求说明书后，需求的变更是不可避免的，如何以可控的方式管理信息系统的需求，对项目的顺利进行有着重要的意义。对于需求变更的
8、管理，则主要使用需求变更流程和变更控制委员会两个手段来实现。如果需要对每项变更带来的潜在影响及可能的成本费用、进度质量进行评估，变更控制委员会应与项目风险承担者进行协商，以确定哪些需求可以变更。同时无论在开发阶段还是测试阶段，每项变更和需求都是可跟踪的。(4).下面关于需求变更的叙述，不正确的是U U /U /U。 A.控制需求变更就是要拒绝用户提出的需求，以保证工程实现核心目标 B.只有建立了基线才能很好地实施变更 C.需求变更应以规定格式提出，并统一提交到变更控制委员会 D.应定期评估需求变更对项目进度、成本、质量等绩效的影响（分数：1.00）A. B.C.D.解析：解析 需求变更应以其可
9、行性为基础，对其有效控制非常重要，否则将会导致工期、成本、质量不断扩大，对工程的成功影响较大。作为项目管理师要充分认识到这点，而且要将其重要性不断灌输给工程的客户、各施工方等所有干系人，特别是让客户认识到，有时控制需求变更不是拒绝用户，而是为了保证工程实现核心目标，达到预期的成功目标，当然控制需求变更也不是一味拒绝用户提出的需求。(5).在各种不同的信息系统需求中，U U /U /U描述了用户使用产品必须要完成的任务，可以在用例模型中予以说明。 A.业务需求 B.非功能需求 C.用户需求 D.功能需求（分数：1.00）A.B.C. D.解析：解析 开发信息系统最为困难的部分就是准确说明开发什么
10、。最为困难的概念性工作便是编写出详细的技术需求，这包括所有面向用户、面向机器和其他系统的接口。同时，这也是一旦出错，将最终会给系统带来极大困难的部分，并且以后再对它进行修改也极为困难。 信息系统需求可以分为几个层次，分别如下。 (1)业务需求(Business Requirements)。反映组织结构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 (2)用户需求(User Requirements)。描述用户使用产品必须完成的任务，在用例文档或方案场景(scenario)说明中予以说明。 (3)功能需求(Functional Requirements)。定义开发人员必
11、须实现的信息系统功能，使得用户能完成他们的任务，从而满足业务需求。 (4)非功能需求(None-Functional Requirements)。描述系统展现给用户的行为和执行的操作等。包括： 产品必须遵循的标准、规范和合约： 外部界面的具体细节； 性能要求； 设计或实现的约束条件； 质量属性。(6).信息系统需求说明书是需求分析阶段的成果，U U /U /U不是其应包含的内容。 A.数据描述 B.功能描述 C.系统结构描述 D.性能描述（分数：1.00）A.B.C. D.解析：解析 信息系统需求说明书是需求分析阶段的成果，不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基
12、础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，信息系统需求规格说明不应该包括设计、构造、测试或工程管理的细节。可以使用以下 3种方法编写信息系统需求规格说明。 (1)用好的结构化和自然语言编写文本型文档。 (2)建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。 (3)编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数信息系统工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的信息系统需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了信息系统需求规格说明。
