在阅读《我们应当怎么做需求分析》这篇文章后，我了解到了许多有关软件需求的相关知识与内容。
文中主要说了三项重要的内容，分别是需求调研、需求分析以及需求确认。而我恰好也觉得这些就是本学期《软件需求与分析》所需要掌握的内容。
一．需求调研
1.初识
在参加客户的见面会时，保持一定的谦卑是必要的，我理解为要有自己的“气场”，过分的谦卑可能会给客户一种上帝的感觉，他们可能会想用非技术手段能够实现的方法来强制要求用技术手段来实现，最后导致效果不如人意。我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
2.拜访
分析一个客户人群的关系，就是在分析这个人群。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。对于领域专家，我们要真诚大方的与他们交往，互相尊重，对于对我们怀有敌意的人，我们更要坦荡，敞开心扉的与他们交往，充分表达自己的诚意。
3.研讨会
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能
称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。这样就会树立一个管理范例，统一管理机构。
4.需求研讨
做需求分析时，我们眼界不能仅仅停留在软件本身，应当更开阔一些，扩展到跟这个业务有关的那些领域知识中。需求研讨是在大量业务分析与技术可行性分析基础上的分析活动，这样才能保证需求的正确与变更的可控。我们更要有自信，在理解客户需求的基础上，提出更加完美的解决方案。
5.迭代
需求分析不是一蹴而就的，是一个反复迭代的过程，不断地进行需求捕获，再进行需求整理和需求验证，这样就会不断完善用户的真正需求，进而更加接近客户满意。
6.需求捕获
在需求捕获中，容易犯的一个错误就是态度的问题，主动态度去捕获需求比被动态度捕获需求更加的合理，适合于信息化的需求。这样最终做出来的需求分析才是完整的、准确的。
二．需求分析
1.功能角色分析与用例图
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓，用例图能够清晰明了的向客户展示我们要设计的系统。
2.业务流程分析
在功能角色分析后，整个系统的整体脉络与轮廓已经被勾画出来，我们应该根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。
3.用例说明
是指对用例图进行进一步的文字描述，其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
4.查询报表分析
一个有效的报表，展示的是一些客观规律、复杂活动与发展趋势。客户方的领导，会通过报表了解他们的工作进程、加强他们的人员管理、发现他们的管理漏洞、指导他们的战略决策。
5.子用例与扩展用例
对子用例与扩展用例的分析，从一开始就将设计中公共的、可共享的部分提取出来，提高了系统的内聚并降低了系统的耦合。
6.行动图和状态图
行动图表示的是业务流程中的一项活动，状态图是一定是对某个关键对象的状态变化的描述，并在业务的大背景下进行的。
7.业务领域分析
进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
8.原文分析法
就是对需求的原文进行分析，提取出业务领域的名词，对名词进行分析提出业务领域的实体。
9.领域驱动设计
在全新的业务领域中一点一滴深入学习，知识的不断完善就是软件的不断完善。
10.非功能需求
它是指一种潜在的、特殊的需求，如果没有考虑到，就会造成巨大的风险。
三．需求确认
1.一个需求列表的实例
它应用于用例模型，软件开发以及用户验收时，查询其中的内容来查看是否满足客户需求。
2.快速原型法
是在捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再根据新的需求开发新的原型的方法。
3.需求规格说明书
需求规格说明书的作用体现在我们是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。
4.评审与签字确认会
主要目的就是确认需求，以便以此开始我们的设计开发工作。是需求分析的最后收尾阶段。
关联关系：
