第四章-软件项目需求管理

第四章软件项目需求管理商务教研室徐建华2010年3月学习目标和能力要求了解软件需求的定义；了解软件需求开发的过程；了解需求建模的方法。需求管理在项目开发路线图的位置合同管理

生存期

需求管理任务分解项目进度规模估算质量计划配置计划风险计划团队管理项目度量集成项目跟踪控制

项目结束软件项目需求概述

软件需求是软件项目最关键的一个输入；具有模糊性、不确定性、变化性和主观性等特点；需求问题通常是最主要、最普遍的问题源。软件需求的定义需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。软件需求的层次业务需求用户需求功能需求软件需求规格非功能性需求质量特性约束和假设系统需求软件需求的类型功能需求性能需求环境需求用户界面需求资源使用需求成本消耗需求开发进度需求现实需求预先估计以后系统可能达到的目标需求管理的重要性软件需求管理过程需求分析编写需求规格需求验证需求获取需求变更需求确认需求变更软件需求管理过程-需求获取用户要求

扩展需求（开发中产生的需求）基线需求（原始需求）软件需求与用户进行交流获取需求的注意事项识别真正的客户正确理解客户的需求具备较强的忍耐力和清晰的思维说服和教育客户软件需求管理过程-需求分析需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。

需求分析模型需求分析的时间1、设计方案的时候2、项目开始的时候3、接管一个项目的时候4、需求变更的时候需求分析的方法1、头脑风暴2、专家评审3、焦点会议组需求分析的难点1、问题的复杂性2、交流的障碍3、不完备性和不一致性4、需求的易变性软件需求管理过程-需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书（SRS）（SoftRequirementSpecification）。需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样做”；要求使用面向处理的规格说明语言（或称系统定义语言）；如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中；规格说明必须包括系统运行环境；规格说明必须是可操作的；规格说明必须容许不完备性并允许扩充。规格文档参考引言系统定义应用环境功能规格性能需求产品提交实现约束质量描述其它签字认证软件需求管理过程-需求验证需求的正确性——所有需求是否正确？需求的一致性——各种需求是否矛盾？需求的完整性——需求是否有遗漏？需求的可行性——需求是否实际可行？需求的必要性——是否客户的真实需要？需求的可检验性——是否可测试来检验需求？需求的可跟踪性——需求是否可跟踪检查？最后的签字。案例分析—“东软网上超市”需求分析甲方：“Neu-Sky东软天空”网站乙方：新空网络科技有限公司项目名称：开发“东软网上超市”系统平台甲方提出原始需求乙方对甲方的需求进行分析并制定需求规格甲乙双方进行头脑风暴。甲乙双方进行需求确认。软件需求管理过程-需求变更需求是永远变化的。必须接受“需求会变动”的事实。对待变更的正确处理方法：根据变更的输入，按照变更控制系统规定的审批程序执行，通过严格审查变更申请后，决定项目变更是否应该得到批准或拒绝。需求变更控制流程变更申请需求方开发方忽略选择变更方式SCCB软件配置管理委员会评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划需求变更提交单软件基线产品修改提交单申请人韩万江申请日期2001．10．11项目名称项目管理系统阶段名称系统设计文件名称见下说明修改内容人员信息应包括如下的内容：人员编码（char(6)）;姓名密码工作类型（char(1)）入司时间（yyyy.mm.dd）：可空转正时间（yyyy.mm.dd）：可空离司时间（yyyy.mm.dd）：可空毕业学校（25汉字）：可空学历（10汉字）：可空技能（100汉字）：可空备注

验证意见*同意变更验证人**章昆验证日期2001．10．11SCCB韩万江，章昆，江浩

填表人韩万江需求管理与项目管理的关系项目需求是制定项目计划，开发项目产品和从事项目活动的依据。需求管理是项目管理的源头。项目的计划、项目的开发活动及开发的产品应与项目需求保持一致，随需求的变化而调整。需求建模的基本方法原型分析方法结构化分析方法用例分析方法关键功能列表方法其他原型分析方法定义按照用户的需要，快速形成一个操作流程界面。可能只是一个框架，具体的功能没有实现，只是结果。静态的操作流程，以便与用户快速就需求达成一致。主要考虑系统的功能需求，很少考虑非功能需求。需求分析原型开发原型评价原型修正原型分析方法图示原型方法的类型进化型开发出来用于了解问题，并形成被交付软件的部分或全部的基础。抛弃型开发出来获以便更多地了解问题或探究可能的方案的灵活性或者合理性，是尝试性软件，不用于被交付软件的实际部分。结构化分析方法定义（SA,StructuredAnalysis）20世纪70年发展起来的面向数据流的方法。是一种自顶向下逐步求精的分析方法。根据软件内部数据传递、变换的关系进行分析的。结构化分析方法的技术手段数据流图(DFD)数据字典(DD)系统流程图数据流图-DataFlowDiagram是一种描述软件系统逻辑模型的图形符号表示数据的起始点和终点表示对数据的加工处理表示数据流,箭头表示数据的流动方向表示对数据的存储描述银行取款过程的数据流图数据字典-DataDictionary描述系统中涉及的每个数据,是数据描述的集合,通常配合数据流图使用,用来描述数据流图中出现的各种数据和加工。数据字典包括：数据项——数据元素。数据流——由数据项组成的数据流。数据文件——表示对数据文件的存储。数据字典部分符号定义注释符,表示两个*之间的内容为对条目的注释*……*可选符,表示对()中的内容可由设计员决定取舍

()重复符,表示对{}中的内容可视需要重复使用{}选择符,表示对[]列举的值可以任取其一[]加+等于,定义为=含义符号系统流程图-FlowChart是描述物理系统的工具。用图形符号表示系统中的元素。表达了系统中各个元素之间的信息流动情况。可分为程序流程图和系统流程图。系统流程图部分符号系统流程图设计步骤分析现实程序必要的设备。分析数据在各种设备之间的交换过程。用系统流程图或程序流程图的基本符号描述其交换过程。外事部门出访流程图举例制定出访计划开始出访组团登记出访计划表出访团组基本情况是否需要办理护照护照管理护照登记表护照卡申请护照签证管理结束是·否临时出访计划表申请出国护照事项表申请出国签证事项表计划是否落实是否是否本单位人员是否结束用例（UseCase）分析方法用例需求分析方法采用一种面向对象的情景分析方法；用例是系统向用户提供一个有价值的结果的某项功能；所有的用例结合起来就构成了用例模型；从用户角度出发考虑的功能需求；通过用例来驱动开发用例只关心用户的需求，而不关心如何来实现这些需求；“用例驱动”使开发过程遵循这样一个流程：定义用例

设计用例

测试用例。统一建模语言UML（UnifiedModelingLanguage）传统开发UnifiedModelingLanguage统一建模语言，是一种通用的模拟语言。Booch,Rumbaugh

和Jocobson

（“三朋友”）基础上发展起来的。1997年11月国际对象管理组织OMG批准将UML作为基于面向对象技术的标准建模语言。UML制定了一整套完整的面向对象的标记和处理方法。UML需求视图用例图（UsecaseDiagram）顺序图（SequenceDiagram）状态图（StateDiagram）活动图（ActivityDiagram）用例图用例（Usecase）：系统所提供的功能描述角色（Actor）：可能使用用例的人或者外部系统UML图符举例用例图举例顺序图顺序图展示了几个对象之间的动态协作关系，主要用来显示对象之间发送消息的顺序，还显示对象之间的交互，即系统执行某一特定时间点所发生的事。

顺序图示例状态图状态图是对类描述的补充，它说明该类的对象所有可能的状态以及那些事件将导致状态的改变。它是一个类对象所可能经历的所有历程的模型图。活动图活动图用来描述执行工作