阅读笔记—我们应当怎样做需求分析
阅读博客“我们应当怎样做需求分析”中几个真实的故事，对用户需求分析有了新的理解。
故事一中，由于不知道客户怎样才会满意，所以一遍一遍的去试，导致变更过程变得越来越多，越来越复杂；这里应该去深入了解客户真正的需求，去理解他问什么提出这样或者那样的想法，这样能了解各个需求背后的目的，想实现的东西。而不是凭借着自己的想法去更改，这样不仅可以使程序员的工作量大大减少，也能使得软件更加符合用户的真正需求。
故事二中，学到了不能用户说一就是一，因为有时可能在他看来很小的区别或者很小的变化可能会造成程序上巨大的变化；也有可能用户提出的想法技术上根本不能实现，所以应该引导着不了解技术的用户按照更加合理的方式去操作与管理。
第三个故事讲述的主要是对于集团的客户（相对较庞大），会有多种角色；而不同角色会有不同的需求，那么在形式化的需求大会上，很多基层人员是无法直接清楚表达自己的想法的，这也就造成的需求大会形同虚设，起不到需求分析的作用，很多细节的业务根本考虑不到，最后系统软件的效果也可想而知。
第四个故事介绍的问题普遍存在，经常会有程序员在做的差不多之后才会拿给客户看，这样很可能出现客户想大面积修改，从而导致前期的工作重头再来，事倍功半。所以，在项目开发的过程中，应该尽量频繁的向客户反馈，争取在每一个模块初期就将需要修改的问题了解清楚，就不会造成较大的偏差，提高效率。
结合博客内容加以总结，对于软件需求分析需要掌握整体流程以及对于捕获的需求所进行的分析与确认。
整体流程：
初识部分即为对集团各类人员的分类：
1、高层领导
高层领导关心的是宏观的目标，不需要与他们谈细枝末节。
2、中层领导
中层领导关心的是具体的效益，但一般不关心一些具体的操作，以及一些具体业务流程的细节。
3、基层人员
基层人员是每一项业务流程的操作者，即使用者。他们关心的则是每项操作的细节。
对于所捕获的需求需进行①分析②确认
①分析：
1、功能角色与用例图：需求调研与需求分析工作应当是相辅相伴共同进行的。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。
2、子用例与扩展用例：这个用例应当是抽象的，没有自己的参与者，只有在调用它的用例中，才能真正明确它的使用者。
3、用例说明：在面向对象的时代，通过绘制行动图、状态图，以及编写用例说明来完成业务流程分析工作。
4、行动图和状态图：行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图；在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。
5、业务流程：将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。首先，我们应当抛开软件实现，对这样一个流程进行梳理，然后，在对原始需求分析的基础上，分析我们的软件能做什么事，最后，企业信息化就是一次改革，这特别集中地体现在了业务流程分析这一部分。
6、业务领域分析：业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。
7、原文分析法：原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。
8、领域驱动设计：对领域知识认识越深，软件就越完善。
9、查询报表分析：报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型等。
10、非功能需求：非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面。
②确认：
1、需求列表（提供一个实例）：需求分析是一个我们与客户不断沟通的过程，这个过程就如同我们与老板的一次对话。
2、快速原型法：快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。
3、需求规格说明书：需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。
4、评审与签字确认会：即为最后阶段，进行签字、评审等工作。
