《我们应当怎样做需求分析》阅读笔记
通过阅读此篇博客，我觉得这学期《软件需求与分析》我们需要掌握的内容就如书中作者介绍的每部分内容：初识，拜访，研讨会，需求研讨，迭代，需求捕获，功能角色分析与用例图，业务流程分析，用例说明，查询报表分析，子用例与扩展用例，行动图与状态图，业务领域分析，原文分析法，领域驱动设计，非功能需求，需求列表，快速原型法，需求规格说明书，评审与签字确认会。
当然博主的水平要比我高出很多，所以这篇博文很多内容我都不理解，但这篇博文对我们应当怎样做需求分析还是给出了很详细的解答，对我的帮助也是很大的。首先初识，我们要与客户保持适当的谦卑，因为第一印象很重要吗，但当客户提出的需求不合理时，我们不能一味服从，但我们也不能态度明确的否定，最好的解决办法则是提出自己更加合理的方案。同时对于不同角色的客户我们要清楚他们对于软件的需求是不同的，我们必须了解每个阶层客户对软件功能的着重点。
拜访，则是分别去拜访软件的用户，当然开始是要搞好感情，然后再展开调研，看看他们的工作流程以及对软件的功能需求，同时还要为了以后工作更好的展开，拉拢可以合作的人，弄清会阻碍我们项目进展的人。
研讨会，就是将各个阶层的用户代表聚集在一起，提出他们各自的业务需求，并且对于有差异的业务需求做出一个确定的管理模式，我们的软件就是要规范各分支机构的管理，抑制个性化差异。
需求研讨，就是与客户进行软件功能需求的讨论，不同的客户对我们专业的了解程度不同，所以对于软件本提出功能需求的能力不同。对于不了解我们专业的客户我们不应该只停滞在他们提出的需求，更加要去挖掘客户没有提出但必须有的功能。而对于了解我们专业的客户经常会提出比较全面的功能需求，但他们往往要求太多而且不是最优的解决方案，此时我们就需要耐心说服客户接受我们的方案。
迭代，应该就是在项目实施中多次进行需求捕获与需求整理，需求验证的过程吧，需求整理的同时要将用例多次细化，每次对客户需求的多理解一些。
需求捕获，为了软件产品更好的满足客户要求，我们必须尽可能准确的捕获客户的需求，当然有些需求客户可以想到并且提出，但我们也要挖掘出那些客户应该提出但没有想到的功能需求。当然对于客户提出的变态的，技术难于实现的，我们需求分析员不能盲目地去记录。为了更好的了解客户的需求，很多时候我们都要去涉足客户的专业领域，当然这不是要求我们成为相关领域的专业人士，我们只要知道一些基本信息就可以了。
功能角色分析与用例图，当完成需求捕获后，我们就要对捕获的信息进行分析，对系统中每个功能和角色进行梳理和分析，对于系统应有的功能，角色以及每个角色应该具备的操作权限，都要进行准确的定位，当然用例图是最适合表示这些信息的工具，但我们要记得尽量使用客户看的懂的语言。
业务流程分析，对于软件来说是模仿企业的整个业务流程，所以我们必须熟悉企业的整个业务流程并且分析在这个流程中我们可以做些什么，业务流程分析就是分析业务流程中哪些需要信息化管理，哪些不需要，哪些我们能做到，哪些我们做不到。因为如果信息化过细，只会加重人们工作的负担，这就背离了我们做软件的初衷。
用例说明，即是用图的形式尽可能的对每个用例进行全面的分析，使每个用例更加形象可观，避免遗漏细节。
查询报表分析，通过数据揭示一些客观规律，复杂活动与发展趋势，方便领导对员工工作进程的了解以及对员工的管理。
子用例与扩展用例，子用例，逻辑上相对独立的一系统流程组成的用例；扩展用例，对于异常流和扩展流建造的用例，对他们的分析和利用，能够提高系统的内聚降低系统的耦合。
行动图和状态图，都是对用例整个流程的形象化。
业务领域分析，就是对每个用户的业务领域，业务流程进行分析，只有更好的了解了每个用户的工作内容，才能更好的根据需要开发相应的功能。
原文分析法，领域驱动设计， 两种业务领域分析的方法。对于这两种方法我不是很理解。
非功能需求，更加靠近的是技术，是设计，是实现，是架构师关注的内容，作者将它分为五个方面，可用性可靠性，性能，可支持性以及其他，我想这就已经很详细了。
需求列表，是最原始的，用户对业务需求的描述。
快速原型法，我的理解是尽量快的按照用户最初对功能需求的描述，开发出一个软件的雏形，并且在以后的开发中不断让用户体验，提出要求。
需求规格说明书，全面需求信息以及开发信息的相关文档。