论文部分内容阅读
【摘 要】软件项目的需求不清晰或者需求变更频繁是导致软件项目进展不顺利甚至最终夭折的的重要原因之一。本文着重讨论了软件项目需求分析阶段常见的四大误区，并逐一提出修正意见。在讨论中，笔者介绍了业务需求的定义，业务需求分析的过程，需求分析师在软件项目中的角色定位和需要掌握的知识结构。希望通过此次讨论可以修正人们对于软件项目需求分析的错误认识，减少在软件项目中因为需求而导致的项目问题。
【关键词】软件项目 需求分析 需求分析师 业务分析师
软件项目的复杂性、多变性和易变性是整个软件项目过程中最难以应对和解决的问题。其导致的直接后果为项目开发出来的系统无法满足客户的需求，软件产品的质量存在严重的漏洞，项目时间和项目成本严重超出预期等等。大量实例证明，项目的需求不清晰或者需求变更频繁往往是导致软件项目进展不顺利甚至最终夭折的的重要原因之一。因此，软件需求分析作为软件项目第一阶段的重要性已经越来越被人们所重视。人们越来越清醒地认识到一个项目的需求分析做得是不是细致、全面、清晰是决定该项目质量高低，进度能否受控制，以及成本是否能满足预算的基础，同时更是直接影响该项目成败与否的关键。
虽然需求分析的重要性在众多软件项目的曲折进程中已经逐渐显现出来，但是它的发展却并不如人意。人们常常拿需求分析和项目管理作比较，说需求分析师（或业务分析师）就是项目需求分析阶段的项目经理。1969年创立的美国项目管理协会（PMI）把项目管理知识的推进和普及推到了一个全球顶尖的高度。与之相比，2003年在加拿大成立的国际业务分析协会（IIBA）则像个还在学习走路的婴儿。业务需求分析的知识还在不断地完善和丰富中，而业务需求分析知识的普及更是需要一个漫长的过程。在不断探索的实践进程中，人们对于业务需求分析相关知识的理解还不够深刻和全面，对于需求分析师（或业务分析师）在软件项目中的角色定位也还不够清晰。接下来，笔者将具体讨论在软件项目需求分析领域常见的四大误区。
一、客户提出的要求就是需求
这是对业务需求分析最常见最基本的一个误解。在软件项目需求分析阶段，项目团队可能会遇到两种极端的情况：一种是客户完全不清楚自己需要什么，说不清项目的需求是什么。这种情况下，需要项目团队成员运用各种需求发掘技术和工具去帮助客户了解自身待解决的问题和想达成的目的，在这里笔者不做详述。另一种情况是，客户“太清楚”自己想要什么，以至于当项目团队在向客户收集需求的时候，客户会非常明确地说“我们希望能有一个xx这样的软件，里面有xx这几个功能，按了xx这个功能按钮之后就跳转至另一个页面，页面的上面如此这般，下面如此这般” 等等。有些项目团队在收到这样的“需求”之后，会觉得客户要求非常清晰，于是就马上着手按照客户所描述的去做。但等到产品完成，交由客户做测试的时候，客户往往会提出产品这里不太好用，那里不符合要求等各种意见。项目团队此时可能会感到不解，甚至与客户发生争论，因为他们完全是按照客户的要求来完成的。为什么会出现这种明明项目团队完全依照客户要求，而客户仍然不满意的状况呢？其中有一个很重要的原因就是，客户和项目团队都没有弄清楚到底什么是需求，什么是解决方案。
要走出这个误区，首先，项目团队要理解需求（requirement）和解决方案（solution）的定义。根据IIBA的定义，需求共包括三层含义：
（一）是帮助项目相关干系人解决问题或达成目的的某种条件或者能力。
（二）是在项目解决方案或者解决方案的组成模块中必须完成或达到的，用来满足某个合约、标准、规格或其他正式文件的某种条件或者能力。
（三）是一份描述上述第1）点和第2）点中所解释的条件或能力的文档。
由此可以看出，软件项目的需求主要指的是项目产品最终能提供的用来解决问题、达成目标、满足要求的某种条件或者能力。
在BABOKR Guide中，IIBA同样描述了解决方案的定义：解决方案是对组织现状所做的一系列的改变，其目的是为了让该组织满足某个业务需要，解决某个问题，或者善用某个机会。
其次，在理解定义的基础上，项目团队要掌握需求和解决方案的区别。“需求”所描述的是达成项目目标所需要的人物（Who）、事件（What）、地点（Where）、时间（When）、频率（How often）和数量（How much）。而解决方案则是描述如何（How）解决的问题。
回到前面提到的那位“太清楚”自己需要什么的客户的案例，不难发现，该客户所提出的需要“这样的软件”，“这几个功能”，“这个按钮”，“这样的页面”等均属于解决方案的范畴，而并非是需求。项目团队在没有弄清楚客户的真正需求的情况下，只是简单地跟随客户提出的解决方案来进行，其结果自然就會出现前文所提到的产品不能满足客户需求的矛盾。此时，项目团队正确的做法应该是：首先，挖掘出客户所提出的解决方案背后真正想解决的问题或想达到的目的；然后，将这个问题或者目的作为项目需求进行记录、分析和确认；再根据项目需求和技术条件与项目团队一起提出相应的解决方案，这个解决方案可能与客户提出的一样，也可能不同；最后，与客户确认该解决方案是否可以满足客户的真实需求。在完成了这一系列分析和沟通之后，项目团队才可以按照达成共识的解决方案开始进行系统的设计和开发。
二、客户需求应全部满足
这是对业务需求分析的又一错误解读。在软件项目中，处于乙方的项目团队有时会对甲方的客户“言听计从”，只要客户提出的需求便理所当然地认为全部都应该完成。其结果最终可能因为采纳了一些不合理或不清晰的需求而导致项目失败。
一谈到软件项目，工程师们谈论的焦点仍然是采用什么解决方案，和存在哪些技术难点，而忽略了分析项目的需求是否是有效的，准确的，清晰的，和可行的。在有些软件项目中，需求分析的过程变成了简单的记录过程。需求分析人员把客户提出的需求逐一记录下来就形成了需求文档，而没有进行任何的分析。事实表明，当客户提出需求时，有时只是站在自己的角度上，而忽略了可能受影响的其他干系人。这一点在当项目产品的影响范围不局限于客户组织的某一个部门，而是跨部门甚至跨组织时尤为明显。这时的需求可能是在局部范围内有效，但从整体上来看是无效的或者不完善的。其次，由于表达的问题，或者客户本身对于所提需求的认知度不全面，有时客户提出的需求可能不准确或者不清晰。对于这部分需求，项目团队很容易仅凭自己的主观猜想去进行设计开发，而在很迟的时间才发现理解错误。另外，客户提出的“天马行空”的想象也是项目团队要面对的困难之一。以上三点都是由于在需求分析阶段需求分析人员只是做了简单的记录工作，而忽略了需求分析而引起的。 要杜绝上述三种情况的发生，需求分析人员在收集需求阶段应该采用“倾听——分析——沟通——确认”的方法。首先，认真倾听客户的需要，了解客户的现状和愿景，收集并记录客户提出的需求。其次，对收集到的所有需求进行分析，包括辨别需求的有效性，进一步完善需求细节，对需求进行分类和排序等。第三，需求分析人员要与各方就需求细节进行沟通，例如与项目开发团队核实需求的可实现性和可能存在的技术风险，与客户沟通所掌握的需求细节以达成共识等等。最后，与各方进行需求确认，形成最终的需求文档，以作为项目下一步的重要依据。在整个过程中，客户的原始需求可能被修改，被推迟实施时间，甚至被取消或被拒绝。
由以上两个常见误区可以看出，需求分析其实是一个专业性很强的领域。需求分析师除了记录客户提出的需求外，还需要对所提的需求进行去伪存真、细化、验证等一系列工作。现在，越来越多的软件开发企业设置了需求分析师（或业务分析师）的职位，专门从事软件项目需求分析的工作，但仍有更多的企业启用项目团队成员担当业务需求分析的工作。到底在软件项目中需不需要设置一个专门的岗位从事业务需求分析呢？到底需求分析师和项目团队中其他岗位的职责有什么不同呢？需求分析师有哪些职业技能需要呢？下面，笔者将就这几个问题具体分析目前对需求分析师这个职业的两个常见理解误区。
三、需求分析师与项目经理、系统分析师和测试经理的区别不大
软件项目一定要有需求分析阶段，但是不一定要有专门的需求分析师的职位。业务需求分析的工作可以由项目团队中的其他成员从事。就像前面所提到的，需求分析师就是需求分析阶段的项目经理，所以有很大一部分项目的需求分析工作是由项目经理兼任的。人们有时会混淆项目经理和需求分析师这两个角色。简单来说，需求分析师是保证项目“做正确的事（Do right things）”，而项目经理是保证项目“正确地进行（Do things right）”。这两者的差别可以具体从以下几个方面进行比较：
（一）需求分析师关心的仅是项目解决方案的成功，即解决方案是否可以满足客户的需求；而项目经理关心的是则是整个项目的成功，即项目是否可以保质保量地按时完成。
（二）需求分析师的职责是管理需求，保证他们是合理的，有效的，可跟踪的；而项目经理的职责是根据项目的三维约束条件（即时间、成本和范围）管理整个项目。
（三）需求分析师定义项目解决方案的范围，项目经理根据解决方案的范围定义整个项目的范围；需求分析师管理需求变更的过程，项目经理管理项目中一切变更的过程；需求分析师分析由于项目需求或者解决方案带来的项目风险，并制定风险应对，项目经理分析项目中一切可能的风险及相应的风险应对。
由以上三点可以得出结论，需求分析师和项目经理从事的工作有很多类似的地方，但是二者的权责范围和关心的重点不同。需求分析师更着重于项目需求和解决方案，而项目经理则更关注整个项目。
另外，人们也容易混淆需求分析师、系统分析师和测试经理三者的概念。其实，他们也是有所区别的。具体如下：
1.需求分析师主要负责收集、记录、分析项目需求，最终形成业务需求说明书；系统分析师主要负责将项目业务需求翻译成系统规格，最终形成系统规格说明书；而测试经理则是负责编写系统测试计划，保证系统功能符合业务需求。
2.需求分析师将收集的业务需求与系统分析师进行交流；系统分析师根据需求设计系统规格说明，然后再与需求分析师进行确认，最后形成解决方案。
3.测试经理根据需求分析师提供的需求说明和系统分析师提供的解决方案设计测试计划。此外，需求分析师和系统分析师都将在测试用例和测试脚本的编写过程中提供必要的咨询和帮助。
四、需求分析师的技能要求不高，入门容易
现在很多的需求分析师都是从软件开发人员转变过来的。人们容易有一个误区，认为需求分析师就是跟人聊天，然后将聊天的内容记录下来，因此对技能的要求不高，入行很容易。因此，当有些程序员不愿意继续做“码农”的时候，就转行做了需求分析师。其实，需求分析师是一个跨行业的职位，对人在不同领域的知识掌握和不同行业的熟悉程度都有很高的要求。一方面，需求分析师需要与专业领域的客户进行沟通，以分析组织现状、定义项目目标、收集和分析业务需求；另一方面，需求分析师需要与项目开发团队进行沟通，解释客户需求并验证解决方案是否满足需求。所以，需求分析师需要对客户的业务领域和IT领域都非常了解，才能顺利地完成以上工作。
BABOKR Guide定義了业务需求分析需要掌握的七大知识领域：业务分析规划和监控（Business Analysis Planning and Monitoring），捕获（Elicitation），需求管理和沟通（Requirements Management and Communication），企业分析（Enterprise Analysis），需求分析（Requirements Analysis），解决方案评估和确认（Solution Assessment and Validation），和潜在能力（Underlying Competancies）。想要成为一名合格的业务需求分析师，需要对这七大知识领域有一定的了解和掌握。
业务需求是软件项目的基础，它直接决定了项目的范围、进度、成本和质量，甚至决定了整个项目的成败。本文讨论了在软件项目需求分析过程中常见的四大误区。希望通过这次讨论，使人们更清晰的理解需求的定义，了解需求分析的过程，认识需求分析师的角色定位和需要掌握的知识结构，从而减少在软件项目中因为需求而导致的项目问题。
参考文献：
[1] International Institute of Business Analysis. A Guide to the Business Analysis Body of KnowledgeR （BABOKR Guide）. Version 2.0. Canada：2009.
[2] 陆丽.需求分析在软件开发过程中的重要性.电脑知识与技术，2012，第8卷第21期：5113
作者简介：
胡芸（1980-），女，湖北武汉人，汉族，硕士研究生，助教，研究方向：需求分析、项目管理和人机交互。
【关键词】软件项目 需求分析 需求分析师 业务分析师
软件项目的复杂性、多变性和易变性是整个软件项目过程中最难以应对和解决的问题。其导致的直接后果为项目开发出来的系统无法满足客户的需求，软件产品的质量存在严重的漏洞，项目时间和项目成本严重超出预期等等。大量实例证明，项目的需求不清晰或者需求变更频繁往往是导致软件项目进展不顺利甚至最终夭折的的重要原因之一。因此，软件需求分析作为软件项目第一阶段的重要性已经越来越被人们所重视。人们越来越清醒地认识到一个项目的需求分析做得是不是细致、全面、清晰是决定该项目质量高低，进度能否受控制，以及成本是否能满足预算的基础，同时更是直接影响该项目成败与否的关键。
虽然需求分析的重要性在众多软件项目的曲折进程中已经逐渐显现出来，但是它的发展却并不如人意。人们常常拿需求分析和项目管理作比较，说需求分析师（或业务分析师）就是项目需求分析阶段的项目经理。1969年创立的美国项目管理协会（PMI）把项目管理知识的推进和普及推到了一个全球顶尖的高度。与之相比，2003年在加拿大成立的国际业务分析协会（IIBA）则像个还在学习走路的婴儿。业务需求分析的知识还在不断地完善和丰富中，而业务需求分析知识的普及更是需要一个漫长的过程。在不断探索的实践进程中，人们对于业务需求分析相关知识的理解还不够深刻和全面，对于需求分析师（或业务分析师）在软件项目中的角色定位也还不够清晰。接下来，笔者将具体讨论在软件项目需求分析领域常见的四大误区。
一、客户提出的要求就是需求
这是对业务需求分析最常见最基本的一个误解。在软件项目需求分析阶段，项目团队可能会遇到两种极端的情况：一种是客户完全不清楚自己需要什么，说不清项目的需求是什么。这种情况下，需要项目团队成员运用各种需求发掘技术和工具去帮助客户了解自身待解决的问题和想达成的目的，在这里笔者不做详述。另一种情况是，客户“太清楚”自己想要什么，以至于当项目团队在向客户收集需求的时候，客户会非常明确地说“我们希望能有一个xx这样的软件，里面有xx这几个功能，按了xx这个功能按钮之后就跳转至另一个页面，页面的上面如此这般，下面如此这般” 等等。有些项目团队在收到这样的“需求”之后，会觉得客户要求非常清晰，于是就马上着手按照客户所描述的去做。但等到产品完成，交由客户做测试的时候，客户往往会提出产品这里不太好用，那里不符合要求等各种意见。项目团队此时可能会感到不解，甚至与客户发生争论，因为他们完全是按照客户的要求来完成的。为什么会出现这种明明项目团队完全依照客户要求，而客户仍然不满意的状况呢？其中有一个很重要的原因就是，客户和项目团队都没有弄清楚到底什么是需求，什么是解决方案。
要走出这个误区，首先，项目团队要理解需求（requirement）和解决方案（solution）的定义。根据IIBA的定义，需求共包括三层含义：
（一）是帮助项目相关干系人解决问题或达成目的的某种条件或者能力。
（二）是在项目解决方案或者解决方案的组成模块中必须完成或达到的，用来满足某个合约、标准、规格或其他正式文件的某种条件或者能力。
（三）是一份描述上述第1）点和第2）点中所解释的条件或能力的文档。
由此可以看出，软件项目的需求主要指的是项目产品最终能提供的用来解决问题、达成目标、满足要求的某种条件或者能力。
在BABOKR Guide中，IIBA同样描述了解决方案的定义：解决方案是对组织现状所做的一系列的改变，其目的是为了让该组织满足某个业务需要，解决某个问题，或者善用某个机会。
其次，在理解定义的基础上，项目团队要掌握需求和解决方案的区别。“需求”所描述的是达成项目目标所需要的人物（Who）、事件（What）、地点（Where）、时间（When）、频率（How often）和数量（How much）。而解决方案则是描述如何（How）解决的问题。
回到前面提到的那位“太清楚”自己需要什么的客户的案例，不难发现，该客户所提出的需要“这样的软件”，“这几个功能”，“这个按钮”，“这样的页面”等均属于解决方案的范畴，而并非是需求。项目团队在没有弄清楚客户的真正需求的情况下，只是简单地跟随客户提出的解决方案来进行，其结果自然就會出现前文所提到的产品不能满足客户需求的矛盾。此时，项目团队正确的做法应该是：首先，挖掘出客户所提出的解决方案背后真正想解决的问题或想达到的目的；然后，将这个问题或者目的作为项目需求进行记录、分析和确认；再根据项目需求和技术条件与项目团队一起提出相应的解决方案，这个解决方案可能与客户提出的一样，也可能不同；最后，与客户确认该解决方案是否可以满足客户的真实需求。在完成了这一系列分析和沟通之后，项目团队才可以按照达成共识的解决方案开始进行系统的设计和开发。
二、客户需求应全部满足
这是对业务需求分析的又一错误解读。在软件项目中，处于乙方的项目团队有时会对甲方的客户“言听计从”，只要客户提出的需求便理所当然地认为全部都应该完成。其结果最终可能因为采纳了一些不合理或不清晰的需求而导致项目失败。
一谈到软件项目，工程师们谈论的焦点仍然是采用什么解决方案，和存在哪些技术难点，而忽略了分析项目的需求是否是有效的，准确的，清晰的，和可行的。在有些软件项目中，需求分析的过程变成了简单的记录过程。需求分析人员把客户提出的需求逐一记录下来就形成了需求文档，而没有进行任何的分析。事实表明，当客户提出需求时，有时只是站在自己的角度上，而忽略了可能受影响的其他干系人。这一点在当项目产品的影响范围不局限于客户组织的某一个部门，而是跨部门甚至跨组织时尤为明显。这时的需求可能是在局部范围内有效，但从整体上来看是无效的或者不完善的。其次，由于表达的问题，或者客户本身对于所提需求的认知度不全面，有时客户提出的需求可能不准确或者不清晰。对于这部分需求，项目团队很容易仅凭自己的主观猜想去进行设计开发，而在很迟的时间才发现理解错误。另外，客户提出的“天马行空”的想象也是项目团队要面对的困难之一。以上三点都是由于在需求分析阶段需求分析人员只是做了简单的记录工作，而忽略了需求分析而引起的。 要杜绝上述三种情况的发生，需求分析人员在收集需求阶段应该采用“倾听——分析——沟通——确认”的方法。首先，认真倾听客户的需要，了解客户的现状和愿景，收集并记录客户提出的需求。其次，对收集到的所有需求进行分析，包括辨别需求的有效性，进一步完善需求细节，对需求进行分类和排序等。第三，需求分析人员要与各方就需求细节进行沟通，例如与项目开发团队核实需求的可实现性和可能存在的技术风险，与客户沟通所掌握的需求细节以达成共识等等。最后，与各方进行需求确认，形成最终的需求文档，以作为项目下一步的重要依据。在整个过程中，客户的原始需求可能被修改，被推迟实施时间，甚至被取消或被拒绝。
由以上两个常见误区可以看出，需求分析其实是一个专业性很强的领域。需求分析师除了记录客户提出的需求外，还需要对所提的需求进行去伪存真、细化、验证等一系列工作。现在，越来越多的软件开发企业设置了需求分析师（或业务分析师）的职位，专门从事软件项目需求分析的工作，但仍有更多的企业启用项目团队成员担当业务需求分析的工作。到底在软件项目中需不需要设置一个专门的岗位从事业务需求分析呢？到底需求分析师和项目团队中其他岗位的职责有什么不同呢？需求分析师有哪些职业技能需要呢？下面，笔者将就这几个问题具体分析目前对需求分析师这个职业的两个常见理解误区。
三、需求分析师与项目经理、系统分析师和测试经理的区别不大
软件项目一定要有需求分析阶段，但是不一定要有专门的需求分析师的职位。业务需求分析的工作可以由项目团队中的其他成员从事。就像前面所提到的，需求分析师就是需求分析阶段的项目经理，所以有很大一部分项目的需求分析工作是由项目经理兼任的。人们有时会混淆项目经理和需求分析师这两个角色。简单来说，需求分析师是保证项目“做正确的事（Do right things）”，而项目经理是保证项目“正确地进行（Do things right）”。这两者的差别可以具体从以下几个方面进行比较：
（一）需求分析师关心的仅是项目解决方案的成功，即解决方案是否可以满足客户的需求；而项目经理关心的是则是整个项目的成功，即项目是否可以保质保量地按时完成。
（二）需求分析师的职责是管理需求，保证他们是合理的，有效的，可跟踪的；而项目经理的职责是根据项目的三维约束条件（即时间、成本和范围）管理整个项目。
（三）需求分析师定义项目解决方案的范围，项目经理根据解决方案的范围定义整个项目的范围；需求分析师管理需求变更的过程，项目经理管理项目中一切变更的过程；需求分析师分析由于项目需求或者解决方案带来的项目风险，并制定风险应对，项目经理分析项目中一切可能的风险及相应的风险应对。
由以上三点可以得出结论，需求分析师和项目经理从事的工作有很多类似的地方，但是二者的权责范围和关心的重点不同。需求分析师更着重于项目需求和解决方案，而项目经理则更关注整个项目。
另外，人们也容易混淆需求分析师、系统分析师和测试经理三者的概念。其实，他们也是有所区别的。具体如下：
1.需求分析师主要负责收集、记录、分析项目需求，最终形成业务需求说明书；系统分析师主要负责将项目业务需求翻译成系统规格，最终形成系统规格说明书；而测试经理则是负责编写系统测试计划，保证系统功能符合业务需求。
2.需求分析师将收集的业务需求与系统分析师进行交流；系统分析师根据需求设计系统规格说明，然后再与需求分析师进行确认，最后形成解决方案。
3.测试经理根据需求分析师提供的需求说明和系统分析师提供的解决方案设计测试计划。此外，需求分析师和系统分析师都将在测试用例和测试脚本的编写过程中提供必要的咨询和帮助。
四、需求分析师的技能要求不高，入门容易
现在很多的需求分析师都是从软件开发人员转变过来的。人们容易有一个误区，认为需求分析师就是跟人聊天，然后将聊天的内容记录下来，因此对技能的要求不高，入行很容易。因此，当有些程序员不愿意继续做“码农”的时候，就转行做了需求分析师。其实，需求分析师是一个跨行业的职位，对人在不同领域的知识掌握和不同行业的熟悉程度都有很高的要求。一方面，需求分析师需要与专业领域的客户进行沟通，以分析组织现状、定义项目目标、收集和分析业务需求；另一方面，需求分析师需要与项目开发团队进行沟通，解释客户需求并验证解决方案是否满足需求。所以，需求分析师需要对客户的业务领域和IT领域都非常了解，才能顺利地完成以上工作。
BABOKR Guide定義了业务需求分析需要掌握的七大知识领域：业务分析规划和监控（Business Analysis Planning and Monitoring），捕获（Elicitation），需求管理和沟通（Requirements Management and Communication），企业分析（Enterprise Analysis），需求分析（Requirements Analysis），解决方案评估和确认（Solution Assessment and Validation），和潜在能力（Underlying Competancies）。想要成为一名合格的业务需求分析师，需要对这七大知识领域有一定的了解和掌握。
业务需求是软件项目的基础，它直接决定了项目的范围、进度、成本和质量，甚至决定了整个项目的成败。本文讨论了在软件项目需求分析过程中常见的四大误区。希望通过这次讨论，使人们更清晰的理解需求的定义，了解需求分析的过程，认识需求分析师的角色定位和需要掌握的知识结构，从而减少在软件项目中因为需求而导致的项目问题。
参考文献：
[1] International Institute of Business Analysis. A Guide to the Business Analysis Body of KnowledgeR （BABOKR Guide）. Version 2.0. Canada：2009.
[2] 陆丽.需求分析在软件开发过程中的重要性.电脑知识与技术，2012，第8卷第21期：5113
作者简介：
胡芸（1980-），女，湖北武汉人，汉族，硕士研究生，助教，研究方向：需求分析、项目管理和人机交互。