《软件需求与分析》阅读笔记

　首先是摘录了一些博文中的内容

　需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。

　　当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

　　必须要基于技术实现去引导客户的需求。应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

　　一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。

　　需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

　　我们应该怎样做需求分析：

　　很多需求分析的工作是从需求调研开始的，需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。第一印象很重要，要与客户多联系加深感情，以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求。在需求分析过程中，客户存在的最大问题就是提不出正确的需求，与客户讨论业务需求，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。总之，我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。

　　需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。需求捕获，就是我们与客户在一起开研讨会，讨论需求的活动。需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。然后，我们再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。领域模型，是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。采用主动态度去捕获需求要求我们在需求分析的整个过程，不断进行业务领域知识的学习。需求分析人员应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。

　　对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。用例图的视角是用户，也就是说，站在用户的角度来观察的我们需要设计的系统。绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。

　　UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言

　　做信息化管理，不是要加重人的负担，而应是降低人的负担。以这样的思路去进行流程分析才能设计出优秀的、人见人爱的管理系统出来。

　　当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。在这部分工作中，编写用例说明应当是最主要的工作

　　任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。

　　在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。业务领域分析不仅出现在需求分析阶段，还应当贯穿与设计阶段、开发阶段、测试阶段，甚至延续到后期的维护与升级。进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。

　　需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。需求分析是一个撒大网的过程，而不是姜太公钓鱼的过程。功能需求固然重要，非功能需求同样重要。我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。

　　不论我们如何分析与设计，我们都要如实记录原始的需求，并以此来验证我们最终的软件。这个如实记录原始需求的文档，就是需求列表。需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。

　　首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。然而，需求列表中应当剔除那些客户对系统设计的内容。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。

　　在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。

　　编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。

 

　　综上，我认为我们所需要掌握理论知识，就是上学期刘老师所讲的UML统一建模语言，除此之外，就是出色的人际交往能力，语言的魅力，如何让人信服自己的能力！