读后感---我们应当怎样做需求分析

　　

　　阅读了《我们应当怎样做需求分析》这篇博客，开头的几个故事都给了我很大的触动。让我明白了一款软件制作成功的不容易，最重要的还是软件需求分析，它决定了一个软件的走向，而需求分析也需要学习很多东西。

　　我觉得我需要掌握以下内容：

　　一、需求调研：很多需求分析的工作是从需求调研开始的，需求调研是需求分析最重要的一环。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。

• 初识：与客户进行交流，并对他们所说的进行分析并提出自己的见解，给客户留下的印象对我们也十分重要。对于一个系统中各个角色的需求要划分清楚并弄清他们的需求。最后也得为软件制定好目标。
• 拜访：确定好各个角色后，要一个一个去拜访他们，展开我们的需求调研。经过交往，在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
• 研讨会：业务研讨会没有有一个定式，它重要，但又灵活。需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
• 需求研讨：我们做需求分析，眼界不能仅仅停留在软件本身，应当扩展到跟这个业务有关的那些领域知识中。需求分析是建立在在大量业务分析与技术可行性分析基础上的分析活动上的。
• 迭代：我们在需求分析阶段，总是重复着一个循环过程：需求捕获->需求整理->需求验证->再需求捕获。我们需要不断的去理解更多更多的客户的意思，使用户更加满意。
• 需求捕获：我们要学会主动去捕获客户的需求，不是单纯的听与记。学习了解有关的行业知识，用相关知识和用户交流得到需求，甚至可以提出合理化建议。

 　　二、需求分析：对调研得到的需求进行一步步分析、细化，得到系统所需要的功能。

• 功能角色分析和用例图：按照各个使用系统的角色所需要的功能进行分析，分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。还有就是绘制UML用例图（三个要素：参与者、用例、系统边界），可以用简单的图形绘制一个系统的整体轮廓。
• 业务流程分析：我们进行流程分析，要分析哪些是系统操作的，哪些是人工操作的。清除低效环节，简化业务瓶颈，整合可用资源，自动化繁重操作。
• 用例说明：描述用例，列出用例名称、用例描述、参与者、前置条件、事件流、后置条件等。
• 查询报表分析：对数据操作的表格展示。
• 子用例与扩展用例：复用性，扩展，高内聚低耦合。
• 行动图和状态图：用图形描述流程。
• 业务领域分析：对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。
• 原文分析法：在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。
• 领域驱动设计：有效建模、统一语言和持续学习。
• 非功能需求：可用性、可靠性、性能、可支持性以及其它。

　　三、需求确认：确认系统需要实现的功能。

• 需求列表：不论我们如何分析与设计，我们都要如实记录原始的需求，并以此来验证我们最终的软件。这个如实记录原始需求的文档，就是需求列表。它不掺杂我们对业务需求的任何分析与设计；它是站在业务人员的视角，对业务需求的简明扼要的描述；需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
• 快速原型法：我们就应当在需求分析阶段拿出实物，用实物与用户确认需求。这样就可以与用户验证想法，找出修改的部分。
• 需求规格说明书：分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。

　　以上就是我读的要学习的一些内容。