软件需求分析阅读笔记

本学期开设了软件需求与分析这门课程，但其实需求一词对我们来说都不陌生，在软件工程概论中，就已经介绍到需求，但是没有进行系统的分析。这篇博客主要是来谈一谈在软件需求与分析中需要掌握的内容，这样有助于理清这门课程的整体脉络，对需求分析有基本的了解

一、我们应当怎么做需求调研

      1.1把握正确姿态，理解客户需求

         在与客户进行沟通时，不能一味地唯唯诺诺的听取，对客户提出的要求不假思索地满口答应，这样往往会因为需求不合理导致工程项目最终失败。正确的态度是对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。我们应该站在与客户同等的角度上，针对需求，仔细讨论，分析其可行性。同时分别与不同部门，不同层级的领导讨论。

      1.2与客户建立长期有好的关系

         这一部分其实主要是依靠自己的情商，学会如何与人打交道，同时要通过自己扎实的专业能力，获取客户的信任，这样会在更有利于项目的进行。

1.3与客户建立长期友好的关系

         需求调查时，公司会由于多不同的管理形态，如果公司员工都在一起，可以采用集中式的业务研讨形式；如果公司办公较分散，应采用分散式的业务研讨形式。业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。

1.4合理地进行需求研讨

   在需求分析过程中，客户存在的最大问题就是提不出正确的需求，因此，我在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。

1.5迭代进行需求分析

需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。

1.6捕获需求

   需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程

二、我们应当怎么做需求分析

2.1功能角色与用例图

对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。

2.2业务流程分析

形成对系统的整体轮廓，对于软件的需求分析来说是远远不够的。许多软件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有深入细致地去分析。在现实世界中，企业是按照怎样的流程来管理，我们的软件就应当去模拟这样的流程。我们进行流程分析，就是要求分析哪些是系统之内的，哪些是系统之外的。

2.3用例说明

用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。同时，这部分还可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。通过用例描述，阅读者可以对该用例有一个整体的认识。

2.4查询报表分析

对于有些功能来说总感觉不对劲，感觉不对劲的，就是那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。而许多需求分析人员没有认识到这一点，这往往导致对查询报表的分析不到位，为项目的研发带来风险。

2.5子用例与扩展用例

在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程。将这部分流程提取出来形成的就是子用例。子用例应当是在逻辑上相对独立的一系统流程组成的用例。另外，在用例中还存在许多扩展流和异常流。当系统在运行到基本流程中某个步骤时，由于满足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。

2.6行动图和状态图

行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。

2.7业务领域分析

业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。

2.8原文分析法

原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中的名词。其次，系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。另外一个非常重要、值得我们着重关注的地方是名词的多义性。

2.9领域驱动分析

在领域驱动设计思想中，有许多是涉及到需求分析领域的先进方法，可以把它归纳为有效建模、统一语言和持续学习。

2.10非功能需求

需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。

三、我们应当怎么做需求确认

  3.1需求列表

需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。

3.2快速原型法

快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。

3.3评审与签字确认会

外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。