三、 需求分析的系统架构
本节描述的是进行需求分析之前，如何在技术层面上建立需求分析的系统架构。
需求分析需要采用需求分析的软件。上图简要描述了需求分析软件的架构。需求分析软件一般采用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 讨论
讨论是在需求分析过程中，需求分析团队成员之间的一种协作机制。这种机制可使相关人员就需求的定义、描述、状态、优先级、一致性、完整性等进行讨论，得出正确的结论。
讨论一般来说分两个级别，项目级别、需求级别。
3.11 文档引用
一个需求的描述可能需要外部的文档，文档引用是用外部文件来描述相关需求的附加信息。目前需求分析产品支持最多的文档类型是MS WORD，此外根据产品的不同，还支持Excel、图像文件、HTML、及OLE等。
3.12 里程碑（BaseLine）
需求是不断变化的，软件产品根据不断变化的需求有不同的版本，每一个版本的软件除了软件自身的BUG外，就是满足新增加的需求，而软件产品需要其实现的功能具有稳定性。里程碑就是需求分析过程的一个阶段结果，这个阶段结果是固定不变的。
3.13 文档的自动生成
参与软件开发的人都有这样的体会，在软件产品完成之前很难给出软件的各种文档，就是给出了相应的文档，文档之间也有各种各样的矛盾。这是需求、设计、开发缺乏同步的表现。
如果我们在软件的开发过程中，严格遵循软件的开发规范，采用相应得软件工程工具，上述情况就可以避免。
在需求分析中，需求分析产品均可以自动根据分析的结果生成相应得文档，文档的格式可以有MS Word、PowerPoint、HTML等。这里我们主要介绍一下Office Word文档的生成方式。
在自动生成文档之前，我们需要定义文档模版。根据所要生成文档的格式和需求分析软件的相关命令，在Office Word创建文档模版。文档模版创建好之后，在需求分析软件中选择里程碑，自动生成出Office Word文档。
