“成功的软件项目都是一样的，失败的项目却各有各的问题。我常常在想，我们的项目开发到底怎么了，进而把它们一个一个的剥开来深入分析，竟然触目惊心。它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题••••••但归根到底更多的还是需求的问题。”
我们可以体会到需求分析的重要性。
“客户对需求改来改去的真正原因是什么呢？当我们对客户的需求没有真正理解清楚时，我们做出来的东西客户必然不满意。客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。”
“不能客户怎么说软件就怎么做。”，“作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。”
“一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。”，需求分析要有正确的方法。
“需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。”
这学期需要掌握的知识点如下：
需求调研之初识
“很多需求分析的工作是从需求调研开始”
“我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。”
项目开始的时候如何着手三点建议：
1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代表建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
需求调研之拜访
与西方人不同，中国人做事往往比较重视感情，所以与客户建立良好的关系就相当的重要。
需求调研之研讨会
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
需求调研之需求研讨
需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
需求调研之迭代
需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。随后的设计开发阶段，我们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。之后，当开发进入到验收测试阶段，我们则是与客户一道，一项一项地验证我们的软件是否满足需求列表中要求的业务需求。最后，当软件迎来下一次升级开发时，我们将开启另一次轮回。
需求调研之需求捕获
从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求
需求分析之功能角色分析与用例图
需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图
用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。
需求分析之业务流程分析
我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。
需求分析之用例说明
通过用例说明对用例图进行细化说明。
需求分析之查询报表分析
没有弄清楚一个报表的真实意图，就不算真正理解了这个报表的业务需求。
需求分析之子用例与扩展用例
用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
需求分析之行动图和状态图
用例描述的事每个功能模块具体的业务功能，而行动图是描述整个系统的流程，状态图用于描述某个对象状态的变化。
需求分析之业务领域分析
业务领域分析也就成为了对系统进行的一种静态分析。
业务领域，就是客户所在的知识领域。
我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
我们可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。
需求分析之非功能需求
在需求分析的细化阶段，需求分析人员应当与架构师一起，一项一项地去分析每个功能的非功能需求，并在用例说明中记录下有特殊非功能需求的功能，使我们对非功能需求的分析落到实处。
哪些是非功能需求呢？我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。
需求确认之需求列表
通过需求列表的形式可以更加直观的看出系统有哪些需求。
需求确认之快速原型法
当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。