需求分析方法探讨
一、 概述
据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。在这75%的失败中，约有50%以上的软件是由于需求的原因造成的。作为软件的设计和开发人员常抱怨用户需求不明确，需求常处于变更状态。新的需求往往在开发阶段才被用户提出。造成软件的完成日期不断的迟后。
一般的软件企业，往往只口头上注重用户需求。但由于没有科学的管理方法，实际上他们描述的用户需求是杂乱无章的，只言片语的。不能有效地和系统设计、开发保持同步最后开发出来的软件产品和实际有很大的差异。导致软件的失败。有证据表明，在需求阶段修正错误的工作量，是在系统设计阶段修正错误的1/10；是在开发阶段修正错误的1/100，是在发布产品阶段修正错误的1/1000。当然这是对大型系统而言，对于不同的系统，随系统的复杂程度这个比率会有所不同。
用户的需求的增加具有渐进的、增量的特点。随着需求分析人员和用户逐渐深入的交流，用户在不断地整理、规范自己的需求。需求分析人员须牢记的是用户不可能一下子给出一个完整、清晰、规范的用户需求。需求分析人员需从与用户的交流中，不断地挖掘，并加以整理，才能得到想要的需求。
需求分析一般来说需要有一个需求分析的团队，如用户代表、系统分析人员、开发人员、需求管理人员等，他们的分工不同各有侧重点。对于小型或中型项目人员可以兼任。
基于上述原因，需要从理论上规范用户需求的收集和整理。本文结合系统建模，给出了需求分析的一般性方法。它如下的包含了两个方面:
1、 技术层面
给出需求分析的系统框架，它包含了需求的项目、参与需求分析的用户、用户对于需求的可操作权限（安全性）等。
2、 操作层面
给出了需求收集、整理、分析的一般性方法。
其中介绍了系统建模和需求分析间的相互关系，最后介绍了目前几种流行的需求分析产品及它们的特点。
二、 需求分析的基本概念
需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。
需求分析的特点是需求的完整性、一致性和可追溯性。
完整性：是准确、全面的描述用户的需求。
一致性：是通过分析整理，剔除用户需求矛盾的方面，规范用户需求。
可追溯性：有两个方面的含义，整理和规范的需求，其一，需要不断的和用户进一步交流，保持和用户最新的需求一致；其二，和系统分析（设计）保持一致。
因此在需求分析之前我们必须建立需求分析技术层面的基本框架，从技术上保证需求分析的要求，在此基础上我们进行的需求分析才能满足项目对需求分析的要求。
三、 需求分析的系统架构
本节描述的是进行需求分析之前，如何在技术层面上建立需求分析的系统架构。
需求分析需要采用需求分析的软件。上图简要描述了需求分析软件的架构。需求分析软件一般采用C/S的结构，需求分析人员作为客户对服务器进行操作，操作主要由四个方面：系统管理（含用户的创建和授权，定义项目的术语表等）、项目视图（涉及项目的相关操作）、需求类型视图（涉及需求类型的相关操作）、需求视图（涉及需求的相关操作）。
项目包含一个或多个需求类型，需求类型包含一个或多个需求。里程碑是特定版本的需求的集合（需求分析软件含有简单的配置管理的功能），它作为软件产品的功能依据。自动文档生成是通过文档模版将里程碑的需求，自动生成相关文档。
3.1 项目
项目在总体上定义了一个应用和系统所涉及到的需求及需求涉及的范围。它包含了在需求分析过程中参与需求分析的人员、需求类型、包含于需求类型中的需求。此外它还包含了如下信息：
项目的相关信息（如创建人员）
项目的里程碑
外部的可追溯性
安全性框架等。
3.2 用户/用户组
用户是指参与需求分析的人员，一般由软件产品的最终用户、软件开发人员、系统设计员、测试人员等组成。在需求分析产品中用户包含用户的基本描述和联系方式（如电子邮件）等，目前大多数需求分析产品还含有消息通讯的机制（类似于QQ），及时地将需求的变化告知相关的需求分析人员。
用户组是指具有相同操作权限的一个或多个用户。用户组可以被指定到特定的项目或需求（用户组中的用户对此具有相应得操作权限）。
3.3 安全性
安全性是指在需求分析过程中，用户对需求的操作权限。安全性防止未授权的用户对关键性需求的操作。安全性是用户/用户组与需求之间的一种关系。
一般来说安全性有三个方面的含义：
系统管理
系统维护（系统数据备份等）、用户管理、用户组管理等。
安全性框架
定义用户的基本操作权限。这种操作权限和具体的项目、项目需求无关。如一个用户添加的需求只能由这个用户自己删除等。安全性框架又可以分为两类：
存取级别（Access Level）创建、查看、维护需求。
删除级别（Delete Level）删除需求。
特定需求的安全性
建立用户/用户组与特定需求的关联，以确定此用户/用户组对需求的操作权限。
3.4 需求类型/需求
需求类型通常是以功能划分的较高层次的需求，如用户界面。需求是所要构建的系统或应用所要满足要求的说明，需求可以由业务规则、处理流程、人员的组织结构获得。需求包含于需求类型之中。需求类型/需求一般是用文字描述的，此外还可以通过需求的属性、外部文件来描述需求。
3.5 属性
属性用来描述需求相关特性，属性一般可分为两类。
系统属性：描述需求的系统特点，如需求是否被确认等。
自定义属性：由用户自定义用来描述需求的属性。如描述人员的电话号码等。
3.6需求网格
需求网格是一组相关的需求用网格的形式表示，主要用于需求的分析。一般来说可以定义显示的方式，如针对某个用户显示他所创建的需求、针对某类功能显示相关的需求等等。
3.7 需求映射
考虑这样的背景，在一个实时系统中，数字信号的采集与传输在不同的控制系统中均使用相同的实现方式，它们的需求也相同。在这种情况下我们可以采用需求映射的技术，需求映射是在不同的项目中使用相同的需求。
在图中有三个项目，项目A中的需求R3被共享出来，项目B中的R3的需求映射到项目A中的需求R3。
3.8 可追溯性（Traceability）
可追溯性是需求的一致性表现形式。它主要包含以下几个方面的含义：
保持和用户要求的同步
必须牢记的是用户需求是不断变化的。需求分析需要适应需求的不断变化。
保持需求之间的完整和一致
用户从各个层面提出的需求，往往含有相当多的矛盾，需求分析的一个重要的方面是要消除这些矛盾，规范用户的需求。此外需求之间的依赖性也可以通过可追溯性来表示。
保持需求和系统设计间的同步
在大多数项目中，需求分析和系统设计没有的必然联系，这种情况造成的后果是软件产品和实际的需求相差甚远。例如采用手工的方法，可以使需求与系统设计保持一致。但这种方法是不安全的，因为没有相应的机制来强制相关人员遵守规则。所以必须从技术层面来保证需求和设计的一致，目前大多数的需求分析工具均有和系统设计工具保持同步的插件，如Borland的CaliberRM、IBM的ROSE、Telelogic的DOORS等。
3.9 报告（Report）
报告可以理解是需求的视图，从不同的层次来描述需求，报告可根据需要进行过滤，如针对某一需求类型的报告、针对不明确需求的报告等。报告一般可以分为：
细节报告
描述需求的细节。
状态报告
描述需求的状态，需求的状态可分为接受、不明确、拒绝等。
责任报告
参加需求分析的人员对其负责的需求产生的报告。
3.10 讨论
讨论是在需求分析过程中，需求分析团队成员之间的一种协作机制。这种机制可使相关人员就需求的定义、描述、状态、优先级、一致性、完整性等进行讨论，得出正确的结论。
讨论一般来说分两个级别，项目级别、需求级别。
３.11 文档引用
一个需求的描述可能需要外部的文档，文档引用是用外部文件来描述相关需求的附加信息。目前需求分析产品支持最多的文档类型是MS WORD，此外根据产品的不同，还支持Excel、图像文件、HTML、及OLE等。
3.12 里程碑（BaseLine）
需求是不断变化的，软件产品根据不断变化的需求有不同的版本，每一个版本的软件除了软件自身的BUG外，就是满足新增加的需求，而软件产品需要其实现的功能具有稳定性。里程碑就是需求分析过程的一个阶段结果，这个阶段结果是固定不变的。
3.13 文档的自动生成
参与软件开发的人都有这样的体会，在软件产品完成之前很难给出软件的各种文档，就是给出了相应的文档，文档之间也有各种各样的矛盾。这是需求、设计、开发缺乏同步的表现。
如果我们在软件的开发过程中，严格遵循软件的开发规范，采用相应得软件工程工具，上述情况就可以避免。
在需求分析中，需求分析产品均可以自动根据分析的结果生成相应得文档，文档的格式可以有MS Word、PowerPoint、HTML等。这里我们主要介绍一下Office Word文档的生成方式。
在自动生成文档之前，我们需要定义文档模版。根据所要生成文档的格式和需求分析软件的相关命令，在Office Word创建文档模版。文档模版创建好之后，在需求分析软件中选择里程碑，自动生成出Office Word文档。
四、 需求的收集和整理
需求分析是从用户的角度描述用户的数据、活动、地点（位置）、人员组织、计划、业务逻辑（业务目标）等相关信息的一个过程，它涉及到如何收集用户的需求，以及如何将这些需求规范化等方面。需求分析的第一步工作是界定需求的边界，主要描述项目的、项目的业务要求、项目所要满足的基本特性等。
在第三节中我们简要描述了如何从技术层面上使需求分析的过程规范化，本节主要阐述如何进行需求的收集和整理。
4.1 数据
数据是指需求涉及的相关静态信息。在需求分析过程中，数据是从用户的角度来描述的；在系统设计过程中，数据用面向对象的方法进行整理和规范，最终形成Class Diagram。
4.2 活动
活动是项目要满足的业务逻辑和规则。它至少有二个层次：
基本目标
简要描述业务逻辑和规则。
功能描述
描述活动执行的过程，以及在执行过程中涉及到的相关资源、活动之间的关联、依赖性、约束性等。
考虑到需求分析和系统设计的一致性。活动在系统设计阶段，可采用用例来表示，通过序列图、活动图、以及状态图来进行细化。
4.3 人员组织
描述用户人员组织结构。如企业领导、部门、部门人员、相关客户信息等。
4.4 地点（位置）
描述需求和地点、位置相关的系统设计中网络、分布式计算的前置条件。
五、 需求分析软件
目前流行的需求分析软件有IBM公司的RequisitePro、Telelogic公司的DOORS、Borland公司的CaliberRM。这些软件均能满足本文中描述的对需求分析功能上的要求，但各有特点，RequisitePro和大多数系统设计软件有较好的结合，目前的版本对Office 2003的支持不够。DOORS在实时系统的需求分析中有良好的表现。CaliberRM对Office有很好的支持，中文的问题也解决得很好，支持Office 2003的版本。
六、 结论
需求具有渐进的，不断变化的特点。需求分析是一个需求分析团队的工作，在需求分析理论的指导下需要采用需求分析的商业化产品，这样才能保持需求和设计的同步，没有这种同步，需求分析不会有太大的实际意义。
大多数系统设计产品如Rose、Together、Tau、Rhapsody（实时系统的系统设计工具）等，具有部分的需求分析功能，严格意义上它们不是需求分析的产品。但他们均有和需求分析产品的接口。
一般说来软件项目涉及到的很多方面，如需求分析、配置/变更管理、系统设计/建模、测试等。本文只是简要描述了作者对需求分析的一些体会。
据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。在这75%的失败中，约有50%以上的软件是由于需求的原因造成的。作为软件的设计和开发人员常抱怨用户需求不明确，需求常处于变更状态。新的需求往往在开发阶段才被用户提出。造成软件的完成日期不断的迟后。
一般的软件企业，往往只口头上注重用户需求。但由于没有科学的管理方法，实际上他们描述的用户需求是杂乱无章的，只言片语的。不能有效地和系统设计、开发保持同步最后开发出来的软件产品和实际有很大的差异。导致软件的失败。有证据表明，在需求阶段修正错误的工作量，是在系统设计阶段修正错误的1/10；是在开发阶段修正错误的1/100，是在发布产品阶段修正错误的1/1000。当然这是对大型系统而言，对于不同的系统，随系统的复杂程度这个比率会有所不同。
用户的需求的增加具有渐进的、增量的特点。随着需求分析人员和用户逐渐深入的交流，用户在不断地整理、规范自己的需求。需求分析人员须牢记的是用户不可能一下子给出一个完整、清晰、规范的用户需求。需求分析人员需从与用户的交流中，不断地挖掘，并加以整理，才能得到想要的需求。
需求分析一般来说需要有一个需求分析的团队，如用户代表、系统分析人员、开发人员、需求管理人员等，他们的分工不同各有侧重点。对于小型或中型项目人员可以兼任。
基于上述原因，需要从理论上规范用户需求的收集和整理。本文结合系统建模，给出了需求分析的一般性方法。它如下的包含了两个方面:
1、 技术层面
给出需求分析的系统框架，它包含了需求的项目、参与需求分析的用户、用户对于需求的可操作权限（安全性）等。
2、 操作层面
给出了需求收集、整理、分析的一般性方法。
其中介绍了系统建模和需求分析间的相互关系，最后介绍了目前几种流行的需求分析产品及它们的特点。
二、 需求分析的基本概念
需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。
需求分析的特点是需求的完整性、一致性和可追溯性。
完整性：是准确、全面的描述用户的需求。
一致性：是通过分析整理，剔除用户需求矛盾的方面，规范用户需求。
可追溯性：有两个方面的含义，整理和规范的需求，其一，需要不断的和用户进一步交流，保持和用户最新的需求一致；其二，和系统分析（设计）保持一致。
因此在需求分析之前我们必须建立需求分析技术层面的基本框架，从技术上保证需求分析的要求，在此基础上我们进行的需求分析才能满足项目对需求分析的要求。
三、 需求分析的系统架构
本节描述的是进行需求分析之前，如何在技术层面上建立需求分析的系统架构。
需求分析需要采用需求分析的软件。上图简要描述了需求分析软件的架构。需求分析软件一般采用C/S的结构，需求分析人员作为客户对服务器进行操作，操作主要由四个方面：系统管理（含用户的创建和授权，定义项目的术语表等）、项目视图（涉及项目的相关操作）、需求类型视图（涉及需求类型的相关操作）、需求视图（涉及需求的相关操作）。
项目包含一个或多个需求类型，需求类型包含一个或多个需求。里程碑是特定版本的需求的集合（需求分析软件含有简单的配置管理的功能），它作为软件产品的功能依据。自动文档生成是通过文档模版将里程碑的需求，自动生成相关文档。
3.1 项目
项目在总体上定义了一个应用和系统所涉及到的需求及需求涉及的范围。它包含了在需求分析过程中参与需求分析的人员、需求类型、包含于需求类型中的需求。此外它还包含了如下信息：
项目的相关信息（如创建人员）
项目的里程碑
外部的可追溯性
安全性框架等。
3.2 用户/用户组
用户是指参与需求分析的人员，一般由软件产品的最终用户、软件开发人员、系统设计员、测试人员等组成。在需求分析产品中用户包含用户的基本描述和联系方式（如电子邮件）等，目前大多数需求分析产品还含有消息通讯的机制（类似于QQ），及时地将需求的变化告知相关的需求分析人员。
用户组是指具有相同操作权限的一个或多个用户。用户组可以被指定到特定的项目或需求（用户组中的用户对此具有相应得操作权限）。
3.3 安全性
安全性是指在需求分析过程中，用户对需求的操作权限。安全性防止未授权的用户对关键性需求的操作。安全性是用户/用户组与需求之间的一种关系。
一般来说安全性有三个方面的含义：
系统管理
系统维护（系统数据备份等）、用户管理、用户组管理等。
安全性框架
定义用户的基本操作权限。这种操作权限和具体的项目、项目需求无关。如一个用户添加的需求只能由这个用户自己删除等。安全性框架又可以分为两类：
存取级别（Access Level）创建、查看、维护需求。
删除级别（Delete Level）删除需求。
特定需求的安全性
建立用户/用户组与特定需求的关联，以确定此用户/用户组对需求的操作权限。
3.4 需求类型/需求
需求类型通常是以功能划分的较高层次的需求，如用户界面。需求是所要构建的系统或应用所要满足要求的说明，需求可以由业务规则、处理流程、人员的组织结构获得。需求包含于需求类型之中。需求类型/需求一般是用文字描述的，此外还可以通过需求的属性、外部文件来描述需求。
3.5 属性
属性用来描述需求相关特性，属性一般可分为两类。
系统属性：描述需求的系统特点，如需求是否被确认等。
自定义属性：由用户自定义用来描述需求的属性。如描述人员的电话号码等。
3.6需求网格
需求网格是一组相关的需求用网格的形式表示，主要用于需求的分析。一般来说可以定义显示的方式，如针对某个用户显示他所创建的需求、针对某类功能显示相关的需求等等。
3.7 需求映射
考虑这样的背景，在一个实时系统中，数字信号的采集与传输在不同的控制系统中均使用相同的实现方式，它们的需求也相同。在这种情况下我们可以采用需求映射的技术，需求映射是在不同的项目中使用相同的需求。
在图中有三个项目，项目A中的需求R3被共享出来，项目B中的R3的需求映射到项目A中的需求R3。
3.8 可追溯性（Traceability）
可追溯性是需求的一致性表现形式。它主要包含以下几个方面的含义：
保持和用户要求的同步
必须牢记的是用户需求是不断变化的。需求分析需要适应需求的不断变化。
保持需求之间的完整和一致
用户从各个层面提出的需求，往往含有相当多的矛盾，需求分析的一个重要的方面是要消除这些矛盾，规范用户的需求。此外需求之间的依赖性也可以通过可追溯性来表示。
保持需求和系统设计间的同步
在大多数项目中，需求分析和系统设计没有的必然联系，这种情况造成的后果是软件产品和实际的需求相差甚远。例如采用手工的方法，可以使需求与系统设计保持一致。但这种方法是不安全的，因为没有相应的机制来强制相关人员遵守规则。所以必须从技术层面来保证需求和设计的一致，目前大多数的需求分析工具均有和系统设计工具保持同步的插件，如Borland的CaliberRM、IBM的ROSE、Telelogic的DOORS等。
3.9 报告（Report）
报告可以理解是需求的视图，从不同的层次来描述需求，报告可根据需要进行过滤，如针对某一需求类型的报告、针对不明确需求的报告等。报告一般可以分为：
细节报告
描述需求的细节。
状态报告
描述需求的状态，需求的状态可分为接受、不明确、拒绝等。
责任报告
参加需求分析的人员对其负责的需求产生的报告。
3.10 讨论
讨论是在需求分析过程中，需求分析团队成员之间的一种协作机制。这种机制可使相关人员就需求的定义、描述、状态、优先级、一致性、完整性等进行讨论，得出正确的结论。
讨论一般来说分两个级别，项目级别、需求级别。
３.11 文档引用
一个需求的描述可能需要外部的文档，文档引用是用外部文件来描述相关需求的附加信息。目前需求分析产品支持最多的文档类型是MS WORD，此外根据产品的不同，还支持Excel、图像文件、HTML、及OLE等。
3.12 里程碑（BaseLine）
需求是不断变化的，软件产品根据不断变化的需求有不同的版本，每一个版本的软件除了软件自身的BUG外，就是满足新增加的需求，而软件产品需要其实现的功能具有稳定性。里程碑就是需求分析过程的一个阶段结果，这个阶段结果是固定不变的。
3.13 文档的自动生成
参与软件开发的人都有这样的体会，在软件产品完成之前很难给出软件的各种文档，就是给出了相应的文档，文档之间也有各种各样的矛盾。这是需求、设计、开发缺乏同步的表现。
如果我们在软件的开发过程中，严格遵循软件的开发规范，采用相应得软件工程工具，上述情况就可以避免。
在需求分析中，需求分析产品均可以自动根据分析的结果生成相应得文档，文档的格式可以有MS Word、PowerPoint、HTML等。这里我们主要介绍一下Office Word文档的生成方式。
在自动生成文档之前，我们需要定义文档模版。根据所要生成文档的格式和需求分析软件的相关命令，在Office Word创建文档模版。文档模版创建好之后，在需求分析软件中选择里程碑，自动生成出Office Word文档。
四、 需求的收集和整理
需求分析是从用户的角度描述用户的数据、活动、地点（位置）、人员组织、计划、业务逻辑（业务目标）等相关信息的一个过程，它涉及到如何收集用户的需求，以及如何将这些需求规范化等方面。需求分析的第一步工作是界定需求的边界，主要描述项目的、项目的业务要求、项目所要满足的基本特性等。
在第三节中我们简要描述了如何从技术层面上使需求分析的过程规范化，本节主要阐述如何进行需求的收集和整理。
4.1 数据
数据是指需求涉及的相关静态信息。在需求分析过程中，数据是从用户的角度来描述的；在系统设计过程中，数据用面向对象的方法进行整理和规范，最终形成Class Diagram。
4.2 活动
活动是项目要满足的业务逻辑和规则。它至少有二个层次：
基本目标
简要描述业务逻辑和规则。
功能描述
描述活动执行的过程，以及在执行过程中涉及到的相关资源、活动之间的关联、依赖性、约束性等。
考虑到需求分析和系统设计的一致性。活动在系统设计阶段，可采用用例来表示，通过序列图、活动图、以及状态图来进行细化。
4.3 人员组织
描述用户人员组织结构。如企业领导、部门、部门人员、相关客户信息等。
4.4 地点（位置）
描述需求和地点、位置相关的系统设计中网络、分布式计算的前置条件。
五、 需求分析软件
目前流行的需求分析软件有IBM公司的RequisitePro、Telelogic公司的DOORS、Borland公司的CaliberRM。这些软件均能满足本文中描述的对需求分析功能上的要求，但各有特点，RequisitePro和大多数系统设计软件有较好的结合，目前的版本对Office 2003的支持不够。DOORS在实时系统的需求分析中有良好的表现。CaliberRM对Office有很好的支持，中文的问题也解决得很好，支持Office 2003的版本。
六、 结论
需求具有渐进的，不断变化的特点。需求分析是一个需求分析团队的工作，在需求分析理论的指导下需要采用需求分析的商业化产品，这样才能保持需求和设计的同步，没有这种同步，需求分析不会有太大的实际意义。
大多数系统设计产品如Rose、Together、Tau、Rhapsody（实时系统的系统设计工具）等，具有部分的需求分析功能，严格意义上它们不是需求分析的产品。但他们均有和需求分析产品的接口。
一般说来软件项目涉及到的很多方面，如需求分析、配置/变更管理、系统设计/建模、测试等。本文只是简要描述了作者对需求分析的一些体会。