5.需求分析与建模

使用策略
废弃策略 追加策略
三个问题确认需求分析是否过关
问题一：需求百度文库否已经考虑到了所有的应用场景？ 问题二：需求描述会给其它人带来歧义吗？
一是尽量从用户的角度来考虑问题。 二是在需求描述中，最好能够配有实际案例。
问题三：是否详细定义了可靠性？
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
周期二：确定需求细节
确定行为需求的细节 确定结构需求的细节 周期二的产物
确定行为需求的细节
确定结构需求的细节
周期二的产物
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
其他需求分析
其他需求分析：设计约束
非技术因素决定的技术选型 预期的使用环境 预期的软硬件环境
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
需求分析的工具列表
原型设计模型工具交互原型设计软 件AxureRPPro5 StarUML工具 Visio工具 FreeMind工具思维导图软件
业务实体分析
任务概述 类图
名称 属性 操作
E/R图
实体 属性 关键属性 关系
角色与使用场景分析
用例分析技术概述
用例图+用例描述
参与者与用例
用例实例是在系统中执行的一系列动作，这些动作将生成特定 执行者可见的价值结果。 一个用例定义一组用例实例。 用例场景是有步骤的 用例场景是有目标的 用例是有路径的。
业务流程改进(BPR)的ESIA策略
E：清除低效环节 S：简化瓶颈点 I：整体资源 A：将烦琐的任务实现自动化
业务流程分析(续)
业务流程分析的要点
流程是有层次的 流程是有类型的
生产性流程 管理性流程 支持性流程
业务流程分析的产物
跨职责流程图 活动图 数据流图(DFD)
建模的要点
设计要考虑到计划之外的变化 设计要文档化，能够使不熟悉的新手也可以有效地利用 用可视化的模型表述架构，有助于理解变化所代表的含义
建模的原则
选择创建什么模型对如何动手解决问题和如何形成解决方案有着 深远的影响 每一种模型可以在不同的精度级别上表示 最好的模型是与现实相联系的 单个模型是不充分的，对每个重要的系统最好用一组几乎独立的 模型去处理
接口需求 非功能需求的追踪 设计约束
其他需求分析：接口需求
使用者 内容与格式 设计约束
其他需求分析：非功能需求的追踪
ISO/IEC 9126(GB/T 16120-1996) 适合性 准确性 功能性 互操作性、互用性（兼容性） 依从性 安全性 成熟性 可靠性 容错性 易恢复性 易理解性 易用性 易学习性 易操作性 时间特性 效率 资源特性 易分析性 易改变性 易维护性 稳定性 易测试性 适应性 易安装性 可移植性 遵循性 可替换性
用例之间的关系
包含 扩展 泛化
周期一的产物
工作任务说明
结合业务流程、报表的需求，梳理出结 构框架(领域模型)和行为脉络(流程图>用例模型) 业务事件分析 报表分析
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
需求分析的基本概念
概述 在需求开发中的重要性 需求分析的内容 需求分析困难的原因 需求分析的方法：原型化 三个问题确认需求是否过关
概述
需求分析就是把客户的功能描述转化 为软件人员所能理解的功能描述，并 在客户描述的基础上去除不合理的地 方，补充系统缺失的地方，最后为系 统的概要设计，详细设计提供准确， 有效的数据基础。
业务流程为主线索的分解 程序结构为主线索的分解 基于场景的分解 基于数据的分解
提炼 清除矛盾
建模的目标与要点
需求建模的过程远比建模的结果更重要 建模的目的
帮助我们按照实际情况或按我们需要的样式对系统进行可视化 提供一份详细说明系统的结构或行为的方法 给出一个指导系统构造的模板 对我们做出的决策进行文档化
选择建模工具的要点
正确认识建模方法论 正确认识UML
需求分析的误区
创意和求实 解剖的快感 角度和思维 程序员逻辑
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
周期一：理清框架与脉络
业务流程分析 业务实体分析 角色与使用场景分析 周期一的产物
业务流程分析
任务概述 与流程管理理论的关系
流程的目标性、内在性、整体性、动态性、层次性、结 构性 工作流实现的本质是原子级流程积木的识别与串接 流程设计的原则
流程以产出为中心，而非任务为中心 让那些需要得到流程产出的人自己执行流程 将决策点位于工作执行的地方，在业务流程中建立控制程 序 流程多样化，应场景不同而变化 单点接触客户
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
要点与误区分析 需求分析到底做什么 建模的目标与要点 选择建模工具的要点 需求分析的误区
需求分析到底做什么
需要分析就是先分解、再提炼，在这个过 程中消除矛盾。 分解
前置条件 后置条件 基本事件流 扩展事件流
编写事件流的注意
使用简单的语法：主语明确，语义易于理解； 明确写出"谁控制球"：也就是在事件流描述中，让读者直观地了解是参与者 在控制还是系统在控制； 从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是第三者 的角度； 显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键做 为一个事件就是不合适的）； 显示参与者的意图而非动作（光有动作，让人不容易直接从事件流中理解用 例）； 包括"合理的活动集"（带数据的请求、系统确认、更改内部、返回结果）； 用"确认"而非"检查是否"：（如系统确认用户密码正确，而非系统检查用户 密码是否正确）； 可选择地提及时间限制； 采用"用户让系统A与系统B交互"的习惯用语； 采用"循环执行步骤x到y，直到条件满足"的习惯用语。
概述(续)
需求分析：将技术语言和业务语言统一
概述(续)
需求分析=提取、抽象、升华 提取出核心、主要、急迫的业务，明晰 业务流程 运用管理思想，优化业务流程 进行业务分类，规划系统蓝图 详细描述软件功能点 需求分析的质量控制
在需求开发中的重要性
需求分析的内容
绘制关联图 创建开发原型 分析可行性 确定需求优先级 为需求建立模型 编写数据字典 应用质量功能调配
需求分析与建模
2009年09月
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
需求分析困难的原因
客户说不清楚需求 需求自身经常变动 分析人员或客户理解有误
需求分析的方法：原型化
原型类型
探索型
目的是要弄清楚对目标系统的要求,确定所希望的特性,并 探讨多种方案的可行性.
实验型
用于大规模开发和实现前,考核方案是否合适,规格说明是 否可靠.
进化型
目的不在于改进规格说明,而是将系统建造得易于变化,在 改进原型的过程中,逐步将原型进化成最终系统。
用例陷阱
1. 2. 3. 4. 5. 连用户都不理解的用例 用例太多啦 过于复杂的用例 描述特定用户界面元素和行为的用例 不再使用其他需求模型
主题
需求分析的基本概念 20条法则 要点与误区分析 周期一：理清框架与脉络 周期二：确定需求细节 其他需求分析 需求分析工具 需求分析实践
需求分析实践
Use case：用例 User Story：用户故事 Feature：特征驱动
用例
用例
用例
用例
参与者，Actor 用例，Use case 事件流
20条法则
1. 分析人员要使用符合客户语言习惯的表达 2. 分析人员要了解客户的业务及目标 3. 分析人员必须编写软件需求报告 4. 要求得到需求工作结果的解释说明 5. 开发人员要尊重客户的意见 6. 开发人员要对需求及产品实施提出建议和解决方案 7. 描述产品使用特性 8. 允许重用已有的软件组件 9. 要求对变更的代价提供真实可靠的评估 10. 获得满足客户功能和质量要求的系统 11. 给分析人员讲解您的业务 12. 抽出时间清楚地说明并完善需求 13. 准确而详细地说明需求 14. 及时作出决定 15. 尊重开发人员的需求可行性及成本评估 16. 划分需求的优先级（商业价值、交付成本、交付日期、交付复杂程度、风险、 与其它需求的关系、何时需要该需求等因素） 17. 评审需求文档和原型 18. 需求变更要立即联系 19. 遵照开发小组处理需求变更的过程 20. 尊重开发人员采用的需求分析过程