系统分析与设计方法 · 需求工程与软件设计总纲

来了。根据 Standish Group 对 23000 个项目进行的研究结果表明：28% 的项目彻底失败，46% 的项目超出经费预算或者超出工期，只有约 26% 的项目获得成功。注意，28 加 46 加 26 正好是 100，考试常把 46 和 28 的位置互换做干扰。

还有第二组：在这些高达 74% 的不成功项目中，有约 60% 的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题。这两句话连着记——74% 不成功，其中 60% 源于需求。

需求分析是软件生命周期中相当重要的一个阶段，它解决的是「做什么」的问题，而系统设计解决的则是「怎么做」的问题。这对问答是整个 8.2 节的题眼。需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成一个完整的、清晰的、一致的需求说明。

需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。一句话概括：需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。这句概括本身就能出选择题。

有。需求分析的实现步骤通常包括三个部分：获取当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的逻辑模型。物理模型、逻辑模型、再逻辑模型，三步。具体来说需求分析阶段的工作可以分成 4 个方面，你逐个记。

一，问题识别：用于发现需求、描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求。二，分析与综合：对问题进行分析，然后在此基础上整合出解决方案，这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法 SA、面向数据结构的 Jackson 方法、面向对象的分析方法 OOA，以及用于建立动态模型的状态迁移图和 Petri 网。三，编制需求分析的文档：对已经确定的需求进行文档化描述，该文档通常称为需求规格说明书。四，需求分析与评审：它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰性，以及其他需求给予评价。

接着看需求的分类。软件需求就是系统必须完成的事及必须具备的品质。具体来说包括三个方面：功能需求，是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作；非功能需求，是指产品必须具备的属性或品质，如性能、响应时间、可靠性、容错性、扩展性等；设计约束，也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统，必须在 UNIX 操作系统之下运行等。功能需求、非功能需求、设计约束，三件套。

同一件事的两套讲法：8.1 节从问题定义角度讲，强调动词、副词的思维模式；8.2 节从软件需求工程角度讲，加上设计约束凑成三分类。考试两套都可能考，口径不冲突，答题看题干落在哪一节。

除了这三种，还有三个不同层面的概念：业务需求，是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求；用户需求，是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求；系统需求，是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性、非功能需求及设计约束。

按眼镜的比喻记：分析师经常围绕着功能需求展开工作，而功能需求大部分都是从系统需求的角度来分析与理解的，也就是用开发人员的视角；但要想真正得到完整的需求，仅戴上开发人员的眼镜是不够的，还需要领域专家的眼镜，从更高的角度理解，这就是业务需求；同时应该深入用户，了解他们的使用场景和想法，这就是用户需求。选择题问「反映组织机构或客户高层次目标要求的是哪个」，答业务需求，别错选成系统需求。

不是一回事，注意措辞。需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，主要包括需求开发和需求管理两大工作。需求开发包括四个阶段：需求捕获、需求分析、编写规格说明书和需求验证。在这个阶段需要完成确定产品所期望的用户类型、获取每种用户类型的需求、分析源于用户的信息、对需求进行优先级分类、将所收集的需求编写成软件规格说明书和需求分析模型、对需求进行评审等工作。

需求管理则通常包括定义需求基线、处理需求变更、需求跟踪等方面的工作。两者的关系原文说得很清楚：这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话说，需求开发是努力更清晰、更明确地掌握客户对系统的需求，而需求管理则是对需求的变化进行管理的过程。问「基线、变更、跟踪属于哪块」，答需求管理。

按分解方式不同和发展历史记四个。一，结构化分析方法：20 世纪 70 年代分析技术发展的分水岭出现，人们开始尝试使用标准化的方法，开发和推出各种名为结构化分析的方法论，而 Tom DeMacro 则是这个领域最有代表性和权威性的专家。二，软系统方法：这是一个过渡性的方法论，并未真正流行过，它的出现只是证明了结构化分析方法的一些不足，因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决不确定性时显得十分无力，最有代表性的软系统方法是 Checkland 方法。

三，面向对象分析方法：20 世纪 90 年代，结构化方法的不足在面对多变的商业世界时显得更加苍白无力，催使了 OOA 的迅速发展。四，面向问题域的分析 PDOA：现在又发现面向对象分析方法也存在很多不足，应运而生了一些新的方法论，不过还在研究阶段，并未广泛应用。

对，越冷门越爱考。接下来 8.2.2，如何进行系统设计。原文先泼冷水：掌握工具和技能绝不是成为优秀设计者的充分条件，甚至也不是必要条件。遗憾的是这里没有捷径，只有设计者在实践中不断学习和总结。核心判断来了：在实践中，系统设计与其说是在设计，不如说是在选择和妥协。

妥协，就是在各个系统目标之间找到一个平衡点。系统目标包括但不限于功能、性能、健壮性、开发周期、交付日期等。这些目标往往是矛盾的：提高软件性能直接意味着开发周期的增加、交付日期的推迟，盲目地增加功能可能导致性能降低，维护成本提高。如果设计者发现没有平衡点，原文的比喻很妙——如同没有一个设计者能让人骑着自行车到月球上去，那么设计者只能提出放弃某个方面的过度要求，否则系统要遭受必然失败的命运。

原文说得直白：没有一个设计者会完全重新开始设计一个系统，他们总参考多个与目标系统相类似的系统，再从中进行甄别、取舍和补充。优秀的设计者能在听完需求后立即构想出目标系统的框架，不是因为聪明或多一个脑袋，而是因为他平时已经了解大量的系统，对各种设计的优缺点、局限性了然于胸。所以了解、掌握、消化、总结前人和自己以前的设计成果是最好的方法，这似乎也是唯一的方法。

有。优秀的系统设计一般在三个方面很出色：一是组件的独立性，审视自己设计的系统，是否做到了高内聚、低耦合；二是例外的识别和处理，谁能保证系统使用者都精确按照使用说明书使用；三是防错和容错，当网络中断、数据库崩溃这样的灾难性事件发生时，系统也跟着崩溃吗。另外有一些技术能够改进系统设计，包括：降低复杂性、通过合约进行设计、原型化设计、错误树分析。注意「组件的独立性」这条埋着后面模块设计的高内聚低耦合，先挂个钩子。

8.2.3，软件设计的任务与活动。软件设计是一个把软件需求变换成软件表示的过程，最初这种表示只是描绘出软件的总体框架，然后再进一步细化，并在此框架中填入细节。从工程管理角度，软件设计可以分为两个步骤：概要设计，也称为高层设计，将软件需求转化为数据结构和软件的系统结构，例如采用结构化设计，将从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系；详细设计，也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算法。概要设计别名高层设计、详细设计别名低层设计，这四个名字要能互认。

在结构化设计风行的时代，主流的设计方法还包括 Jackson 方法和 Parnas 方法。三者的侧重点：结构化方法侧重于模块相对独立且功能单一，使模块间联系弱、模块内联系强；Jackson 方法则是从数据结构导出模块结构；Parnas 方法的主要思想是将可能引起变化的因素隐藏在有关模块内部，使这些因素变化时的影响范围受到限制，它只提供了重要的设计准则，但没有规定出具体的工作步骤。而近年来，对象技术凭借其对数据的高效封装及良好的消息机制，实现了高内聚、低耦合的系统设计，成了现代软件设计的主流方法学。

本集必背：Standish 统计 28% 彻底失败、46% 超支或超期、26% 成功，74% 不成功里约 60% 源于需求；需求分析答「做什么」、设计答「怎么做」；需求分析四方面是问题识别、分析与综合、编制文档即需求规格说明书、评审；需求分功能需求、非功能需求、设计约束三种，另有业务、用户、系统三层模型；需求工程等于需求开发加需求管理，开发是主线是目标、管理是支持是保障，开发含捕获、分析、编写规格说明书、验证四阶段，管理含基线、变更、跟踪；系统设计是选择和妥协，三个出色方面是组件独立性、例外处理、防错容错；概要设计即高层设计、详细设计即低层设计；结构化、Jackson、Parnas 三方法的侧重点。

下一集进入本章第一座大山：结构化分析。数据流图的五个元素、三种图的分层结构、数据字典的六个符号，练习题第 3 题和第 14 题都在那儿等着。