系统架构设计专业技能 · 软件工程（一）【系统架构设计师】

系列文章目录

系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】

一、软件工程概念★

软件开发生命周期：

软件定义时期 ：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标，具体可分成问题定义、可行性研究、需求分析等。
软件开发时期 ：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
软件运行和维护 ：就是把软件产品移交给用户使用。

软件系统的文档：

软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关系这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。

软件工程过程是指为获得软件产品包括以下4个方面活动（PDCA）：

P(Plan)——软件规格说明 ：规定软件的功能及其运行时的限制。
D(Do)—―软件开发 ：开发出满足规格说明的软件。
C(Check)——软件确认 ：确认开发的软件能够满足用户的需求。
A(Action)―—软件演进 ：软件在运行过程中不断改进以满足客户新的需求。

软件系统工具通常可以按软件过程活动将软件工具分为：

软件开发工具 ：需求分析工具、设计工具、编码与排错工具、测试工具等。
软件维护工具 ：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具 ：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件设计四个活动：
数据设计、架构（体系结构）设计、人机界面（接口）设计、过程设计。

1.1 软件危机

二、 软件能力成熟度模型

软件能力成熟度模型（Capability Maturity Model for Software，CMM）

软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）
阶段式模型，CMMI是在CMM的基础上发展而来的，它关注组织的成熟度。

三、软件过程模型

3.1 瀑布模型

瀑布模型（SDLC）也称为生命周期法，是生命周期法中最常用的开发模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。如图：

瀑布模型特点：

• 从上一项开发活动接受该项活动的工作对象作为输入。
• 利用这一输入，实施该项活动应完成的工作内容。
• 给出该项活动的工作成果，作为输出传给下一项开发活动。
• 对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动;否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件

瀑布模型有利于大型软件开发过程中人员的组织与管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下的，而是呈线性图示，因此，瀑布模型存在严重的缺陷：

• 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样，软件与用户见面的时间间隔较长，也增加了一定的风险。
• 在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能导致整个软件项目开发失败。
• 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。

3.2 原型模型

原型化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。

原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下：

• 实际可行。
• 具有最终系统的基本特征。
• 构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。

有关原型化方法/模型的内容：

软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决在产品开发的早期阶段的需求不确定的问题，其目的是明确并完善需求、探索设计选择方案、发展为最终的产品。原型模型比较适合需求不够明确的项目。

原型有很多种分类方法。从原型是否实现功能来分，软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。

从原型的最终结果来分，软件原型可分为 抛弃型原型和 演化型原型。抛弃型原型也称为探索型原型，是指达到预期目的后，原型本身被抛弃。 抛弃型原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。演化型原型为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分。演化型原型主要用在必须易于升级和优化的项目，适用于Web项目。

有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。进化型原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。

原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型（在生命周期法中，需求分析成文档后一般不再多修改）。

在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，最终的结果是更适合用户的要求。

这种原型技术又可分为三类：抛弃式、演化式和递增式。这种原型法成败的关键及效率的高低在于模型的建立及建模的速度。

3.3 增量模型

增量模型融合了瀑布模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的"增量“。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都作为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。

增量模型强调每一个增量均发布一个可操作的产品。如图：

增量模型像原型实现模型和其他演化方法一样，本质上是迭代的。但与原型实现不同的是增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的"可拆卸"版本，但它们确实提供了为用户服务的功能，并且提供了给用户评估的平台。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求，还需要更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。

采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源，如果核心产品很受欢迎，则可以增加人力实现下一个增量；当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。增量模型的缺点是如果增量包之间存在相交的情况且不能很好地处理，就必须做全盘的系统分析，不能很好的进行模块划分。增量模型将功能细化、分别开发的方法适用于需求经常改变的软件开发过程。

3.4 螺旋模型

螺旋模型将瀑布模型和原型化（演化）模型相结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动，并开发原型的一个新版本。

螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。经过若干次螺旋上升的过程，得到最终的系统，如图：（需求在项目刚开始的时候往往会比较模糊，而随着项目的进行会慢慢的明确下来，也就是需求有渐进明细的特点。）

3.5 V 模型

在开发模型中，测试常常作为亡羊补牢的事后行为，但也有以测试为中心的开发模型，那就是V模型。V模型只得到软件业内比较模糊的认可。V模型宣称测试并不是一个事后弥补行为，而是一个同开发过程同样重要的过程，如图：

V模型是最具有代表意义的测试模型，它是瀑布模型的变种，它在瀑布模型的基础上加强了测试，反映了测试活动与分析和设计的关系。V模型中，左边下降的是开发过程阶段，右边上升部分是测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。让测试工作贯穿于始终。

V模型强调软件幵发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质M情况下缩短开发周期。V模型适合企业级的软件幵发，它更淸楚地揭示了软件开发过程的特性及其本质。

V模型的价值在于它非常明确地表明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系：

• 单元测试的主要目的是针对编码过程中可能存在的各种错误。例如：用户输入验证过程中的边界值的错误。
• 集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。
• 系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行。例如：在产品设置中是否达到了预期的高性能。
• 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

迭代与增量的概念

3.6 喷泉模型

喷泉模型对软件复用和生命周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法，是一种以用户需求为动力，以对象作为驱动的模型。"喷泉"一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界，如图：

3.7 CBSD基于构件的模型（构件组装模型/基于构件的软件开发）

构件（Component，组件）是一个具有可重用价值的、功能相对独立的软件单元。基于构件的软件开发（ComponentBased Software Development，CBSD）模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。

基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立（其中构件库包括了构件获取和构件管理）、应用软件构建、测试和发布5个阶段组成。如图：

CBSE的构件应该具备的特征：

• 可组装性：所有外部交互必须通过公开定义的接口进行。
• 可部署性：构件总是二进制形式的，能作为一个独立实体在平台上运行。
• 文档化：用户根据文档来判断构件是否满足需求。
• 独立性：可以在无其他特殊构件的情况下进行组装和部署。
• 标准化：符合某种标准化的构件模型。

CBSE的构件的组装顺序：

• 顺序组装：按顺序调用己经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
• 层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。
• 叠加组装：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口。

构件作为重要的软件技术和工具得到了极大的发展，这些新技术标准和工具有Microsoft的DCOM/COM，Sun的EJB，OMG的CORBA等。基于构件的开发活动从标识候选构件开始，通过搜索已有构件库，确认所需要的构件是否已经存在，如果已经存在，就从构件库中提取出来复用；如果不存在，就采用面向对象方法开发它。在提取出来的构件通过语法和语义检查后，将这些构件通过胶合代码组装到一起实现系统，这个过程是迭代的。

基于构件的开发方法使得软件开发不再一切从头开始，开发的过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程，其优点是构件组装模型导致了软件的复用，提高了软件开发的效率；构件可由一方定义其规格说明，被另一方实现，然后供给第三方使用；构件组装模型允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。
缺点是由于采用自定义的组装结构标准，缺乏通用的组装结构标准，引入具有较大的风险；可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员，一般的开发人员插不上手，客户的满意度低；过分依赖于构件，构件库的质量影响着产品质量。

3.8 敏捷模型

开发宣言：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。

敏捷开发方法

敏捷方法区别与其他方法的两个特点：
（1）是”适应性“而非“预设性”。
（2）是“面向人的”而非“面向过程的”。
敏捷开发核心思想：
（1）敏捷开发是适应型，而非可预测型。拥抱变化，适应变化。
（2）敏捷开发是以人为本，而非以过程为本。发挥人的特性。
（3）迭代增量式的开发过程。以原型开发思想为基础，采用法代替增量式开发，发行版本小型化。

XP极限编程

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：

（1）以代码驱动的规则，其重要的文档是源代码。
（2）在更短的周期内，更早地提供具体、持续的反馈信息。
（3）迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展它。
（4）依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
（5）依赖于口头交流、测试和源程序进行沟通。
（6）倡导持续的演化式的设计。
（7）依赖于开发团队内部的紧密协作。
（8）尽可能达到程序员短期利益和项目长期利益的平衡。

四大价值观：

• 沟通，加强面对面沟通
• 简单，不过度设计
• 反馈，及时反馈
• 勇气，接受变更的勇气

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

XP提倡测试先行，为了将以后出现bug的几率降到最低。

XP一些对费用控制严格的公司中的使用，非常有效。

水晶方法

水晶系列方法与XP方法一样，都有以人为中心的理念，但在实践上有所不同。其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。

水晶方法：探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。

开放式源码

开放式源码：程序开发人员在地域上分布很广【其他方法强调集中办公】。

并列争求法

并列争球法（SCRUM）是一种迭代的增量化过程，把每段时间（如30天）一次的迭代称为一个“冲刺”（Sprint），并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

并列争求法（SCRUM）：明确定义了的可重复的方法过程，侧重于项目管理。。

特征驱动开发方法（FDD）

特征驱动开发方法（FDD）是一个迭代的开发模型。认为有效的软件开发需要3个要素：人、过程和技术。有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。

功用驱动开发方法（FDD）：编程开发人员分成两类：首席程序员和“类”程序员。

ASD方法

ASD方法：其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。

动态系统开发方法

动态系统开发方法（DSDM）：倡导以__业务为核心。

3.9 RAD模型（快速应用开发模型）

快速应用开发（Rapid Application Development，RAD）模型是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。如果需求理解得好且约束了项目的范围，利用这种模型可以很快地创建出功能完善的“信息系统“。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。瀑布模型和CBSD（Component-Based Software Development基于构建的软件开发模型）的综合开发模型，如图：

RAD模型各个活动期所要完成的任务如下：

• 业务建模：以什么信息驱动业务过程运作？要生成什么信息？谁生成它？信息流的去向是哪里？由谁处理？可以辅之以数据流图。
• 数据建模：为支持业务过程的数据流，找数据对象集合，定义数据对象属性，与其他数据对象的关系构成数据模型，可辅之以E-R图。
• 过程建模：使数据对象在信息流中完成各业务功能。创建过程以描述数据对象的增加、修改、删除、查找，即细化数据流图中的处理框。
• 应用程序生成：利用第四代语言（4GL）写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成并构造出整个应用系统。
• 测试与交付，由于大量重用，一般只做总体测试，但新创建的构件还是要测试的。

与瀑布模型相比，RAD模型不采用传统的第三代程序设计语言来创建软件，而是采用基于构件的开发方法，复用已有的程序结构（如果可能的话）或使用可复用构件，或创建可复用的构件（如果需要的话）。在所有情况下，均使用自动化工具辅助软件创造。很显然，加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成，那么它就是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现，最后再集成起来形成一个整体。

RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是像所有其他软件过程模型一样，RAD方法也有其缺陷：

• 并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一项功能不能被模块化，那么建造RAD所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。
• 开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
• RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计算机程序有较高的互操作性时，这种情况就会发生。

3.10 统一过程模型（RUP/UP）

RUP的特点

（1）用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
（2）以架构为中心：包括系统的总体组织和全局控制、通信协议等。是一个多维的结构，会采用多个视图（4 + 1 视图） 来描述。
（3）迭代与增量：把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程;每次迭代是在己完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。

RUP中有4个阶段

统一软件开发过程定义了四种开发阶段，它们按照过程顺序分别是起始阶段，细化阶段，构建阶段和交付阶段，其中在构建阶段主要产生的文档有设计模型。

• 初始阶段：项目蓝图文档（核心需求，关键特征，主要约束），用例模型，项目计划

• 细化阶段：完成架构设计，淘汰高风险元素

• 构造阶段：UML模型，测试用例

• 交付阶段：可运行的软件产品，用户手册，用户支持计划。

RUP中有9个核心工作流

RUP的工作流程分为两部分：核心工作流程与核心支持工作流程。核心工作流程（在项目中的流程）包括业务需求建模、分析设计、实施、测试、部署；核心支持工作流程（在组织中的流程）包括环境、项目管理、配置与变更管理。

RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，如下：

• 业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
• 需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
• 分析与设计：把需求分析的结果转化为分析与设计模型。
• 实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
• 测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
• 部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
• 配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
• 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
• 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

四、逆向工程

逆向工程的特点是从已有的程序中抽取数据结构，体系结构和程序设计信息。

它的流程为：现有系统 → 逆向工程 → 考虑新需求 → 正向工程 → 新系统。

软件的逆向工程是一个恢复设计的过程，从现有的程序中抽取数据，体系结构和过程设计信息。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述，在大多数情况下，抽象层次越高，完备性就越低。

领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程：

• 重构（restructuring），重构是指在同一抽象级别上转换系统描述形式。
• 设计恢复（design recovery），设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
• 逆向工程（reverse engineering），逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
• 正向工程（forward engineering），正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
• 再工程（re-engineering），再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。

逆向工程恢复信息的方法:

五、需求工程

2.1 软件需求的层次

2.2 需求工程

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

需求工程（Requirement Engineering，RE） 是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

需求工程由需求获取、需求分析、形成需求规格（或称为需求文档化）、需求确认与验证、需求管理5个阶段，如图：

软件需求规格说明书（Software Requirement Specification，SRS）
SRS具体包括功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的SRS是需求开发和需求管理之间的桥梁。

需求管理
需求管理是一个对系统需求变更、了解和控制的过程，包括变更控制、版本控制、需求跟踪等活动。

2.5 需求开发（主线、目标）

2.5.1 需求分类

• 需求分类

（1）业务需求：业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。

（2）用户需求：用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求

（3）系统需求：系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

• 质量功能部署QFD

它是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

（1）基本需求：也叫常规需求，用户认为系统应该做到的功能或性能，实现越多用户会越满意。

（2）期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

（3）意外需求：意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

2.5.2 需求获取

• 用户访谈
  用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
  用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

• 问卷调查
  问卷调查与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性，其他缺点还有：
  ① 双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
  ② 用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
  ③ 调查表不利于对问题进行展开的回答，无法了解一些细节问题。
  ④ 回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。

• 抽样调查/采样
  抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。
  但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

• 联合需求计划（JRP）
  JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
  JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：
  ① 在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
  ②按照既定的时间安排进行。
  ③尽量完整地记录会议期间的内容。
  ④在讨论期间尽量避免使用专业术语。
  ⑤充分运用解决冲突的技能。
  ⑥会议期间应设置充分的间歇时间。
  ⑦鼓励团队取得一致意见。
  ⑧保证参加JRP的所有人员能够遵守事先约定的规则。

2.5.2 需求分析

需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

需求分析的任务：
（1）绘制系统上下文范围关系图
（2）创建用户界面原型
（3）分析需求的可行性
（4）确定需求的优先级
（5）为需求建立模型
（6）创建数据字典
（7）使用QFD（质量功能部署)

2.5.2.1 结构化分析方法 - SA

结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型，分别是数据模型，功能模型，行为模型（状态模型）。

结构化分析的步骤，如下：
（1）分析业务情况，做出反映当前物理模型的数据流图（Data Flow DiagramDFD）。
（2）推导出等价的逻辑模型的DFD。
（3）设计新的逻辑系统，生成数据字典和基元描述。
（3）建立人机接口，提出可供选择的目标系统物理模型的DFD。
（5）确定各种方案的成本和风险等级，据此对各种方案进行分析。
（6）选择一种方案。
（7）建立完整的需求规约。

结构化分析方法SA是数据流和控制流，常用手段是数据流图（DFD）和数据字典。

2.5.2.1.1 SA - 数据字典DD

数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。

数据字典有4类条目：数据流、数据项、数据存储和基本加工。包括了数据元素，数据结构，数据流，加工逻辑和外部实体。如下图：

2.5.2.1.2 SA - 数据流图DFD

数据流图DFD是用数据流图表示功能模型，DFD说明系统所完成功能，从数据传递和加工的角度，利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能。如下图：

其中，DFD还会有“顶层DFD图”和“0层DFD图”。

如上图，有如下几种“图元”描述：

另附一个错误的DFD图，如下：

如上图错误：

加工3.1.2有输入但是没有输出，称之为“黑洞”。
加工3.1.3有输出但没有输入。称之为“奇迹”。
加工3.1.1中输入不足以产生输出，我们称之为“灰洞”。

2.5.2.1.3 SA - 状态转换图STD

用状态转换图表示行为模型，STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出做为特定事件的结果将执行哪些动作。如下图：

2.5.2.1.4 SA - E-R图/实体联系图

ER图主要描述实体属性，以及实体之间的关系。另外，ER模型是结构化时代的模型与产物，在面向对象和UML中是没有的。如下图：

什么是弱实体？
举例说明：在人事管理系统中，职工子女的信息就是以职工的存在为前提的，子女实体是弱实体，子女与职工的联系是一种依赖联系。所以，职工是实体，也可以成为强实体。
强实体与弱实体的联系只能是1：1或1：N。

2.5.2.2 面向对象的分析方法 - OOA

相关的几个概念

OOA大致上遵循如下5个基本步骤：

（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

2.5.2.2.1 OOA - UML

OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。

UML基本构造块之事物【重要组成部分】

UML基本构造块之关系【把事物紧密联系在一起】

UML基本构造块之图【多个相互关联的事物的集合】

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.5.2.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.5.2.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.5.2.2.4 需求分析工具

2.5.2.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.5.2.2.4.1 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.5.2.2.4.1 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.5.2.2.4.1 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.5.3 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5.4 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

2.6 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

2.6.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

2.6.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

2.6.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

2.6.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

（1）所有需求变更必须遵循变更控制过程。
（2）对于未获得批准的变更，不应该做设计和实现工作。
（3）变更应该由项目变更控制委员会决定实现哪些变更。
（4）项目风险承担者应该能够了解变更的内容。
（5）绝不能从项目配置库中删除或者修改变更请求的原始文档。
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

2.6.5 需求风险

带有风险的做法有：①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。

变更产生的原因：①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。

2.6.6 需求跟踪

SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要具有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。文章来源地址https://www.toymoban.com/news/detail-642209.html

到了这里，关于系统架构设计专业技能 · 软件工程（一）【系统架构设计师】的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！