1.1建立需求分析和需求管理过程

　　任何一个软件项目都是从需求开始，以软件是否满足需求为结束条件的。其中有很多角色参与。如何保证这些角色对于项目需求达成共同的理解，并在此基础上进行开发，关系到项目的成败。因此，在软件开发过程中，应当加强需求管理，要在所有与项目有关的人员之间建立对软件需求的共同理解，才能够保证整个项目进展与需求一致，从而保证项目的成功，保证软件的质量。

　　需求分析提供适当的机制以了解业务部门想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约。需求工程以全局视图开始，分析业务领域或产品以建立所有的基本业务需求。然后，关注点缩窄到领域视图，每个系统元素被单独地分析，每个元素被分配给工程构件，然后被相关的工程方法处理。

　　而需求管理是建立在需求分析的基础上的。也就是说，需求管理不包括需求获取和需求分析的技术性活动，需求管理的对象应该是需求分析的最终结果---需求基线。需求管理包括以下内容：

　　Ø 控制对需求基线的变更

　　Ø 保持项目计划与需求一致

　　Ø 控制单个需求和需求文档的版本

　　Ø 管理需求与软件开发过程中其他产品之间的依赖关系

　　Ø 跟踪基线中需求的状态

　　1.1.1需求获取和确认

　　获得规范、准确、完整、一致、无歧义、可界定的需求说明对于项目的有效开展和高效运作，减少项目中后期的波动具有十分重要的意义。根据我们的经验，需求诱导是有效的技术手段，以下是举例说明在获取需求时应关注的内容：

　　Ø 从相关的各方面挑选合适、具有代表性的人员建立需求分析管理团队，从各个不同的视角定义需求，采用会议、讨论、反馈、交流和通讯联络等方式开展需求挖掘和规约;

　　Ø 确定最终产品系统的功能和性能;

　　Ø 定义最终产品系统在计算机体系结构、操作系统、网络系统等技术环境的需求;

　　Ø 收集到的需求应该进行分类，组织为相关的子集，检查需求的疏漏项、一致性和二义性，并通过以下方面进行需求分析：

　　Ø 每个需求是否和项目的整体目标相一致

　　Ø 是否每个需求被界定且无歧义

　　Ø 记录每个需求的提出或要求者及时间、场合等信息

　　Ø 有无需求间的冲突

　　Ø 各需求能否在目标环境中实现

　　Ø 各需求是否可测，能否描述出针对需求的测试集，需求是否被定量的术语界定

　　Ø 需求间的相关性、交叉引用矩阵注记

　　Ø 和系统性能、行为及运行特征相关联的需求是否已被清楚地陈述

　　评审小组将按照以上这些方面进行彻底的检查。

　　1.1.2需求文档的编写

　　编写优秀的需求文档没有现成固定的方法。许多需求定义文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。在编写软件需求文档时，由于需求的编写是层次化的，因此可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了。如果评审软件需求规格说明的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。

　　文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这也造成了维护上的困难。需求的多个实例都需要同步更新，以免造成需求实例间的不一致。可以在软件需求说明中交叉引用相关的各项。让独立性强的需求在管理工具或数据库中只出现一次，这样可以缓和冗余问题。

　　文档的编写人员应考虑用最有效的方法表达每个需求。不要漏掉任何一个需求。

　　需求文档的编写原则参见太平洋软件的模板：《软件需求说明书》，此处不再赘述。

　　1.1.3需求分析建模

　　4.1.3.1结构化分析设计方法基本思想

　　结构化分析设计方法(Structured Analisys and Design，SAD)是一组经典的用于软件需求分析和系统设计技术的统称。

　　SAD就是用抽象模型的概念，按照系统内部信息传递、变换的关系，自顶向下逐层分解，直到找到并设计出满足用户功能要求的所有可实现的软件为止。

　　SAD要求软件分析设计人员首先要对业务流有很深的认识和高效的管理，然后以数据为中心，进行功能模块的分解与设计，这样才能实现自顶向下逐步求精的软件分析与设计。SAD适用于数据处理类型软件的分析与设计。

　　对于大型、复杂系统来说，最困难的事是如何处理复杂性。SAD方法采用“分解”与“抽象”的手段来对付一个复杂系统。即用“自顶向下逐层分解”的方式。按这种方法，无论系统是多么复杂，分析设计工作总是可以有条不紊地进行。系统的规模无论有多大，分析设计工作的复杂程度不会随之而增大，而只不过是多分解几层而已。由此可见，SAD方法有效地控制了分析设计工作的复杂性，可以很好地处理大型复杂系统的需求分析工作和系统的设计工作。

　　需求分析阶段，主要任务是研究问题域(用户需求)，产生一个满足用户需求的系统模型。这个系统模型应能正确地描述问题域和系统责任，(即描述系统“做什么”)，并使后继开发阶段的有关人员能根据这个模型继续进行工作。

　　系统设计阶段，主要任务是在明确了未来系统将要“做什么”的基础上，进行系统设计，描述系统“怎么做”。设计阶段是软件工程项目中的重要阶段，软件设计是系统实现的根本依据。

　　可见，在分析设计阶段最重要的工作是根据用户需求，抽象出系统模型。系统模型主要应从两个方面对系统进行描述：业务模型和信息(数据)模型。

　　业务模型又称为功能模型、行为模型，主要用于描述系统业务功能(行为)及它们之间的关系。信息(数据)模型主要侧重于描述系统的信息(数据)结构和业务规则。

　　描述业务领域的数据结构的数据模型与描述系统功能的业务模型同样重要，两者互为补充，共同整合成系统模型。我们在分析系统功能的时候常常能够发现隐含的数据需求;而对系统数据结构的讨论又往往揭示了附加多功能需求，可见，建立业务模型和信息模型是建立系统模型的过程中紧密联系、不可分割的两个方面。

　　另外，随着计算机辅助软件工程的发展，出现了许多优秀的CASE工具。

　　例如;在分析设计阶段有业务建模工具BPwin，数据库设计工具Erwin，数据模型检查工具ERwin Examiner，模型管理工具ModelMart等等。

　　4.1.3.2面向对象分析设计方法的基本思想

　　面向对象分析设计方法与结构化方法不同，它不是面向过程的。面向对象思想的实质是，并不是从功能上，或是从处理问题的算法上来考虑，而是从系统的组成上来进行建模。例如汽车可以理解成由底盘、车身、发动机等组成的对象。这种对问题进行自然分割，利用类及对象作为基本构造单元，以更接近人类思维的方式建立问题域模型，从而使设计出的软件尽可能地描述现实世界，构造出模块化的、可重用的、可维护性好的软件，并能控制软件的复杂性和降低开发维护费用。

　　因此，在我们进行系统建模时，利用了一些相互作用的对象，即不考虑被建模系统的类型，我们都将它看成是大量的对象。例如，我们的环境由以下对象组成：人、树、汽车、房屋、城市等，这些对象在某些方面是相关的。另外一个环境的模型可能是由税收、政府和政治等对象组成。因此我们所选择的，包含在模型中的对象取决于对象模型要代表什么，即取决于我们要处理问题的范围。利用面向对象方法设计的模型通常很容易理解，因为它直接和现实相关。同时，这样的设计模型保证了我们在软件的分析、设计、实现的过程中用相同的方法来思考。

　　面向对象方法的一般思路是：首先取得用户需求，用各种图表辅助以文字、表格等形式构造系统对象模型，识别与问题有关的类与类间的联系，加上与解决方案有关的类(如界面等);经过对设计的类与联系进行调整后，对类进行编码测试，得到结果。其中，在分析设计阶段的主要内容是面向对象建模语言——UML。

　　1.1.4需求跟踪

　　在软件开发的需求管理过程中，需求跟踪是最基本的活动。需求跟踪包括编制每个需求同其它系统元素之间的联系文档。这些元素包括系统中其它的需求、系统的体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。

　　在系统开发过程中可以使用需求跟踪能力矩阵表示需求和别的系统元素之间的联系链。

　　需求之间的关系主要有以下两种：

　　n 父子联系：父子联系指的是同类需求之间的层次关系。

　　n 跟踪联系：跟踪联系指不同类需求(如某一功能需求和相关设计元素)之间的追溯关系。

　　需求跟踪能力矩阵中主要涉及需求之间的跟踪联系。跟踪联系的建立与维护是需求管理的基础，是进行变更控制、影响分析等活动的前提。

　　1.1.5变更控制

　　软件开发过程中一个最显著的特点是需求的不稳定性。表现为需求总是处于不断的变化中。变更的原因有很多：用户由于自身业务活动的变化，产生的对需求的变更;需求分析不彻底，造成用户不断提出需求的变更;同类产品的激烈竞争也会导致需求的变更。

　　对于大多数项目来说，需求的变更是不可避免的。作为项目管理人员，如何有效地控制需求的变更，很大程度上决定了项目的成败。

　　在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价，但是，在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的变更控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的变更控制，其中主要是实行软件基线的配置管理。所谓基线配置，就是经过阶段评审后的软件配置成分(各个阶段产生的文档或程序代码)。

　　需求管理的主要工作之一就是要对需求的变更进行管理和控制。要想使软件开发项目从容的面对需求变更所带来的冲击，应当做到以下几点：

　　Ø 建立变更控制流程

　　Ø 进行影响分析

　　Ø 及时更新相关工作产品

　　下图为需求变更控制流程示意图：

　　当用户要求对需求提出变更时，首先应填写需求变更请求文档，并提交给相关人员进行影响分析，之后此变更请求和影响分析结果应交由CCB进行审批，由CCB成员共同决定是否通过此变更请求。

　　通过上图所示的需求变更控制流程，可以使得项目中发生的需求变更得到有效的控制。

　　1.1.6管理需求的属性

　　完善的需求管理除了管理需求文档的版本以外，还应当记录和管理单个需求的版本。要达到这个目的，就要在需求管理过程中，适当地记录并维护每个需求的属性，从而更细致、更准确、更有效的管理需求。例如，我们可以考虑为每个需求建立下列属性：

　　Ø 创建需求的时间

　　Ø 需求的版本号

　　Ø 创建需求的作者

　　Ø 需求状态

　　Ø 需求的原因或根据(或信息的出处)

　　Ø 需求涉及的子系统

　　Ø 需求涉及的产品版本号

　　Ø 使用的验证方法或接受的测试标准

　　Ø 产品的优先级或重要程度

　　Ø 需求的稳定性

　　通过在需求管理过程中定义和更新这些属性值，也为项目管理人员和决策人员度量需求管理的实施效果提供了丰富的基础数据。

　　1.1.7需求状态统计

　　有了丰富的需求的属性，在需求管理过程中，我们就可以通过各种形式的统计报告为项目管理人员了解项目进展情况提供准确的信息，还可以供高层管理人员掌握项目中需求管理的实施效果提供帮助。

　　例如，我们为每个需求指定一个属性：状态，具体取值见下图。

　　图中展示了某项目开始10个月以内需求状态分布图。通过这张图，我们可以看出项目的实际进展情况。

　　通过这些统计报告，高层管理人员可以了解项目当中需求管理实施的效果、存在的问题、成功的经验，从而为持续过程改进提供实际的数据。

　　1.1.8使用工具

　　需求分析和需求管理是一项复杂的工作，仅靠手工是不能很好的完成的。目前市场上的需求分析和管理工具可以为我们带来以下方便：

　　Ø 提高需求分析的效率

　　Ø 需求模型尽可能为用户所理解

　　Ø 采用一整套连贯的、规范的方法

　　Ø 得到标准的模型设计

　　lØ 文档生成功能

　　lØ 通过数据库管理需求信息

　　lØ 安全性管理

　　lØ Web发布

　　如果使用工具，项目进行中大部分的过程都将自动定义执行，如：工具将手工任务自动化，因此开发团队有更多时间用于实际开发。

　　针对实际情况，可以选用优秀的CASE工具辅助实现软件需求阶段的规范管理。关于工具的介绍请参见附录B。

　　通过实施提供的专业化的软件需求管理服务，科技研发中心将能够在短期内建立一套符合本身状况的需求管理系统，建立自动化的需求管理流程，同时可以帮助研发中心的项目管理不断良性发展，并达到更高的标准，在未来的开发中更好地保证项目质量和周期，控制成本，降低风险，更高效地完成软件开发项目。愿意为项目开发工作尽我们最大的努力!