CHP02_需求讲稿.pptVIP

软件工程第2章　需求分析 高俊涛 副教授 IBM缺陷放大模型 需求: 1 设计: 5 编码: 10 测试: 20-50 运行与维护: 200 提纲 2.1　软件需求的概念 什么是软件需求 软件需求的分类 需求分析过程 2.2　需求分析技术 2.3 需求规格说明书 2.4 需求确认 2.5 需求管理 软件需求定义 　　(1)用户解决问题或达到目标所需的条件或能力。 　　(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 　　(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。 　　软件需求的基本任务是准确回答“系统必须做什么”这个问题。 2.1 软件需求的概念 按层次划分软件需求 业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。业务需求描述了企业一组概要性的目标，概要性的目标可能要依靠多个用户目标来实现。 用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。用户需求描述了用户目标，是具体明确的任务，但还不是详细的细节。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 2.1 软件需求的概念 三类需求的关系 业务需求 项目视图与范围文档 用户需求 使用实例文档 功能需求 软件需求规格说明书 非功能 需求 2.1 软件需求的概念 概要目标层次 用户目标层次 功能层次 软件需求的非功能性需求 非功能需求:定义产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。 2.1 软件需求的概念 非功能需求 过程需求 产品需求 外部需求 软件交付 互操作性 实现方法 标准 法规 成本 可用性 软件性能 存储空间 可靠性 可移植性 安全性 软件需求分析的困难 (1)客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。 农夫和耕牛的故事 有些客户心里非常清楚想要什么，但却说不明白。 我的鞋是什么样的？ “不懂装懂”或者“半懂充内行”的客户令人恐惧 2.1 软件需求的概念 软件需求的复杂性 (2)需求自身经常变动 2.1 软件需求的概念 需求变更原因--客户方： 对信息系统的了解不够 对业务需求表达不清 对自身业务抽象程度不够 对需求重视程度不够 与开发人员配合不够 业务范围不断拓展 业务流程不断变更 管理模式不断创新 软件需求的复杂性 (2)需求自身经常变动 2.1 软件需求的概念 需求变更原因—软件人员： 沟通技巧不高 需求工程技术不精 需求人员知识储备不够 不了解客户方的业务流程 调研范围不确定 需求不够细致、明确 项目管理不规范 需求描述存在歧义 合同对客户方约束不够 个人能力或经验不足。 软件组织的能力不足 软件需求分析的基本过程-需求工程 2.1 软件需求的概念 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。 需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。 需求工程的活动可分为两大类： 一类属于需求开发，另一类属于需求管理。 需求工程 软件需求工程 2.1 软件需求的概念 需求获取 　 通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求； 需求建模(需求分析) 　为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述； 形成需求规格 　 生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约； 需求验证(需求确认) 　 以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性； 需求管理 　 支持系统的需求演进，如需求变化和可跟踪性问题。 提纲 1.1　软件需求的概念 1.2　需求分析技术 功能分析 数据分析 1.4 需求规格说明书 1.5　需求确认 功能分析工具 用例图 顺序图 活动图 界面定义 原型开发 2.3 需求分析技术：功能分析 用例图(UseCase Diagram) 用例是从系统的外部对系统进行黑盒视图描述的一种组织方法。 用例是抽象使用系统的一种方式，用户通过用例与系统交互。用例图主要的作用有三个： 获取需求 在其它环节中起指导作用 指导测试 参与者（Actor） 用例（Use Case） 指系统以外的，在使用系统或与系统交互中所扮演的角色 用例是