• 通常是在确定了商业要求或者发现新市场、 新服务时，项目才开始，
• 相关人员会进行粗略的可行性分析、并确 定项目范围后开始。
导出需求
• 看似简单：
– 询问客户，系统或者产品的主要目标是什么？ – 想要实现什么？ – 产品如何满足业务要求，如何用于日常工作？
• 实则困难
为何导出需求十分困难？
• 范围问题
–将系统看作若干功能模块的集合，进行子功 能分解，最终形成系统雏形。
• 结构化分析法
–面向数据流的结构化分析方法 (SA) –面向数据结构的Jackson方法 (JSD) –面向数据结构的结构化数据系统开发方法
(DSSD)
常用的分析方法
• 信息建模法
–借助各种有序模型（功能、信息、数据、控制、 决策等），来分析系统。常用工具：E－R图
需求分析的重要性
“构建一个软件系统最困难的部分是确 定构建什么。其他部分工作不会像这部分 工作一样，在出错之后会如此严重的影响 随后实现的系统，并且在以后修补竟会如 此的困难。”
－－Fred Brooks
• 问题：
对于任何项目是否一定要严格执行全面的 需求分析呢？
需求分析的过程
(1) 问题识别
逻辑视图给出的是系统要达到的功能 和要处理的信息间的关系，而不是实 现细节。
物理视图给出的是系统处理功能和数 据结构的实际表示形式，这通常由设 备本身所决定。
小结：需求分析方法
本章主要内容
• 软件需求分析的任务和过程 • 结构化分析方法 • 原型化方法 • 动态分析方法 • 数据及数据库需求
需求（Requirements)
• 定义:需求是关于系统将要完成什么工作 (what)的一段描述语句,是指用户或者客户 对要开发的软件系统的要求。
–它们必须经过所有相关人员的认可,其目的是 彻底解决客户的问题。
确定对目标系统的综合要求，即软件的 需求
提出这些需求实现条件，以及需求应达 到的标准
软件的需求包括：
• 功能需求 • 性能需求 • 环境需求 • 可靠性需求 • 安全保密要求 • 用户界面需求
• 资源使用需求
• 成本消耗需求
• 开发进度需求
• 预先估计以后 系统可能达到 的目标
问题识别的另一项工作是建立分析所需要 的通信途径，以保证能顺利地对问题进行 分析。
• 限制需求
– 不能头脑发热 – 认清真正的需求 – 定义需求的边界
• 引导需求 • 控制需求
精化
• 是一个分析建模动作，由一系列的建模和 求精任务构成。
• 最终形成一个分析模型，定义了问题的信 息域、功能域和行为域。
• 协商
– 通过协商来调解需求冲突。
• 规格说明
– 可以是一份文档、一套图形化的模型等
– 系统边界不清楚，客户或者用户的说明带有多 余的技术细节，可能混淆系统整体目标
• 理解问题
– 用户不能完全确定需要什么，在与工程师沟通 过程中有问题。需求之间还可能存在冲突。
• 易变问题
– 需求随时间变化
可采取的解决办法
• 发掘需求
– 克服企业背景对需求工程的影响 – 克服方法不当对需求工程的影响。 – 克服受访谈者对需求工程的影响。 – 克服就项目论项目对需求工程的影响。
齐全; 文档中的所有描述是否完整、清晰、准
确反映用户要求; 与所有其它系统成分的重要接口是否都
已经描述;
被开发项目的数据流与数据结构是否足 够确定;
所有图表是否清楚，在不补充说明时能 否理解;
主要功能是否已包括在规定的软件范围 之内，是否都已充分说明;
设计的约束条件或限制条件是否符合实 际;
(2) 分析与综合
基本思想：
从信息流和信息结构出发，逐步细化所有的 软件功能，
找出系统各元素之间的联系、接口特性和设 计上的约束，分析它们是否满足功能要求， 是否合理。
剔除其不合理的部分，增加其需要部分，最 终综合成系统的解决方案，给出目标系统的 详细逻辑模型。
常用的分析方法
• 功能分析法
– 确定系统功能、性能、运行等 方面要求
– 对将来可能提出的要求做准备
• 分析系统的数据要求
– 考虑数据、数据处理
• 导出系统逻辑模型
– 通常用数据流图表示
• 修正系统开发计划
– 对系统成本、进度有更精确的估算
• 总之，需求分析的任务就是借助于当 前系统的逻辑模型导出目标系统的逻 辑模型，解决目标系统的 “做什么” 的问题。
• 面向对象的分析方法 (OOA)
–识别问题域内对象，及其之间的联系，并建立 模型
(3) 编制需求分析阶段的文档
软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施
计划
(4) 需求分析评审
系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否
–数据流就是数据经过系统时的变化形式， 输入数据先转换成中间数据，再由中间 数据转换成输出结果数据。
–数据内容就是数据项。 –数据结构就是各数据项的逻辑组织。
• 把问题以自顶向下、逐层分解的方式分解 为几个较易理解的部分，并确定各部分之 间的接口，从而实现软件的整体功能。
– 在需求分析阶段，软件的功能域和信息域都可 以做进一步的分解。
• 确认
– 检查规格说明，排除不一致性、疏漏和错误
• 管理
– 帮助项目组在进展中标识、控制和跟踪需求及 其变更

软件需求分析的原则
1. 需要能够表达和理解问题的信 息域和功能域
2. 要能以层次化的方式对问题进 行分解和不断细化
3. 要给出系统的逻辑视图和物理 视图
信息域包括数据流、数据内容和数据结 构。
–需求的内容在“问题定义”中描述（可能是招 标文件）。
需求分析
• 指开发人员为了准确地理解和表达用 户要求，进行细致的调查分析，将用 户非形式的需求陈述转化为完整的需 求定义，再由需求定义转换到相应的 形式功能规约（需求规格说明）的过 程。
• 准确地回答“系统必须做什么？”
软件需求分析的目标
• 确定系统的综合要求
开发的技术风险是什么;
是否考虑过软件需求的其它方案;
是否考虑过将来可能会提出的软件需求;
是否详细制定了检验标准，它们能否对系 统定义是否成功进行确认;
需求分析流程
需求分析过程的任务
• 可以概括为7个不同的活动：
– 起始 – 导出 – 精化 – 协商 – 规格说明 – 确认 – 管理
起始