《我们应当怎样做需求分析》阅读笔记

原文链接（转载请注明出处）：如何做好需求分析

这学期的《软件需求与分析》课可以说是软件工程专业比较重要的一门课。如何做好软件需求分析就等同于如何做好一个项目。客户对需求一改再改，如果我们只是一味的去抱怨，而不去思考客户对需求更改的原因是什么，不了解业务，那我们做出来的产品肯定得不到客户的认可。
通过阅读我们应当怎样做需求分析这一系列的文章，我总结出来做好软件需求分析需求从这几方面入手。首先是做需求调研，就是采集需求这个阶段，在这个阶段其实是一个反复循环的过程：需求捕获——需求整理——需求验证——再需求捕获......；在每一次做完需求调研后就要做一次需求分析，并且等到下一次去做需求调研时，我们应该首先将上一次的需求分析结果与客户进行确认。然而在每次的需求分析阶段其实也是一个比较复杂的分析过程，我们需求画大量的UML图（例如用例图），对角色功能进行分析，对业务流程进行分析等。最后我们还需要做好需求确认工作，写好需求规格说明书然后评审签字确认。

经过阅读与思考，我认为以下内容我们需要掌握的：

许多需求分析工作都是从需求调研开始的，需求调研工作既是一份技术活更是一份体力活。它要求我们具有一种理解能力，设计能力，更要求我们具有一种与人交往与沟通的能力。

（1）开研讨会捕获需求

我们需求获得客户的需求，必须要了解业务，要想了解业务，一是可以学习相关的知识，最有效的方法就是开业务研讨会，需求研讨会等，在会上我们不但可以更好的和客户交流整个流程，还可以讨论一些比较细节的地方。但是在组织研讨会的同时必须注意两点：有效抑制个性化差异，分模块组织专项研讨会。

（2）学会需求捕获

整个需求分析过程是一个迭代的过程，在需求捕获这个阶段，往往不是考验我们的专业知识，而是涉及人际交往，沟通理解等方面。如果学会了如何捕获客户的需求，那我们的项目成功的概率就会得到质的飞跃。在学会捕获需求之前我们要清楚的认识到软件需求不仅仅是客户嘴里说出来的。还有两类需求需要我们自己去发现：一是客户嘴里没有说的需求，二是客户压根没有想到的需求。知道这些后如果我们不能更好的处理与客户交流的方式，那一切都是百搭，在与客户讨论需求过程中，态度决定一切，既不能让自己处于被动状态，对客户提出的所有需求都记下来然后不加分析地给开发人员；也不能盲目主动，不分析客户的需求，按照自己的想法来，最后交付的时候客户说这不是自己想要的软件。最明智的做法是先跟客户谈业务，先谈论业务流程，在此阶段我们还要多问为什么，这样可以让我们深入地了解这些领域的知识，站在客户的角度去思考问题，进而能够深入理解客户为什么要提出他们的那些业务需求。

（3）功能角色分析

当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来后我们就要对需求进行行之有效的分析，而这种分析首先应当从功能角色分析开始，所谓的功能角色分析就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底提供给那些角色使用。而对一个系统进行功能和角色方面的梳理和分析，可以采用画用例图的方法。运用这种方法对业务需求进行分析、抽象、整理、提炼进而形成用例模型。
我们在画用例图的过程中不能以一个开发者的角色来绘制，许多描述信息也绝不能按照开发者的思维和习惯去写，而是要贴近客户，因为用例图的视角是用户。所以描述信息应该迎合用户平时的习惯用语。

（4）业务流程分析

做好角色分析后，最重要的一步就是要做好业务流程分析。文章作者在这一章中用了许多例子来说明问题，在分析ERP对企业流程改进的例子中，作者分析出来的思路是清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。计算机信息化管理并不是万能的，它并不能代替现实世界中的所有工作。因此我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。

（5）业务领域分析

在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。什么叫业务领域，就是客户所在的知识领域，譬如财务人员所在的是财务领域，税务人员所在的是税务领域。不同的知识领域拥有各自不同的领域知识，需求分析人员就应该通过客户中的领域专家去学习这些知识、掌握这些要点，并最终体现在我们的需求分析中。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。其中，我们可以通过两种分析方法一步步进行分析：原文分析法与领域驱动设计。

（6）挖掘非功能需求

需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。 非功能需求可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。，将我们分析出来的功能中所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。

（7）做好需求列表

需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。 首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。在需求列表中应当剔除那些客户对系统设计的内容。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。

（8）写好需求规格说明书

我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达大家都清楚明白的概念 。我们不能拿着用户编写的原始需求就开始开发，只有依据自己的公司、项目、特别是需求分析中采用的方法，写出一份既是从用户角度描述的系统业务需求说明书，又是一份指导开发人员完成设计与开发的技术性文档。

图示：