我对需求分析的理解

1 引言

进入一个新的行业，去做行业软件，如何去快速掌握业务知识？掌握基本的业务知识后，如何去快速确定软件需求，使用项目快速进入开发状态。以上是本篇文章的写作背景。

2 需求调研的两个步骤

如下图所示需求调研分为两个大的步骤，一是用户需求调研和分析，二是系统需求调研和分析。

2.1 用户的视角进行业务的需求调研和分析

1、把用户的业务目标进行明确，尤其是高层用户的目标要求，一般情况下这是这个项目/产品存在的理由。

2、进行客户基本情况调研，包括组织结构和职责，主要人员、岗位及分工。然后找中层人员调研业务流程、操作人员了解操作细节。最后形成业务架构，把业务大块之间的逻辑关系明确出来。

3、了解现有系统的情况、各层级用户的软件功能和非功能的相关要求。

2.2 计算机信息系统视角进行软件需求调研和分析

1、理清楚系统的目标，明确系统实现了以后给用户带来哪些价值和收益。

2、通过软件需求分析的方法（下面章节详细介绍）定义应用架构、功能模块层级，进行功能描述和做功能原型。

3、描述数据需求、接口需求及非功能性需求等。

2.3 软件需求分析和设计

我理解软件需求分析和设计目的就是确定软件系统和功能的划分。一般情况下大家采用经验主义的方法去划分和确定功能，前期写过一篇文章《我对软件工程的理解》，其中提到过软件工程的技术开发方法有两种，一是结构化的方法，二是面象对象的方法。所以软件的需求分析也有以上两种方法。

2.3.1 结构化的需求分析和设计

2.3.1.1 结构化分析

结构化分析是通过数据来对需求进行分析，功能模块之间通过数据进行联系，采用的建模技术有：数据流图DFD(Data Flow Diagram)、ERD(Entity Relation Diagram)和数据字典DD(Data Dictionary)等。数据在结构化分析方法中举足轻重，就相当于血管之于人体，系统的各个模块通过数据的传递进行沟通和联系，导致了功能模块的强耦合性，模块之间的耦合性降低了结构化程序的可重用性和可维护性

主要分析步骤如下：

①  分析当前的情况，做出反映当前物理模型的DFD；

②  推导出等价的逻辑模型的DFD；

③  设计新的逻辑系统，生成数据字典和基元描述；

④ 建立人机接口，提出可供选择的目标系统物理模型的DFD。

2.3.1.2 结构化设计

将分析阶段得到的目标系统物理模型的DFD表示的具体信息转化成程序结构的设计描述，过渡成软件结构。在这个过程中采用的建模技术有：系统结构图SSD(System Struct Diagram)。这个过程分两步完成，第一步是从分析得到的结果出发，构造一个设计方案，决定系统功能模块的结构。第二步进行详细设计，确定每个功能模块的内部控制结构和算法，最终产生每个功能模块的程序流程图。划分子系统采用“U/C矩阵”，用来表达功能与数据两者之间的关系。

具体步骤如下：

①   评审和细化数据流图；

②   确定数据流图的类型；

③   把数据流图映射到软件模块结构；

④   基于数据流图逐层分解高层模块，设计中下层模块；

⑤   对模块的控制结构和算法进行优化；

⑥ 描述模块接口。

结构化方法对需求变化的适应能力比较弱，功能的改变甚至会牵一发而动全身，但由于结构化分析和设计对系统进行完整的架构和具体功能的分析以及实现的各个阶段严谨的测试，所以结构化程序可靠性高。基于结构化分析、设计和实现中的这些主要优点和缺点，结构化比较适合于像操作系统、实时处理系统等这样以功能为主的系统。比如绝大多数操作系统都是以结构化语言C语言写的。

2.3.2 面向对象的需求分析和设计

面向对象的需求分析和设计相比结构化分析和设计来说，方法、工具等更成熟，目前我看到的讲得最清楚的最明白的是谭云杰著的《Think in UML》，大家有时间可以详细看看。

面向对象的需求分析和设计是以“用例驱动”整个过程的，每个过程通过“建模”的方式进行呈现。那什么是用例？用例是与用户交互的，并且给用户提供可观测的有意义的结果的一系列活动的集合，简单地说用例就是用户所做的事情。什么是建模？建模就是把“人”、“事”、“物”、“规则”这些元素给描述清楚并理解这些元素的手段方法或过程。

整个分析和设计过程最主要的是从业务建模到概念建模，从概念建模到系统建模，经过这三个阶段后，基本上就完成了整个分析和设计的过程。下面是比较核心内容：

3 最后

下次有时间，以读书笔记的形式和大家一起学习谭云杰著作，本文的部分内容来自《博客园》、《CSDN》、《Think in UML》，欢迎大家进行讨论，我们共同进步。