软件工程 ch3.pptVIP

第三章 需求分析 瀑布模型 第三章 需求分析 教学的基本要求： 掌握需求分析阶段的概念、任务以及需求分析的方法；熟悉利用结构化分析方法进行需求阶段的数据建模、功能建模和行为建模。 3.1 需求分析任务 3.1 需求分析任务 1.确定对系统的综合要求。 (1) 功能需求 系统必须完成的所有功能 (2) 性能需求 必须满足的定时约束或容量约束 3.1 需求分析任务 ⑶ 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性 可用性量化了用户可以使用系统的程度 (4) 出错处理需求 系统对环境错误应该怎样响应 (5) 接口需求 描述应用系统与它的环境通信的格式 常见的接口需求有:用户接口需求、硬件接口需 求、软件接口需求、通信接口需求 3.1 需求分析任务 (6) 约束 描述在设计或实现应用系统时应遵守的限制条件 (7) 逆向需求 说明软件系统不应该做什么 (8) 将来可能提出的要求 2. 分析系统的数据要求 (1) 导出系统的逻辑模型 (2) 修正系统开发计划 3.2 与用户沟通获取需求的方法 一. 访谈 ⑴ 归纳和整理用户提出的各种问题和要求； ⑵ 弄清用户企图通过软件达到的目的； ⑶ 借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。 3.2 与用户沟通获取需求的方法 当前状况 ⑴ 误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。 ⑵ 交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。 ⑶ 缺乏共同语言：由于需求分析员和系统用户的经历和教育背景不同，他们之间通常缺乏足够的沟通。 ⑷ “完整性”问题：软件工程师希望提出系统需求的用户领域专家能清晰、简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最初阶段可能是模糊、不完备甚至是不正确的。 ⑸ 需求永远不会稳定：用户对软件的需求常常会发生变化，并且是不可预测的。 ⑹ 用户意见不统一：大系统往往有各种不同的用户，他们往往有互相冲突的需求和不同的需求优先次序，寻求折衷是不容易的。 ⑺ 错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需求相冲突。 ⑻ 认识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应达到的更为一般的特征，而需求应是可测试的。 解决问题的建议 1. 调查表 (1) 不要用计算机专业术语与用户或用户领域专家交谈 (2) 不要使用“你应该…”这样的字眼 (3) 始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息 (4) 要善于把用户中职位高的人和职位低的人的谈话结合起来分析 解决问题的建议 2. 情景分析技术 对用户将来是使用目标系统解决某个具体问题的解法和结果进行分析 (1) 在某种程度上演示目标系统的行为 (2) 保证用户在需求分析过程中始终扮演一个积极主动的角色 3.2 与用户沟通获取需求的方法 二、面向数据流自顶向下求精 ◆需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。 3.2 与用户沟通获取需求的方法 3.2 与用户沟通获取需求的方法 三、简易的应用规格说明技术 ◆ 一种面向团队的需求收集法,称为简易的应用规格说明技术。 ◆用户与开发者密切合作，共同标示问题，提出解决方案要素，商讨不同方案并指定基本需求。 3.2 与用户沟通获取需求的方法 四、快速建立软件原型 1. 快速原型的特性 ◆快速 ◆容易修改 2. 通常使用的方法和工具 （1）第四代技术 （2）可重用的软件构件 （3）形式化规格说明和原型环境 3.3 分析建模与规格说明 1. 分析建模 数据模型 ----实体联系图 功能模型 ----数据流图 行为模型 ----状态转换图 3.3 分析建模和规格说明 二、软件需求规格说明 1. 需求规格说明书的作用 ⑴ 为用户、分析人员和软件设计人员之间的理解和交流提供了方便； ⑵ 支持目标软件系统的确认； ⑶ 起到控制系统演进的作用。 2．什么样人阅读需求规格说明书 必须阅读需求规格说明书的是各种背景和技术能力都不同的人：客户和使用者，分析人，设计师和工程师，项目管理者等。 3.