阅读了《我们应该怎样做需求分析》一博，可以说这是我软件需求与分析这一课的敲门砖，给我指明了道路，让我明白应该怎样去走。
作者开始叙述了三件事：
- 东软：
a) 东软团队对一个项目进行10多次大变更，但是客户始终不满意，最终结果是团队里各成员都离开了东软，不再涉足软件行业。
b) 如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
- 作者自己：
a) 客户给了许多正在使用的统计报表，报表都是手工报表，许多格式既不规范，又很难于被计算机实现，最终没有完成。
b) 客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。他们提出的很多需求常常比较理想而不切实际，毕竟人家是非技术的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
- 重大项目：
a) 作者在接到一个重大项目，面对一个十分复杂的场景的的时候，没有充分了解到每一个角色对项目的意见和需求，导致更加细节的业务没有分析到，以失败告终
b) 真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
最终得出一个结论：需求分析是做一个项目最重要的问题。
那么如何做好需求分析呢？
需求分析主要是调研：关于调研有如下环节：
- 初识
- 拜访
（这个是项目的开端，由于项目的开始是和人打交道，所以对不同层次的人沟通方式和内容都要因人而异，下面是作者的几个建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。）
- 研讨会
- 需求研讨
5. 迭代
6. 需求捕获
（这一部分就是讲的就是项目的前期调研准备工作，我们想做一个项目，就要先知道客户想要什么样的东西，这些不是一下子就能领会到的，所以需要我们不断的领会，探讨。）
然后就是需求分析工作
1. 功能角色分析与用例图
2. 业务流程分析
3. 用例说明
4. 查询报表分析
5. 子用例与扩展用例
6. 行动图和状态图
7. 业务领域分析
8. 原文分析法
9. 领域驱动设计
10.非功能需求
为了完成项目，我们必须要做出分析。我们首先是调研，就是要了解到用户需要什么，而调研结果如何转化为我们程序员工作的需要，那就是我们进行分析的过程，我们要对我们调查到的结果整理，变成我们能看懂的，也是用户看见能理解的，这样既利于我们自己接下来的工作，也会让用户放心。
在用户分析中，最重要的一环就是需求确认：
1. 需求列表
2. 一个需求列表的实例
3. 快速原型法
4. 需求规格说明书
5. 评审与签字确认会。
接下来我将面临的是一个学期的软件需求课程，这个课程也许和上半年java+软工概论比起来要轻松一些，但是我认为涉及到的更精了。可以说我们之前接触的是如何编代码、如何处理自身问题，而现在我们的学习是如何完成一个项目，是关于和客户打交道，自己如果做的。
针对这半年的学习，我做了如下计划：
- 努力学习编程方面的知识，编程是程序员最低级的工作，但也是程序员最基本的工作，如果连编程都是问题的话，后续的工作都是空谈。
- 学习一下建模语言，上学期自己留下的恶果，现在要自己食了。
- 除此外，还要按照课本上的内容一部分一部分的吃透……
为此我做出了这半年的学习树：
