看了王老师推荐的博客，大体对软件需求分析这门课程或者称之为技能有了大致了解，接下来我就说说我的读后感和这学期关于这门课的知识点，然后附上关系图。
首先是针对三个故事的感悟：
①当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
②作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
③一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
接下来就是对这门课程的初识和个人的一些理解。
首先，软件需求分析，既然有需求，那肯定就有需求的人，也就是客户。要想知道客户的需求，首当其冲的就是沟通能力，如何从客户的口中得知客户的真正需求，如何了解项目的目标，这就需要需求调研，需要与一个企业的各层领导乃至下层员工进行必要的沟通与交流。所以，沟通能力在软件需求分析中应该是很重要的一项能力。从博客中我学到了三点：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
其次，软件需求分析，也需要我们从客户中结识一批一些能够帮助我们的人。通过他们，我们可以向他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
然后就是需求调研，这里就需要研讨会和迭代。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
在下面就是一些技术层面的，业务流程分析和各种图的绘制以及说明。最开始就是功能角色分析和用例图，功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。然后就是业务流程分析，接着就是用例说明。当然，还有查询报表分析，子用例和扩展用例，这些都是属于用例图这一类的。然后就是行动图和状态图，在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。然后就是业务领域分析，这里包括原文分析法和领域需求设计。然后就是非功能需求和需求列表，当这些都做完了后，就可以写需求规格说明书了。最后就是评审与签字确认会。需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。。
以上就是大体的软件需求分析的全部流程。下面是我绘制的各个过程之间的关联关系。
