软件开发主要活动——需求分析

http://www.caixiaodong.com/archives/56.html

需求分析活动解决软件开发“做什么”的问题。客户对于需求的认知并不清晰，且经常同时包含了几个层次的需求概念，提交给软件项目组，要求按需求实现。需求分析活动的目标，是为后续各活动提供一个稳定的需求文档，作为软件开发的“输入”。

一、需求的层次

需求通常分为3个层次：业务需求、用户需求、功能需求。业务需求即客户希望通过该系统实现的业务目标，例如通过该系统运行某种业务获得收入，以及与 其它应用系统在概念层次上的分工等。业务需求描述的是业务领域的问题，应当向客户方负责人或业务专家收集获得。业务需求一般最稳定，不会发生显著变更。

用户需求是指具体的“用户”希望如何使用该系统。行业应用系统都有很多类别的用户，例如：采编录入信息的采编员、面向公众客户的业务受理员、班组 长、使用报表的各级领导。可以通过向各个用户走访获取用户需求，汇总成文档后，再向客户负责人进行确认。由于各个用户对于系统应当如何使用系统的想法是不 同的，有时甚至是冲突的，因此，用户需求比较容易发生变更。

功能需求是指软件系统应实现的功能。功能需求的视角不是用户，而是软件开发者。确保功能需求尽可能不发生变更，是需求分析的目标之一。

二、需求分析活动

纵观50年软件工程史，无数失败的项目与需求的不确定有关。在项目之初，确定了一个需求范畴，而当项目深入，需求的反复变更耗尽了所有人的心力，最 终草率收场或是不了了之。软件开发是对真实世界的模拟，行业应用软件则模拟了客户企业的业务流程。这就需要一个先抽象，再具象的过程。需求分析，是将客户 企业实际运作的流程，以及各个用户所希望运作的流程抽象出来，成为软件开发者可以理解的文本。之后，再由软件开发者通过设计、编码实现等活动，将其具体 化，成为可操作的软件系统。

因此，需求分析活动，重在分析。客户口头或书面提出的需求文本，可能包括业务需求，也包括用户需求，甚至还会对功能模块的查询条件、作出指定。这些 不同层次的需求应当分类整理。对于业务需求，应当充分理解，勾勒出客户的业务流程图，尽管这个业务流程可能超出了本系统的范围。对于用户需求，应仔细鉴 别，各个用户的要求是否存在冲突，是否与业务需求冲突？对于功能需求，应当理清用户到底想要什么，实际上，他们并不真的关心功能需求，而只是在表述时将其 表达为功能需求。例如，对于报表需求，可能表述为需要哪几张报表，报表的格式是什么。实际上，他们真正想要的，是那些特点列的业务数据能够被方便的获得。

三、需求的概念完整性

一份完整的需求，应是一个完整的体系，即《人月神话》一书中反复出现的一个词汇：概念完整性。业务需求，体现了 客户高层对系统的目标和定位；从业务需求层次看来，系统与周边系统的关系清晰，使用一张数据流图，能够清晰的看到数据从周边系统如何流入该系统，如何加 工，再如何流出到周边系统。如果一类数据不是由本系统录入的，也没有其他数据来源，却能够直接流向周边系统，那么一定是哪里遗漏了。系统能够表述的很简单，这就是业务需求层面的概念完整性。

在用户需求层次，各个用户使用系统的方式都被充分表述，同一个业务功能被多个用户使用，在操作权限上或有不同，但不存在明显冲突。用户需求与业务需 求一致，也可以认为用户需求是业务需求的一种实现（具体化）。业务需求的各个数据流都在各个用户节点上充分表达，即体现为具体用户对业务数据的操作。

功能需求是软件开发者视角的需求，由于功能需求的侧重点在于系统功能，而非业务属性，因此对概念完整性的要求是：不丢失用户需求信息。由于大多数开发者不可能直接接触用户，因此要求功能需求的表述规格化。

特别需要说明的一点，在我看来，业务需求、用户需求、功能需求实际上是一样事物的三个视图，分别反映了三个不同视角所看到的景象。例如一个圆柱体， 业务需求是从上向下看，用户需求则从外往内看，功能需求则是从圆柱体内部向外看。业务需求、用户需求、功能需求是对同一个事物的表述，因此天然具备概念完 整性的特点。当然，需要在我们的需求分析活动中描述出来。

四、需求分析活动的文档

在软件项目组接触到这个项目的时候，通常业务需求已经明确，但用户需求还是非常混乱的。客户提交的需求描述文档混杂有业务需求、用户需求和功能需 求。对大多数需求分析活动来说，首先分析用户需求，输出《用户需求说明书》，并提交给客户确认。在《用户需求说明书》中，建议加上对业务需求的理解，例如 数据流图，让客户一并确认，并及时纠正理解不当的部分。

一般的，《用户需求说明书》已经可以作为设计活动的输入，但还不能作为编码实现活动的输入。《需求规格说明书》主要表述功能需求。按照标准说法，《需求规格说明书》还应当表述非功能性需求，但在实践中，这部分很少被关注，非功能性指标往往到了测试阶段才真正被重视。

《需求规格说明书》之“规格”，即要求格式化的表述，以便在软件开发过程中不产生歧义。一般使用表格方式，以强制文档作者必须填写所有内容：用例编号（唯一确定需求）、用例操作简要说明、前置条件、操作结果（分为成功、失败）、操作者（角色）。