软件工程需求析--需求分析.ppt

第5章 需求分析 可行性研究通过以后，下一步就要根据草拟的开发计划，展开详细的需求分析活动。 软件需求分析，是详细分析需求，并建立需求分析模型的阶段 第5章 软件需求分析 5.1 需求分析概述 5.2 结构化分析方法 5.3 数据流图的绘制 5.4 编制数据字典 5.5 加工逻辑的分析与表达 5.6 需求验证与评审 5.1 需求分析概述 5.1.1 需求分析的任务、特点、主要困难 5.1.2 人员组成 5.1.3 分析师的角色 5.1.4 需求分析的活动和原则 5.1.1 需求分析的任务 完成“分析建模”; 拟定“确认测试”计划 修订“开发计划” 编写“需求规划说明书” 需求评审 1. 分析建模 针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规约; 准确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。 1. 分析建模 发掘需求——调查需求、挖掘潜在需求、预测未来可能的需求； 需求求精——对模糊不清的用户需求明确、精化； 逻辑建模——在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型； 形成规约——将双方达成共识的需求文档化、模型化，这份文档被称为“需求规约”和“需求规格说明书”，它将是后需活动开发方努力实现的目标 2. 拟定“确认测试”计划 有了共同的需求约定以后，就可以制定“确认测试”计划，它是用户验证软件是否满足需求的依据； 这个计划到综合测试后期执行。 3. 修订开发计划 系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计划更准确一些。 4 . 编写“需求规划说明书” 需求分析阶段的成果集中体现在“需求规格说明书”中，这是一个里程碑； 有明确的格式和内容 5. 需求评审 需求评审是“质量保证活动”的内容； 体现出瀑布模型的“文档驱动”特点 由项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组； 阶段性成果（主要文档）包括： 需求规格说明书 细化的项目计划 确认测试计划 主要特点: 面向问题域（即用户业务领域） 只关注“逻辑”，不考虑“物理” 只研究应该“做什么？”，暂不考虑用什么手段、如何实现，即“怎么做”的问题； 用数流据图、数据字典、加工描述等工具建立逻辑模型 面临的主要困难 需求分析活动面临的挑战： 使用有效的软件工程方法克服复杂性 建立分析员与用户的有效沟通 使用有效的工具，克服需求表述的二义性 5.1 需求分析概述 5.1.1 需求分析的任务、特点、主要困难 5.1.2 人员组成 5.1.3 分析师的角色 5.1.4 需求分析的活动和原则 5.1.2 人员组成 如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员； 参与团队的用户包括： 企业负责人、部门负责人、专业岗位上的员工； 参开团队的开发人员包括： 系统分析师、数据管理员； 在需求评审时，还需要”可行性分析“和”系统设计“阶段的主要人员参与； 5.1 需求分析概述 5.1.1 需求分析的任务、特点、主要困难 5.1.2 人员组成 5.1.3 分析师的角色 5.1.4 需求分析的活动和原则 5.1.3 分析师的角色 是用户与开发人员的桥梁； 与项目经理合作，是开发团队的领军人物； 具体业务主要集中在可行性研究和需求分析阶段； 个人素质方面： 具有领导才能，善于沟通； 具有实干作风； 知识面宽，重在广度而不是深度； 技术全面； 有时分析师是一个团队，由若干人承担； 5.1 需求分析概述 5.1.1 需求分析的任务、特点、主要困难 5.1.2 人员组成 5.1.3 分析师的角色 5.1.4 需求分析的活动和原则 5.1.4 需求分析的活动和原则 活动主要分为： 需求获取； 分析建模； 需求评审 需求获取的目标 对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性； 把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价值的潜在需求； 需求获取中风验 需求获取隐藏着很大的风险 因为任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果，而实际情形是这种潜在的风险是客观存在的 总的原则 分析师关注的焦点是“做什么（What）”，而不是“怎么做How”，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇到什么约束？等。 这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来，影响逻辑功能的分析。 5.1.