对需求分析的一些理解

1，有业务需求，更要有功能需求。

        业务需求、用户需求和功能需求并非同一回事。业务需求反映了组织机构或客户对系统及产品高层次的目标要求。用户需求描述了用户使用产品必须完成的任务。而功能需求则应明确表示出产品开发时的功能要求。

          一般我们从业务人员或者时产品经理手中拿到的是业务需求，这时候我们应该整理为用户需求和功能需求，并在完成此步骤后，再到用户那里进行再次的用户调研，逐条商讨，得到修改后的用户需求，再根据用户需求生成功能需求。

2，需求描述不能有二义性。

        一个优秀的需求文档并没有固定的模式，但是在编写需求文档时，我们应该尽量杜绝描述的二义性问题。首先我们要使用简短的句子和段落。如果语句过长，理解句子本身的意思都非常困难，还怎么来理解真正的需求呢？同时过长的句子和段落也容易让人忽视一些需求。所以如果一个句子不能完全描述清楚需求，我们就将其拆分成多个小句子。另外注意句子中不能有语法错误，还要注意标点符号。

        尽量采用主动式的表达方式，必须怎么样，要求怎么样，都要采用主动式的肯定语气，而不要采用含糊不清，模棱两可的语气与词汇。另外注意引用的术语和词汇前后要一致。不要在表达同一个意思时，而前后使用的却是不同的词汇。

        同时利用一些工具，例如Rational Rose,Microsoft Visio来描述业务需求和用户需求的图形，配合文字表达。

3，需求描述尽量细化。

        食不厌精，能细化的就尽量的细化。例如某个产品有这样一个需求：

        界面提供日期导航，当用户点击某一日期时，看到该日期下的数据。

        看到这个需求时，我们很难想出测试用例是什么。日期导航是什么样的？列出日期又是什么日期？是一个月还是一年？用户点击后看到的是哪些数据？这些都是问题。下面我们将需求细化：

        1，后台系统根据计算机当前日期得到当前月份。

        2，后台系统根据当前月份找到登陆用户上载自己文章的日期。

        3，得到这些日期的天数，由前台系统将这些天数以列表形式显示出来。

        4，在前台系统，当用户点击列表中的某一天时，将用户上载的文章以列表形式列出。

        经过这样的细化以后，将一个需求分割成了不同的小需求，每个需求都是我们能想出测试用例来测试的，那么，这个需求细化到这个程度也就可以了。

4，在需求过程中尽可能的多沟通。

          无论是在需求报告完成前还是编写过程中，尽可能的和用户，和其他的项目成员沟通，可以及时将需求进行细化，把自己没想到的部分再补充进来。沟通在需求的过程中起到了文字所不能表达的效果，也是消除人与人理解偏差的很重要的手段。因此在需求过程中，用户与系统分析员之间，分析员与设计员、编码人员之间都需要进行充分的沟通。

        沟通能解决一切问题。