专业的工具帮你处理关于需求的那些事

需求是项目成败的关键，管理好需求，处理好需求的那些事，至关重要。。

人是解决问题的，工具可以更好的帮你记录和反馈你解决事情的能力。

Trufun服务目标——国产最专业UML建模工具、需求管理工具、ALM管理工具等

规范软件开发过程     优化软件开发流程

保证软件开发质量     提高软件开发效率

    西安楚凡科技有限公司（Trufun）是全球领先的软件开发行业应用生命周期管理（ALM）和CASE工具解决方案提供商，倡导"实用、简洁"的产品理念，拥有业内领先的国产中文UML建模工具，国产中文需求管理工具，国产中文MDA工具等一系列产品。支持软件开发的整个生命周期，涵盖需求获取、需求分析、分析设计、软件开发、软件测试、软件部署等环节。

1. 需求分析

    在完成需求获取所得到的记录与资料的分析与整理后，项目经理应组织软件的需求分析工作，建立各需求元素之间的关系，明确分配给软件的需求、需求的分类、需求的优先级等。

需求分析的方法种类繁多，但常见的需求分析方法主要是结构化分析方法和基于用例的需求分析方法。

    Trufun 工具是两种分析方法都可以支持的。

1.1. 结构化分析方法

结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析，描述工具有：

l 数据流图（Data Flow Diagram，DFD）：数据流图是一种图形化的系统模型，它在一张图中展示信息系统的主要需求，即输入、输出、处理过程、数据存储。

l 数据字典（Data Dictionary，DD）：数据字典技术是一种有效表达数据格式的手段，它是对所有与系统相关的数据元素的一个有组织的列表和精确、严格的定义，从而使用户和系统分析员对于输入、输出、存储成分和中间计算机有共同的理解。

l 结构化语言：结构化语言是结构化编程语言与自然语言的有机结合，可以采用顺序结构，分支机构、循环结构等机制，来说明加工的处理流程。

l 判定表和判定树：判定表是一种处理逻辑的表格表示方法，其中包括决策变量，决策变量值、参与者或公式；而判定树则使用像树枝一样的线条对过程逻辑进行图表化的描述。判定表和判定树用来描述复杂决策逻辑，要远远优于使用结构化语言。

l 实体-关系图（Entity RelationshipDiagram，E-R图）：E-R图可以用来描述数据的存储需求，包括数据实体，数据实体的属性以及它们之间的关系等。

结构化分析方法从总体上看是一种强烈依赖数据流图的自上而下的建模方法，它不仅是需求分析计划，也是完成需求规格化的有效技术手段，使用结构化分析方法时可遵循下列活动：

１）  建立系统的物理模型

首先，画出系统得数据流图，说明系统的输入、输出数据流，说明系统的数据流情况，以及经历了哪些处理过程。在这个数据流图中，可以包括一些非计算机系统中数据流及处理过程的名称，如部门名、岗位名、报表名等。这个过成可以帮助分析人员有效地理解业务环境。

２）  建立系统的逻辑模型

在物理模型建立之后，接下来的工作就是画出相对于真实系统的等价逻辑数据流图。将所有自然数据流图转换为等价的逻辑流。

３）  划清人机界限

最后，确定在系统逻辑模型中，哪些部分将采用自动化完成，哪些部分仍然保留手工操作，从而清晰的划清系统的范围。

1.2. 基于用例的分析方法

从定义中我们得知用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（High Level）用户功能性需求。用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。

使用用例分析方法时可遵循以下步骤：

1)       识别系统参与者，确定谁会直接使用该系统。参与者是同系统交互的所有事物，该角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟。

2)       合并需求获得用例。找到所有参与者之后，根据需求获取所得到的用户需求，定义每个参与者希望系统做什么，参与者希望系统作的每件事将成为一个用例。

3)       绘制用例图。将所识别的参与者以及所定义的用例通过用例图的形式整理出来，以获得例模型的框架。

4)       细化用例描述。用例描述包括以下几个部分：

l 用例名称；

l 用例参与者；

l 用自然语言对用例进行简要的描述；

l 描述参与者何时使用该用例，即用例的触发条件；

l 描述在一般情况下，参与者使用该用例时会发生什么事情，即用例的基本过程；

l 在基本过程的基础上，考虑一些可变情况，把他们创建为扩展用例；

2. 需求定义

需求定义的目的是根据需求获取和需求分析的结果，进一步定义软件需求，产生《需求规格说明书》。

2.1. 标识需求

为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于需求规格说明书

2.2. 定义需求的优先级

需求分析师应确定每个需求的优先级并写入需求规格说明书，需求的优先级的评价

标准如下：

级别定义	判断标准	采取措施
高	满足以下任意一条时： １）              需求实现的紧急程度为特急或紧急 ２）              国家或行业法律法规、标准要求的，客户明确要求的,满足正常业务必须的。	对于这些需求在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现。通常这类需求在当前版本必须实现。
中	满足以下任意一条时： １）            客户隐含要求，对正常业务影响程度不大 ２）            需求实现的紧急程度为中 ３）            支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要求的。	这些需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，如果有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。
低	满足以下任意一条时： １）            功能或质量上的附加功能； ２）            实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能，属于锦上添花； ３）            需求实现的紧急程度为低；	实现或不实现均可；可以在项目组有较足够的时间时考虑这些需求的实现

优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。

2.3. 编写《需求规格说明书》

需求分析师在需求分析过程中根据分析步骤逐步编制形成《需求规格说明书》。编写需求规格说明书应遵循以下规则：

l  相关的需求都得到了识别与描述，以确保需求的完整性；

l  各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；

l  正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；

l  定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；

l  使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；

l  确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；

l  考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。

《需求规格说明书》可以包括但不局限于：

l  需求描述约定

l  系统概述，如系统功能、业务描述、数据流程描述、用户的特点、运行环境要求、设计与实现上的限制等

l  功能需求描述

l  非功能性需求，如系统性能要求、***备份与恢复要求、系统日志等。

l  外部接口说明，如软硬接口、通信接口等

l  其它需求描述

l  功能列表等

3. 需求确认

需求确认是指项目组和客户（或客户代表）共同对《需求规格说明书》进行评审，双方对需求达成共识后做出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。

3.1. 需求评审

应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审的方式分为“技术评审会议”。

项目组根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。组内评审要求：

l  评审组长：项目经理；

l  评审组成员：需求分析师、系统分析师、测试工程师，适当邀请组外专家参与；

l  输入：《需求规格说明书》初稿

l  输出：会议纪要

l  检查单：需求评审检查单

项目组只有在完成组内评审、并完成问题修改与验证后，方可向公司提出技术评审会议申请。当需要召开技术评审会议时，由项目组向项目管理部门提出需求技术评审申请和组内评审会议纪要，项目管理部门完成文档规范性、完整性检查，并确认已经通过内部评审后，提交评审管理部门，由评审管理部门组织按“技术评审会议”的方式实施需求评审。技术评审会议要求如下：

l  评审组织部门：评审管理部门

l  评审组成员：

a)     项目组代表

b)     测试组代表

c)     公司的技术专家与业务专家

d)    实施组代表

e)     客户或客户代表

f)      系统关联组代表

g)     QA工程师

l  输入：需求规格说明书以及相关文档

l  输出：评审报告

l  检查单：需求评审检查单

关于“技术评审会议”的要求详见《评审规程》。

3.2. 需求承诺

项目经理将评审通过的《需求规格说明书》提交给客户（或客户代表）、系统关联项目组进行确认，确认的方式可以是以下方式之一：

l  直接签字：由承诺方在评审报告上直接签字或盖章确认

l  邮件方式：由项目经理将《需求规格说明书》与评审报告通过邮件发送给接收方，并明确确认通过的准则（如：如果在一周内未予以回复则默认为确认通过）；

l  发送会议纪要函：如果承诺方参加了评审会议并在会上达成了共识，则可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通过纪要函的方式发送给承诺方。

3.3. 建立需求基线

项目的需求规格说明书经过评审与确认后，应根据《配置管理过程》的要求建立需求基线。

4. 需求变更

对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。这主要有以下几种原因：

1.       软件所应用的外部环境发生变化；

2.       随着用户对软件的熟悉和应用，又提出新的需求；

3.       项目组进行需求分析时未能彻底分析用户的需求，或分析错误；

4.       用户在开始时不能很全面的知道所需软件的功能。

4.1. 需求变更申请

需求变更由变更申请人通过填写《软件变更申请表》向项目组提出进行。

当项目组接收到项目管理部门的《软件变更申请表》时，应先根据要求进行需求的评估，判断需求的类型、分析需求变更影响到的范围、估算需求实现的工作量（含需求、设计、编码、测试、用户文档编写）、预计可以完成的时间等内容。若估算的开发工作量大于10人月时，项目组可以根据《项目立项过程》的要求向项目管理部提出项目立项申请；若小于10人月，且评估结果与申请部门达成共识，则开发项目组根据《计划变更规程》实施变更，若无法达成共识，则提交研发部进行最终裁定。

4.2. 需求变更的实施

项目组根据《计划变更规程》中的要求实施变更。

在变更完成后，若需要发布新的需求基线，项目组应根据《配置管理过程》中“基线发布”的要求重新建立需求基线，并通知相关的人员。

5. 需求跟踪

对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。因此，一个比较好的方法就是建立一种需求双向跟踪机制。双向跟踪即：

l 正向跟踪：当发生需求变更时，通过从需求向后追溯到下游相关工作产品，可分析出这些关联项是否需要变更，从而达到追溯的目的；

l  逆向跟踪。通过从下游工作产品回溯到需求，可分析需求是否得到满足，从而达到回溯的目的。

进行需求双向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，以及从编码到测试用例，把每个需求都映射到对应的位置。这个映射可以用需求跟踪矩阵来实现。

5.1. 建立需求跟踪矩阵

当《需求规格说明书》通过评审之后，项目经理应组织根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。项目经理指定人员对需求跟踪矩阵进行个人复查，确保跟踪粒度合理、跟踪项适用。

5.2. 需求跟踪矩阵的维护与使用

随着软件设计、编码、以及测试开发的不断推进，项目经理应指定专人在项目的各个阶段产品形成时，将相关的信息填入需求跟踪矩阵，建立阶段工作产品与需求的对应关系，并由项目经理指定人员对其完整、正确、一致性进行确认。对于已纳入需求跟踪矩阵的相关工作产品产生的变更，则由项目经理在每次变更完成后根据变更修改需求跟踪矩阵的对应关系，在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。

在项目实施过程中，项目组可以利用需求跟踪矩阵实施相关的控制，如：

l  利用需求跟踪矩阵，审核所有定义的需求是否已经在相关产品中得到实现；

l  当发生需求变更时，可以利用需求跟踪矩阵受需求变更影响的其它工作产品，确保不忽略每个受到影响的系统元素；

l  当相关的工作产品产生变更时，可以向前追溯到与其相关的需求与其它工作产品，从而判断是否需要对这些关联产品进行变更；

在开发过程中，可以对所有定义的需求的当前开发状态进行跟踪。　 

 

Trufun SDP提供了满足从软件开发的全生命周期支持，从专业的需求管理开始到UML分析设计、编码开发、软件测试等环节，并且可以实现从需求的一一对应。