怎样做需求分析读后感
当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角 度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合 理的方式去操作与管理。
一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份 体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
初识的时候，文章给了我们一些建议
1） 树立良好的职业威信；
2） 进行详细 角色分析，将与会各方代表对号入座；3）
3） 从宏观上制订目标与方案。随后 的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一 步进行下去。
拜访
不能总是期望客户中的所有人都能与我们合作，很多项目 都不可避免地存在阻碍项目开展的人
在客户中找到一批人，可以解答困扰我们多时的业务问题之后，如何以合适的时间、合适的地点、通过合适的形式与客户研讨业务需求，是摆在项目经理面前的一道难题。
需求研讨
们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些， 应当扩展到跟这个业务有关的那些领域知识中。
我们学习领域知识是为了更好地理解和开 发软件，是学习与这个软件有关的领域知识，而不是成为一个专家。
与业务实现有关的需求都是无效的需求， 它们仅仅只能作为我们的一个参考。
迭代
需求分析不是一蹴而就的，是一个反 复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。
需求捕获
需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际 交往、沟通、知识理解，以及心理学等一系列问题。
是采用主动态度去捕获需求，还是采用被动的态度去 捕获需求。如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。客 户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求， 而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分 析地就直接扔给了开发人员。这就是采用被动的态度去捕获业务需求的方 式。毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险。
客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。针对这些问题，迭代式的需求分析与开发就出现了。我们先用最短的时间先做一个可以展示和操作的原型给客户看，让客户 提一些意见。然后我们再在这个原型的基础上再多做一些，再给客户看。我们就这样一步一步推进，直到最终项目研发结束。
功能角色分析与用例图
有人说，我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图， 辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有 将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。
用例说明
许多软 件最终失败的非常重要的原因就是对需求分析过于草率、浮于表面，而没有 深入细致地去分析，往往到了项目后期才把需求搞懂，才发现真正的需求与 起初的认识大相径庭，才恍然大悟需求原来是这样，而往往那时已经追悔莫 及了。这样的经历相信你也有过吧。所以，我们一定要沉下气来认真仔细地 做需求分析，一定要做到位。
用例说明
做用例分析首先是要绘制出用例图（前面已经说过了）。图形的 最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多 的细节信息，因此我们必须要对它进行进一步的文字描述。
