• 1. 第三章 需求分析13份WPF经典开发教程 http://download.csdn.net/album/detail/1115 C#资料合辑二[C#桌面编程入门篇] http://download.csdn.net/album/detail/957 C#资料合辑一[C#入门篇] http://download.csdn.net/album/detail/669 [Csharp高级编程(第6版)](共8压缩卷) http://download.csdn.net/album/detail/667 10个[精品资源]Java学习资料合辑[一] http://download.csdn.net/album/detail/663 10个C#Socket编程代码示例 http://download.csdn.net/album/detail/631 6份GDI+程序设计资源整合[全零分] http://download.csdn.net/album/detail/625 更多免费资源 http://download.csdn.net/user/cleopard
  • 2. 本章主要内容3.1 需求分析的概念与任务 3.2 获取需求的方法 3.3 结构化分析方法 3.4 原型法
  • 3. (本页无文本内容)
  • 4. 3.1 需求分析的概念与任务需求分析虽处于软件开发过程的开始阶段,但它对于整个软件开发过程以及软件产品质量至关重要。 在需求分析阶段,要对经过可行性分析所确定的系统目标和功能作进一步的详细论述,确定系统“做什么”的问题。需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义, 再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。
  • 5. 3.1 需求分析的概念与任务3.1.1 需求的概念 对用户来讲,需求是对软件产品的解释,是对目标软件在功能、行为、性能、设计和约束等方面的期望。 对开发人员而言,他们的需求对用户而言像是详细设计。 IEEE软件工程标准词汇表的需求定义: 用户解决问题或达到目标所需的条件或权能(Capability); 系统或系统部件要满足合同、标准、规范或其他正是规定文档所需要具有的条件或权能; 反映上面描述的条件或权能的文档说明。 需求及反映了系统的外部行为,也反映了内部特征,反映的方式是需求文档。用规范的格式表达出来的文档说明称为需求规格说明书,或者简称为“需求说明”。
  • 6. 3.1 需求分析的概念与任务3.1.2 需求的层次 软件需求包括四个不同的层次——业务需求、用户需求和功能需求、非功能需求。 业务需求(Business Requirement) 反映了组织机构或客户对系统、产品高层次的目标要求,确定了系统的目标、规模和范围,是用户需求和功能需求的依据,通常在项目定义与范围文档中予以说明。 用户需求(User Requirement) 用户使用该软件要完成的任务。要弄清这部分需求,应充分调研具体业务部门,详细了解最终用户的工作过程、涉及信息、当前系统的工作状况、与其他系统的接口等。 用户需求是最重要、也是最容易出问题的需求。
  • 7. 3.1 需求分析的概念与任务功能需求(Functional Requirement) 定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。 用户出于完成任务的角度对软件的需求,通常是凌乱、非系统化、冗余的,分析人员必须在充分理解用户需求的基础上,将其整理成满足特定功能需求的软件功能需求。 软件分析人员应该是计算机方面的专家,架起用户与开发人员之间的桥梁。 非功能需求 非功能需求是对功能需求的补充,可分为两类。 用户关心的重要属性:有效性、效率、灵活性、完整性、互操作性、可靠性、健壮性、可用性等等。 开发者关心的属性:可维护性、可移植性、可复用性、可测试性等等。
  • 8. 非功能需求产品要求性能要求实时性;其他时间要求,如响应时间、处理时间、包传送时间等; 资源配置要求; 精确度、处理量等要求可靠性要求有效性;数据完整性安全保密要求安全性;保密性运行要求使用频度、运行期限;控制方式;对操作员要求物理要求系统的规模等过程要求开发类型实用性开发或试验性开发项目估算开发工作量估计开发方法质量控制标准;里程碑和评审;验收标准优先顺序权衡各种质量目标要求,排定优先实现次序可维护性可理解性、可测试性、可修改性、可移植性
  • 9. 3.1 需求分析的概念与任务业务需求项目视图与范围文档用户需求质量属性使用实例文档系统需求功能需求其他非功能 需求约束条件软件需求规格说明软件需求各组成部分关系图
  • 10. 3.1 需求分析的概念与任务3.1.3 需求分析的任务 基本任务:准确地定义新系统的目标,为了满足用户需求,回答系统必须“做什么”的问题,获得需求规格说明书。 为了更加准确地描述需求分析的任务,Boehm给出软件需求的定义: 研究一种无二义性的表达工具,它能为用户和软件人员双方都接受,并能够把“需求”严格地、形式地表达出来。 随着软件系统规模的扩大,需求分析预定义在整个软件开发与维护过程中 越来越重要,直接关系到软件的成功与否。人们逐渐认识到,需求分析阶段不只限于软件开发的最初阶段,而是贯穿于系统开发的整个生命周期,并将需求工作分为需求开发和需求管理两部分,并统称为“需求工程”(Requirement Engineering,RE)。 需求分析阶段的任务就是实现需求工程。
  • 11. 需求工程需求工程结构图需求开发需求管理需求获取分析建模编写规格说明需求验证变更控制版本控制需求跟踪需求状态跟踪需 求 工 程
  • 12. 需求工程——需求开发 需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。 1 需求获取 进行用户需求调查,获取需求、识别问题。 分析员与用户充分交流,准确、完整的获取用户需求,确定软件系统的总和要求。系统软件的综合要求通常包括以下几部分: 功能要求:最主要的需求,确定系统必须完成的所有功能及其必要性和相容性。 性能要求:确定目标系统必须达到的性能指标。如联机系统的响应时间、可靠性、存储容量、计算精度与效率等。
  • 13. 需求工程——需求开发运行和扩充要求: 运行要求通常包括系统运行的物理环境、支持的软件系统、数据通信方式、系统界面、与其他系统的数据交换格式、用户终端类型、用户操作的易接受程度等。 可扩充要求主要由是否要求可移植、未来扩充或升级的要求、扩充的范围、方式、接口等等。 维护要求 系统出错后可允许的最大恢复时间、对错误修改的回溯测试要求、系统运行日志规格、是否允许对系统修改、系统变化如何反映到设计中等等。 文档规格要求 系统编制的文档类型、规范以及预期的使用对象等等 。
  • 14. 需求工程——需求开发2 分析建模(导出系统逻辑模型) 软件系统本质上是信息处理系统,应通过分析系统信息流的构成和相互之间的关系,确定: 数据(需要哪些数据、数据间联系、数据来源、性质、结构、存储方式) 数据处理(处理的类型、处理的逻辑功能、输入输出规格、种类和形式等等) 分析系统的数据要求是需求分析的主要任务之一,通常采用建立数据模型的方法,建立起新系统的逻辑模型。理解需求表达需求当前系统目标系统物理模型物理模型物理模型逻辑模型逻辑模型导 出抽象实例化抽象模型化具体化
  • 15. 需求工程——需求开发3 编写需求规格说明 主要工作是需求描述。在对问题空间准确、全面理解的基础上,对需求模型进行精确的、形式化的描述。 需求描述应定义和详细描述全部系统功能。 结果为以文档形式表述的可交流、可复审的系统逻辑模型。主要包括:需求规格说明书、用户手册初稿、确认测试计划、修改的开发计划。 ①编写“需求说明书” ,把双方共同的理解与分析结果用规范的方式描述出来,作为今后各项工作的基础。 ②编写初步用户使用手册,着重反映用户功能界面和使用的具体要求,可强制分析人员从用户使用的角度考虑软件。 ③编写确认测试计划, 作为今后确认和验收的依据。 ④修改完善项目开发计划。 经需求分析后,对系统有了进一步了解,能更准确地估计开发成本、进度及资源要求,因此对原计划要进行修正。
  • 16. 需求工程——需求开发4 需求验证 专家、分析人员、开发人员、用户共同对需求分析的正确性、合理性、有效性进行检查,确保需求分析的全面、准确和一致性。 完整性:不能遗漏必要的需求;清晰、完整的描述需求; 正确性:需求必须准确反映用户要完成的任务。 一致性:用户需求必须和业务需求一致;功能需求必须和用户需求一致。 必要性:需求必须为客户所需,不得随意增删需求。 无歧义性:不同人员对需求描述的理解应该是一致的。 可验证性:需求必须是可验证的。 优先级的划分:将需求按重要程度划分优先级别。
  • 17. 需求工程——需求管理 需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。需求管理是认识和管理对产品的全部需求,并确保主生产计划反映这些需求的功能。 软件开发中的很多问题,都是由于收集、编写、协商、修改产品需求过程中的手续和做法带来的。 计算机系统的需求经常变更常贯穿于软件生命周期的始终,开发人员必须能把需求变更应用到软件中,有效地控制需求变化,准确的实现既定需求。 需求管理包括在工程进展过程中为保证需求集成性以及精确性所进行的所有活动,具体包括需求变更控制、版本控制、需求跟踪和需求状态跟踪。
  • 18. 需求工程——需求管理(1)需求变更控制 建议变更→评审需求变更,评估变更影响,决定是否实施变更→以可控方式将需求变更融入项目。 (2)版本控制 建立需求基本版本和需求控制版本文档。每个版本需求规格独立说明。 需求变更时记录记录文档版本日期、所做的变更及原因,还包括由谁负责更新和更新的版本号等。 (3)需求跟踪 跟踪所有受需求变更影响的工作产品,每项需求都能与其对应的设计、源代码和测试联系起来;变更时,通过上述联系更新相应的其他需求、设计、源代码。 (4)需求状态跟踪 定义需求状态,项目中跟踪需求每个状态及其变更情况。需求状态有已推荐的、已通过的、已实施的或已验证的。
  • 19. 需求工程需求开发与需求管理的关系市场客户需求管理分析编写文档 评审、商议基准需求说明需求变更过程当前基线修正后基线市场 客户 管理需求变更项目环境项目变更需求开发需求管理
  • 20. 3.2 获取需求的方法3.2.1 需求获取中存在的典型问题 对需求的理解问题 应用领域的专业性常导致对需求不能全面、深入的理解。 分析人员与用户的通信问题 用户对系统的描述具有片面性、模糊性,只考虑本身业务领域,有效通信、交流和沟通是解决问题的关键。 用户需求的可变性问题 用户需求的多样性、业务扩展或转移、市场竞争、用户主管变更等常常导致需求的变化。 分析方法和分析工具问题 方法工具的缺乏;应用范围的局限。需求分析是公认的软件开发中最困难的一个问题。概括来说,其主要任务就是正确理解和表达用户需求。如何从应用领域获取所需知识,往往是需求分析的障碍。所以,获取需求是需求分析的关键,也是最困难、最容易出差错的一步。
  • 21. 3.2 获取需求的方法3.2.2 获取需求的常用方法 访谈法 正式访谈;非正式访谈。关键是问题的设计。 问卷调查 需要调查的内容制成问卷交由用户填写,需调查大量人员时,非常有效。关键是问卷的设计。 情景分析 对待解决问题给出可能的情景描述,获取用户的具体需求。 实地考察 分析人员到用户工作现场,实地观察操作过程。 系统目标不应是手工操作的简单模拟。 构造原型 快速构造原型,用户提修改意见,使用户明确需求。 原型可针对整个系统,也可针对具体功能。
  • 22. 3.2.3 针对信息系统的需求调研方法 调研用户的组织结构、岗位设置、职责定义 从功能上区分有多少个子系统,划分系统的大致范围,明确系统的目标。 调研每个子系统的工作流程、功能与处理规则 收集原始信息资料,用数据流来表示物流、资金流、信息流三者的关系。 事先准备调研内容,针对不同管理层次的用户询问不同的问题,列出问题清单。 将操作层、管理层、决策层的需求既联系又区分开来,形成一个需求的层次。 及时总结归纳与用户沟通的情况,整理调研结果 初步构成需求基线。若基线符合要求,则需求获取完成。
  • 23. 3.2 获取需求的方法3.2.4 需求分析的原则 解决逻辑问题 给出要完成的功能和基本的信息,而不考虑实现细节。 “系统必须做什么”而非“怎么做”。 以运行环境为基础 以具体的运行环境为基础,实事求是,不能照搬其他类似系统的分析工作。 用户参与 需求分析工作要有客户指定人员参加,保证交互的有效性和工作效率。 构造高质量的需求说明书 分析人员应严格遵守既定规范,做到内容全面、结构清晰、格式严谨。
  • 24. 3.3 结构化分析方法结构化开发方法(Structured Developing Method)是现有的软件开发方法中最成熟,应用最广泛的方法, 主要特点是快速、 自然和方便。 结构化开发方法由结构化分析 (SA)、结构化设计(SD)及结构化程序设计(SP)构成。 结构化分析(Structured Analysis, SA)方法是面向数据流的需求分析方法, 70 年代末由 Yourdon E,Constaintine L及 Demarco T等人提出和发展,并得到广泛的应用。它适合于分析大型的数据处理系统,特别是企事业管理信息系统。 SA 法也是一种建模的技术,主要是根据软件内部的数据传递、变换关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。
  • 25. 3.3 结构化分析方法3.3.1 结构化分析方法的基本思想 结构化分析是面向数据流的需求分析方法,基本思想是“分解”和“抽象” 。 分解:是指对于一个复杂的系统,为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决。 抽象:分解可以分层进行,即先考虑问题最本质的属性,暂把细节略去,以后再逐层添加细节, 直至涉及到最详细的内容, 这种用最本质的属性表示一个自系统的方法就是 “抽象” 。 教学管理系统学生管理教师管理考试管理课程管理教务管理考务管理题库维护试卷生成学生考试试卷评阅
  • 26. 3.3 结构化分析方法3.3.2 描述工具 SA方法提供一套图形、表格和结构化英语(Structured English)等半形式化的描述方式表达需求,通俗易懂,描述工具包括: 数据流程图(Data Flow Diagram,DFD) 描述系统逻辑模型的图形工具。 描述了系统的组成部分及各部分之间的联系。 通常通过对系统的分解得到一套分层的数据流程图。 数据字典(Data Dictionary,DD) 对数据流程图中的元素进行定义。 结构化英语、判定表和判定树 详细描述数据流程图中一些复杂处理的加工逻辑。
  • 27. 3.3 结构化分析方法——数据流图3.3.3 数据流图 数据流图(Data Flow Diagram,DFD)是描述系统中数据流程的图形工具,它标识了一个系统的逻辑输入和逻辑输出,以及把逻辑输入转换逻辑输出所需的加工处理。 目标系统被表示成如下图所示的数据变换流程图。系统的功能体现在核心的数据变换中。外部实体外部实体外部实体外部实体目标系统输入信息输出信息输入信息输出信息
  • 28. 3.3 结构化分析方法——数据流图DFD基本符号符号含义加工,输入数据在此变换产生输出数据。通常由加工编号和加工命名标识。要注明加工的名字,通常为动宾短语。表明数据的源点或数据的终点,是系统之外的实体。可以是人、物、部门、或其他系统。要注明源点的实体名。数据流,被加工的数据的流向。 箭头边要给出数据流的名字,可用名词或名词性短语命名。数据存储文件,可用名词或名词性短语命名。
  • 29. 3.3 结构化分析方法——数据流图图书预定系统的数据流图(顶层DFD图)画图步骤 : 1.确定外部实体及输入、输出数据流。 2.确定分解顶层的加工。 3.确定使用的文件。 4.用数据流将各部分连接起来,形成数据封闭。1 验证订单2 汇总订单订单顾客档案图书目录文件待处理订单文件出版社档案文件订货存根文件顾客出版社正确订单出版社订单一批订单
  • 30. 3.3 结构化分析方法——数据流图数据流与加工之间的关系∨∨∨与,数据流同时到达加工才能启动异或,不能同时到达或,有一个到达加工即开始
  • 31. 3.3 结构化分析方法——数据流图数据流图的分层 若系统规模较大,仅用一个 DFD 图难以描述,复杂且难以理解。为了降低系统复杂性,采取“逐层分解”的技术。 画分层 DFD 图的一般原则是: “先全局后局部,先整体后细节,先抽象后具体” 。 通常将分层的 DFD图分为顶层、中间层、底层。 顶层图说明了系统的边界,即系统的输入和输出数据流,顶层图只有一张。 底层图由一些不能再分解的加工组成,这些加工都已足够简单,称为基本加工。 在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解,而它的组成部分又要进一步分解。 画各层 DFD 图时,应“由外向内” 。
  • 32. 3.3 结构化分析方法——数据流图
  • 33. 3.3 结构化分析方法——数据流图严格地表现DFD图的相关概念 父图与子图 上层图是其分解的下层图的父图,下层则是子图。父图是子图的抽象,子图是父图的细化。 分层图编号 整个系统编号以0表示,下层分级标号。编号中所含小数点的个数即为层次数。 父图子图数据流平衡 加工数据的接口保持逻辑上的平衡一致。 局部文件 中间层的DFD数据存储不是上层中相应加工的 外部接口,而是本图中某些加工之间的信息接口。
  • 34. 3.3 结构化分析方法——数据流图S1S2S3父图ABCMNOS3.1S3.2S3.3NXTMOQ子图S3.1S3.2S3.4NXPOQS3.3M子图FiS3.1S3.2S3.4NXPJQS3.3M子图KFi注意:父图子图的平衡性,不一定是数据流的名称、个数和形式上的完全一致,是逻辑上的一致。
  • 35. 3.3 结构化分析方法——数据流图构造分层数据流图及求精的一般原则 数据流图中所有元素必须为四种元素之一,每个元素都应有良好的命名。 实际使用中,还有一套等价符号:
  • 36. 13份WPF经典开发教程 http://download.csdn.net/album/detail/1115 C#资料合辑二[C#桌面编程入门篇] http://download.csdn.net/album/detail/957 C#资料合辑一[C#入门篇] http://download.csdn.net/album/detail/669 [Csharp高级编程(第6版)](共8压缩卷) http://download.csdn.net/album/detail/667 10个[精品资源]Java学习资料合辑[一] http://download.csdn.net/album/detail/663 10个C#Socket编程代码示例 http://download.csdn.net/album/detail/631 6份GDI+程序设计资源整合[全零分] http://download.csdn.net/album/detail/625 更多免费资源 http://download.csdn.net/user/cleopard
  • 37. 3.3 结构化分析方法——数据流图分解应自然,概念上清晰合理。每次分解生成的DFD数据流和加工都应确切命名。 流入、流出数据流加工应连续,即每个加工必须有输入输出数据流。 分解过程中,注意保持父图、子图数据流的平衡性一致性。 控制单张数据流图的复杂性。 当一个加工逻辑足够简单,可以终止分解。 分析中应只考虑稳态,暂时忽略某些细节,如错误的处理逻辑等。 逐层分解时,注意分解层次的均匀性,从树根到所有树叶的路径长度之差不应太大(一般不超过2)。
  • 38. 实例:考务处理系统1 功能 (1) 对考生送来的报名单进行检查; (2) 对合格的报名单编好准考证号后将准考证送给考生,并将汇总后的考生名单送给阅卷站; (3) 对阅卷站送来的成绩单进行检查,并根据考试中心制定的合格标准审定合格者; (4) 制作考生通知单 (含成绩及合格/不合格标志) 送给考生; (5) 按地区进行成绩分类统计和试题难度分析,产生统计分析表。
  • 39. 2 顶层数据流图 根据考务处理业务,画出顶层数据流图,以反映最主要业务处理流程及系统与外界的关系。 经过分析,考务业务处理的主要功能应当有登记报名单、统计成绩两个主要数据流。输入的源点和输出终点是考生、考试中心和阅卷站。 然后从输入端开始,根据考务业务工作流,画出数据流流经的各加工框,逐步画到输出端,得到第 0 层数据流图。考 生考务 处理系统考 试 中 心阅卷站不合格报名表报名表准考证考生通知单成 绩 单合格标准错误成绩单考生名 单统计分析表
  • 40. 3 第0层数据流图考生名册报名表准考证1 登记 报名表不合格 报名表考生名 单2 统计 成绩考生通知单成绩单统计分析表合 格 标 准错误成绩单
  • 41. 第一层数据流图 (a)1.1 检查 报名表报名表准考证1.2 编准考证号码不合格 报名表考生名册考生名单合格 报名表1.3 登记 考生合格报名表考生名册报名表准考证1 登记 报名表不合格 报名表考生名 单
  • 42. 第一层数据流图 (b)2.1 检查 成绩单2.2 审定 合格者考生名册正确 成绩单2.3 制作 通知单2.4 分析统 计成绩2.5 分析试 题难度试题得分表考生 通知单难度 分析表合格 标准分类 统计表成绩单错误 成绩单经审定的 成绩单
  • 43. 3.3 结构化分析方法——数据字典3.3.4 数据字典分层数据流图只是表达了系统的“分解”,为了完整地描述这个系统,还需借助“数据字典”(Data Dictionary) 对图中的每个数据和加工给出解释。 对数据流图中包含的所有元素的定义的集合构成了数据词典。 它有四类条目: 数据流、数据项、文件及基本加工。在定义数据流或文件时,使用一些符号,将条目按照一定的规则组织起来,构成数据词典。 数据词典精确地、严格地定义了每一个与系统相关的数据元素,并以字典式顺序将它们组织起来,使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。
  • 44. 3.3 结构化分析方法——数据字典数据字典编写的基本要求 对数据流图上各元素的定义必须明确、一致且容易理解。 命名、编号应该与数据流图一致。 对数据流的成分定义与说明无遗漏,无同名异义,或异名同义。 格式规范、文字精练、符号正确。
  • 45. 3.3 结构化分析方法——数据字典数据字典的内容和格式 数据流条目 定义数据流的数据项组成。包括名字、别名、编号、来源去向、包含的数据结构名以及处理特点(使用频率、数据量等)和其他注释信息(如格式、位置等)。 数据流名: 说明:简要介绍它产生的原因和结果 数据流来源:来自何方 数据流去向:去向何处 数据流组成:数据结构 数据量流通量:数据量,流通量数据流名发票别名购书发票组成学号+姓名+{书号+单价+数量+总价}+书费合计备注“{}”表示重复,次数不限;其他数据项在数据流中仅出现一次。“别名”只是正名的进一步解释,同一系统中并不允许相同数据使用不同名称
  • 46. 3.3 结构化分析方法——数据字典数据项条目 数据项是数据流的组成要素 ,分为基本数据项和结构型数据项。基本数据项是数据处理中基本的、不可分割的逻辑单位,如整数、小数、字符串、时间日期、逻辑等。结构型数据项由若干基本数据项组成。 类型:数字(离散值,连续值),文字(编码类型)长度 取值范围: 相关的数据元素及数据结构:数据项名数量别名购书数量取值正整数备注数据项名书费合计别名取值0.00 ·· 999.99备注
  • 47. 文件存储条目 说明存储文件的名称、编号、文件组织方式、记录数及存储介质等。 数据文件名: 简述:存放的是什么数据 输入/输出数据: 数据文件组成:数据结构 存储方式:顺序,直接,关键码 存取频率:文件名各班学生用书表别名组成{系编号 + 专业和班编号 + 年级 + {书号} }组织按系、专业和班编号从小到大排序嵌套的“{}” 一个文件需要多种这样的记录。每班每年需要多种教材。
  • 48. 3.3 结构化分析方法——数据字典加工说明条目 说明加工的名称、编号、输入/输出数据、加工逻辑概要描述等加工逻辑。 加工名: 加工编号:反映该加工的层次 简要描述:加工逻辑及功能简述 输入/输出数据流: 加工逻辑:简述加工程序,加工顺序 数据源及数据实体词条描述 说明数据源以及外部实体。 名称:外部实体名 简要描述:什么外部实体 有关数据流: 数目:
  • 49. 符号含义例及说明=被定义为+与X=a+b表示X由a和b组成[… | …]或X=[a|b]表示X由a或b组成{…}重复X={a} 表示X由0个或多个a组成m{…}n或{…}重复X=2{a}6或 x={a} 表示重复2-6次 a(…)可选X=(a) 表示a可在X中出现,也可不出现“…”基本数据元素X=“a” 表示X是取值为字符a 的数据元素 ..连接符X=1 .. 8表示X可取1到8中任意一个值m n数据字典定义中的符号及含义为使定义简明,可在数据字典中使用定义符号表示数据字典。2 6
  • 50. 3.3 结构化分析方法——数据字典数据结构的描述 对数据字典中条目(数据结构)进行定义时,仍体现自顶向下、逐步细化的思想,直至到基本的数据项定义为止。 例如,教学管理成绩管理子系统中数据文件“学生选课登记表”格式如下表所示:学号姓名课程专业开课时间备注学生选课登记表=1{学号+姓名+课程+专业+开课时间+(备注)}23学号=“00001”..“99999” 姓名=4{字符}8 课程=课程名+课程号+学分 专业= =“01”..“99” 注:专业代码,两位数字 开课时间=年+月+日 备注=0{字符}40课程名=“001”..“999” 注:课程代码,三位数字 课程类型={B|X|R}注:课程类别为标识符 B=“必选” X=“限选” R=“任选” 学分=“x”
  • 51. 存折=户名+所号+帐号+开户日+性质+ (印密) + 1{ 存取行}50 户名= 2{ 字母}24 所号= 001..999 帐号= 00000001.. 99999999 开户日=年+月+日 性质=“ 1 ”..“ 6 ”注:“ 1 ”表示普通户,“ 5 ”表示工资户等 印密=“ 0 ”注:印密在存折上不显示 存取行=日期+(摘要)+支出+存入+余额+操作+复核
  • 52. 3.3 结构化分析方法——加工逻辑说明3.3.5 加工逻辑说明对数据流图的每一个基本加工,必须有一个基本加工逻辑说明。 基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。 加工逻辑说明中包含的信息应是充足的,完备的,有用的,无冗余的。 目前用于描述加工逻辑的工具有结构化英语、判定树和判定表。
  • 53. 3.3 结构化分析方法——加工逻辑说明(1)结构化英语(Structured English) 结构化英语也叫问题描述语言(Problem Describe Language,PDL),是在自然语言基础上加上一些限制条件得到的一种介于自然语言和结构化语言之间的半结构化语言,用以消除在语法上的歧义性。 结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、CASE_OF 、 WHILE_DO、REPEAT_UNTIL等组成。 基本控制结构 简单陈述句结构:避免复合语句 重复结构:while_do 或repeat_until 结构 判定结构:if_then_else 或case_of 结构
  • 54. 3.3 结构化分析方法——加工逻辑说明用结构化语言描述的规格说明的正文可以在计算机上编辑,不必过多地考虑语言的在语法上的限制,使得分析员可以集中考虑加工的策略或规则。 结构化语言描述的商店业务处理系统中“检查发货单”Begin if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else (欠款未超期) 发批准书,发货单 else (发货单金额未超过$500) if 欠款超过60天 then 发批准书,发货单及赊欠报告 else (欠款未超期) 发批准书,发货单 End
  • 55. 3.3 结构化分析方法——加工逻辑说明(2)判定树(Decision Tree) 判定树是一种呈树状的图形工具,适合于描述处理中具有多种策略、要根据若干条件的判定确定所要采用的策略的情况。 判定数据有清晰、直观、易用的优点。金额>$500金额$500检 查 发 货 单 欠款>60天 欠款60天 欠款>60天 欠款60天不发出批准书发出批准书、发货单发出批准书、发货单及赊欠报告发出批准书、发货单
  • 56. 3.3 结构化分析方法——加工逻辑说明(3)判定表(Decision Table) 判定表是一种二维的表格,常用于较复杂的组合条件。通常由四部分组成,可以处理用结构化语言不易处理的,有较复杂的组合条件的问题。 使用判定表,较容易保证所有条件和操作都被说明,不容易发生错误和遗漏。基本判定条件基本动作基本判断条件组合执行动作规则所有可能的基本判断条件,顺序无关所有可能的采取的动作,顺序无关在各种条件的特定取值下应采取的动作。各种条件给出的多种取值,即多个条件所取真假的集合
  • 57. 3.3 结构化分析方法——加工逻辑说明“检查发货单”判定表条件发货单金额赊欠情况 操 作不发出批准书发出批准书发出发货单发赊欠报告规则1规则2规则3规则4>$500> $500≤ $500≤ $500>60天≤ 60天> 60天≤ 60天√√√√√√√√条件发货单金额赊欠情况 操 作不发出批准书发出批准书发出发货单发赊欠报告规则1规则2规则3>$500≤ $500—>60天> 60天≤ 60天√√√√√√实际使用判定表时,常常需要先将其简化。 方法是:如果表中有两条或更多的规则具有相同的动作,则设法将它们合并。“—”表示与取值无关。
  • 58. 3.4 原型法按照传统的瀑布模型进行软件开发时,是将软件开发这样一个充满回朔的过程硬性地割裂开,虽然强调各个阶段的复审,但由于用户所提出的需求往往是模糊的,因此很难得到一个完整精确的规格说明,这将直接影响到后期的开发。尤其是对于某些试验性、探索性的项目,更是难于得到一个准确、无二义性的需求。 原型法改变了系统分析、设计和实现这三个顺序阶段的观点,改变了传统的自顶向下的开发模式,降低了软件需求风险。
  • 59. 3.4 原型法3.4.1 原型的概念 原型的概念和特点 通常,原型是指模拟某种产品的原始模型。在软件开发中,原型是软件的一个早期可运行的版本,它反映最终系统的主要特性。 快速原型法(Rapid Prototyping)是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。 原型就是模型,而原型系统就是应用系统的模型。它是待构筑的实际系统的缩小比例模型,但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。
  • 60. 3.4 原型法——原型的概念软件原型的分类 由于软件项目的特点和运行原型的目的不同,原型有两种不同的类型: (1)废弃(Throw away)型 先构造一个功能简单而且质量要求不高的需求规格模型,针对这个模型系统反复进行分析修改,形成比较好的设计思想,据此设计出更加完整、准确、一致、可靠的最终系统。通过评估后,原型被抛弃,重新规划和实施系统的开发。框架需求开发原型确定系统评估原型开发软件问题可验证系统问题可交付的软件系统可复用构件
  • 61. 3.4 原型法——原型的概念(2)追加(Add on)型 先构造一个功能简单而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充修改,逐步追加新的要求,最后发展成为最终系统。 采用什么形式主要取决于软件项目的特点和开发者的素质,以及支持原型开发的工具和技术。要根据实际情况加以决策。 开发抽象描述建立原型系统使用原型系统系统充分吗?交付系统否是
  • 62. 3.4 原型法——原型的概念构建原型的方法和工具 原型系统不同于最终系统,需要快速实现、实现运行。所以要注意功能和性能上的取舍。基本要求包括: 体现主要功能; 提供基本的界面风格; 展示比较模糊的部分,便于确认或进一步明确; 原型最好是可运行的,至少在各主要功能模块之间能够建立相互的连接。
  • 63. 3.4 原型法——原型的概念为了快速的构建和修改原型,通常使用以下三种工具或方法。 (1)第四代技术 包括众多的数据库查询和报表语言、程序和应用系统生成器、以及其他高级的非过程语言。 (2)可重用的软件构件 利用可复用的模块,作出适当组合,快速构造原型系统。而不是从头构建原型。 现有软件可被用作“新的或改进的”产品的原型。 (3)形式化规格说明和原型环境 在开发交互环境中,调用自动工具把基于形式化语言的规格说明翻译成可执行的程序代码,用户能够使用可执行的原型代码去进一步细化形式化的规格说明。
  • 64. 3.4 原型法3.4.2 快速原型的开发过程改进的原型用户和设计者是否满意确定基本信息要求 基本要求 应用框架 预估成本 确定数据开发初始原型初始的原型使用原型系统 澄清需求N是否放弃运行的原型修正和改进原型N运行的原型原型作为 应用系统原型作为 应用系统 开发基础
  • 65. 3.4 原型法(1)快速分析 分析者、用户密切配合下,快速确定软件基本要求;描述基本规格说明,满足开发原型要求。 (2)构造原型 快速分析基础上,根据基本规格说明,尽快实现可运行的系统。要有开发工具支持,反映特征,忽略细节要求。 (3)运行评价原型 这是频繁通信、发现问题、消除误解的重要阶段。验证原型正确程度,修改原需求。
  • 66. 3.4 原型法(4)修正和改进 根据修改意见对原型进行修改完善。若由于需求规格不准确导致原型错误,首先修正完善需求规格,再修改系统;若出现严重理解错误,应放弃原型,重新开发。 (5)判定原型完成 经改进的原型,达到参与者一致认可,则原型迭代过程可结束。判断最终系统的需求是否已被掌握,原型迭代过程是否可以结束,以便决定下阶段的工作内容,即进行细部说明或继续验证原型。 (6)判断原型细部是否说明 在原型方法中,对那些不能通过原型进行说明的项目,如果有必要的话,应该提供详细的文字或其它形式的说明。本阶段的任务就是判断是否需要进行该项说明。
  • 67. 3.4 原型法(7)原型细部说明 对那些不能通过原型说明的项目,用文字和图形等方式进行严格、详细的描述,写入需求说明的文本中。 例如,系统的输入、输出、系统的逻辑功能、数据库组织、系统可靠性等项目均为需要进行严格说明的。 在原型方法中,可借助屏幕和原型来进行讨论和确定,从而帮助进行严格的细部说明。 (8)判断原型效果 检查在上一阶段对某些项目进行严格说明后,是否会引起原型的失效。这时如果原型出现问题,则需对上述严格说明进行修改。 (9)整理原型提供文档 把原型进行整理 、编写,以便为下一步开发服务。像任何其它软件系统一样,原型法也必须提供文档,包括最终系统的需求文档和原型本身的说明文档等。
  • 68. 3.4 原型法3.4.3 原型法的选择 增进软件者和用户对系统服务需求的理解,使比较含糊的具有不确定性的软件需求(主要是功能)明确化。 软件原型化方法提供了一种有力的学习手段。 使用原型化方法,可以容易地确定系统的性能,确认系统设计的可行性,确认系统作为产品的结果。问题废弃型 原型法演化型 原型法其它预备工作目标系统要解决的问题弄清楚了吗?是是否问题可以被建模吗?是是否客户能够确定基本需求吗?是/否是/否否需求已经被建立而且比较稳定了吗?否是是有模糊不清的需求吗?是否是需求中有矛盾吗?是否是
  • 69. 13份WPF经典开发教程 http://download.csdn.net/album/detail/1115 C#资料合辑二[C#桌面编程入门篇] http://download.csdn.net/album/detail/957 C#资料合辑一[C#入门篇] http://download.csdn.net/album/detail/669 [Csharp高级编程(第6版)](共8压缩卷) http://download.csdn.net/album/detail/667 10个[精品资源]Java学习资料合辑[一] http://download.csdn.net/album/detail/663 10个C#Socket编程代码示例 http://download.csdn.net/album/detail/631 6份GDI+程序设计资源整合[全零分] http://download.csdn.net/album/detail/625 更多免费资源 http://download.csdn.net/user/cleopard