系统架构设计笔记（34）—— 需求分析与软件设计

「爱情、让人受尽委屈。」 2023-02-14 01:25 135阅读 0赞

需求分析是软件生命周期中相当重要的一个阶段。根据 Standish Group 对 23000 个项目进行的研究结果表明， 28% 的项目彻底失败， 46% 的项目超出经费预算或者超出工期，只有约 26% 的项目获得成功。需求分析工作在整个软件开发生命周期中有着十分重要的意义。而在这些高达 74% 的不成功项目中，有约 60% 的失败是源于需求问题，也就是差不多有一半的项目都遇到了这个问题，这一可怕的现象引起人们对需求分析的高度重视。

需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流，不断澄清一些模糊的概念，最终形成一个完整的 、 清晰的 、 一致的需求说明。

而当明确了用户的需求之后，下一步的任务就是对未来的软件系统进行设计，它是确定系统实现的关键工作。需求分析和设计的方法对软件开发过程而言是十分重要的，因此必须扎实地掌握它。

需求分析与软件设计是软件生存期中最重要的两个步骤，需求分析解决的是 “ 做什么 ” 的问题，系统设计则是解决 “ 怎么做 ” 的问题。

## 1 需求分析的任务与过程 ##

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

### 1.1 需求分析阶段的工作 ###

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

**（1）问题识别**

用于发现需求 、 描述需求，主要包括功能需求 、 性能需求 、 环境需求 、 可靠性需求 、 安全保密需求 、 用户界面需求 、 资源使用需求 、 软件成本消耗与开发进度需求，以此来预先估计以后系统可能达到的目标。

**（2）分析与综合**

也就是对问题进行分析，然后在此基础上整合出解决方案。这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法（ Structured Analysis ， SA ），面向数据结构的 Jackson 方法，面向对象的分析方法（ Object Oriented Analysis ， OOA ），以及用于建立动态模型的状态迁移图和 Petri 网。

> Petri 网是对离散并行系统的数学表示。它适合于描述异步的 、 并发的计算机系统模型。 Petri 网既有严格的数学表述方式，也有直观的图形表达方式，既有丰富的系统描述手段和系统行为分析技术，又为计算机科学提供坚实的概念基础。

**（3）编制需求分析的文档**

也就是对已经确定的需求进行文档化描述，该文档通常称为 “ 需求规格说明书 ”。

**（4）需求分析与评审**

它是需求分析工作的最后一步，主要是对功能的正确性 、 完整性和清晰性，以及其他需求给予评价。

### 1.2 需求的分类 ###

什么是软件的需求呢？软件需求就是系统必须完成的事及必须具备的品质。具体来说，软件需求包括功能需求 、 非功能需求和设计约束三方面内容。各种需求的概念示意图如图 1 所示。

![format_png][]

> SRS，即需求规格说明书(Software Requirements Specification)。

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

除了这三种需求之外，还有业务需求 、 用户需求 、 系统需求这三个处于不同层面的概念，充分地理解这样的模型才能够更加清晰地理清需求的脉络。

1.  业务需求（Business Requirement）：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
2.  用户需求（User Requirement）：是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发的需求。
3.  系统需求（System Requirement）：是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性、非功能需求及设计约束。

分析师经常围绕着 “ 功能需求 ” 来展开工作，而功能需求大部分都是从 “ 系统需求 ” 的角度来分析与理解的，也就是用 “ 开发人员 ” 的视角来理解需求。但要想真正地得到完整的需求，仅戴上 “ 开发人员 ” 的眼镜是不够的，还需要 “ 领域专家 ” 的眼镜，要从更高的角度来理解需求，这就是 “ 业务需求 ” ；同时还应该更好地深入用户，了解他们的使用场景，了解他们的想法，这就是 “ 用户需求 ” 。这是一个理解层次的问题，并不仅仅是简单的概念。

### 1.3 需求工程 ###

需求工程就是包括创建和维护系统需求文档所必需的一切活动的过程，主要包括需求开发和需求管理两大工作。

（1）需求开发：包括需求捕获 、 需求分析 、 编写规格说明书和需求验证4个阶段。在这个阶段需要完成确定产品所期望的用户类型 、 获取每种用户类型的需求 、 了解实际用户任务和目标及这些任务所支持的业务需求 、 分析源于用户的信息 、 对需求进行优先级分类 、 将所收集的需求编写成为软件规格说明书和需求分析模型 、 对需求进行评审等工作。

（2）需求管理：通常包括定义需求基线 、 处理需求变更 、 需求跟踪等方面的工作。这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话说，需求开发是努力更清晰 、 更明确地掌握客户对系统的需求；而需求管理则是对需求的变化进行管理的过程。

### 1.4 需求分析方法 ###

需求分析的方法可谓种类繁多，不过如果按照分解方式的不同，可以很容易地划分出几种类型。

**（1）结构化分析方法**

最初的分析方法都不成体系，而且通常都只包括一些笼统的告诫，在 20 世纪 70 年代分析技术发展的分水岭终于出现了。这时人们开始尝试使用标准化的方法，开发和推出各种名为 “ 结构化分析 ” 的方法论，而 Tom DeMacro 则是这个领域最有代表性和权威性的专家。

**（2）软系统方法**

这是一个过渡性的方法论，并未真正流行过，它的出现只是证明了结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入，而且在解决 “ 不确定性 ” 时显得十分无力。最有代表性的软系统方法是 Checkland 方法。

**（3）面向对象分析方法**

在 20 世纪 90 年代，结构化方法的不足在面对多变的商业世界时，显得更加苍白无力，这就催使了 OOA 的迅速发展。

**（4）面向问题域的分析（Problem Domain Oriented Analysis， PDOA）**

现在又发现面向对象分析方法也存在着很多的不足，应运而生了一些新的方法论， PDOA 就是其中一种。不过现在还在研究阶段，并未广泛应用。

## 2 如何进行系统设计 ##

当设计者拿到一个需求，他如何开展系统设计呢？许多想进入系统分析与设计的年轻人以为自己知道了面向对象 、 统一建模语言 、 设计模式等新鲜深奥的名词就可以进行设计了，可是掌握工具和技能绝不是成为优秀设计者的充分条件，甚至也不是必要条件。遗憾的是这里没有捷径，只有设计者在实践中不断学习和总结。而在实践中，系统设计与其说是在设计，不如说是在选择和妥协。

妥协，就是在各个系统目标之间找到一个平衡点。系统目标包括但不限制于功能 、 性能 、 健壮性 、 开发周期 、 交付日期等。不幸的是，这些目标往往是矛盾的，提高软件性能直接意味着开发周期的增加 、 交付日期的推迟，盲目地增加功能可能导致性能降低，维护成本提高。软件设计者的难题在于在如此众多的目标之间找到这个平衡点，并且明确知道如何设计能实现这个平衡，既可以让投资者觉得在预算之内，又能让用户相对满意。可行性分析阶段应该已经论述了这样一个平衡点，可是如果设计者发现没有这样一个平衡点，如同没有一个设计者能让人骑着自行车到月球上去，那么设计者只能提出放弃某个方面的过度要求，否则系统要遭受必然失败的命运。

更多的情况是没有经验的设计者不知道是否存在这些平衡点，更不知道如何利用合理的设计及有效的工具来达到平衡。因此设计者需要了解可以解决问题的各种方案，并清楚知道各个方案的效果 、 成本 、 缺点，以及这些方案的区别，并在各种方案中进行选择。而这些，不是一个人能在一两天了解的。

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

设计者的苦恼有时候和编程人员一样。计算机系统的发展如此迅速，解决方案也越来越多，如同编程语言的发展，同时，随着人类社会的进步，投资者和客户也提出了越来越高的要求，这又需要设计者不断学习 、 创造新的方案。但系统设计也并非没有规律可以遵循，如同幸福的家庭都很相似，不幸的家庭各有各的不幸，人们在实践中发现优秀的系统设计一般在以下几个方面都很出色。

（1）组件的独立性。审视自己设计的系统，是否做到了高内聚、低耦合？  
（2）例外的识别和处理。谁能保证系统使用者都精确按照使用说明书使用？  
（3）防错和容错。当网络中断、数据库崩溃这样的灾难性事件发生时，系统也跟着崩溃吗？

而且，更幸运的是，也有一些技术能够改进系统设计，这些方法包括：降低复杂性 、 通过合约进行设计 、 原型化设计 、 错误树分析等。

## 3 软件设计的任务与活动 ##

软件设计是一个把软件需求变换成软件表示的过程。最初这种表示只是描绘出软件的总体框架，然后再进一步细化，并在此框架中填入细节。

### 3.1 软件设计步骤 ###

软件设计的两个阶段从工程管理角度，软件设计可以分为两个步骤：

（1）概要设计：也称为高层设计，将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则将从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。

（2）详细设计：也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算法。同样的，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

### 3.2 主要的设计方法比较 ###

在结构化设计风行的时代，主流的设计方法还包括 Jackson 方法和 Parnas 方法。

结构化方法侧重于 “ 模块相对独立且功能单一，使模块间联系弱 、 模块内联系强 ” ；而 Jackson 方法则是从数据结构导出模块结构； Parnas 方法的主要思想则是将可能引起变化的因素隐藏在有关模块内部，使这些因素变化时的影响范围受到限制，它只提供了重要的设计准则，但没有规定出具体的工作步骤。

而近年来，对象技术凭借其对数据的高效封装及良好的消息机制，实现了高内聚 、 低耦合的系统设计，成了现代软件设计的主流方法学。

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8zMzg2MTA4LTZiNDIzYWUzMjY0ODMwNTEucG5n?x-oss-process=image/format,png