开发过程中的 需求分析与管理 案例教学
关系您的软件工程技术实践
成功的软件项目有多少？
31% 16%
53%
成功 实现 失控 取消
2011-5-19
2
1
项目为什么会失败？
项目失败的前5个原因
需求分析不完整 缺少用户参与 缺少资源 不现实的期望 缺乏系统支持 0% 5% 10% 15%
2011-5-19
3
需求分析过程中的误解
2011-5-19 4
2
软件工程的本质分析
农民（8小时产出） 牛肉 土豆 8 32 24 48 牧牛人（8小时产出）
各自工作，各获所需的方式： 农民 牛肉 土豆 4（工作4小时） 16（工作4小时） 牧牛人 12（工作4小时） 24（工作4小时）
——摘自《经济学原理》曼昆（美国）
2011-5-19
5
需求分析的经济作用
促进分工合作； 降低交换成本；
2011-5-19
6
3
课程简介
2011-5-19 7
教学形式和目的 多人一组，按公司模拟演练。通过案例 的全过程仿真，体会项目开发全过程中： 各个阶段的划分方法和里程碑； 各个角色在各个阶段的工作和验收标准； 项目开发中的对开发过程的管理和持续质 量改进； 各类角色在具体案例中的知识要点。
? ? ? ?
2011-5-19
8
4
项目立项阶段
目标：决定干不干
需求分析阶段
目标：建立需求基线
原型验证阶段
目标：通过原型验证
迭代实现阶段
目标：实现剩余用例
项目阶段
2011-5-19
交付验收阶段
目标：上线使用
9
第一部分 项目立项阶段
2011-5-19
10
5
目标 确定项目是否能够启动。 角色 项目发起人（用户领导或市场人员等）、需求分析师、项目经理、立项 评委（相关领导、业务专家、技术顾问等） 工作 1. 分析业务问题，提出项目目标和验收标准（尽可能量化）； 步骤 2. 协调项目相关人员，协商问题解决方案（鼓励业务创新）； 3. 识别项目风险和约束条件，如进度、成本、技术要求和标准法规等； 4. 在“人、事、物”分析的基础上，根据项目约束条件，确定项目范围； 5. 初步规划项目进度和资源分配。 输入 与项目有关的任何信息 输出 初步的《用户需求分析报告》、初步的《项目计划》 说明 1、对于有些必须完成的项目（如上级下达的指令性项目），可以将该阶 段和需求分析阶段合并，一并评审； 2、初步的《项目计划》已完成两部分内容：一是包括整个项目进度和资 源分配的主计划（又称基线计划，在每个项目阶段结束时需重新调整 ）；二是用于完成下一阶段（需求分析阶段）工作的详细计划。
项目立项阶段工作要点
2011-5-19 11
案例1——订餐系统（中小型项目） 员工到食堂用餐，在路途和排队上浪费很 多时间，并且去晚了经常会吃不到想吃的食 物； 员工对食堂的满意度不高，有将近一半的 员工会选择去周边饭店用餐。因此，食堂更 无法准确预测员工需求，经常会出现有些食 物因为没有卖出去只好倒掉，而员工需要的 一些食物却已卖完的现象。
2011-5-19
12
6
需求方法简介
2011-5-19
13
主要需求方法
1.用户代表访谈 2.需求研讨会 3.原型法 4.问卷调查 5.学徒法 6.头脑风暴会议 7.联合应用设计（JAD） 8.文档“考古”
2011-5-19
14
7
用户代表访谈法
1，提出问题 2，选择面谈者
主要考虑以下人员代表。 ? 初级人员：由于他们经验不多，并不能做出很多贡献，但他们可能有新鲜的观点， 也可能有意想不到的信息。 ? 中级相关人员：由于经验丰富，这些人员对领域操作性和技术性的问题，能够提供 详细的理解，应该经常与项目领导进行面谈。 ? 管理人员和其他特殊客户：CEO有该领域的知识，并影响着项目的成功，他们无疑 是面谈的重要对象，只要有可能，应该经常与执行发起人面谈。 ? 理论家：如果有这样的相关人员，他们能够开阔你的视野。 ? 系统典型“用户”：这样的相关人员是重要的，因为他们将花更多的时间与系统打交 道。他们可能是革命精神的思想家，也可能对新系统抱有偏见。 ? “后起之秀”：这样的人将成为该领域的领导者，可以提供深刻的思想和信息。
3，计划联系方式 4，进行面谈
1）建立氛围 2）提出问题 3）如果面谈中止 4）结束会议
2011-5-19
15
需求研讨会法
需求研讨会——会前准备阶段工作流程图
2011-5-19
16
8
需求分析要点
2011-5-19
17
业务分析、范围协商过程
2011-5-19 18
9
业务分析要点 ——因（项目目标）
长久以来，银行信息系统在开发时仅仅考虑到本业务的需求，很少考虑到为 其它系统提供标准统一的信息服务，各个系统间很难实现共享和互通，形成许多信 息孤岛和信息烟囱，无法满足一体化管理和保障的需要。为了消除信息孤岛和信息 烟囱，有效整合和利用现有各种信息标准资源，推进银行信息化工作现向规范化、 成熟化迈进，需开发“信息化标准管理与服务系统”实现以下目标。 a) 汇集银行共用信息标准，建立和规范标准体系库、数据元字典库、代码标准库、 数据模型库和标准文本库，为实现银行信息资源中心打好数据标准基础（验收标准： 各类库内数据的完备率达到70%以上）; b) 提供银行共用信息标准的浏览、检索、查询以及下载服务，为所有部门提供高 效便捷的银行信息标准服务平台（验收标准：符合权限要求的用户，能在10分钟内 方便快捷地获取所需的各类银行信息标准）； c) 为标准制修定、代码管理、数据元管理、数据模型管理等银行信息标准业务提 供工作平台（验收标准：经过培训后，相关用户能方便地使用系统处理管理业务， 工作效率提高一倍以上）。 d) ……
“银行标准管理与服务系统”项目目标示例
2011-5-19 19
业务分析要点——人（相关涉众）
“银行标准管理与服务系统”相关人员分析示例
2011-5-19 20
10
业务分析要点——事（业务流程）
“银行标准管理与服务系统”标准审批业务流程分析示例
2011-5-19 21
业务分析要点——物（业务实体和报表）
“银行标准管理与服务系统”数据报表分析示例
2011-5-19 22
11
业务分析要点——规（约束条件）
可参考如下列表： ?要求交付的最后时间期限； ?财务预算金额； ?技术平台等技术要求； ?需要遵循的标准法规和管理规定； ?安全保密要求等。
2011-5-19
23
最终形成产品用例（或功能列表）
使用数据元标准 查阅标准文本
使用数据模型标准
统计标准完成情况 提交标准需求 标准使用者 标准管理者
下达任务和计划 提交标准审查意见
标准评审专家 维护标准审批流程
提交标准文稿
标准承办单位代表 ...... 后台维护人员
“后勤标准管理与服务系统”用例模型示例
2011-5-19 24
12
需求分析模型
2011-5-19
25
? 需求分析模型——主题模型
2011-5-19
26
13
? 需求分析模型——上下文范围
服务人员 收费人员 维护人员
通知用户 取报告 开单 处理 改单
收费 管理体 验项
申请体检
体检者
返回报告 申请改单 提交团队 缴费情况
体检业务 子系统
出具报告
体检并记 录结果
体检科室
查询体检 情况
客服中心 财务部门 综合科医生
2011-5-19
27
? 需求分析模型——业务流程图
2011-5-19
28
14
需求分析模型——用例图
学生注册系统
请求花名册 学生 维护选课计划 维护课程表 教授
财务系统
管理员
2011-5-19
29
从业务用例到功能用例
2011-5-19
30
15
? 项目功能分析：以业务流程为主线索
2011-5-19
31
? 项目功能分析：从业务用例到产品用例
2011-5-19
32
16
? 项目功能分析：业务边界确定
2011-5-19
33
? 项目功能分析：从业务用例到产品用例
2011-5-19
34
17
用例要点——确定用例范围
? 区分业务用例和产品用例（网上订单系统确定边界的例 子）； ? 产品用例是涉众利益协调的结果，如业务模式的确定、边 界的划分等； ? 用例图可分级，按“一页纸原则”引入次级用例（图书管理 的例子）； ? 对于GUI系统可酌情使用用户界面图，提高用例的真实感 （单位列表的例子）；
2011-5-19
35
用例要点——确定角色
? ? ? ? 应以责任边界，而不是物理边界识别角色，现实中 的一个人可能有多个角色； 外部系统也是角色，如财务系统； 角色间可以使用继承关系简化设计（药房管理员的 例子）； 产品用例中的角色是实际使用系统的岗位名；
2011-5-19
36
18
用例要点——确定用例
? ? ? 可梳理“事”将用例找出并串起，可分析“人”查找遗 漏用例； 别把动作过程当作用例（如设置查询条件），用例 应该能为角色带来业务价值； 采用用户的视角和术语命名用例，常为动名词。如 银行管理帐户的例子。
2011-5-19
37
总结阶段工作流程图
2011-5-19 38
19
立项研讨、评审会成果——用户需求分析报告示意
一般应该包括如下几个部分。 ? 1 项目背景 ? 1.1 业务问题 ? 1.2 业务目标和验收标准（因） ? 2 业务分析 ? 2.1 涉众人员分析（人） ? 2.2 业务流程分析（事） ? 2.3 数据报表分析（物） ? 3 限制条件（规） ? 3.1 运行环境约束 ? 3.2 质量要求 4 功能分析 ? 4.1 用例图 ? 4.2 进度安排
2011-5-19 39
案例1——订餐系统（中小型项目）
案例练习与点评
2011-5-19
40
20