软件开发和需求管理概述.pptx
软件需求与需求管理软件需求与需求管理2002-4-4 内内 容容 软件发展的三个时期 软件生存期过程 软件开发 软件需求 需求工程 需求变更及其控制 CMM2级需求管理关键过程域一、软件发展的三个时期 表一 时期年代阶段涉及注重主要使用语言标准模型初期50-60程序设计点编程技巧ALGOLFORTRANCOBOLBASIC 中期70-80软件开发线结构化模块化PASCALGB8566软件开发规范瀑布原型现代90-软件过程面过程能力C,C+JAVAVB、VCISO/IEC12207软件生存期过程ISO9000螺旋CMM二、软件生存期过程 ISO/IEC12207 信息技术软件生存期过程 基本过程支持过程组织过程软件生存期过程图1-1供应过程开发过程运行过程基本过程获取过程维护过程图1-2质量保证过程验证过程确认过程支持过程配置管理过程联合评审过程审核过程文档编制过程问题解决过程图1-3基础设施过程改进过程培训过程组织过程管理过程图1-4 三、软件开发 1.计算机系统 人员硬件软件数据传输机构执行机构（剧作家、导演）（舞台剧本演员道具）图2 计算机系统2.软件开发过程： 活动任务 系统需求分析系统结构设计 软件需求分析建立软件需求评价软件需求联合评审软件结构设计软件详细设计软件编码和测试 软件集成 软件鉴定测试系统集成系统鉴定测试软件安装软件验收支持 软件开发面临的实际问题软件开发面临的实际问题软件开发面临的实际问题3当前软件开发项目的特点 规模大： LOC1万几十万 HP激光打印驱动软件 4万110万 复杂 质量要求高满足客户需求和期望 客户满意度统计 开发和维护成本缺陷后期发现 返工成本 延误交付期四、软件需求 1. 系统需求分析 软件系统需求(1)系统需求分配软件工程组硬件系统需求(2)其它成分系统需求(n)软件需求客户最终用户系统工程组图3 系统需求分配2.软件需求 定义（IEEE-STD-610） 用户为解决某个问题、或为实现某一目标， 要求软件必须满足的条件或能力。 软件需求的三个层次 业务需求 用户需求 功能需求和非功能需求 非功能需求 过程需求：交付需求，实现需求，遵循的标准性能需求：速度，容量，可靠性外部需求：互操作性，伦理性， 机密性，安全性，使用要求 业务需求业务说明使用实例用户需求功能需求约束条件非功能需求软 件 需 求 规 格 说 明图 4 软件需求的层次质量功能展开（QFDQuality Function Development） 客户需求 常规需求：客户明确提出 期望需求：并未明确提出的潜在需求， 不 言而喻的需求 兴奋需求：客户未想到，若实现客户 感到意外分配需求的实例 系 统 需 求ACCS应能使汽车保持在预期车速的2KMH范围内行驶分配给硬件的需求硬件应能使车速在规定的精确度1.5KMH范围内分配给软件的需求软件应能在车速超出预期车速0.5KMH时给硬件加/减速命令软 件 需 求软件应能：读入当前车速值计算当前车速与预期车速之差若差值0.5KMH给出加/减速命令图5 汽车限速系统ACCS的需求分配3CMM 2级 关键过程域需求管理（KPA RM）中对软件需求的解释： 分配需求（allocated requirements）： 分配给软件的系统需求 （1）分配需求包括： 影响和确定软件项目活动的非技术性需求 （在合同条款中规定），如：要交付的产品交付日期里程碑 软件的技术需求，如：最终用户、操作人员、支持或集成的功能性能需求设计约束条件编程语言界面需求 用于确认软件产品满足分配需求的验收准则（2）分配需求应当是：以软件来实现是可行的，而且是适合的；已得到清晰而正确的阐述；相互之间是一致的；可以测试的。 同时，分配需求应当：被管理和控制（如必要可纳入软件配置管理）是制定软件开发计划SDP的基础是制定软件需求的基础 （3）与分配需求相关的组：软件评估组系统工程组系统测试组软件质量保证组SQA合同管理组文档支持组 五、需求工程 1需求工程需求开发需求管理 获取需求分析需求定义需求验证需求需求变更控制需求跟踪需求状态跟踪需求文档版本控制需求开发需求管理需求工程图6 需求工程的构成用户/系统市场管理者初始需求变更的需求获取,分析,定义,验证需求控制需求变更需求规格说明项目环境需求开发需求管理图7 需求开发与需求管理2需求开发 （1）获取需求确定目标用户、服务对象明确用户代表用户培训了解实际业务和业务需求（2）分析需求分清功能需求、性能需求、使用需求必要性可行性（3）定义需求编写软件需求规格说明（SRS）作用要求：完整、正确、可行、无歧意、可验证形式：图、表、文字（4）验证需求联合评审 六、需求变更1 、难于完全避免 初始需求变更的需求对问题的初始理解对问题的新理解时间图8 需求的变更2、需求变更原因分析1) 单纯的用户因素 2) 市场形势变化 3) 系统因素 4) 工作环境和要求变化 5) 需求开发的缺陷 需求分析、定义和评审不充分 与用户沟通不畅 3、需求变更对软件开发的影响 使变更前开发工作和成果失效 返工成为被迫采取的对策 工作量及资源投入的增加使开发成本提高 项目完成时间后延 4、需求变更失控可能导致的后果 未受控的需求 变更引起需求 和实现不一致 需求文档V1系统实现V1系统实现V2需求变更 受控的需求 变更使需求和实现一致 图7 未受控及受控的需求变更 需求文档V1需求文档V2系统实现V1系统实现V2需求变更5.降低需求变更风险的策略 与用户充分沟通与用户共同明确确定的需求的意义 项目开发工作项目开发组织用户* 产品后续开发工作的基础* 产品维护工作的重要参考* 对用户的承诺* 关系到项目开发工作的投入、交付期和产品质量* 关系到能否如期获得所需的产品* 作为合同的附件，关系到双方的权益* 是产品验收的依据向用户说明需求不确切或频繁变更对开发工作的冲击使用户理解过多变更最终对用户不利 与用户共同确定需求，作为合同附件， 签字生效 合同中含有对需求变更的条款 采用原型方法开发，或螺旋模型开发 项目计划中适当留有余地（时间进度、人力投入、 费用等） 严格实施变更控制 七、需求变更控制要求 1变更控制的策略（1）所有需求变更必须遵循需求变更控制规程实施变更。（2）需求变更提出后是否被接受，应由专门的组织变 更控制委员会（CCBChange Control Board）审查决定。（3）不得以任何理由删除和修改需求变更的原始文件。（4）应将已接受的需求变更通知到所有相关人员。（5）已接受的需求变更应能追溯到批准的变更请求。（6）对项目的需求赋予状态属性，以利于需求变更的控制。 2需求变更影响的控制 按CMM2级RM KPA的要求，由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作：识别评价风险分析编制文档制定计划传达给受影响的小组和人员跟踪直至结束3变更控制的步骤 （1）提出变更请求（2）审理变更请求，进行变更影响评估。评估内容包括：变更所需人力投入变更对原计划安排的影响估计变更引起的成本增加（3）批准变更请求（4）取得用户的认可（5）修订项目计划（6）实施变更（7）验证变更 批准提出变更请求变更影响评估评审评估报告审批用户认可修订项目计划实施变更验证变更结束拒绝修正图10 需求变更控制流程八、需求变更控制实施 1需求变更请求（1）内容申请号变更说明变更类别影响分析变更请求状态变更请求日期 （2）需求变更请求实例（表三） 项目名：XYZ变更申请号11 日期：23 Feb 1998变更说明IS-41 分析器对CDMA的支持影响分析 对CDMA的配置模块和分析器无影响 TDMA码可复用 受影响的模块是： CGAAPP模块，需对IS-41单独进行规范性分析 CDMAPP01模块 （a） TRIS41R01按TRCDMARS 41R01复制 （b） 使用纯虚拟对TRCDMAR01建立 （c） Actual Call Mode Manager 并重新定义 SILVER 06 GUIAPP+ 模块：在资源表中加入IS-41工作量5 人日计划时间无需重大变动状态将并入新的CDMA软件包2需求变更累积影响的跟踪 （1）需求变更累积影响跟踪的意义和作法累积影响变更累积表（2）需求变更累积表实例（表四） 表四需求变更累积表 需求变更号需求变更时间变更说明工作量状态118/2规定使用情况统计322/2结束2演示期用户阻塞2未结束3演示期用户强迫退出2未结束418/2用户信息归档527/2结束5演示期关闭窗口1未结束6演示期保存扩展数并在需要时恢复10未结束7演示期能够在特定节点启动2未结束8演示期删除时列出所有节点1未结束918/2注释（建立删除批准修改等）10未结束1023/2PENETCONFIG支持netconfig 格式10未结束1123/2IS-41分析器IS-41分析器对CDMA的支持51/3结束总计513需求控制流 （1）需求状态及其演变软件需求在后继阶段开发工作中将逐步展开，加以实现。在不同的开发阶段软件需求以不同的形式进行着状态的演变。例如：需求阶段从获取的需求到定义的需求建议阶段制定出项目计划以后演化为承诺的需求设计阶段设计工作完成并在验收后成为设计的需求编码阶段完成编码和单元测试后成为实现的需求测试阶段完成确认测试后成为完成的需求 开发阶段需求状态需求建议设计编码测试获取定义承诺设计实现完成图11 生存期各阶段需求 状态的演变九、可追溯性管理 1 需求可追溯性与需求变更控制随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作产品之间存在的继承关系可追溯性矩阵2可追溯性管理的目标使每一项需求均能追溯到前后继承关系的脉络清晰可见3两类不同的追溯（1）向前追溯（2）向后追溯 4可追溯性矩阵 （1）矩阵的作用 可防止遗漏为评审提供方便便于进行变更影响追踪、分析和检查（2）矩阵的建立与维护（3）矩阵的应用完整性检验考察有无需求遗漏的情况有无冗余代码检查所有性能需求是否已被测试用例测试对集成测试计划和系统测试计划进行交互检查需求变更控制需求变更后相关的工作产品受影响的部分应随之变更更新需求规格说明，同时要更新追溯矩阵每增加一项需求，应在追溯矩阵中得到体现 表五 追溯矩阵实例 12345678需求号需求描述概要设计文档索引号对应的设计(功能,结构,数据库)实现(程序,类,继承类)单元测试用例集成/系统测试用例验收测试用例1.1.2利用收集的数据实现亮点的实时集成5.3.2数据采集与亮度控制器接口PB405数据采集#12#46#11CICS203亮点控制器启动#1#47#11十、CMM 2级 RM KPA 需求管理（RMRequirements Management）是CMM 2级的第1个关键过程域。需求管理的目的是要在客户和将处理客户需求的软件项目之间形成共同的理解。这种共同理解应该体现在：客户需求的文档和对客户需求的控制中使项目的计划、产品和活动都应与需求一致 2级RMSPPSPTOSSMSQASCM目标G1G2约定能力活动测量验证C1Ab1Ab2Ab3Ab4Ac1Ac2Ac3M1V1V2V3图13RM KPA 结构1目标与活动 目标目标1：分配给软件的系统需求应是受控的， 以利建立软件工程和管理的基线活动1：在分配需求被纳入软件项目之前， 软件工程组应对其进行评审目标目标2：软件计划、产品和活动要与分配给软件的 系统需求保持一致活动2：软件工程组将分配需求作为软件计划、 工作产品和活动的基础活动3：评审对分配需求的变更，并将变更纳入 软件项目2约定与能力 约定约定1：项目要遵循一个书面的组织方针来管理 分配给软件的系统需求能力1：为每个项目规定分析系统需求并将其分 配给硬件、软件和其它系统成分的职责能力2：编制分配需求文档能力3：为管理分配需求提供足够的资源和资金能力4：软件工程组人员和与软件相关的其它组 人员要接受培训，以利于完成他们的需 求管理活动 3测量与验证 测量测量1：进行测量，并将测量结果用于确定对分配 需求所作管理活动的状态验证1：高级管理者定期评审管理需求分配的活动 验证2：项目经理定期地也要在特定事件出现时 审管理需求分配的活动验证3：软件质量保证组评审和（或）审核管理 需求分配的活动和工作产品，并报告结 果 4入口任务验证出口（ETVXEntry, Task, Verification and eXit (表六 ）入口条件入口条件 任务任务 出口条件出口条件 1方针 （C1） 2职责 （Ab1） 3文档化需求 （Ab2） 4评审和(或)审核 （Ab3 ）5 5人员培训 （Ab4） 1.1.需求纳入之前应进行评审 （Ac1）2.2.需求作为计划、工作产品和活动的基础 （Ac2） 3.3.变更评审和纳入 （Ac3） 1需求基线化 （G1） 2一致的需求、计划、产 品和活动 （G2） 3基线化需求成为受控的 工作产品 4对需求基线作文档化的、 经评审和批准的变更 验证验证 1高级管理者评审 （V1）2项目经理评审 （V2）3SQA评审和(或)审核 （V3）4RM活动状态的测量 （M1）
