这学期我们开始学《软件需求与分析》这门课，这门课程算是软件工程专业比较重要的课程了，因为软件的需求是一个软件项目的开始，没有需求将会没有软件，但是有了需求之后，我们要做好充分地分析后才能着手开始开发项目，那么如何做好软件的需求与分析就显得尤为重要了
通过阅读《我们应该怎样做需求分析》这一博文，我总结出来做好软件需求分析一共分三步。需求调研-需求分析-需求确认三大部分，对每一个部分又有更具体的的划分，要想做好软件需求分析，就要把握好这三步！首先是做需求调研，就是采集需求这个阶段，在这个阶段其实是一个反复循环的过程：需求捕获——需求整理——需求验证——再需求捕获.，文中提到的方式有拜访等，与直接接触到相关人员和相关的利益群体面对面交谈，通过他们最直接的表达来进行的调研方式，面对直接的利益体，不可能泛泛而谈，这需要提前做好准备，因为我们可能会遇到不同的群体和领导层。他们对软件的认识和理解对不在同一层面上。交谈的内容自然也不尽相同。研讨会作为需求调研的一个重要方式之一，把同一人群或同一业务的相关人员组织到一起，以商议和探讨的方式总结出统一的要求和看法，效率会有所提升，但容易出现混乱的情况，这需要很好的组织和策划。随着时间的改变，需求不会一直不变的
需求捕获(requirement elicitation)是需求工程的主体。对于所建议的软件产品，捕获需求是一个确定和理解不同用户类的需要和限制的过程。获取用户需求位于软件需求三个层次的中间一层。业务需求决定用户需求，它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。需求捕获和分析包括对原始需求变更控制，版本控制，从需求到产品和模块的可追溯性，成品交付和产品的状态跟踪。
在每一次做完需求调研后就要做一次需求分析，需求分析包括（功能角色分析、业务流程分析、用例说明、查询报表分析、愿文分析法、领域驱动设计、非功能需求），开一个业务研讨会，采用一个比较分散的业务研讨形式，让我们作为外人来规范客户的管理模式，常常会有这样那样的不便，但这也是我们可能面对得最多的需求研讨形式。在这样的形式中，寻找一个典型范例也许可以算是一种最佳实践。当我们面对管理松散的多组织机构时，寻找一个管理规范、对我们的支持度高的分支机构，首先将他们的信息化系统建立起来，产生预期的效益，这就树立了一个范例。它的成功就会为其它分支机构带来一种精神动力和成功案例，照着做肯定不会错。这样就可以更容易地说服其它分支机构，摒弃现有的管理模式而朝着规范化管理迈进。业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护）。我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。与客户密切联系是解决客户需求的重要手段，正如敏捷开发中所要求的一样
等到下一次去做需求调研时，我们应该首先将上一次的需求分析结果与客户进行确认。然而在每次的需求分析阶段其实也是一个比较复杂的分析过程，我们需求画大量的UML图（例如用例图），对角色功能进行分析，对业务流程进行分析等。最后我们还需要做好需求确认工作，写好需求规格说明书然后评审签字确认，或许我们够不喜欢写文档说明书，只是想编写代码，但这就是我们以后工作的要求，写出一份好需求说明书让客户满意，也让我们以及满意，做好需求分析需要养成良好的习惯，这些都要生成文档，同时也是关系到软件的具体功能实现和设计。
