首页>>技术前沿>>网站/软件行业动态不是危言耸听，软件开发过程中中40%十至60%的问题都是在需求分析阶段埋下的“祸根”。同样的道理用在若要建一幢数百万元的房子，甲乙双方详细讨论各种细节，都明白完工以后的修改会造成损失，以及变更细节的危害性，否则不会匆忙开工。可许多软件公司仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟—软件开发者的结果与客户所想得到的软件存在着巨大期望差异。
在软件项目管理中，风险承担者包括客户、客户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与软件公司之间联系沟通的人)、软件开发人员、测试人员、客户文档编写者、项目管理者和客户管理者。需求分析若处理不好，会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件项目管理和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。
软件需求包括三个不同的层次—业务需求、客户需求和功能需求—也包括非功能需求。
业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
客户需求描述了客户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
功能需求定义了软件开发人员必须实现的软件功能，使得客户能完成他们的任务，从而满足了业务需求。
作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给客户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对软件开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对客户和软件开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向客户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。为什么这么说呢，因为在大多数的软件系统中，最终客户可能都不清楚他的需求是什么，这是千真万确的。如果你的客户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。
下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。
1. 无足够客户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，软件开发人员可能也不重视客户的参与。究其原因：一是因为与客户合作不如编写代码有意思；二是因为软件开发人员觉得已经明白客户的需求了。在某些情况下，与实际使用产品的客户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的客户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 最重要的就是客户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果客户不够重视，想办法解决，否则你就不用再继续了。
2. 客户需求的不断增加
在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于客户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。
最糟糕的莫过于客户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，客户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到客户投诉说项目失败。
3. 模棱两可的需求
模棱两可是需求规格说明中最为可怕的问题。模棱两可的需求会使不同的风险承担者产生不同的期望，它会使软件开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。
模棱两可的需求带来不可避免的后果便是返工—重做一些你认为已做好的事情。处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。
4. 不必要的特性
“画蛇添足”是指软件开发人员力图增加一些“客户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是客户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。软件开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与软件开发人员在允许时限内的技术可行性之间求得平衡，软件开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。
同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使客户完成他们业务任务的核心功能。
5. 过于精简的规格说明
有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让软件开发人员在项目进展中去完善，结果很可能出现的是软件开发人员先建立产品的结构之后再完成需求说明。在大多数情况下，这会给软件开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。
6. 忽略了客户分类
大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要客户进行分类的话，必然导致有的客户对产品感到失望。例如，菜单驱动操作对高级客户太低效了，但含义不清的命令和快捷键又会使不熟练的客户感到困难。
7. 不准确的计划
“上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多软件开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。
【全文完】
版权声明:
1、陕西弈聪网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，百度关键词优化，西安软件开发等技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。
2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。
企业动态
