需求分析

软件需求常常被写得很糟且难于遵循。清楚地阐明你的需求将使每位项目参与者获益。

需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

沟通本来就是一门艺术，而需求沟通的双方通常是不同专业背景的，这就更需要应用一些得当的“艺术性技巧”。接下来，我们就通过几个场景实例来体会一下。

DFD其实主要是对加工不断分解的过程，在此过程中要重点注意父子图以及数据、数据流的平衡。

软件的成功从“需求开始”，所以需求人员是软件的成功之本。

本文通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。

花了一天的时间，整理了下需求工程方面的有关方法。并对这些方法的实现难易度以及效果进行了分类。供大家参考讨论

“ 需求分析”不代表“用户要求什么就是什么”也不代表“我们能做什么就做什么”，做为需求人员，在进行需求分析的时候，首先应该明白用户的需求，然后再加上自己的分析处理过程，知道哪些我们现在能做，哪些我们做不了，哪些我们咬咬牙齿能做，需求人员在做需求分析的时候不能一味的成为客户的传话筒，要有自己的分析。

多数软件项目都是在时间紧、人员少、项目预算有限的条件下完成的。在这些“先天不足”的条件下，如何做到项目进度不延迟、工作量不超期、费用不超支？首先就是关注需求分析。 “良好的开端就成功了一半”，需求分析做好了，对下一步的设计阶段工作真正起到指导性作用，规避需求开发过程存在的问题，成功的软件项目指日可待。

如果你赞成客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就会努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。

需求开发（Requirement Development，RD）是CMMI中一个重要的过程域，因为它的质量决定了研发产品的方向，如果需求没有把握准确，不仅产品在研发过程中多有返工，增加了成本；而且上市后不能满足目标客户的要求，又影响收入，那么企业的利润空间被压缩，必然影响企业发展。正如图1所示，我们常把企业的市场收入比作房子的屋顶，成本比作地板，那么努力抬高房顶、压下地板，企业就能获得更大的利润空间；反之，就减少了企业的利润空间。

对于特定的招标型项目，用户需求一般会体现在SOW工作说明书或招标相关文件里面。用户需求是从用户期望角度出发，提出的为了解决用户实际问题而提出的产品在功能或非功能上应该具备的各种特性。对于IT项目，最好是在项目启动阶段就已经确定好了用户需求，用户需求是软件项目范围的重要输入，在项目计划阶段或执行阶段还在确定用户需求必然会存在范围蔓延或镀金的问题。项目范围不明确和不受控是导致IT项目频繁变更和延期的重要原因。

在实施ERP前，对企业进行需求分析是非常重要的，而需求分析，首先要从企业的管理诊断开始。

软件做出来的功能不是用户想要的，则是我们在出功能性需求的时候出现明显的偏差。但是如何功能是不好用，则是我们没有重视需求开发中的非功能性需求方面的描述，而关于软件的性能，UI和交互，安全性，可靠性和健壮性等都是软件的非功能性需求。很多时候软件产品的失败往往就是在非功能性需求上面。

在实施标准化文档(项目实施WBS)中，我将现场准备阶段的工作进行了扩充，需求分析工作就在这个阶段的建立数据职责体系中完成。

工作流作为近几年以来热门的话题，已经在诸多信息化系统中得到了应用，但使用的结果不尽人意。上一篇文章分析了用不起来的原因，本文将直接对客户需求进行分类分析，下一篇将对这些分类进行分析，了解一下客户的真实需求所在。

在需求分析原则一中的第一条就是“了解需求，而不是去批评用户”，而我们的许多同行却是一直在扮演着批评家的角色，对于用户的需求阳奉阴违，当面说的是“非常感谢您的建议，我们会认真考虑的”，头一扭，就对团队的人说“提的这是什么，大家别管这些，继续按照我们的做”。

需求分析第二个原则的中心思想：1、需求分析第二个原则：尊重用户的现实选择。2、原则第一点：客户永远是对的。3、原则第二点：提供最合适的解决方案，而非最好或最贵的方案。4、原则第三点：不要把客户当傻瓜。

本文通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。

项目失败的原因有两个：需求分析不到位、架构设计不合理。