一、阅读我们应当怎样做需求分析的感悟。(原文博客地址http://blog.csdn.net/yqmfly/article/details/7679781）
这学期的《软件需求与分析》课是软件工程专业比较重要的一门课。如何做好软件需求分析直接影响到整个项目的成功与否。了解业务，即客户的具体要求就显得至关重要。但做不出客户满意的成果项目又是失败的，而往往客户不清楚自己最终想要的到底是什么，这就要我们有足够的实力让客户信服，这样才能让客户尽可能认同，不至于被客户牵着鼻子走。
近来通过阅读我们应当怎样做需求分析等文章，我总结出来做好软件需求分析需求入手的几个方面：首先最重要的是做需求调研，在这个阶段其实是一个反复循环的过程：需求捕获---需求整理---需求验证---再需求捕获，在每一次做完需求调研后就要做一次需求分析，并且等到下一次去做需求调研时，我们应该首先将上一次的需求分析结果与客户进行确认。然而在每次的需求分析阶段其实也是一个比较复杂的分析过程，我们需求画大量的UML图（例如用例图），对角色功能进行分析，对业务流程进行分析等。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。最后我们还需要做好需求确认工作，写好需求规格说明书然后评审签字确认。
二、经过阅读与思考，我认为学好需求分析需要做到以下几点：
（1）开研讨会捕获需求
我们需求获得客户的需求，必须要了解业务，要想了解业务，一是可以学习相关的知识，最有效的方法就是开业务研讨会，需求研讨会等，在会上我们不但可以更好的和客户交流整个流程，还可以讨论一些比较细节的地方。但是在组织研讨会的同时必须注意两点：有效抑制个性化差异，分模块组织专项研讨会。整个需求分析过程是一个迭代的过程，在需求捕获这个阶段，往往不是考验我们的专业知识，而是涉及人际交往，沟通理解等方面。如果学会了如何捕获客户的需求，那我们的项目成功的概率就会得到质的飞跃。在学会捕获需求之前我们要清楚的认识到软件需求不仅仅是客户嘴里说出来的。还有两类需求需要我们自己去发现：一是客户嘴里没有说的需求，二是客户压根没有想到的需求。知道这些后如果我们不能更好的处理与客户交流的方式，那一切都是百搭，在与客户讨论需求过程中，态度决定一切，既不能让自己处于被动状态，对客户提出的所有需求都记下来然后不加分析地给开发人员；也不能盲目主动，不分析客户的需求，按照自己的想法来，最后交付的时候客户说这不是自己想要的软件。最明智的做法是先跟客户谈业务，先谈论业务流程，在此阶段我们还要多问为什么，这样可以让我们深入地了解这些领域的知识，站在客户的角度去思考问题，进而能够深入理解客户为什么要提出他们的那些业务需求。
（2）功能角色分析
当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来后我们就要对需求进行行之有效的分析，而这种分析首先应当从功能角色分析开始，所谓的功能角色分析就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底提供给那些角色使用。而对一个系统进行功能和角色方面的梳理和分析，可以采用画用例图的方法。运用这种方法对业务需求进行分析、抽象、整理、提炼进而形成用例模型。
我们在画用例图的过程中不能以一个开发者的角色来绘制，许多描述信息也绝不能按照开发者的思维和习惯去写，而是要贴近客户，因为用例图的视角是用户。所以描述信息应该迎合用户平时的习惯用语。
（3）业务流程分析
做好角色分析后，最重要的一步就是要做好业务流程分析。文章作者在这一章中用了许多例子来说明问题，在分析ERP对企业流程改进的例子中，作者分析出来的思路是清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。计算机信息化管理并不是万能的，它并不能代替现实世界中的所有工作。因此我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。
（4）业务领域分析
在需求分析工作中，最后一项分析工作就是业务领域分析。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。不同的知识领域拥有各自不同的领域知识，需求分析人员就应该通过客户中的领域专家去学习这些知识、掌握这些要点，并最终体现在我们的需求分析中。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。其中，我们可以通过两种分析方法进行分析：原文分析法和领域驱动设计。过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。
（5）非功能需求的挖掘
非功能需求又称“约束”，它主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等。需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。 非功能需求可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。
（6）需求列表
需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。 首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。在需求列表中应当剔除那些客户对系统设计的内容。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
（7）需求规格说明书
我们之所以要编写需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。这就是需求规格说明书的重要性。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达大家都清楚明白的概念 。我们不能拿着用户编写的原始需求就开始开发，只有依据自己的公司、项目、特别是需求分析中采用的方法，写出一份既是从用户角度描述的系统业务需求说明书，又是一份指导开发人员完成设计与开发的技术性文档。
需求分析过程：
