风险一般指由于在从事某项特定活动过程中存在的不确定性而产生的经济与财务损失、自然破坏或损伤的可能性。软件工程项目中同样充满着风险，因此软件工程产生了风险管理的概念。业界经验表明，在系统生命周期的需求阶段发现错误与在维护阶段发现错误的费用支出比为1：200，而且需求错误一般是项目中所发现的最大一类，占总数的4l％-56％，为此返工所需开销占项目总费用的45％。由此可见，需求分析阶段的风险最大。
换个角度来看，需求分析阶段却又是最能提高开发效益的时机。软件项目如果不能满足用户的需求，就不能算作成功，而正是在需求分析阶段，用户和开发人员双方就需要什么样的应用系统或软件产品达成一致。所以，如果此时开发者运用沟通技巧与用户交流，同时进行批判思考，并在理解业务的基础上尽可能将需求细化量化，就能够检查出系统缺陷，彻底降低软件项目的成本和失败率。
那么，采用什么手段能够规避需求分析中的风险?本文将从与用户沟通、业务建模以及需求测试三个方面进行探讨。
一、与用户沟通
软件项目的成功有赖于用户和开发者对于需要什么样的应用系统达成共识，所以需求分析首先是一个软件开发者与用户沟通交流的过程。开发人员可以通过区分用户类型、提供候选方案，减少语言二义性，声明需求变更成本等方法促进交流，取得实效。
如何调动用户的积极性，使他们参与到需求调研和确保需求质量的工作中来？ 开发人员应针对不同用户不同需求与用户沟通。实际上，系统开发者面对的用户总是处于机构中不同的行政和业务层次上，他们关注的“焦点”并不相同，所以在探讨需求之前，有必要先进行用户细分。
另外，由于出发点和利益不同，系统开发者与用户对于同一问题常有不同看法，在一场场漫无目的的争论中，需求分析的风险逐渐加大 。开发人员可以利用以往成功案例的经验，带着自己拟定好的多个解决方案供用户选择定夺，即给用户出“选择题”。例如，开发人员设计界面时可以先提出几种风格的方案，用户针对特定的对象“审美”，很快就会定下需要的方案或者指出改进的方向。
但是，即使与用户最初的沟通很顺利，开发人员也不能轻易乐观。因为需求的变化是不可避免的，而需求的一小步变化，也许会使已经完成的工作前功尽弃，不仅造成项目无法按期完工，更使成本飞涨。在现实中需求与设计活动是迭代进行的，此时关键在于做好需求变更控制。其中最为重要的是，首先进行需求变更影响分析，并向用户详细说明这些影响、相应的成本和工作量。进行需求变更时，可以利用配置管理工具建立基线及其跟踪表。如果出现较为复杂的需求变更，则应将其纳入版本规划。对需求变更的评估包括此项需求的各种属性描述是否恰当，时间紧迫性，技术风险性，与系统的相关性及其重要程度，需求变更的波动分析，实现需求的资源状况等等，据此确定其对项目计划安排和其它需求的影响，同时还要明确与变更相关的任务并评估完成这些任务需要的工作量。
在项目结束后进行总结时，尤其应对需求变更跟踪表“温故知新”，检视哪些需求是一以贯之的，哪些是被改变甚至放弃的，哪些是新提出并且不可或缺的，哪些是在原有基础上深入发展的，开发者可以从中理清需求变更的脉络，找到需求分析的“关键路径”，建立起一套需求框架。这样不仅能够站在新的高度深入理解本项目的需求，而且也能帮助自己在以后的软件项目中更加贴近用户视点，达到用户预期。例如，经过多年的信息化建设，许多单位已积累了大量的数据资源。此时，一个新启动的软件项目很大程度上要继承或利用老系统的数据。在这样的形势下，即使需求分析初期用户没有提及历史数据，开发人员也应提前考虑到保护用户投资的问题，这样当用户从初期探讨新系统功能转而提出如何处理遗产系统时，开发人员就能够拿出恰当的解决方案。
二、业务建模
从熟悉用户业务到获得系统需求是一个转换的过程，在其中可以采用模式、用例、原型以及功能点分析等方法。
开发人员常常并不熟悉行业领域内的专业知识，却又要在短期内熟悉具体业务，无疑被置于两难的境地。为快速地深入了解实际业务，可以借助业务调查表来模拟用户行为，其内容包括：具体业务的名称、上级业务、下级业务、优先级、发生条件、处理的数据和详细流程，如处理岗位、处理方式和审核细节等。在掌握业务之后，又如何从中进一步梳理出真正的需求呢?此时，开发人员要从用户视角转换到系统视角，将条分缕析的业务流程转换成用户与系统的交互。
软件需求表述的是软件代表用户、设备或其他系统所做的事情。寻找软件需求的第一个地点就是在系统的边界上观察“进出”系统的事物，即系统与用户的交互。因此，最简单的方法就是将系统看作一个黑盒，然后考虑为了完整地描述这个黑盒的功能开发人员所要做的工作，这里包括输入、输出，系统的性能以及系统与环境的交互。相应地，通过定义系统的输入、输出、功能、系统的属性和环境的属性即可以确定一组完整的软件需求。
系统的输入不仅包括输入的内容，还包括输入的设备、形式、外观以及感觉等必要的细节。系统的输出必须包括对输出设备的描述，如语音输出或可视化显示等，以及系统产生信息的协议和格式。系统的功能是指将输入映射到输出，以及它们的不同组合。系统的属性指一些非行为需求，如可靠性、可维护性，可获得性以及容量等开发人员必须考虑的因素。系统环境的属性包括附加的非行为需求，如系统在不同操作约束、负载和操作系统兼容性中运行的能力。
用户的业务繁多，系统开发者应从何处下手?这时要根据项目目标划出明确的范围，围绕系统必须为用户解决的问题，提取核心、主要、急迫的业务，明晰业务流程。在需求分析过程中，系统开发者可以借鉴一些软件体系架构方法提炼业务需求，如层模式(Layer)、管道和过滤器模式(PipesandFilters)等，还可以借助伪代码、有限状态机、决策树和决策表、UML语言的用例图、类图、活动图，以及实体关系图、数据流图、界面原型等，从不同角度深入挖掘和细化需求。
层(Layer)模式把应用系统分解成子任务组，其中每个子任务组处于一个特定的抽象层次上。每一层为上层服务(ServiceProvider)，同时也作为下层的客户端。如果我们将一个复杂问题分解成一个层堆栈的实现，由于每一层最多只影响两层，同时只要给相邻层提供接口，允许每层用不同的方法实现，这不仅为软件重用提供了强大的支持，而且为新增和改变需求留出了充足的空间。
管道和过滤器(PipesandFilters)模式是为处理数据流的系统提供的一种模式。每个处理步骤都被封装在一个过滤器组件中，数据通过相邻过滤器之间的管道进行传输。每个过滤器可以单独修改，功能单一，并且它们之间的顺序可以进行配置。也就是除了输入和输出外，过滤器之间不共享任何状态信息，不相互影响。在需求容易变动的情况下，管道和过滤器模式能够通过替换或重新排序处理步骤来为将来的灵活性作出规划。
用例方法把系统分成参与者(actor)和用例(usecase)。参与者(actor)表示系统用户能扮演的角色(role)。参与者可以是人，也可以是另一些相关的软硬件系统。用例被定义成系统执行的一系列动作，动作执行的结果能被指定的参与者察觉到。用例方法可以捕获某些用户可见的需求，实现一个具体的用户目标。
原型也是探索需求的有效辅助手段，它将存在于大家头脑中的虚拟系统实实在在地表达出来，促使双方的理解迅速向一个折衷方案靠拢。原型之后的需求沟通更为务实，由此催生出可以指导研发过程的软件需求说明书。原型有许多种，如只实现用户界面的水平原型，以较高的质量实现少量需求的垂直原型，目的在于建立可行性分析，用后即作废的抛弃型，以及通过发展该原型来构建最终系统的演进型。
用户的业务各不相同，因此应用系统功能也是各异的，但其本质都是建立行为主体、限制条件、客体对象和操作四种要素之间的关系，即行为主体在一定的限制条件下对客体对象施加某项操作。如果针对某个行业或类型的应用系统开发一些原型产品，或者针对系统中具有共性的部分开发一些组件，如权限管理、菜单和工具条生成器，以及较为通用的界面等，那么与用户交流需求，尤其在碰到那些对具体需求缺乏明确概念的用户时，就能够引导用户有的放矢，并基于原型迭代产生出真正的需求信息。即使缺乏有关的原型产品，也可以利用直观的页面链接简明地示意出上述关系。在使用原型时，可以忽略业务处理过程，但应尽量采用真实的输入信息并模拟真实的输出结果，这样有助于用户建立感性认识，使之较易接受系统开发者提供的原型。
如果能够找到软件项目开发的固定程式，那将是化解风险的最佳方案。虽然没有“银弹”，但是人们已总结出了一些软件过程度量的方法。例如，功能点分析(FPA)是基于软件功能性来估算和度量应用软件规模的方法，其重点在于枚举可视的、用户可识别的软件外部性质，并通过权重将它们结合起来，形成软件规模的复合功能度量。应该说，需求分析分段只能做功能点估算，在软件项目结束后计算出的功能点才是最准确的，不过却失去了对本次项目的指导意义。但是，开发人员有必要在项目总结时认真地进行功能点计算，这些数据累积起来就会形成宝贵的经验，使得新项目的功能点估算愈加准确。
功能点分析方法将应用系统的功能分为数据处理和事务处理。内部逻辑文件(ILF)和外部接口文件(EIF)是数据处理功能的两种类型。ILF是存储在系统内并由系统维护的一级信息。EIF是系统和外部应用程序共享的惟一文件。事务处理包括外部输入(EI)、外部输出(EO)和外部查询(EQ)。EI是更新系统内数据的事务。EO是通过边界离开系统的单一数据或控制输出。EQ是数据的检索。每个功能的功能点因其功能类型(ILF、EIF、EI、EO或EQ)和复杂度(简单、一般、复杂)的不同而不同。每个功能类型按照一定的规则来确定其复杂度。找出的所有功能定为未调整功能点，以计算总的未调整功能点。然后依据需求规格说明书中定义的非功能需求和设计限制因素形成值调整因子(VAF)。VAD乘以未调整功能点便得到功能点数。
执行FPA的每一个步骤都有发现需求缺陷的能力。例如，标识计算功能点数的范围和应用程序的界限，可能发现系统中对应该包括的功能和不应该包括的功能的误解。计算数据和事务功能类型能帮助标识出遗漏的需求，如可能发现报告(外部输出)里面没有数据源(内部逻辑文件丢失)；还可能发现系统有能力向逻辑数据组增加数据(外部输入)，但没有浏览数据(外部查询)或者删除数据的能力(遗漏了外部输出)。这种对外部数据(外部接口文件)的标识有可能显示出外部接口的要求被完全忽略了。另外，对一般系统特点的分析可能提示出以前没有标识出的设计限制。
三、需求测试
应该从什么时候开始测试软件项目?有人认为是编码阶段，即编码的同时进行单元测试，编码完成后进行系统测试。实际上在现代软件过程中，测试从需求分析阶段就开始了，需求分析是测试计划的输入和参照，更为重要的是，开发人员可以利用需求测试作为规避需求风险的有效方法。开发人员应时刻警醒：只有当软件项目的所有需求都可以被测试时，才能够保证应用系统始终围绕着用户的需要，保证软件过程的成功。
那么，到底什么样的需求才是可测试的？如果用户给出这样一段描述：“我们要用新的系统完成报表自动化处理”，开发人员就要继续追问报表包括哪些，自动化处理的标准是什么?如果不说明这些细节，那么所做的需求描述就是不可测试的，其含混之处将形成开发过程中的重重陷阱。实际上，描述需求可以称为“解剖”需求，即将大的任务划分成若干需求，再将每一需求解构成原子粒度的测试项，即给出输入、处理、输出的量化指标，包括格式、数据量、容错性、接口、速度等等。在需求规格说明书中应注意不要出现那些不能被检验的词汇，如“充分或足够”，而应代之以数量或其他方式的度量。例如，“A应该是用户友好的”就是不可测试的，将其转换为可测试的需求描述则为：A应该提供说明控件用途的标签，字母大小应为0．75~0．05厘米；A的控件位置应该按照使用顺序排列(从左到右)；A应该显示控件选项菜单；A应该显示用户下一步动作的提示；A应该使用产品PQR的显示约定；A应用红色显示紧急停止控件。
在进行需求测试时，首先，应从语义和语法上检查需求文档的正确性，然后针对系统的输入、输出、功能、系统的属性和环境的属性，根据已经建立起的一些规则进行同行评审、走查，还可以在某些环节上结合等价类划分、边界值分析、因果图、逻辑覆盖等黑盒与白盒方法设计测试用例，再次验证相应的需求描述是否“达标”，找出需求规格说明书中遗漏、过度、错误、重复，模糊甚至矛盾的内容。
对需求文档的检查包括确认定义的所有概念和实现方法是否清楚地表达了用户的原要求，对功能的描述是否背离其实际要求，是否有不能理解或造成误解的描述；是否对每一个需求都给出了充分的理由；各个需求之间是否一致，需求定义是否参照了有关标准，算法和规则是否有文献依据，是否兼容，能否在相应的限制条件下实现；是否对所有的图形、表格都进行了标号，是否采用了索引和交叉引用表等保证对需求定义的描述易于修改；一项需求是否被定义了多次；是否有需求可以被定义的更细致或更简单；语言是否无歧义；是否对每一个需求都指定了验证过程。
对于系统的输入和输出，应检查是否定义了系统的所有输入并标识清楚了系统输入的来源，是否标识出了系统的输出并说明了系统输入/输出的类型，以用系统输入/输出的值域、单位、精度、格式等，是否说明了如何进行系统输入的合法性检查；是否充分定义了关于人机界面的需求。
在功能方面，应检查需求规格说明书是否清楚明确地描述了所有的功能；所有已描述的功能是否是必须的，是否能满足系统目标；是否包含了覆盖了各种操作模式(如正常、非正常、有干扰等)下的情况处理；是否为每个需求指定了软件失效的结果、特定的失效保护信息、特定的错误检测策略以及错误纠正策略；是否标识出了所有与时间因素有关的功能，并说明它们的时间准则，是否定义了最大、最小执行时间；是否清楚地定义了所有的外部/内部接口，所有接口是否必须，各接口间的关系是否一致、正确；所有对其他需求的内部交叉引用是否正确。
对于系统的属性，应检查需求规格说明书中是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性；是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序；是否包含了所有与需求相关的安装特性和维护特性；模块或子程序(过程)间的关系是否是松耦合的；是否精确地描述了所有的性能要求及最低的性能指标；是否指定了处理时间、数据传输速率和系统容量。
对于系统环境，应检查需求规格说明书中是否包含了所有与需求相关的软硬件环境及兼容性；是否指定了最大/最小内存、最大/最小存储空间；是否规定了系统在不同负载状态下的效率；是否说明了本项目对用户、其他系统及环境的相互影响。
四、结论
综上所述可以看出，开发人员是能够在与用户沟通、业务建模、需求测试三个方面采取有效措施规避需求风险的，这些措施的核心是保证用户认可开发者所定义的需求，同时保证开发人员正确地理解需求。