需求工作大体分为：需求收集，需求分析。需求收集就是派人到甲方单位收集相关人员对系统的要求。大公司有专职的需求人员去做这个事，小公司可能就是项目经理去做这件事了。不同的人去做自然效果不一样。需求收集需要记录完整，准确。一个系统在甲方单位涉及到多个岗位，职位的用户。每类用户对系统的诉求是不一样的。曾经一个系统，就主界面都做了4版，甲方领导说界面看上去要高端、大气，信息展示丰富，主要的报表图表什么的都要在首页显示；中层职位用户要求我只关心我那部分的数据、工作流程，其他的不要显示；基础岗位用户要求界面简洁，输入方便，尽量少让点击鼠标，到处找。最后按用户岗位不同，进入系统后显示不同的主界面。如果在需求收集阶段，漏掉部分类型的用户，后期再调整工作量就会加大。需求收集阶段记录的内容基本上是作为原始需求的，但也需要准确，详尽。因为有些用户在讲述要求时，不能很准确的描述，用些比如，类似，就像之类的词。有时是在需求人员的提示下才能说明白，“对，就是你说的那个”。

      这就要求需求人员有一点的行业知识，能从行业背景，企业背景去理解客户说的要求，并提示，补充完整。同时需要对收集到，理解到的需求进行适当的转义，转成软件行业内语义。

      还有个关键人物也应该参与到需求工作中，测试人员。因为后期的测试都将基于需求来验证功能是否达到规定要求。

      还有个人也应该参与到需求工作中来，主开发员（核心开发，设计人员）。后期开发中的设计，技术选型，工作量估算都需要准确了解需求。同时弥补需求人员在与客户沟通时，软件专业技术知识的不足，特别是需求分析阶段，有些需求在技术实现方面存在困难，或冲突都需要专业软件人员来一一分析、识别。对后期的开发也是有利的。核心开发人员掌握第一手的需求，而不是通过其他人转述的，更容易把握需求，使开发在正确的轨道上进行。

     有了专业技术人员的参与，在工作量，时间估算上也会更准确。当然这里的专业技术人员就是以后项目开发的主技术员。交给谁来做就应该由谁来估算工作量，工作时间。否则都是不准确的。在这点上吃过亏，掉过坑。项目的初次谈判，到签订合同，往往都是项目经理（或老板）和甲方项目负责人，碰个面商谈项目的大概情况，觉得可以做，就让项目经理写总体设计，实施方案。这些又都是套用以前项目的文档改改，就拿去投标了，到签订合同。到了开发时，开发人员手上可能都没有需求文档，就一个总体设计。做到具体的功能又去询问甲方用户，一问傻了，这么多，这么复杂。而总体设计或者合同上写得很粗犷。导致最后的时间估计不足，技术风险估计不足，技术准备不足。

    就角色而言，需求工作需要：需求人员，主开发人员，测试人员，或者 项目经理，主开发人员。即不能少了主开发人员角色。

需求，需要谁参与进来？