设计之路：如何进行软件需求分析？

1、需求分析的重要性

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

通常，软件生存周期包括可行性分析与开发项计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动。

常用的三种软件生命周期（瀑布模型、迭代式模型和快速原型模型）中，需求分析中都占据了举足轻重的作用，是系统分析、软件编程、软件测试和系统维护的输入物。

软件生命周期的五个重要步骤： 需要、分析、页面、设计、开发。

1.1 瀑布模型

瀑布模型由于酷似瀑布闻名，（Waterfall Model）首先由Royce提出。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。

 

从上图可看出，需求分析的产出物《需求规格说明书》（有的项目组还会产出软件原型，例如静态HTML原型等）是后续设计、编码、测试和系统维护的基础。

 软件原型设计属于需求分析的一个重要部分。

可将瀑布模型的“需求分析”阶段细分为“软件概念”和“用户需求分析”两个阶段，前者用于收集用户的原始需求，包括用户在功能、行为、性能、设计约束等方面的期望，并经过初步分析后形成《用户需求说明书》，而后经过进一步分析，将用户需求精确化、完全化，最终形成《需求规格说明书》。

可将瀑布模型中的“系统设计”细分为“架构设计”和“详细设计”两个阶段，前者在总体上把握，更关注架构层面，包括系统的总体架构，以及各个子系统或各个模块之间的关系。后者更注重细节，包括系统设计的方方面面都要在详细设计中有所体现。

作为系统分析师，或系统架构师，主要在“需求分析”和“系统设计”阶段体现自己的作用，后续的各个阶段主要通过与项目组成员的沟通贯彻自己的设计。

1.2 迭代式模型

迭代式模型是是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程（编码流程）和测试工作流程。实质上，可将它理解为多个小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

迭代式原型图示如下：


 

在每一个迭代中，“需求分析”阶段与瀑布模式一样，是后续系统分析、编码和测试阶段依赖的基础。如果需求分析有较大偏差，势必造成迭代过程中产生的一个产品子集有较大偏差。

1.3 快速原型模型

快速原型（Rapid Prototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。

在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。

在快速原型模型中，原型最重要的目的是为了确定用户的真正需求。从某种程度上，可以将快速原型理解为需求分析的一种更直观的方式，也是业界比较认可和取得良好效果的一种方式。

 

2、需求分析的目标

通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。

需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

 

3、如何进行需求分析

3.1 需求分析的困难

需求分析的目标，说得通俗一点，就是确定“做什么，不做什么”。但需求分析却不像想象的那么简单，主要因为如下原因：

3.1.1  客户需求自身经常变动

    这世间的一切，只有“变化”是绝对的，从这点来理解，软件系统的需求不断变化也是可以理解的。老听设计人员和开发人员抱怨客户的需求老是变化，其实应该将“需求变化”理解为一种常态。

引起需求变化的原因诸多，例如：

（1）因为某些前置条件未满足，之前按照“妥协”方案实现，但若在某个时间点上这些前置条件被满足，于是引起了需求的变化。

（2）某个后台操作之前不需要走审批流程，但因为客户的某个内部流程改变，需要走审批流程，势必引起需求 -> 设计 -> 编码 -> 测试的一系列变更。

【对策】：因为需求变动无可避免，系统分析师在进行需求分析时需要明确：

（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。

（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。小的变动影响不大，也不致影响进度，但是对于一些改动会引起设计重大改变的需求，需要在合同中清楚说明。

 3.1.2 客户说不清楚需求，分析人员理解错误

    客户的计算机水平、对需求的理解、表达程度都参差不齐。有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。有些客户心里非常清楚想要什么，但却说不明白。有的客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。

不同性格、不同水平、与客户交流前准备情况不同的的系统分析师去跟客户讨论需求时，会得到很不不一样的结果。

作为系统分析师，可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。一个好的系统分析师，能从客户的一两句话中提出很多自己的观点或可进行拓展，进而进一步挖掘客户需求，或者若与之前的需求矛盾，可进行正确需求导向。

【对策】：若客户说不清楚需求，为了不造成理解错误，系统分析师可采用多次沟通的方式，例如第一次通过客户初步了解需求，回去分析哪些是合理需求，那些是自相矛盾或不合理的需求，以及哪些是需要进一步明确的需求。经过细化后，第二次交流可提供PPT或简单的Word文档与客户进行第二次深入交流。第三次交流可通过建立快速模型进一步与客户交流得到精确的需求。需求分析也可参考“迭代式模型”来进行不断迭代，一直到挖掘出客户所有的潜在需求为止。

 3.1.3 客户在没看到原型或完整系统时，有一些潜在需求未被挖掘

    甚至有不少这样的客户，去进行需求沟通时提不出太多的需求，但是在你做完整个系统时，潜在需求突然迸发出来。

【对策】：为了避免此种情况对项目造成破坏性影响，建议相关人员为一些大的功能模块建立快速原型让客户进行确认，并在合同中一定要说清楚“做什么”和“不做什么”

 

3.1.4 多个相关方需求相互冲突，需求有二义性

若些需求若牵涉客户不同部门，若有不一致意见，若私自按某一方的意见进行修改，很可能在后期涉及到按另一个部门的想法进行改造。

【对策】：对于这种客户内部有冲突的需求，需求组织客户方相关部门一起讨论，由客户更高领导层决定实现哪一方的需求，或者采用折衷方案。需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。

 

3.2 需求分析的活动

3.2.1 需求获取

通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

软件需求常见的获取方法（在《软件需求获取方法》一文中写得很详细）如下：

Ø 面谈

个人觉得面谈是获取软件需求的最有用的方法，也是需求分析时常用的方法。通过多方面谈，得到的信息最多，进行我们现在所做的系统，与移动集团客户部、业务支撑部、网管中心、系统运营人员等都进行过面谈。

面谈需准备的内容：面谈对象和面谈问题。

面谈对象：需要尽量让面谈对象包括可与系统相关的涉众，并具有代表性，保证涵盖到每个角色。一般包括谁为系统付费，购买系统？谁使用系统？谁会受到系统结果的影响？谁来监管该系统？谁来维护系统？

Ø 问卷调查

调查问卷无法取代面谈在需求获取阶段的作用，问卷调查的问题和答案具有一定的引导性，在某种程度上会影响结果。

问卷调查的结果好坏与问卷的设计有直接的关系，在做这个项目时，运营人员在进行前期推广会议上，也给企业客户发过调查问卷，但因为诸多原因，效果不甚理想，基本没为我们项目需求分析出多少力。

Ø 小组讨论

小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势：容易在内部取得对方案的认同，有利于项目的开展；在讨论会上每个相关人员都可发表自己的意见，保证了获取信息的全面性。缺点：不容易把握。

对于涉及系统边界的需求，或一些相互冲突的需求，采取该种方式是非常可取的。

Ø 情景串联

由于软件产品的抽象性，大部分涉众在脑海子未有一个清晰的产品轮廓，影响涉众对产品的理解。基于此可考虑编写清晰、完整的情景描述文档。

 1、采用PPT加图片的方式描述情景：一个好的PPT能更直观的描述各种情景；

2、采用原型法（比较推荐这种方法）。

Ø 参与、观察业务流程

涉众描述的业务流程可能由于某些原因会遗漏掉重要的信息，需求分析人员可申请参与到他们具体的工作，观察、体验业务操作过程。需求分析员在观察业务操作过程时，可根据实际的情况提问并详细记录，记录业务操作员操作过程，操作过程中碰到的难题，可获取真实的材料和理解整个业务。

Ø 现有产品和竞争对手的描述文档

阅读现有产品文档有利于了解当前系统情况，从中也可以了解业务流程，对操作员反映的系统问题有着更深层次的理解。

3.2.2 需求建模

要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。

Ø 域建模

域建模指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。

域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。

Ø 用例建模

用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。

用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。

Ø 组件和服务建模

组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。

服务模型将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。

Ø 性能建模

可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，必须考虑性能建模过程中其他的几个方面：

l 构建和部署应用程序的速度如何？

l 构建、维护和运行需要多少花费？

l 该应用程序能在多大程度上满足其需求？

l 对于必须使用该应用程序的人来说，需要为其付出多大的开销？

l 该应用程序会对其他应用程序和基础结构产生怎样的影响？

【说明】需求建模是一门深奥的学问，在做这个项目时，需求建模基本只是用到了“用例建模”，对一些典型流程进行用例建模。域建模、组件和服务建模和性能建模基本是空白状态，希望在下一个项目中有所改进。

 

  3.2.3 形成《需求规格说明书》

 生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。

3.2.4 需求验证

以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。

 

3.2.5 需求管理

持系统的需求演进，如需求变化和可跟踪性问题。

要在需求变更时，同步更新《需求规格说明书》以及相关文档，要知道，一个正确的文档是指导软件系统不同阶段的参考，但一个没有同步更新的文档是对软件系统有破坏性作用的，相关人员会受到错误引导。