我们应该怎样做需求分析
通过阅读这篇博客，我觉得对于我们的软件需求分析，有了一些自己的看法和认识。
无论做什么样的需求分析，我们都应该了解到需求分析不是一蹴而就的，它应当贯穿整个周期，不断的分析确认的过程，这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此，从一开始客户诉说对软件功能的要求，到我们对软件的设计，开发，测试以及最后完成，在这个整个过程中我们都应该在每一个部分，不停地用开发的成果与客户交流，及时获得反馈。只有这样我们才能减少客户和我们对软件需求理解的偏差，确保项目成功。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，客户对你的信任度也会有很大程度的提升，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，想要做到这一点，必须要在开始交流的前期就给客户留下极好的印象才行。
我觉得有以下几点总结：
1.需求调研：
需求调研是需求分析里很重要的一个环节，根据这篇博客上可以总结出关于需求调研的四点:
<1>初识。即在一个项目启动上，要大方而得体地提出自己的意见，使客户重视你的意见，甚至主动征求你的意见。同时，不同的部门，由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。而且，纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，要与每个层次的人员都要适当的沟通，明白他们对该项目每个方面的需求。划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。
<2>拜访。分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。
<3>开研讨会。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
<4>迭代。需求分析就是按照迭代这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
<5>需求捕获。我们在需求分析的整个过程，不断进行业务领域知识的学习，采用主动态度去捕获需求，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。
2.需求分析。
<1>功能角色分析与用例图
这个运用学过的统一建模的知识，用客户易懂的词语进行功能描述，从而让客户了解我们了解到的需求，并提出修改意见。
<2>业务流程分析
我们可以用以下思路来进行我们对流程改进的分析：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。
<3>用例说明。
图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
<4>查询报表分析
报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型，等等。只要我们把这些都分析到了，我们的查询报表就分析到位了。
<5>子用例与扩展用例
我们都学过同意建模，如图所示，对项目进行子用例和扩展用例。
<6>行动图和状态图
用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
<7>业务领域分析
我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
<8>原文分析法
由于考核指标掌握着指标的定义，还有那些执法行为，所以它可以执行考核，而过错类型则掌握着过错标准，因此可以执行过错的判断。注意，这里的“执行”什么行为，是软件意义上的概念，即一个类可以拥有什么行为，而非现实世界的概念。要知道现实世界中的事物是不可能有主动执行什么操作的能力的。
<9>领域驱动设计
<10>非功能需求
非功能需求包括可用性、可靠性、性能、可支持性以及其他，非功能需求时需求人员非常容易忽略的，但是确实对软件开发非常重要的，某一方面考虑不周全，可能会导致软件的失败，例如界面不友好，性能差，支持性差等都会导致客户不想使用导致软件开发的失败。
3.需求确认。
<1>需求规格说明书。
<2>评审和签字确认会。
关联关系：