清华大学郑人杰 殷仁昆教授 《软件工程讲义》-02.ppt

软件工程第二章 需求分析 2.1 系统分析 2.2 软件需求分析 2.3 结构化分析方法 2.4 快速原型化方法 2.5 需求定义与评审 2.1 系统分析 基于计算机的系统的系统元素包括硬件、软件、人、数据库、文档和过程。 系统分析的目标 识别用户要求 评价系统的可行性，进行经济和技术分析 把功能分配给硬件、软件、人、数据库和其它系统元素 建立成本和进度限制 生成系统规格说明 识别用户要求 分析员必须考虑以下问题： 识别希望的功能和性能范围; 确定系统的功能、性能、约束和接口; 可行性研究 经济可行性 成本–效益分析 推荐可行的方案 编写可行性研究报告 成本估算 专家估算技术（Delphi技术） 成本估算模型（COCOMO） 效益估算 投资回收期 纯收入 投资回收率 技术可行性 技术风险分析 技术解决方案的实用性 使用的技术实用化程度 技术解决方案合理程度 技术资源的可用性 参与人员的工作基础 基础硬件/软件的可用性 软件工具实用性 法律可行性 侵权和责任问题 专利法 著作权法 软件保护条例 用户类型：外行型／熟练型／专家型 操作习惯 使用单位的计算机使用情况 使用单位的规章制度 2.2 软件需求分析 需求分析是一项软件工程活动，其目的是： 清楚地理解所要解决的问题，完整地获取用户要求； 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约束。 2. 需求分析的任务 需求分析是一项软件工程活动，它包括： 需求获取 刻划出软件的功能和性能； 指明软件与其他系统元素的接口； 建立软件必须满足的约束。 需求建模 需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和处理过程设计的模型。 需求规格说明 需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。 需求评审 需求分析研究的对象是用户的要求。 必须全面理解用户的各项要求，准确表达被接受的用户要求。 只有经过确切描述的软件需求才能成为软件设计的基础。 软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统 “做什么” 的问题。 3、需求获取 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。 需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。 获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。 软件需求的层次 业务需求 反映了组织或客户对系统、产品高层次的目标要求，它们一般在项目视图和范围文档中给予说明。 用户需求 描述用户使用软件需要完成哪些任务，它们可通过使用实例图或脚本说明加以阐明。 功能―非功能需求 定义了开发者必须实现的软件功能，而非功能需求如表所示: 需求获取过程 需求获取包括以下活动： 发现和分析问题 发现问题症结，并分析问题的原因/结果关系。 获取需求 根据对问题的理解定义需求。 使用调查研究方法收集信息； 遵循需求获取框架，按照三个成分观察：即数据、过程和接口。 需求归档 以草稿形式归档调查结果。形式有用例、决策表、需求表等。 需求获取技术的基本特征 好的需求获取技术，对于规范需求获取活动，高效准确地获取需求定义，是十分重要的。 好的需求获取技术，应具有如下基本特征： 提供便于沟通的工具，如易于理解的语言和直观的图表； 提供定义系统边界（交互）的方法； 提供支持抽象的机制，如“分解”、“映射”等； 鼓励分析员使用面向问题的术语思考问题，编写文档； 为分析员提供多种可供选择的解决方案； 适应需求的变化。 适于以上特征的需求获取方法： 基于数据流图的结构化分析方法； 基于用例（use case）的建模方法。 需求获取技术的关键点在于： 深入浅出 需求获取要尽可能全面、细致。 获取的需求是个全集，系统真正实现的是个子集。分析时的调研内容并不都纳入到新系统中，目的在于以后的扩充。 以流程为主线 在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。 流程描述有宏观，也有微观。既要强调总体的业务流程、全生存周期的业务流程，又要对流程细化，有分支的业务流程。 需求获取应遵循的原则 抽象和分解是在人们认识世界和改造世界的长期实践中总结出来的行之有效的原则，在需求获取的过程中需遵循的三个原则： 分解：捕获问题空间的整体 – 部分关系。如问题／子问题分解； 抽象：捕获问题空间的一般化 – 特殊化关系。如问题的不同变型； 投影：捕获问题空间的多维视图。即从不同角度考察。 需求获取的步骤 软件开发项目和组织文化的不同，对于需求