[第二篇第3章结构化分析1.pptVIP

第二篇　传统方法学 第三章　结构化分析 第四章　结构化设计 第五章　结构化实现 第三章　结构化分析 重点： 本章学习用结构化的分析方法来获取用户需求 软件开发的第一步就是了解用户的需求。完全理解用户需求对于软件开发的成功是非常重要的。不管软件的设计和编码多么好，如果没有好的分析，用户最终会对你的程序失望，给开发人员带来很多麻烦。 难点： 数据模型的建立 功能模型的建立 行为模型的建立 需求分析技术 3.1需求分析 所谓需求分析是指软件开发人员了解软件的使用者（用户）对软件的功能、性能要求的过程。 用户的需求是软件的目标 需求可能是隐含的 需求是不断变化的 需求分析的任务 说明软件功能,性能,限制条件以及其他系统的接口 精确软件分配，建立数据、功能、行为模型 为用户和管理人员提供一种评估软件质量的方法 3.2 通信技术 用户面临的问题是需要用基于计算机的方案来解决；开发者应该对用户的需求做出反应，给用户提供帮助。 然而用户对计算机领域不熟悉，开发者又对用户的领域不了解。这就产生了相互通信的需求。但是从开始通信到真正相互理解的道路是充满坎坷的。良好的通信技术有助于加快理解过程。 1、访谈 正式访谈：分析员提出一些事先准备好的具体问题 非正式访谈：提出一些可以自由回答的开放性问题，鼓励被访谈人员表达自己的想法。 发调查表：适用于调查大量人员的意见时。 访谈时的问题： 询问公司基本情况 销售商品种类，信息反馈有多快等？ 谁是软件的使用者？ 成功的方案会带来多大的经济效益？ 是否有其他资源可以用来解决方案？ 了解用户要求 成功的方案应该给出什么输出？ 软件的运行环境是什么？ 是否有影响解决方法的性能问题或约束条件？ 访谈的效果 你是可以回答这些问题的人吗，你的回答代表官方吗？ 我的问题是否涉及到现有的问题？ 还有其他人可以提供额外的信息吗？ 还有什么问题需要问吗？ 2、简易的应用规格说明技术Facilitated Application Specification Technique (FAST) 访谈技术有时并不有效。用户和开发者会有意无意区分“us and them”。不能像一个团队的人那样同心协力地识别和精华需求。 简易的应用规格技术(Facilitated Application Specification Technique)：面向团队的需求收集法 在中立地点举行由开发者和用户双方出席的会议 制定准备会议和参加会议的规则 提出一个议事日程 由一个协调人主持会议 使用一种“定义机制”(图表、工作表) 目标是标识问题、提出解决方案要素、商讨不同方法，在有利于实现目标的氛围中确定初步的需求。 FAST过程 用户和开发者通信时通常以访谈开始，通过一些基本的问题来确定问题的范围以及总体的解决方案。用户和开发者都写下1-2页的产品需求。 选择进行FAST的时间、地点、日期以及协调人。邀请分别代表开发者和用户的人员参加会议。 在会议开始前把产品需求分发给所有成员。各成员复查产品需求，同时列出系软件环境中的对象，软件将输出的对象以及用来实现软件功能的对象。另外还要列出与处理这些对象或与对象有关的过程和功能；最后列出约束条件（成本、大小等）和性能标准（速度、准确率等） 不要求会议成员列出的表项是详尽的，没有遗漏的。这些列表只要能反映出每个人对软件的期望。 An example 一个研究表明市场上对家庭安全系统的需求每年按40%增长。我们希望开发一个基于微处理器的家庭安全系统，这个系统能够防止和识别意外情况发生，例如非法进入、火灾、水灾及其它。我们暂时把这个系统叫做SafeHome，它应该允许户主自己编程。它能够利用传感器检测到每一种意外情况，当意外发生时自动拨通监控中心的电话。 continued 首先通过防谈确定软件的范围，以上的产品描述已经足够了。 开始FAST FAST团队由市场部、软件工程师、硬件工程师、生产商的代表，以及一个协调人组成。 每个成员首先给出对象列表：烟火检测器、门窗检测器、报警器、一个事件（传感器被触发）、控制面板、显示器、电话号码、电话等；服务列表包括设置报警器、检测传感器、打电话、给控制面板编程，读显示器等。约束列表：成本不超出$200，界面友好，事件优先等） continued 会议开始后，第一个讨论的主题是是否需要这个新产品。一旦所有人都同意开发时，每个人展示会前准备的列表供大家讨论。列表可以用大纸抄写钉在墙上。理想的情况是表中每一项都能移动，这样就能删除和填加表项，或组合不同的表列。这个阶段禁止争论和批评。 之后小组共同创建一张组合列表，消去冗余，加入新的想法，不删除任何实质性的内容。然后由协调人主持讨论。组合列表将被缩短、加长、重新措辞。讨论的目的