一个项目的开始便是为了满足客户的需求，有了需求才有了我们的供需关系。但是软件与人之间的关系并不是如同人与人来的那么清晰于简单。人们对于一个目标的软件总是有不同的想法和思路。客户和经理的交流和沟通并不能是他们完全的理解对方，而经理带回项目交给开发团队也并不是能够完全的满足顾客的想法。因为顾客经常也不知道他们想要的是什么，他们也知识靠想象来尝试，这无疑给一个开发团队带来了无穷的潜在茅盾。
《我们应当怎样做需求分析》这一文章，做好软件需求调研从这几方面入手。首先是做需求调研，就是采集需求这个阶段，在这个阶段其实是一个反复迭代的过程：需求捕获——需求整理——需求验证——再需求捕获。
需求的捕获有个初始阶段，然后我们还不要不断的接触客户沟通，了解客户的变化并且了解客户的目的自己理性的分析客户到底要什么。接下来我们开发团队要不断的与客户开展研讨会，跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”以及客户现有的业务流程。在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。
需求的整理也就是需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图。用例分析的过程，之所以称之为分析，它掺入了很多需求分析人员对业务的理解与设计：模块如何划分、流程如何设计、业务如何转换，等等。
需求的验证即当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确。但是需求的验证也不是此时才开始而是从始至终的因为我们是一个服务行业，顾客的需求的是不断变化，我们得到的的需求也不断有细微变化。在开发过程中不断的与顾客交流这样客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小，不会浪费不必要的劳动。
最后便是双方在需求规格说明书的签字了。这也是需求确认书，双方达成一致。但这也并不以为，后面所有的工作都一次为标杆开展。需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。但是这种需求的变化是可见的听不会随意的变化而是只发生在某些固定的范围内，弄清楚了这些范围，我们的问题就迎刃而解了。
