大二下学期刚开始，在老师的推荐下我阅读了这篇http://blog.csdn.net/yqmfly/article/details/7679781博客后，对做好软件需求分析的一些总结收获。
正如本篇博客开始举例说的案例那样，一个项目的成功失败与需求分析的准确与否有这很大的关系。因此对于一个项目来说，好的需求分析就显得
至关重要了。
首先是进行需求调研：
1.初次见面：注意在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。 我们应当客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。
2拜访：与西方人不同，中国人做事往往比较重视感情。做事先培养感情，感情培养起来才好慢慢做事。需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。而主动拜访客户是培养感情的一种不错的选择。
3研讨会：做获得一些基本需求后，召集有关各方面的代表进行研讨准确把握确定主要的需求。
4迭代：需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
5绘制用例图：将需求分析获得的材料整理，对一个系统进行功能和角色方面的梳理和分析。用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例。
6业务流程分析，也就是说要编写的软件系统大致的功能能链接起来形成完整的系统。确定每一步的开发目标。
7业务领域分析就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。用例分析，它是从整体的角度对整个系统人机交互的分析与整理。业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。但是，所有的行为，所有的操作，最终施与的对象都是那些实体。系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，是业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。软件系统，就是对现实世界的真实模拟。现实世界中的事物，在软件世界中就被模拟成一个对象。
8领域驱动设计（由于本人对此部分内容不是很理解，不在进行相应的描述）具体内容可参见https://baike.baidu.com/item/%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1/3260671?fr=aladdin
9.非功能需求：非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。在非功能需求分析中另一个非常常见的错误，就是将非功能需求仅仅归结为一些放之四海而皆准的原则，比如专门拿出一章来描述报表查询效率要怎样、系统易用性要怎样。诚然，这些原则性的东西是十分必要的，但许多非功能需求不能仅仅停留在这些基本原则上，要落实到对一个一个功能的分析中。
10.需求列表：
在需求分析中，需要不断地复述的步骤就是需求确认。需求分析与一次简单的沟通不同，她是一系列复杂的沟通过程，它涉及到许多人，谈论的是许多的事物。因此，一次简单的口头复述不足以满足需求分析的需要。因此，需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。需求规格说明书就成了我们确认需求的有效的方法。
