需访谈的个体太多 需要回答容易确定的细节问题 当你希望有个详细的结果时 使问卷表尽可能的简短。用多个短小的问 卷表替代一个长的问卷表。如果在回答了 前15-20个问题后，长的问卷表会使用户感 觉厌烦，他们就不会对其余的问题做出正 确的判断。通常，一个问卷表包含的问题 不超过10-15。
需求捕获技术－小组会议



用户访谈 收集资料 问卷表 小组会议
需求捕获技术－用户访谈

准备访谈 计划访谈日程 访谈开始和结束 引导访谈
需求捕获技术－用户访谈

准备访谈
在进行访谈前，需求分析者应该很好的理解 行业的组织结构，行业定位、项目范围和项目目 标，访谈会涉及下面内容：



组织结构报告 年度报告 长期发展计划 部门目标的陈述 已有程序手册 已有系统的演示 已有系统文档
需求分析

如果投入大量的人力、物力、财力和时间，而开发出的软件 却没人要，那么所有的投入都是徒劳。如果费了很大的精力 开发一个软件，最后却不能满足用户的要求，而要重新开发， 那么这种返工是让人痛心疾首的。例如，用户需要一个响应 时间快的软件，而在软件开发前期忽略了软件的性能要求， 忘了向用户询问这个问题，想当然地认为是开发无响应时间 这一性能要求的软件，如果当你千辛万苦地开发完成向用户 提交时才发现出了问题，是要付出很大的代价的。所以，需 求分析在软件开发过程中具有举足轻重的地位，具有决策性、 方向性、策略性的作用，我们应对需求分析具有足够的重视。 在一个大型软件系统的开发中，需求分析的作用要远远大于 程序设计。
需求获取


5）建立核心队伍：建立起典型用户的核心队伍把同类产品 或你的产品的先前版本用户代表召集起来，从他们那里收 集目前产品的功能需求和非功能需求。这样的核心队伍对 于商业开发尤为有用，因为你拥有一个庞大且多样的客户 基础。与产品代表的区别在于，核心队伍成员通常没有决 定权。 6）确定使用实例：让用户代表确定使用实例从用户代表处 收集他们使用软件完成所需任务的描述-使用实例，讨论用 户与系统间的交互方式和对话要求。在编写使用实例的文 档时可采用标准模版，在使用实例基础上可得到功能需求。
学习任务3
软件需求分析建模
主讲：陈荣保
项目开发实践
简勇 陈荣保 编著
析是指理解用户需求，就软件功能和性能与客户达成 一致，估计软件风险和评估项目代价，最终形成开发计划的 一个复杂过程。在这个过程中，用户处在主导地位，需求分 析工程师和项目经理要负责整理用户需求，为之后的软件设 计打下基础。需求分析阶段结束后，要求得到《用户需求说 明书》和《需求规格说明书》两份文档。广义上，需求分析 包括需求的获取、分析、规格说明、变更、验证、管理的一 系列需求工程； 狭义上，需求分析是指需求的获取、分析及定义的过程。需 求分析的任务就是软件系统解决“做什么”的问题，就是要 全面地理解用户的各项要求，并准确地表达所接受的用户需 求的过程。
需求获取



首先，需求获取要定义问题范围，而系统的边界往往是很 难明确的，用户不了解技术实现的细节，这样将造成系统 目标的混淆。 其次，是对问题的理解。任何一个系统都会有很多的用户 或者不同类型的用户，每个用户只知道自己需要的系统， 而不知道系统的整体情况；他们不知道系统作为一个整体 怎么样工作效率更好，也不太清楚哪些工作可以交给软件 完成；他们不清楚需求是什么，或者说如何以一种精确的 方式来描述需求；他们需要开发人员的协助和指导，但是 用户与开发人员之间的交流很容易出现障碍，往往忽略了 那些被认为是“很明显”的信息。 最后，是需求的确认。需求的不稳定性往往随着时间的推 移产生变动，使之难以确认。 为了克服以上的问题，必 须有组织地执行需求的获取活动。
需求捕获技术－用户访谈

引导访谈



避免提封闭性的问题 询问开放性的问题 使用适当的表达 重述被访谈者的回答 有效的使用沉默
需求捕获技术－收集资料

收集用户的书面需求文档 收集用户现在的业务操作流程及其改 进意见文档 收集用户现在使用的数据表和文件及 其格式，并确定数据的来源


需求捕获技术－问卷表
需求获取

3）用户群分类：产品的用户在很多方面存在着差异，例如： 用户使用产品的频度、他们的应用领域和计算机系统知识、 他们所使用的产品特性、他们所进行的业务过程、他们在 地理上的布局以及他们的访问优先级。根据这些差异，你 可以把这些不同的用户分成小组。用户类不一定都指人， 你可以把其它应用程序或系统接口所用的硬件组件也看成 是附加用户类的成员。以这种方式来看待应用程序接口， 可以帮助你确定产品中那些与外部应用程序或组件有关的 需求。将用户群分类并归纳各自特点为避免出现疏忽某一 用户群需求的情况，要将可能使都有所差异。详细描述出 它们的个性特点及任务状况，将有助于产品设计。
按 课 程 统 计
角 色 设 置
权 限 设 置
设 置 统 计 类 型
需求获取—参与者

角色及其职责描述

•谁使用了系统的主要功能？ •谁来维护和管理系统使系统正常工作？ •哪些人对系统产生的结果感兴趣？
角色获取 职责描述
角色要求系统提供哪些功能？ 角色在系统中的工作是什么？ 角色的某些功能是否必须被系统自动 实现？
选课 数据库
成绩 数据库
需求分析--实例

1 层选课数据流图
教务 人员
录入
学生
选择
教务 人员 审核 审核选课申请
同意
开设新课程
选择课程
选中
可选课程数据库
选中课程数据库
开设课程数据库
需求分析--实例

1 层成绩数据流图
学生 教师
录入
学生
考试
交卷
成绩处理
查询
查询成绩
考试题库
学生考卷
学生成绩库
需求分析
可扩展性
可移植性
本系统在数据库上可以进行移植，支持Oracle,Sybase等 数据库。
需求获取-功能实例
网上选课系统
课程管理
成绩管理
成绩统计
系统管理
开 设 新 课 程
选 课 申 请
审 核 选 课 申 请
结 束 课 程
课 程 考 试
录 入 成 绩
成 绩 查 询
按 班 统 计
处 理 成 绩 的 各 类 表
需求获取－需求人员
谁参加需求？
角色 需求分析员 客户与最终 用户 项目组 职责 调查、分析用户的需求、定义产品需求、 撰写《用户需求规格说明书》 提供必要的需求信息；确认最终需求 参与需求评审
需求获取－功能

功能性需求

软件必须实现的软件功能

非功能性需求

系统的易用性、反应速度、容错性、健壮性等等质量属性
需求分析建模
1.需求获取 2.需求捕获技术 3.需求分析 4. 需求文档的编写
需求获取

开发软件项目关键的第一步工作是什么？

软件的需求分析 理解用户对软件提出的要求

需求获取

需求获取可能是软件开发中最困难、最关键、 最易出错及最需要沟通交流的活动。对需求的 获取往往有错误的认识：用户知道需求是什么， 我们所要做的就是和他们交谈，从他们那里得 到需求；只要问用户系统的目标特征，什么是 要完成的，什么样的系统能适合商业需要就可 以了。但是实际上需求获取并不是想象的这样 简单，这条沟通之路布满了荆棘。

需求分析-用例图实例
需求分析-用例描述实例
需求分析-用例描述实例
需求分析

数据流程图的基本图例符号
外部实体 处理 数据流 数据存储

数据流程图画法

工具
Microsoft Office Visio PowerDesigner ……
需求分析--实例

0 层数据流图
学生
选择
教师
录入
选择课程
成绩处理

业务处理过程

业务数据及关系

找出元数据：数据的数据 找出中间数据：描述统计数据的数据 找出元数据和中间数据的关系
需求获取-报表
学生成绩统计表
学号 20090105001 20090105002 20090105003 20090105004 20090105005 学生 平均分 名次
需求捕获技术
需求捕获技术－用户访谈

访谈开始和结束




陈述访谈的目的，谈谈被访谈者关心的事。 讨论他们所熟悉的日常工作的过程。 怎样的变化将使你的工作更简单或更有效？暗 示被访谈者提出改进意见。 当列表中的所有领域都讨论过后，提出下面问 题： “还有什么问题我们没有讨论吗？”或 是 “我们还需要讨论些别的内容吗？” 结束会谈时，简短的总结讨论过的问题，重点 指出会谈的要点，并说出你的理解。 最后，你必须感谢被访谈者参加这次访谈。

实体-关系图
学生 课程 代码 <pi> VA4 <M> 名称 VA20 学分 N2 课程号 <pi> 0,n 选课 成绩 N3,1 0,n 授课 教师 姓名 VA20
学号 <pi> VA10 <M> 姓名 VA20 电话 I 学号 <pi>
需求文档的编写

编写用户需求报告

需求获取－非功能
主要质量属性
正确性 可靠性 易用性 安全性
详细要求
数据输入输出保持正确，界面显示无误。 本系统操作的数据是财务数据，因此必须保证所有数据 的可靠性和正确性 本系统用户界面简单，用户在经过培训以后，就能很快 上手使用。 所有操作人员都要通过用户名和密码登陆系统，特别是 B/S端用户还必须通过证书验证，才能进去系统，保 证了数据的安全性。 本系统对于用户的需求，在功能上可以进行扩展，能满 足各级财政业务上的需求。