软件需求与结构化方法

本节导读

这一节讲软件工程大纲的第（三）单元「软件需求与软件需求规约」（需求的定义和分类、常用的需求发现技术、需求规约及其格式）和第（四）单元「系统规约及软件设计」中的结构化方法。需求回答「做什么」，设计回答「怎么做」；结构化方法用数据流图描述需求，用模块结构图描述设计。

常见资料提到软件工程有「建模」题，结构化方法里建模的典型做法是画数据流图；简答可以重点准备需求的分类、需求规约的质量要求、耦合与内聚；判断和选择则要记准数据流图的规则和耦合内聚的强弱次序。学完你应该能按题目描述画出顶层和 0 层数据流图，并能判断一个模块属于哪种耦合、哪种内聚。

软件需求的定义与分类

IEEE 对需求的定义有三层意思：用户解决问题或达到目标所需的条件或能力；系统为满足合同、标准、规格说明等而必须满足的条件或能力；对上述条件或能力的文档化描述。

需求可以这样分类：

类别	含义	例子
功能需求	系统必须完成的功能	「用户可以按书名查询图书」
性能需求	速度、容量、吞吐量等指标	「90% 的查询在 3 秒内返回」
外部接口需求	与用户、硬件、其他软件的接口	「通过标准接口读取门禁卡号」
设计约束	对实现方式的限制	「必须使用某种指定的数据库」
质量属性	可靠性、安全性、可维护性、可移植性等	「连续运行一个月故障不超过一次」

后四类常统称为非功能需求。需求工作包括需求获取（发现）、分析、规约、验证和管理。

常用的需求发现技术

大纲要求掌握常用的需求发现技术，通行教材列出的主要有：自悟（分析员凭自己对业务的理解提出需求）、交谈（与用户面谈，可以有提纲也可以开放式）、观察（到现场看用户实际怎样工作）、小组会（召集各方代表集中讨论）、提炼（分析现有的业务单据、报表、文档，从中提炼需求）。此外还常用原型、问卷调查和场景分析。实际项目往往几种技术结合使用。

需求规约

需求规约（软件需求规格说明）是对需求准确、完整的书面描述，是设计、测试和验收的依据。一份好的需求规约应当：正确、无歧义、完整、一致（各条需求之间不矛盾）、可验证（每条需求都能用测试或检查确认是否实现）、可修改、可追踪（能追溯到需求的来源和后续的设计）。常见格式按 IEEE 830 分为引言、总体描述、具体需求（外部接口、功能、性能、设计约束、质量属性）和附录几部分。

结构化分析：数据流图与数据字典

数据流图（DFD）只用四种元素描述数据在系统中的流动和加工：

元素	含义	常见画法
数据流	流动中的数据	带名字的箭头
加工	对数据的处理	圆或圆角矩形，写编号和名字
数据存储	暂存的数据（文件、数据库）	两条平行线或一端开口的矩形
数据源和数据潭	系统外的数据来源和去处（外部实体）	方框

数据流图要分层画：顶层图只有一个加工，代表整个系统，用来确定系统的边界和输入输出；0 层图把它分解成几个主要加工；需要时再继续分解。父图中的一个加工与它的子图必须平衡：子图的输入、输出数据流与父图中这个加工的输入、输出一致。数据流图不表示控制流程，不画判断和循环。

数据字典给数据流图中的每个数据流、数据存储、数据项和加工下定义。常用符号：「=」表示由什么组成，「+」表示并且，「[ … | … ]」表示几项中选一项，「{ … }」表示重复，「( … )」表示可选。加工的逻辑用加工说明描述，常用结构化语言、判定表和判定树。判定表把条件的所有组合列成规则，n 个二值条件在合并之前有 $2^n$2n 条规则。

结构化设计：模块结构图与设计准则

结构化设计把数据流图映射为模块结构图：方框表示模块，箭头表示调用，箭头旁的小箭头表示传递的数据或控制信息。数据流图是变换型的（输入、变换、输出三部分明显）就用变换分析，找出变换中心，分出输入、变换、输出三个分支；是事务型的（一个事务中心按类型把数据分派给不同处理）就用事务分析。