第三章软件需求管理.pptVIP

需求变化 合理范围内的变化： 用户不了解自己的需求 需求本身易变，市场、技术、竞争因素 不合理的变化： 需求文档质量不高 需求分析技能、技术和管理上的缺陷 需求变化的原因： 未受控制的需求变更 遗漏需求 用户交流不够 需求规约质量差 低效的需求分析 3.1.2 需求与需求管理的概念 什么是需求？ 需求的基本概念 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 需求是对系统要做什么、如何工作、表现出来的特征、必须具备的质量、必须满足的约束的叙述 需求的重要性 需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。 国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 面对软件工程过程中存在的需求不确定性问题，软件工程进一步获得发展，其中一个具体体现，就是发展出“需求工程”的概念。 需求工程是提供一种适当的机制，以了解用户想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约以及在开发过程中管理这些被确认的需求规约的过程。 因此，需求工程的活动也可分为两大过程域，一个过程域是需求开发，另一过程域是需求管理。 需求开发过程域 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 需求获取的目的是通过各种途径获取用户的需求信息，产生《用户需求说明书》或《产品远景文件》。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求处理的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解的基础上，实现需求并在实现的过程中，维护需求与其它工作成果的一致性，并控制需求的变更。 需求实现是指在系统概要分析、详细分析和系统编码、测试等开发过程中，实现系统的需求。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 回忆一下：问题定义阶段的任务和步骤 (一)系统任务的提出 1. 系统任务的提出者 2. 系统任务的提出形式 3. 系统任务提出的目的 (二)初步调查 1. 初步调查的目的 2. 初步调查的主要内容 (三)系统目标的确定 1. 系统目标的含义 2. 如何确定系统的目标 成果交付物： 《需求说明书》或 《产品前景文档》 编制软件需求规格说明（Software Requirements Specification，SRS） 3.2.3 需求分析阶段 需求验证阶段——需求评审对象 CMM2就需求评审的对象——“给定需求”的文档依据规定为： （1）???? 影响和决定软件项目活动的非技术需求（例如：协议、条件和/或合同条款）。具体实例有：要交付的产品、交付日期、里程碑。 （2）???? 软件的技术需求实例有：最终用户、操作员、支持或综合能力；性能需求；设计约束条件；程序设计语言；界面需求。 （3）???? 用于确认软件产品是否能满足给定需求的验收标准。 需求验证阶段——需求评审内容 CMM2对评审内容规定为： （1）???? 确定不完整和遗漏的给定需求； （2）???? 评审给定需求以确定他们是否：可行、适用于软件实现、说明清楚、适当、彼此一致、可测试。 （3）???? 有负责分析和分配系统需求的小组对确认可能有问题的给定需求进行评审并进行必要的修改。 （4）???? 相关小组协商由给定需求所得出的约定。 需求验证阶段——良好的需求规格说明属性 具有良好的需求规格说明属性的需求文档，具有如下的属性： （1）不含糊性：如果每一个需求只有唯一的一种解释，那它是不含糊的； （2）完整性：如果需求包括了功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求，是完整的； （3）可检验性：存在有限的、经济与技术都是可行的检验方法和程序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认需求被按照需求规格说明实现； （4）一致性：需求作为一种要求是一致的，不存在系统内相互冲突的需求要求； （5）可跟踪性：需求