通过阅读博客《我们应当怎样做需求分析》，我明白了在大二下半学期中我们“软件需求与分析”这门课需要掌握哪些内容。我总结出来做好软件需求分析需求从这几方面入手。首先是做需求调研，就是采集需求这个阶段，在这个阶段其实是一个反复循环的过程：需求捕获、需求整理、需求验证、再需求捕获......；在每一次做完需求调研后就要做一次需求分析，并且等到下一次去做需求调研时，我们应该首先将上一次的需求分析结果与客户进行确认。然而在每次的需求分析阶段其实也是一个比较复杂的分析过程，我们需求画大量的UML图，对角色功能进行分析，对业务流程进行分析等。最后我们还需要做好需求确认工作，写好需求规格说明书然后评审签字确认。
首先，我们要学会捕获需求。整个需求分析过程是一个迭代的过程，在需求捕获这个阶段，往往不是考验我们的专业知识，而是涉及人际交往，沟通理解等方面。如果学会了如何捕获客户的需求，那我们的项目成功的概率就会得到质的飞跃。在学会捕获需求之前我们要清楚的认识到软件需求不仅仅是客户嘴里说出来的。还有两类需求需要我们自己去发现：一是客户嘴里没有说的需求，二是客户压根没有想到的需求。知道这些后如果我们不能更好的处理与客户交流的方式，那一切都是百搭，在与客户讨论需求过程中，态度决定一切，既不能让自己处于被动状态，对客户提出的所有需求都记下来然后不加分析地给开发人员；也不能盲目主动，不分析客户的需求，按照自己的想法来，最后交付的时候客户说这不是自己想要的软件。
其次，我们要学会对功能角色进行分析，所谓的功能角色分析就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底提供给那些角色使用。而对一个系统进行功能和角色方面的梳理和分析，可以采用画用例图的方法。运用这种方法对业务需求进行分析、抽象、整理、提炼进而形成用例模型。我们在画用例图的过程中不能以一个开发者的角色来绘制，许多描述信息也绝不能按照开发者的思维和习惯去写，而是要贴近客户，因为用例图的视角是用户。所以描述信息应该迎合用户平时的习惯用语。
业务流程分析同样是我们需要掌握的内容。文章作者在这一章中用了许多例子来说明问题，在分析ERP对企业流程改进的例子中，作者分析出来的思路是清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。计算机信息化管理并不是万能的，它并不能代替现实世界中的所有工作。因此我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。
然后就是业务领域分析。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。什么叫业务领域，就是客户所在的知识领域，譬如财务人员所在的是财务领域，税务人员所在的是税务领域。不同的知识领域拥有各自不同的领域知识，需求分析人员就应该通过客户中的领域专家去学习这些知识、掌握这些要点，并最终体现在我们的需求分析中。
需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。 首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。在需求列表中应当剔除那些客户对系统设计的内容。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
最后，我们要学会书写需求规格说明书，要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达大家都清楚明白的概念 。我们不能拿着用户编写的原始需求就开始开发，只有依据自己的公司、项目、特别是需求分析中采用的方法，写出一份既是从用户角度描述的系统业务需求说明书，又是一份指导开发人员完成设计与开发的技术性文档。
