阅读了《我们应当怎么做需求分析》之后，了解了很多。
1.需求调研 需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。初识：首先和对方认识，树立良好的职业威信；不能唯命是从，顾客就是上帝，一切都要服从上帝，这样是不现实的，唯唯诺诺的话会让顾客提出很多不合理，无法完成的目标。最后只能是我们累还完成不了，顾客还不满意，进行详细角色分析，将与会各方代表对号入座；有什么需求就跟什么部门谈，每个部门的需求是不一样的。要将每个部门的对号入座，这样谈起来就会很轻松，从宏观上制订目标与方案。
随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。逐一拜访每个，给客户留下好的印象。之后自己碰到的问题可以问一问这些客户。
之后开研讨会。将项目负责人以及客户代表聚到一起开需求研讨会是非常重要的，在研讨会上可以详细地对项目进行需求分析，将客户聚到一起一方面可以将各个部门的客户的需求统一化，避免每个部门的需求不一致，导致项目需要开发很多的版本，导致项目太大开发困难而且不容易维护；另一方面可以将各个部门的需求进行分析，取长补短，从而制定一个好的项目。
之后需求研讨，就是与客户进行软件功能需求的讨论，不同的客户对我们专业的了解程度不同，所以对于软件本提出功能需求的能力不同，对于开发不了解，有的人提出的问题是无法解决的 ，碰到这些，我们没有办法解决的情况下，我们就要努力的说服客服接受我们的方案。
需求捕获是很有必要的，需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。我们不能只是被动等待顾客放映，我们应主动地从客户那里捕获需求，不能被动地捕获，这样可以有效地分析客户业务的详细流程，了解由谁来操作，并了解为什么要这样操作，深入地了解这些领域和知识，另外因为我们对客户的业务不熟悉，我们要主动地对客户进行询问，深入明确地了解用户的需求和业务流程。大多数客户对于软件开发并不专业，所以很有可能会遗漏一些东西，需求人员应该深入分析客户的需求，提出客户遗漏的东西，使需求更接近与客户真正的需求。
2.需求分析：需求调研与需求分析工作应当是相辅相伴共同进行的。
功能角色分析和用例图：我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。用例图是提供给客户看的，所以不应该出现技术性较强的表达方式，应该用客户易懂的词语进行功能描述，从而让客户了解我们了解到的需求，并提出修改意见。业务流程分析：，对于软件来说是模仿企业的整个业务流程，所以我们必须熟悉企业的整个业务流程并且分析在这个流程中我们可以做些什么，业务流程分析就是分析业务流程中哪些需要信息化管理，哪些不需要，哪些我们能做到，哪些我们做不到。因为如果信息化过细，只会加重人们工作的负担，这就背离了我们做软件的初衷。
用例说明：在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，所以我们需要有一些文字的描述，就是用例说明。
查询业务分析：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。
子用例和拓展用例在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合
业务领域分析：在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。
需求列表：它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。在开始因为没有实物，客户往往描述不清楚自己的确切需求，所以需求往往不明确，我们应该根据用户的初步需求利用快速原型法快速构建出一个实物供用户参考，然后再让用户提出更深一层次的需求，从而不断地深化、细化需求，从而使用户的需求都展现给需求人员需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
