第6章软件工程需求开发及管理.pdf

需求开发及管理 第六章需求开发及管理 CMMI对应实践 需求开发及管理简述 需求开发及管理流程 需求获取 需求分析 需求评审 需求管理 需求的定义  在IEEE软件工程标准词汇表(1997年) 中定义软件需求 为 1. 用户解决问题或达到目标所需的条件或能力。 2. 系统或系统部件要满足合同、标准、规范或其它正式 规定文档所需具有的条件或能力。 3. 一种反映上面(1)或(2)所描述的条件或能力的文档说明 。通俗的讲，“需求”就是用户的需要，它包括用户要 解决的问题、达到的目标、以及实现这些目标所需要 的条件，它是一个程序或系统开发工作的说明，表现 形式一般为文档形式。 3 需求管理（REQM）  目的：管理项目产品和产品组件的需求，并识别需求 与项目计划和工作产品之间的不一致项  需求包括：技术性需求、非技术性需求、功能需求、 非功能需求，来自客户的需求、来自项目组内部的需 求等。  项目组应该管理需求变更（当出现变更时），并且识 别在项目计划、工作产品和需求之间发生的不一致项 。作为需求管理的一个部分，需求变更及其理由应填 入记录文档，并且在最初需求与产品和产品组件的所 有需求之间维持双向可追溯性。 需求管理（REQM）  SG 1 Manage Requirements （管理需求），对需求进行 管理，并识别需求与项目计划和工作产品之间的不一 致项。  SP 1.1 Obtain an Understanding of Requirements （取得对需求的理 解）  随着项目的进展，会不得收到新的需求，为了避免需求不断发生 变化，应建立准则，用以指明接受需求的正规渠道和需求的合法 来源。通过分析和沟通的结果是形成取得一致理解的需求集合。  工作产品：合格需求提供者判断准则；需求验收和鉴定标准；根 据准则进行分析后所得的各类结果；达成一致理解的需求集。  SP 1.2 Obtain Commitment to Requirements （取得对需求的承 诺）  从项目的参与者处取得对需求的承诺。  工作产品：需求影响评估结果；对需求及其变更承诺的记录 文档。  实践步骤：一时评估各项需求对已有承诺的影响；二是协商 并记录承诺。  SP 1.3 Manage Requirements Changes （管理需求变更）  在项目开发期间，需求发生变更时，应对需求变更进行管理 。  工作产品：需求状态表；需求数据库；需求决策数据库等  实践步骤：一个是汇总交给项目组的或项目组产生的全部需 求及变更；二是维护需求变更的历史以及变更理由；三是从 项目的吸纳古墓干系人的角度出发评价需求变更的影响；四 是使需求和需求变更数据可供项目组使用。  SP 1.4 Maintain Bidirectional Traceability of Requirements （维 护对需求的双向跟踪）  维护需求与项目计划和工作产品之间的双向可追溯性。其意 图是在于维护每个产品分解层次的需求的双向可追溯性。  工作产品：需求追溯性矩阵；需求跟踪系统。  实践步骤：一时维护需求的可追溯性，以确保将低层需求的 原需求记入文档；二是维护每个需求与它的派生需求的可追 溯性，维护每个需求与功能分配、目标、人员和过程的可追 溯性；三是维护功能模块之间和跨接口两边的功能之间横向 可追溯性；四是生成需求可追溯矩阵。  SP 1.5 Identify Inconsistencies Between Project Work and Requirements （识别项目工作与需求之间的不一致项）  目的是发现需求与项目计划和工作产品之间的不一致项，并启 动纠正措施。  工作产品：记录不一致项目的文档；启动的纠正措施。  实践步骤：一是评审项目计划、活动和工