软件工程 第三章 需求分析答案

2． 以流程为主线
在与用户交流的过程中， 应该用流程将所有的内容串起来， 如单据、 信息、 组织结构和 处理规则等， 这样便于交流沟通。 流程的描述既要有宏观描述， 也要有微观描述。
第3章
3.2 需求获取的方法
5
3.2.2 获取需求的途径和方法
1.问卷调查 2.访谈和会议 3.市场调查 4.实地操作
用户之间要进行充分和有效的沟通， 需要采取科学的需求获取方法与技巧， 恰当地启发引导用
户表达自己的需求， 以减少后期重复修改需求的次数。
第3章
3.2 需求获取的方法
4
3.2.1 需求获取的基本原则
1． 深入浅出 需求获取要尽可能全面、 细致。 调研获取的需求是个全集， 而目标系统真正实现的是个 子集。 分析时的调研内容并不一定都要纳入到新系统中， 但全面、 细致的调研既有利于弄清 系统全局， 又有利于以后的扩充。
层、 管理层和决策层的需求既联系又区分开来， 形成一个金字塔， 使下层满足上层的需求。
（4） 对与用户沟通的情况及时总结归纳， 整理调研结果， 找出新的疑点， 初步构成需求基线。 （5） 若需求基线符合要求， 则需求分析完毕； 反之返回到前面某一步。 如此循环多次，直到需求
分析使双方满意为止。
第3章
第3章
需求分析
1
理解需求分析的任务；
本章 要点
熟悉需求分析的步骤； 理解结构化需求分析的基本思想； 掌握数据流图和数据词典的用法。
第3章
3.1 需求分析的任务
2
需求分析的任务是要准确地定义新系统的目标， 准确回答“系统必须做什么” 的问题， 并用需求规格说明书规范的形式准确地表达用户的需求。
5.建立原型
第3章
3.2 需求获取的方法
6
3.2.3 需求调研的步骤
获取用户需求， 就需要深入企业现场调研， 需求调研的步骤如下： （1） 调研用户领域的组织结构、 岗位设置和职责定义， 从功能上区分有多少个子系统，划分系统 的大致范围， 明确系统的目标。 （2） 调研每个子系统所需的工作流程、 功能与处理规则， 收集单据、 报表和账本等原始调研每个 子系统所需的作流程功能与处资料， 分析物流、 资金流和信息流三者的关系， 以及如何用数据流来表示 这三者的关系。 （3） 对调研的内容事先准备， 针对不同管理层次的用户询问不同的问题， 列出问题清单。将操作
实现过程中的需求可回溯性， 并进行需求变更管理。
一般情况下， 需求验证以用户、 系统分析员、 系统设计人员和管理人员共同参与的会议 形式进行， 最后由评审负责人签字。
实体联系图（E\|R图） 、 状态转换图、 用例图、 类图、 对象图等。 系统分析员根据目标系统的模型， 从信息流和信息结构出发， 逐步细化所有的软件功能，
找出系统各元素之间的联系、 接口特性和对设计的限制， 剔除需求中不合理的成分， 增加需
要的部分， 最终把各项需求组织起来， 提交目标系统的详细逻辑模型。
对于复杂的软件系统， 此阶段除产生软件需求规格说明书（称软件需求文档， 主要描述
软件部分的需求） 外， 还要产生系统定义文档（即用户需求报告） 和系统需求文档（即系统 需求规格说明书） 。
第3章
3.3 需求获取的步骤
11
3.3.4 需求验证
需求验证就是验证（复查） 需求分析的成果， 也称综合评审。 需求验证就是对需求的正 确性进行严格的验证， 确保需求的一致性、 完整性、 清晰性、 现实性和有效性， 确保设计与
3.3 需求获取的步骤
7
一般来说，需求分析分为需求获取、分析建模、需求建模、需求验证四个步骤，如下图所 示：
第3章
3.3 需求获取的步骤
8
3.3.1 需求获取
此阶段的工作是需求获取、 问题识别， 即收集并明确用户需求的过程。首先， 系统分析 员要研究可行性研究报告和软件项目实施计划。 主要是从系统的角度来理解软件， 确定对目标 系统的综合要求， 即软件的需求。 还要提出这些需求实现的条件， 以及需求应达到的标准。 也就是解决待开发系统需要“做什么” ， “做到什么程度” 的问题。这些需求包括： （1） 功能需求： （2） 性能需求： （3） 环境需求： （4） 可靠性需求： （5）安全保密性需求： （6） 用户界面需求： （7） 资源使用需求： （8） 软件成本消耗与开发进度需求： （9） 预 计系统可达到的目标：
第3章
3.3 需求获取的步骤
9
3.3.2 分析建模
获取到需求后， 要把来自用户的信息加以分析， 通过“抽象” 建立待开发的系统逻辑模 型。 模型是为了 理解事物而对事物做出的一种抽象， 通常由一组符号和组织这些符号的规则
组成。 为待开发系统建立模型， 有助于人们更好地理解问题， 常用的建模方法有数据流图、
第3章
3.2 需求获取的方法
3
在需求分析过程中， 需求获取阶段是开发人员和用户交往最多的阶段。 一般情况下， 用
户并不熟悉计算机的相关知识， 更不懂得需求分析方法， 所以他们不知道如何全面而又准确无
误地表达自己的需求。 而软件开发人员对相关的业务领域也不甚了 解， 用户与开发人员之间 对同一问题理解的差异和习惯用语的不同往往会给需求分析带来很大困难。 所以， 开发人员与
需求分析是理解、 分析和表达“系统必须做什么” 的过程。
虽然在可行性研究阶段虽然在可行性研究阶段， 对用户需求有了 初步了解， 但对需求的 了 解是概括的、 粗略的，对用户需求有了 初步了解但对需求的了 解是概括的粗略的许多细节 被忽略了 。 可行性研究是决定“做还是不做” ， 而不是对需求进行定义。 而需求分析阶段则 需要充分理解用户需求， 通过分析得出对新系统完整、 准确、 清晰、 具体的要求。 需求分析的结果是否正确， 关系到软件开发的成败和软件产品的质量， 正确的需求分析 是整个系统开发的基础。
第3章
源自文库
3.3 需求获取的步骤
10
3.3.3 需求描述
需求描述就是指编制需求分析阶段的文档。 即将已经过分析的需求清晰、 全面、 系统、 准确地描述成正式的文档——软件需求规格说明书。
软件需求规格说明书以开发人员的角度， 对开发系统的业务模型、 功能模型、 数据模型
等内容进行描述， 明确地表达了 用户与系统分析员对软件系统的共同理解， 将作为概要设计 和详细设计的基线。