系统架构主题之二：软件系统需求分析方法及其应用

软件系统的开发工作始于需求获取，成于需求分析。这里的需求分析，也就是系统分析。需求获取阶段挖掘的是用户的原始需求，这些需求并不能直接用来指导设计和开发。原始需求一般通过用户需求列表文档传递进来。而需求分析所做的工作，就是对用户原始需求进行研究，提取其中的功能性需求和非功能性需求，也就是质量需求，将其转换为软件开发空间的需求。因此，需求分析或者说系统分析，所做的工作就是用户空间（问题域）的需求转换为解空间也就是软件开发空间的需求。很多人在很多项目中，这两点都没有很好的区分，往往是少了用户原始需求的记录这一步骤，需求获取人员直接将原始需求按自己的理解转换为软件需求表达了出来。其实，更好的做法是记录原始用户领域的需求，然后通过专门的分析处理过程，将其转换为软件需求，输出软件需求规格说明书（SRS）。通过记录这个步骤，就可以了解需求分析是怎么做的，对不对、合理不合理这些问题就有记录可查可判了。所以讲，需求分析做的好，系统就成功了一半，因为至少没有出现南辕北辙或者缘木求鱼的情况。

从大的方面来看，需求分析主要有两种方法，结构化分析方法和面向对象分析方法。下面我们就分析和应用两个方面分别进行说明。

  

1 软件系统需求分析方法相关概念

结构化分析方法（SASD，结构化分析结构化设计）。一般通过图形表达，有数据流图（DFD）、数据字典（包括数据项、数据结构、数据流、数据存储、数据处理）、结构化语言、判定表及判定树等。

  

数据流图：通常也称为过程建模或功能建模，主要描述功能需求。核心是围绕数据流，识别数据流和对数据流的加工处理过程。比如，初始数据有哪些，从哪里来，流向了哪里，经过了什么加工，又变成了什么数据，得到了什么结果等。

数据流图中包含四中基本元素：数据流（箭头）、处理（矩形）、数据存储（数据库或文件，双线段）、外部项（源或终点，圆角框或者平行四边形）。

实践过程中，需要先

1. 明确目标，确定系统范围
2. 建立顶层DFD图
3. 构建第一次DFD分解图
4. 开发DFD层次结构图
5. 检查确认DFD图（有一些注意的规则，父图数据流必须在子图中出现；处理至少一入一出；存储至少一入一出；流至少关联一个处理；全局全面完整一致正确）

  

数据字典：数据字典对数据流程中的每个数据元素加以定义和说明。数据字典相对而言，有规范严格的定义，有利于分析员和用户之间的沟通。数据字典的构成包括：

1. 数据项，不可再分
2. 数据结构，数据项的组合
3. 数据流，数据流图中流线的说明
4. 数据存储，数据块存储特性的说明
5. 处理过程，数据流程中功能块的说明

数据字典对数据流图进行了详细说明，方便查询。

  

面向对象分析方法。与结构化方法不同，是在对需求调查后，按照OO要求所需进行的素材提取、归类、分析整理。OOA模型由5个层次和5个活动构成，5个层次为：主题层、对象类层、结构层、属性层和服务层。5个活动为：标识对象类、标识结构、定义主题、定义属性、定义服务。基本跟是相互对应的。

面向对象分析过程为：确定对象和类；确定结构；确定主题（主题包含一组用例）；确定属性；确定方法。

  

上面所说的有点抽象，跟实际的对应关系不是很明确，下面所述的基于UML的需求分析倒是更有实际操作指导性。首先，提取需求信息，生成用例；其次，用活动图表示用例；之后，生成用例图；下一步提取关键概念，形成领域概念模型，研究模型中的概念与用例的关系，提取类，生成类图、包图。简而言之，分析过程就是分析有哪些业务场景，流程是什么，这个过程中涉及哪些类，把这些整理起来，就是需求提炼过程。有了这些信息，设计时就是采用什么架构风格，基于哪些设计模式来实现这些场景用例，这些过程。

有的教材中将后续的识别对象关系、为类添加职责、建立交互图也放到面向对象分析中，实在很难认同。如果这些也是分析，那么设计做什么？就有点让人费解了。

 

面向问题域分析方法 PDOA，暂不展开了。

 

总的来看，结构化分析方法更加倾向于自顶向下，而面向对象方法则倾向于自底向上。其实，对一个系统来讲，自顶向下前期切入容易，后期开展存在风险；而自底向上，前期识别元素困难，后期整合容易。所以，从这两点来看，实际中如果能够做到二者结合，则更为有益。

2 实际系统开发中如何应用相应的需求分析方法

方法流程是固定的，但是掌握应用的人是活动的。软件开发活动是一门实践性特别强的学科，因此实际中，既要避免固守陈规，有一定发挥创造，又要避免忽视理论，完全凭感觉行动。

就系统的分析来看，结构化方法和面向对象方法均有涉及。

对于业务类型比较成熟、偏底层偏纯技术方向的业务，采用结构化方法较好。这种情况，业务流程基本是比较清晰的，有比较完整的竞品可以对比，前期可以对系统进行一个拆分，分解功能需求并对标业务需求。像基于数据库表ER图的分析，对各种管理系统也是非常适用的。这些方法不一定能够完全分析系统，但通过数据模型促进对领域的深刻理解，对于面向对象的分析也是很有帮助的。另外，对偏技术层面的，因其属于变化波动较为小的领域，也可以采用结构化分析方法，对需求进行拆解细化为功能项。有些特殊领域，这种方法仍然有很强大的生命力。比如音视频处理中，以数据流图为基础进行分析，比较容易抓住重点。且数据本身的特性是比较稳定的，基于数据流图的分析结果，在后期设计实现中，也具有很好的不变形特性，这对于软件开发需求易变的常态来讲，是非常难得的。还有，像一些特定领域，核心算法基本是固定不变的，实际中变化多的为参数调整，也是比较适合采用结构化方法来分析的。

  

我们在某电力系统项目中，就用上面的方法，综合使用了结构化分析方法和面向对象分析方法。

对于新的增值业务，涉及新技术的应用，客户本身对需求的描述就不是很清晰，这时候采用面向对象的分析方法，利用场景法，外部场景，使用情景等，通过故事卡片形式展示，以此挖掘需求，进一步转换为用例和用例集。通过跟客户一起，对用例表达的流程进行确认，为后续概念模型的建立提供了很好的参考。比如电力监测中，在传统电压电流温度等方式基础上，客户希望能够在电网智能化进程中，应用更多新技术，对故障做出更加智能更加高效的预判，从而在构建坚强电网的道路上迈出坚实一步。为此，技术人员根据客户的需求痛点，结合技术的切入角度，实现复杂度，成本等因素综合考虑，增加了利用人工智能进行图像处理的用例，结合视频和红外信息，可对线路热变化进行大角度的预警检测，对开关、线路异物等状态进行巡检预警检测，从而提高了预警能力，形成了更加立体的可靠防护网。对这些新技术的应用带来的业务变化，就需要在需求分析阶段进行充分的识别，从而在前期功能规划中能够全面的体现出来。

仍然针对上述新业务的植入，从上到下的分析有利于功能需求的提炼，但对于整个系统设计层面的影响，仅仅通过上述用例到概念模型的构建还不够。相反，使用结构化方法中的数据流图和数据字典，则可以有效弥补这一缺陷。因为上述新功能的引入，从底层数据采集，数据流转，数据存储等方面，对整个系统都产生了影响。为了更好的设计系统，梳理已有数据流，然后补充新增数据流，比如红外视频流、普通视频流、图像流以及由此引入的定位流、控制流、配置流等，还有为实现需要的素材流、模型库等，都需要充分的考虑进来。这时候，构建清晰完整的数据流图，就显得特别重要。

大量图片、视频的引入，对系统存储能力和响应也提出了更高的要求。而电力系统的安全性要求，导致无法充分利用公网基础设施，且因为加密框架的引入，导致数据流带宽更加受限。充分的识别这些二次引入的非功能需求，也是需求分析工作是否完整的一项要求。

最终综合上述分析成果，生成软件系统需求规格说明书，包括功能性需求，描述主要功能用例，也包括非功能性需求，描述性能、可用性、安全、可修改性、可靠性等相关需求。

 

虽然结合各种方法，对系统需求进行了深入完整的分析，但还是出现了一些意料之外的因素，对分析工作形成了干扰。这些因素一方面是技术方面的，比如在电网高电压环境下，采集源的电磁干扰考虑不够，部分内部信息存储、传输的可靠性受到了一定的影响。在可靠性需求中虽然有提到可能存在电磁干扰，但是考虑到有外壳屏蔽作用，只在外部使用光纤，认为内部影响不大，但实际中还是出现了一些偶发的连接中断、数据位异常情况。这在后续开发工作中需要更加严格要求，对于不确定性的内容，一方面要及时寻求领域专家的指导意见，另一方面需要做好充分的验证工作；在非技术方面也出现了一些问题，主要是现场人员认为操作流程繁琐，使用麻烦，对识别的可靠性存在疑虑，且对整体系统了解不够，倾向于只负责传统方法覆盖的自留地，因此对新业务的积极性不高，部分设备甚至不开机，这对产品整体的应用、价值发挥、效益评估产生了不利影响。对于这个问题，一方面是由于前期需求获取、分析阶段，与一线人员接触不够，对于产品体验方面的规划不足，影响了后期的功能应用；另一方面是培训不够充分，缺乏清晰简单、影响深刻的使用案例，其实这些也是产品分析设计的一部分，是需要加强的。