搜索
需求管理1．需求管理的主要目的不包括下列中的(1)。A．确保项目相关方对需求的一致理解B．减少需求变更的数量C．保持需求到最终产品的双向追踪D．确保最终产品与需求相符合答案(1)B[分析]需求管理的目的是在用户和将处理用户需求的信息系统项目之间建立对用户需求的共同理解。需求管理包括和用户一起建立与维护有关信息系统项目需求的协议，该协议称作“分配给信息系统的系统需求”。协议既包括技术需求，又包括非技术需求(例如，交付日期)。该协议形成估计、策划和跟踪整个信息系统生存周期内项目活动的基础。需求管理的目标主要体现在三个方面：(1)确保项目各方对需求的一致理解。(2)管理和控制需求的变更，确保最终产品与需求相符合。(3)从需求到最终产品的双向追踪。2．需求变更提出宋之后，接着应该进行下列中的(2)。A．实施变更B．验证变更C．评估变更D．取消变更答案(2)C[分析]需求变更的管理控制程序一般如下：(1)建立需求基线、变更控制策略和变更控制系统。只有建立了基线才能很好地实施变更，否则无法控制。没有参照标准，也就没有控制而言；变更控制策略和变更控制系统同样重要，是变更的控制标准和手段，有良好的可行的变更控制系统，可以达到事半功倍的效果。这里需要特别强调的是，变更控制系统并非都要用计算机信息系统来实现，格式化的表格、流程图和制度组合起来也是一套很好的变更控制系统。(2)需求变更以规定格式提出。需求变更应以规定格式提出，并统一提交到CCB。需求变更一定要CCB统一管理，不能出现多头管理。以规定格式提出需求变更，是为了保证需求的明确性、可实现性和无二义性。(3)CCB对需求进行评估论证。CCB接收到需求变更申请后，应评估变更的技术可行性、代价、业务需求和资源限制，决定是采纳还是拒绝。(4)需求变更以书面方式获得批准并修改进度和成本等项目计划。CCB应给每一个采纳的变更需求设定一个优先级或变更实现的日期，项目管理团队对人员、进度计划、成本计划进行变更，并通知到相关的项目干系人。(5)定期评估需求变更对项目绩效的影响。应定期评估需求变更对项目进度、成本、质量等绩效的影响，以便及时对偏差进行调整，并为后续的需求变更不断积累数据和经验。以上第一项工作是工程项目准备阶段就应该做的整体准备工作，后面的第二到第五的4项工作针对每个需求变更都是要顺序执行的。3．需求跟踪矩阵的作用是(3)。A．可以体现需求与后续工作成果之间的对应关系B．固化需求，防止变更C．明确项目干系人对于需求的责任D．对于需求复杂的项目，可以用来明确需求答案(3)A[分析]需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文档等。需求跟踪信息使变更影响分析十分便利，有利于确认和评估某个建议的需求变更所必须做的工作。图15-1说明了四类需求跟踪能力链，客户需求可以向前追溯到需求，这样就能区分出开发过程中或开发结束后由于需求变更受到影响的需求。同时也确保了需求说明包括所有客户需求，同样，可以从需求回溯到相应的客户需求，确认每个需求的源头。表示需求和别的系统元素之间的联系链的最普遍的方式是使用需求跟踪能力矩阵，表15-1展示了这个矩阵。表15-1需求跟踪能力矩阵使用实例功能需求量设计元素代码测试实例US-28××××UC-29××××需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。实际上，创建需求跟踪能力是困难的，尤其是在短期之内会造成开发成本的上升，虽然从长远来看可以减少信息系统生存期的费用。组织在实施这项能力的时候应循序渐进，逐步实施需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。4．关于需求管理的描述，不正确的是(4)。A．需求管理要确保利益相关方对需求的一致理解B．需求管理要获取用户需求并定义产品需求C．需求管理要与需求开发紧密合作D．需求管理要取得利益相关方对需求的一致承诺[分析]需求工程的活动可分为两大类：一类属于需求开发，另一类属于需求管理。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求，需求开发的过程有四个：需求定义、需求获取、需求分析和需求验证。需求管理的目的是确保各方对需求的一致理解，管理和控制需求的变更，从需求到最终产品的双向跟踪。在需求管理中，要收集需求的变更和变更的理由，并且维持对原有需求和产品及构件需求的双向跟踪。答案(4)B5．在需求变更管理中，CCB的职责是(5)。A．决定采纳或拒绝针对项目需求的变更请求B．负责实现需求变更C．分析变更请求所带来的影响D．判定变更是否正确地实现[分析]变更控制委员会(ChangeControlBoard，CCB)也可称为配置控制委员会(ConfigurationControlBoard)，是配置项变更的监管组织。其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，完全可以根据工作的需要组成。例如，按变更内容和变更请求的不同，组成不同的CCB。小的项目CCB可以只有1人甚至只是兼职人员。如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。答案(5)A信息系统需求分析的任务不应包括(6)。进行需求分析可使用多种工具，但(7)是不适用的。(6)A．问题分解B．可靠性与安全性要求C．结构化程序设计D．确定逻辑模型(7)A．数据流图(DFD)B．判定表C．PAD图D．数据词典答案(6)C(7)C[分析]信息系统需求分析的目标是深入描述系统的功能和性能，确定系统设计的约束和信息系统同其他系统元素的接口，定义系统的其他有效性需求。也就是说，信息系统需求分析的任务是要解决“信息系统做什么”的问题，而不是解决“如何做”的问题，因此不包括程序设计。在需求分析中，可使用的工具主要有数据流图(DFD)、数据词典(DD)、结构化语言、判定表及判定树等。PAD图(问题分析图)主要用在信息系统设计过程中。8．以下关于需求管理的描述中，不正确的是(8)。A．在获取用户需求完毕后，才能分析用户需求B．通过原型向用户提供可视化的界面，用户可以对需求做出自己的评价C．需求验证是为了确保需求说明书准确、完整地表达必要的质量特点D．当完成需求说明书后，需求的变更是不可避免的答案(8)A[分析]在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：(1)以图形表示的方式描述系统的整体结构，包括系统的边界与接口：(2)通过原型、页面流或其他方式向用户提供可视化的界面，用户可以对需求做出自己的评价：(3)系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等：(4)以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。需求验证是为了确保需求说明书准确、完整地表达必要的质量特点。这里需要强调的是，在需求验证过程和评审过程中，客户的参与是非常重要的。对需求文档进行正式审查是保证产品质量的有效方法，组织一个由分析人员、客户、设计人员、测试人员等组成的小组，对其进行仔细的检查和评审。如果有必要的话，还可以组织公司外的、行业内的专家评审。一般的评审分为用户评审和同行评审两类。用户和开发方对于项目内容的描述，是以需求规格说明书作为基础的：用户验收的标准则是依据需求规格说明书中的内容来制定，可见，评审需求文档时用户的意见是第一位的。而同行评审的目的，是在项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。当完成需求说明书后，需求的变更是不可避免的，如何以可控的方式管理信息系统的需求，对项目的顺利进行有着重要的意义。对于需求变更的管理，则主要使用需求变更流程和变更控制委员会两个手段来实现。如果需要对每项变更带来的潜在影响及可能的成本费用、进度质量进行评估，变更控制委员会应与项目风险承担者进行协商，以确定哪些需求可以变更。同时无论在开发阶段还是测试阶段，每项变更和需求都是可跟踪的。9．下面关于需求变更的叙述，不正确的是(9)。A．控制需求变更就是要拒绝用户提出的需求，以保证工程实现核心目标B．只有建立了基线才能很好地实施变更C．需求变更应以规定格式提出，并统一提交到变更控制委员会D．应定期评估需求变更对项目进度、成本、质量等绩效的影响答案(9)A[分析]需求变更应以其可行性为基础，对其有效控制非常重要，否则将会导致工期、成本、质量不断扩大，对工程的成功影响较大。作为项目管理师要充分认识到这点，而且要将其重要性不断灌输给工程的客户、各施工方等所有干系人，特别是让客户认识到，有时控制需求变更不是拒绝用户，而是为了保证工程实现核心目标，达到预期的成功目标，当然控制需求变更也不是一味拒绝用户提出的需求。10．在各种不同的信息系统需求中，(10)描述了用户使用产品必须要完成的任务，可以在用例模型中予以说明。A．业务需求B．非功能需求C．用户需求D．功能需求答案(10)C[分析]开发信息系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细的技术需求，这包括所有面向用户、面向机器和其他系统的接口。同时，这也是一旦出错，将最终会给系统带来极大困难的部分，并且以后再对它进行修改也极为困难。信息系统需求可以分为几个层次，分别如下。(1)业务需求(BusinessRequirements)。反映组织结构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。(2)用户需求(UserRequirements)。描述用户使用产品必须完成的任务，在用例文档或方案场景(scenario)说明中予以说明。(3)功能需求(FunctionalRequirements)。定义开发人员必须实现的信息系统功能，使得用户能完成他们的任务，从而满足业务需求。(4)非功能需求(None-FunctionalRequirements)。描述系统展现给用户的行为和执行的操作等。包括：·产品必须遵循的标准、规范和合约：·外部界面的具体细节；·性能要求；·设计或实现的约束条件；·质量属性。11．信息系统需求说明书是需求分析阶段的成果，(11)不是其应包含的内容。A．数据描述B．功能描述C．系统结构描述D．性能描述答案(11)C[分析]信息系统需求说明书是需求分析阶段的成果，不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，信息系统需求规格说明不应该包括设计、构造、测试或工程管理的细节。可以使用以下3种方法编写信息系统需求规格说明。(1)用好的结构化和自然语言编写文本型文档。(2)建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。(3)编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数信息系统工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的信息系统需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了信息系统需求规格说明。