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