《咱们应当怎样作需求分析》阅读笔记

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

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

通过阅读与思考，我认为如下内容咱们须要掌握的：

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

（1）开研讨会捕获需求

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

（2）学会需求捕获

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

（3）功能角色分析

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

（4）业务流程分析

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

（5）业务领域分析

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

（6）挖掘非功能需求

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

（7）作好需求列表

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

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

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

图示：