从VB，PB 的开发到J2EE，.net的大型web应用，加之敏捷开发等不断提出的新概念，再到“互联网+”，国内互联网的发展可以说是十分的迅猛，软件行业的发展也是蒸蒸日上，但不同的软件也各自出现不同的问题。第一堂课上，老师也说了，软件有70%会出问题，认真剖析发现，它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题......但归根到底更多的还是需求的问题。需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。那么我们在大学期间学习这门软件需求分析的课程，应该掌握一些什么内容呢？
1）初识——很多需求分析的工作是从需求调研开始的。需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
初识，字面理解就是最初的认识，即第一印象很重要。
比如这张图，就明显表现出了初识的重要性，因为对于一个项目，不同的人理解是不同的。我们做项目是为了稳定交付，如果连内容都对不上号，那稳定交付就更谈不上了。
2）拜访——中国的社会与西方有很大不同，来往中讲究人情味儿，说道这里，我想到了电视剧《少帅》里张作霖说过的一句话“江湖是什么？江湖就是人情事故。”我们不妨理解为：搞项目是什么？搞项目就是人情世故。老师在课上也不止一次跟我们提到，我们做软件的，归根结底是在和人打交道，除了技术，你还得学会罗永浩般的忽悠。我们在拜访客户的过程中得与客户“交朋友”，慢慢去了解他需要的是什么。说白了就是先培养感情，再谈生意。
3）研讨会——如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。有经验的过来人说，业务研讨会没有一个是相同的。业务研讨形式比较容易出现的一个问题，就是将各个方面的业务代表拉过来开大会。在大会上，你说你的，我说我的，杂乱无章，一些重要的需求被不经意地漏掉。遇上这样的情形，项目经理应当有清醒的认识，我们需要再下来开小会。销售部门的需求跟销售部门谈，采购部门的需求跟采购部门谈......既然是小会，每次谈的时候人不在多，在精，参会的业务人员对自己的业务了解精细而全面。这样的会议，通常有一至三个业务人员，和一个负责人（负责拍板）参加。会议之后，我们最好询问与会人员的联系方式，便于日后建立长期的联系，毕竟业务需求不是一蹴而就的事情。同时，如果我们今后采用的是迭代式开发，他们也就成为了我们业务验证的客户代表。
4）迭代——很多时候，就连客户自己也不了解自己到底需要的是什么，也就是说，我们要帮助他了解他需要的是什么。我们做出来的alpha内部测试版本是我们了解客户需要的关键环节，第一版产品出来后，我觉得这时候我们与客户之间的交流是最有价值的，之后不断的修改，优化让产品更成熟。
5）需求捕获——前面我们讨论了，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。但更让我感到遗憾的是，在我读过的许许多多关于需求分析的书籍中，讨论需求分析与建模的书很多，但讨论需求捕获的书籍却寥寥无几。确实，要讨论这部分内容，真的已经远远超出了软件开发这个知识领域。
那么，在软件需求捕获过程中，最根本、最容易犯错的问题是什么呢？我认为是一个态度的问题，是采用主动态度去捕获需求，还是采用被动的态度去捕获需求。如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。客户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求，而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分析地就直接扔给了开发人员。这就是采用被动的态度去捕获业务需求的方式。毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险
思维导图：
