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

　　在软件开发中，软件需求分析是至关重要的一个环节。而过去我只知道其重要性，并不知道如何去做需求分析，只是简单的认为我们只要与客户充分沟通了解其真正需求即可，在读了fangang的博客我们应当怎样做需求分析后才意识到软件需求分析并不那么简单，软件需求分析更是作为软件工程专业的一门学科，需要深入学习，掌握科学恰当方法才能把需求分析做好，从而避免软件项目开发的失败。如作者在文章中与我们分享的项目失败经历，皆因需求问题所致，于是作者向我们给出我们详细介绍了需求分析的方法。

　　首先，需求调研是需求分析的第一步，在项目开始时，应树立自己的职业威信，千万不能被客户牵着鼻子走，应深入理解客户的业务，向其提出更好的解决方案。进行详细的角色分析，将与会各方代表对号入座，对于高层领导，应从宏观角度讨论项目各个方面，中层领导关心的则是功能的定义、业务流转的衔接、查询报表的设计，基层人员是软件的真正使用者，然而他们大多视野范围较小，往往只了解与自己工作相关的一部分，因此要努力寻找那些业务涉及面广经验丰富的专家，让他们参加，对软件做出明确需求。

　　需求分析不是一蹴而就的，而是一个反复迭代的过程，贯穿了整个项目开发周期，是一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获……不断与客户进行交流确认，才能确保需求的准确性。

　　需求捕获是整个迭代过程的开始，却是我们进行需求分析最薄弱的地方。许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。

　　在需求捕获中，并不是完全按照客户说的来做，客户说什么就做什么的想法是完全错误的，如作者在文章中列出较难捕获的两大需求：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。客户与开发人员背景环境不同，也许有些需求在客户看来天经地义无需提及，但因为开发人员对客户的业务不了解，根本不了解那一点，到最后客户不得不对需求提出修改。这就要求在进行需求分析的整个过程，不断进行业务领域知识的学习，深刻了解客户所提出的需求，最终才能得到一份完整、准确的需求。另一类是客户也没想到的需求，因为客户对软件并不了解，其对软件产品最终形态在先前并不知晓，也无法用专业知识想开发人员描述，所以在产品成形之后，有了一个软件实体之后，客户便才意识到其他相关需求，要求做出更改。面对这一问题，需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。

　　我们对需求的分析，首先应当从功能角色分析开始。所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。

　　对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。用例是一个场景。在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。

《软件需求与分析》需要掌握必要的内容：

　　需求获取：需求获取就是进行需求收集的一个活动，它从人员、资料和环境中得到系统开发所需要的相关信息。需求获取绝不完全来自于用户口中，还要开发者努力去发掘。

　　需求分析：需求分析就是用来解决需求获取得到的信息和需求开发应建立的软件系统解决方案之间的差距的需求工程活动。

　　需求规格说明：需求规格说明活动就是将需求及其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。

　　需求验证：需求验证就是在需求工程中发生的验证活动，它的主要手段是静态分析。

　　需求管理：需求管理是在需求开发结束后保证后续的系统开发活动依照需求的基线进行展开，从而保障系统的质量的管理活动。