３． ２ 软件工程基本概念

　　软件开发方法是软件开发过程所遵循的方法和步骤，其目的在于有效地得到一些工作产品，即程序和文档，并且满足质量要求。软件开发方法包括分析方法、设计方法和程序设计方法。
　  结构化方法经过30多年的发展，已经成为系统、成熟的软件开发方法之一。结构化方法包括已经形成了配套的结构化分析方法、结构化设计方法和结构化编程方法，其核心和基础是结构化程序设计理论。

　　3.2.1 需求分析与需求分析方法
　　3.2.2 结构化分析方法
　　3.2.3 软件需求规格说明书

　　3.2.1　需求分析与需求分析方法

　　1. 需求分析
　  软件需求是指用户对目标软件系统的功能、行为、性能、设计约束等方面的期望。需求分析的任务是发现需求、求精、建模和定义需求的过程。需求分析将创建所需的数据模型、功能模型和控制模型。
　  ⑴需求分析的定义
　  1997年IEEE软件工程标准词汇表对需求分析定义如下：
　  ① 用户解决问题或达到目标所需的条件或权能；
　  ② 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能；
　  ③ 一种反映①或②所描述的条件或权能的文档说明。
　  由需求分析的定义可知，需求分析的内容包括：提炼、分析和仔细审查已收集到的需求；确保所有利益相关者都明白其含义并找出其中的错误、遗漏或其他不足的地方；从拥护最初的非形式化需求到满足用户对软件产品的要求的映射；对用户意图不断进行提示和判断。
　  ⑵需求分析阶段的工作
　  需求分析阶段的工作，可以概括为四个方面：
　  ①需求获取 需求获取的目的是确定对目标系统的各方面需求。涉及到的主要任务是建立获取用户需求的方法框架，并支持和监控需求获取的过程。
　  需求获取涉及的关键问题有：对问题空间的理解；人与人之间的通信；不断变化的需求。
　  需求获取是在同用户的交流过程中不断收集、积累拥护的各种信息，并且通过认真理解拥护的各项要求，澄清那些模糊的需求，排除不合理的，从而较全面地提炼系统的功能性与非功能性需求。一般功能性与非功能性需求包括系统功能、物理环境、用户截面、用户因素、资源、安全性、质量保证及其他约束。
　  要特别注意的是，在需求获取过程中，容易产生诸如与用户存在交流障碍，相互误解，缺乏共同语言，理解不完成，忽视需求变化，混淆目标和需求等问题，这些问题都将直接影响到需求分析和系统后续开发的成败。
　  ②需求分析 对获取的需求进行分析和综合，最终给出系统的解决方案和目标系统的逻辑模型。
　  ③编写需求规格说明书 需求规格说明书作为需求分析的阶段成果，可以为用户、分析人员和设计人员之间的交流提供方便，可以直接支持目标软件系统的确认，又可以作为控制软件开发进程的依据。
　  ④需求评审 在需求分析的最后一步，对需求分析阶段的工作进行复审，验证需求文档的一致性、可行性、完整性和有效性。
　  2.需求分析方法
　  常见的需求分析方法有：
　  ①结构化分析方法。主要包括：面向数据流的结构化分析方法（SA — Stryctured analysis）,面向数据结构的Jackson方法(JSD — Jackson system development method),面向数据结构的结构化数据系统开发方法（DSSD — Data structured system development method）。
　  ②面向对象的分析方法（OOA — Object-Oriented method）。
　  从需求分析建立的模型的特性来分，需求分析方法又分为静态分析方法和动态分析方法。

　　3.2.2 结构化分析方法　

　　1. 关于结构化分析方法
　  结构化分析方法是结构化程序设计理论在软件需求分析阶段的运用。它是20世纪70年代中期倡导的基于功能分解的分析方法，其目的是帮助弄清用户对软件的需求。
　  对于面向数据流的结构化分析方法，按照DeMarco的定义， “ 结构化分析就是使用数据流图（DFD）、数据字典（DD），结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化规格说明的目标文档。 ”
　  结构化分析方法的实质是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。
　  结构化分析的步骤如下：
　  •  通过对用户的调查，以软件的需求为线索，获得当前系统的具体模型；
　　•  去掉具体模型中非本质因素，抽象出当前系统的逻辑模型；
　  •  根据计算机的特点分析当前系统与目标系统的差别，建立目标系统的逻辑模型；
　  •  完善目标系统并补充细节，写出目标系统的软件需求规格说明；
　  •  评审知道确认完全符合用户对软件的需求。
　  •  结构化分析的常用工具
　　2.结构化分析的常用工具
　  ⑴数据流图（DFD — Data Flow Diafram）
　  数据流图是描述数据处理过程的工具，是需求理解的逻辑模型的图形表示，它直接支持系统的功能建模。
　  数据流图从数据传递和加工的角度，来刻画数据流从输入到输出的移动变换过程。数据流图中的主要图形元素与说明如下：
　  加工（转换）：输入数据经加工变换产生输出。
　  数据流：沿箭头方向传送数据的通道，一般在旁边标注数据流名。
　  存储文件（数据源）：表示处理过程中存放各种数据的文件。
　  源，潭：表示系统和环境的接口，属系统之外的实体。
　  一般通过对实际系统的了解和分析后，使用数据流图为系统建立逻辑模型。建立数据流图的步骤如下：
　  第1步：由外向里：先画系统的输入输出，然后画系统的内部。
　  第2步：自顶向下：顺序完成顶层、中间层、底层数据流图。
　  第3步：逐层分解。
　  数据流图的建立从顶层开始，顶层的数据流图形式如图3.2所示。顶层数据流图应该包含所有相关外部实体，以及外部实体与软件中间的数据流，其作用主要是描述软件的作用范围，对总体功能、输入、输出进行抽象描述，并反映软件和系统、环境的关系。
　  对复杂系统的表达应采用控制复杂度策略，需要按照问题的层次结构逐步分解细化，使用分层的数据流图表达折中结构关系，分层的数据流图的形式如图 3.3 所示。
　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　图3.3　分层的数据流图
　  为保证构造的数据流图表达完整、准确、规范，应遵循以下数据流图的构造规则和注意事项：
　  •  对加工处理建立唯一、层次性的编号，且每个加工处理通常要求既有输入又有输出；
　　•  数据存储之间不应该有数据流；
　　•  数据流图的一致性。它包括数据守恒和数据存储文件的使用，即某个处理用以产生
　  输出的数据没有输入，即出现遗漏，另一种是一个处理的某些输入并没有在处理中使用以产生输出；数据存储（文件）应被数据流图中的处理读和写，而不是仅读不写、或仅写不读。
　  • 父图、子图关系与平衡规则。相邻两层 DFD 之间具有父、子关系，子图代表了父图中某个加工的详细描述，父图表示了子图间的接口。子图个数不大于父图中的处理个数。所有子图的输入、输出数据流和父图中相应处理的输入、输出数据流必须一致。
　  图 3.4 是银行取款业务的数据流图。
　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　图 3.4 银行取款业务的数据流图

　　⑵数据字典（DD — Data Dictionary）
　  数据字典是结构化分析方法的核心。数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算结果有共同的理解。数据字典把不同的需求文档和分析模型紧密地结合在一起，与各模型的徒刑表示配合，能清楚地表达数据处理的要求。
　  概括地说，数据字典的作用是对DFD中出现的被命名的图形元素的确切解释。通常数据字典包含的信息有：名称、别名、何处使用/如何使用、内容描述、补充信息等。例如，对加工的描述应包括：加工名，反映该加工层次的加工编号、加工逻辑及功能简述数据结构。表3.1给出了常用的定义式符号。
　　　　　　　
　　　　　　　　　　　　　　　　　　　　　表3.1　数据字典定义式方式中出现的符号

　　例如，银行取款业务的数据流图中，存储文件 “ 存折 ” 的 DD 定义如下：
　  存折 = 户名 + 所号 + 账户 + 开户日 + 性质 + （印密） +1{ 存取行 }50
　  户名 =2{ 字母 }24
　  所号 = “ 001 ” … “ 999 ”
　  账号 = “ 00000001 ” … “ 99999999 ”
　  开户日 = 年 + 月 + 日
　  性质 = “ 1 ” … “ 6 ”
　  印密 = “ 0 ”
　  存取行 = 日期 + （摘要） + 支出 + 存入 + 余额 + 操作 + 复核
　  日期 = 年 + 月 + 日
　  年 = “ 00 ” .. “ 99 ”
　  月 = “ 01 ” .. “ 12 ”
　  日 = “ 01 ” .. “ 31 ”
　  摘要 =1{ 字母 }4
　  支出 = 金额
　  金额 = “ 00000000.01 ” .. “ 99999999.99 ”
　  操作 = “ 00001 ” .. “ 99999 ”
　  ⑶判定树
　  使用判定树进行描述时，应先从问题定义的文字描述中分清那些是判定的条件，哪些是判定的结论，根据描述材料中的连接次找出判定条件之间的从属关系、并列关系、选择关系，根据他们构造判定树。
　  例如，某货物托运管理系统中，对发货情况的处理要依赖检查发货单，检查发货单受货物托运金额、欠款等条件的约束，可以使用类似分段函数的形式来描述这些约束和处理。对这种约束条件的描述，如果使用自然语言，表达易出现不准确和不清晰。如果使用如图 3.5 所示的判定树来描述，则简捷清晰。
　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　图3.5　“检查发货单”的判定树
　  ⑷判定表
　  判定表与判定树相似，当数据流图中的加工要依赖与多个逻辑条件的取值，即完成该加工的一组动作是由于某一组条件取值的组合而引发的，使用判定表描述比较适宜。
　  判定表由四部分组成，如图3.6所示。其中标识为①的左上部称条件项，它列出了各种可能的条件。标识为②的右上部称条件项，它列出了各种可能的条件组合。标识为③的左下部称基本动作项，它列出了所有的操作。标识为④的右下部称动作项，它列出在对应的条件组合下所选的操作。
　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　图3.6　判定表
　  图3.7为 “ 检查发货单 ” 判定表，其中 “ √ ” 表示满足对应条件项时执行的操作。
　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　图3.7　“ 检查发货单 ” 判定表
　　判定表或判定树是以图形形式描述数据流图的加工逻辑，它结构简单，易读易懂。尤其遇到组合条件的判定，利用判定表或判定树可以使问题的描述清晰，而且便于直接映射到程序代码。在表达一个加工逻辑时，判定树、判定表都是好的描述工具，根据需要还可以交叉使用。

　　3.2.3 软件需求规格说明书

　　软件需求规格说明书 （ SRS ， Software Requirement Specification ） 是需求分析阶段的最后成果 ， 是软件开发中的重要文档之一。
　  1. 软件需求规格说明书的作用
　  软件需求规格说明书的作用是：
　  •  便于用户、开发人员进行理解和交流。
　  •  反映出用户问题的结构，可以作为软件开发工作的基础和依据。
　  •  作为确认测试和验收的依据。
　  2. 软件需求规格说明书的内容
　  软件需求规格说明书是作为需求分析的一部分而制定的可交付文档。该说明把在软件计划中确定的软件范围加以展开，制定出完整的信息描述、详细功能说明、恰当的检验标准以及其他与要求有关的数据。
　  软件需求规格说明书所包括的内容和书写框架如下：
　　　　　
　　其中，概述是从系统的角度描述软件的目标和任务。
　　数据描述是对软件系统所必须解决的问题作出详细说明。
    功能描述中描述了为解决用户问题所需要的每一项功能的过程细节。对每一项功能要给出处理说明和在设计时需要考虑的限制条件。
    在性能描述中说明系统应达到的性能和应该满足的限制条件，检测的方法和标准，预期的软件响应和可能需要考虑的特殊问题。
    参考文献目录中应包括与该软件有关的全部参考文献，其中包括前期的其他文档、技术参考资料、产品目录手册以及标准等。
    附录部分包括一些补充资料。如列表数据、算法的详细说明、框图、图表和其他材料。
    3. 软件需求规格说明书的特点
　　软件需求规格说明书是确保软件质量的有力措施，衡量软件需求规格说明书质量好坏的标准、标准的优先级及标准的内涵是：
　　① 正确性。体现待开发系统的真实要求。
　　② 无歧义性。对每一个需求只有一种解释，其陈述具有惟一性。
　　③ 完整性。包括全部有意义的需求，功能的、性能的、设计的、约束的，属性或外部接口等方面的需求。
　　④ 可验证性。描述的每一个需求都是可以验证的，即存在有限代价的有效过程验证确认。
　　⑤ 一致性。各个需求的描述不 10 矛盾。
　　⑥ 可理解性。需求说明书必须简明易懂，尽量少包含计算机的概念和术语，以便更用户和软件人员都能接受它。
　　⑦ 可修改性。 SRS 的结构风格在需求有必要改变时是易于实现的。
　　⑧ 可追踪性。每一个需求的来源、流向是清晰的，当产生和改变文件编制时，可以方便地引证每一个需求。
　  软件需求规格说明书是一份在软件生命周期中至关重要的文件，它在开发早期就为尚未诞生的软件系统建立了一个可见的逻辑模型，它可以保证开发工作的顺利进行，因而应及时地建立并保证它的质量。
　  作为设计的基础和验收的依据，软件需求规格说明书应该是精确而无二义性的，需求说明书越精确，则以后出现错误、混淆、反复的可能性越小。用户能看懂需求说明书，并且发现和指出其中的错误是保证软件系统质量的关键，因而需求说明书必须简明易懂，尽量少包含计算机的概念和术语，以便用户和软件人员双方都能接受它。