一，文字描述
刚刚读了《我们应当怎样做需求分析》，这篇文章对我的启发很大。
确实，这几年的信息行业发展十分迅速，出现的新语言新技术越来越多，所以这就需要我们学习越来越多的知识来适应这变化着的世界。
首先作者通过几个例子来介绍在软件制作过程中出现的很多的问题。
首先提出在设计，技术，时间管理，人员培养，客户关系过程中出现的问题，其根源都是需求的的问题。我十分同意这个观点。因为确定需求是软件制作的前提，所有的程序以及数据库的设计都得以这个为基础，所以是一切问题的根源，所以做好需求分析十分的重要。
作者的第一个问题是客户在软件制作过程中总是进行业务变更，这就需要与客户交流，理解客户意思，然后从业务角度深入分析，提出更合理的方案。这里面同时包含着一个与人际交流的问题，这就需要我们在社会上多多与人交流，以此来提升自己的这项技能。
第二个问题是客户提出的要求不可能实现，这个时候我们就不能对用户满口答应了，毕竟术业有专攻，不可能每个客户都了解信息技术有关的知识，这就需要我们理解管理模式，站在信息化角度审视他们是否合理，从而引导他们以更合理的方式操作与管理。
第三个问题是没认真分析清楚所有人的需求，这个时候就需要进行角色分析，对不同角色分别调研（初期召开项目动员大会）。
第四个问题是分析，设计，开发，测试，十分顺利，最后阶段客户不满意，这就需要我们提早给客户看，让客户看到问题的存在并且自己及时改正，避免等到软件成型后再进行整个程序的大改动。
然后详细地介绍了我们应当怎样做需求调研：拜访：这一步是给客户的第一印象，所以需要提前做好准备，然后必须具有一定的交流能力，这样才能放心地把项目交付给我们的团队。
研讨会：研讨会很重要，他可以把整个团队的进行步骤确定下来，让团队有一个共同的努力方向。
需求研讨：这也是很关键的一步，因为它可以确定我们用户的需求，来帮助团队更好的理解自己的工作。
迭代：需求分析是一个逐渐深入的过程，每每更深入才能使用户更满意。
需求捕捉：在前期准确地捕捉到客户的需求，才能领导好一个团队，让团队有一个正确的方向，不至于让客户不满意。
然后是需求分析需要具备的技能：功能分析与用例图：用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的 蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
业务流程分析：业务流程分析是对业务功能分析的进一步细化，从而得到业务流程图的方法，即TFD （Transaction Flow Diagram ），是一个反映企业业务处理过程的“流水帐本”。
用例说明：是从用例模型到分析模型的过程，是需求与设计之间的桥梁。用例分析把系统的行为分配给分析类，让分析类交互完成系统的行为。
查询报表分析：报表分析是基于报表的一种财务分析，主要提供对资产负债表、利润表的分析。报表分析的常用方法有比率分析法、比较分析法、趋势分析法和结构分析法，分析结果可以文字、数值、图形等多种形式输出。
子用例与扩展用例：用例模型作为uml中4+1视图中非常重要的一员，非常集中地体现了面向对象的分析与设计思想。
行动图与状态图：行动图比较类似于我们过去绘制的流程图，状态图是对关键对象中流程中状态变化的描述。
业务领域分析：业务分析是一系列短期战略与战术协议。它可以为组织提供快速的评估和路线图，帮助组织识别机遇和规划转型路径以实现其分析举措和目标。业务分析可以通过分析，帮助组织开启实现价值和竞争优势的新途径。
原文分析法：从文本的表层深入到文本的深层，从而发现那些不能为普通阅读所把握的深层意义。
领域驱动设计：面向对象开发人员、系统分析人员合理地组织工作，彼此协作，有条不紊地进行复杂系统的开发，帮助建立丰富而实用的领域模型
非功能需求：非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求，包括安全性、可靠性、互操作性、健壮性等。
然后是需求确认需要具备的技能：需求列表：指用来描述某种商品的价格与需求量相互对应关系的表格。它描述了某一市场某种商品在各种不同价格下的个人需求量和市场需求量的变化状况。
一个需求列表的实例
快速原型法：一种基于离散和堆积原理的崭新制造技术。它将零件的CAD模型按一定方式离散，成为可加工的离散面、离散线和离散点，而后采用物理或化学手段，将这些离散的面、线段和点堆积而成零件形状
需求规格说明书：是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等
评审与签字确认会
二，图像表示
