浅谈软件需求

做软件和做其他商品一样。一定要符合规格，也就是需求。

而且如果软件开发周期比较长的话呢，要求项目人员（特别是项目经理和分析师）对规格就一定要把握的很准确。

好处自然不用说了，降低风险，减少成本，最大化收益！

然而，拿过来一个项目或产品，如何才能很准确地把握需求呢？

首先，要明白，把握需求的关键是：问题是什么？别看只有5个字，但很多人却理解不好。有很多人在这个阶段过多地考虑到了设计和实现。结果导致理解的需求不是用户真正的需求，而是从自己设计或实现的角度曲解的东西。结果可想而知，最终产品总有这样或那样的问题。

“问题是什么？”，就像我们考试一样，对于问答题，首先要理解题干，就是问题是什么？明确问题的实质；然后才是如何解决问题，构思答案；然后是回答问题，最后是检查，交卷。所以做个类比，理解题干就相当于我们做需求分析；构思答案就相当于设计；写答案就相当于实现；检查就相当于软件测试；交卷就相当于交付。

当然，回答一个问题周期一般不会很长，然而，针对软件开发，这个周期可能要长的多。所以每一个阶段都要占用很长的时间。虽然这个理论在很多软件工程书上都写了。但真正在实现的时候，却有很多人或团队不按照这样干，还是作坊式的各行其是。

那么既然明白了软件开发首当其冲的任务是搞清需求。理解问题的实质。

那么理解问题实质的最佳途径也是最有效的途径就是最终用户参与和交互。然而在这里有一个问题一定要注意：需求不等同于需求分析。

需求是用户提出的要求。它只能从用户的角度粗粒度的说明待开发的项目或产品业务范围，也就是我们通常所说的商业场景。其最大的特点就是粗粒度的，简单描述的业务场景。然而，这同时也是项目最原始的，最根本的依据。

需求分析一般由系统分析师完成。系统分析师主要的职责就是从用户模糊的需求中分析出项目要包含的功能性的和非功能性的细致的描述。

需求分析一般可以通过两种方式完成：一种是原型法。另一种是用例驱动法。

原型法：顾名思义，为了准确地把握用户需求，先让项目组成员开发出一个项目原型，交由用户使用，用户根据原型进一步确定需求。系统分析师根据用户使用后的反馈，完善需求分析，最后获取用户的全部需求进行分析。由于用于获取需求的原型要事先做出来，所以从成本的角度讲，原型的开发周期不能太长，成本不能太高。

另外一种就是用例驱动，对用户提出的需求进行建模，然后对每一个用例进行描述，交由用户查看反馈，优化模型，最终得到全部的需求。

从这两种的途径看来，需求分析是至关重要的。它能够清晰反映用户的要求，清楚表示每个功能的业务规则和业务数据。为项目经理的项目进度计划安排提供佐证。为后期的设计提供根据。

所以做好第一步，后面的东西就有据可依，就能有效降低风险，保证项目的成功！