《软件需求分析》
阅读了主任推荐的csdn博客后，不能说是受益匪浅，但是还是有些许收获的，这次的阅读笔记就把自己的心得体会写出来，好让未来的自己不怎么迷茫。
首先，博主举出了四个比较差强人意的项目作为引子，第一个是东软的项目，由于项目结构不断的调整，要对几百处的程序进行调整，最后客户还是不满意，结果崩了的例子，失败的原因还是客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。于是作者知道了当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。第二个是自己的项目，报表的不统一和设计上的不规范，导致很难弄用计算机来实现，最后作者又要得出结论：但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理，其余的就不一一列出。
随后博主进行了细致的调研划分，从初识到到拜访再到研讨会，从而需求调研到迭代到需求捕获再到用例图和业务流程分析.......这一系列的步骤才能保障一个项目尽可能的可能成功。
首先先开始初始需求调研，要对企业的高层，中层还有基层进行一次“对什么人说什么话的”这样 的问答，高层就要宏观的讲，不要那么婆婆妈妈和细枝末节，中层领导看的是收益或者是效益，要看这个东西能带来什么样的好处，不关心业务的流程，基层人员，就是软件的操作者，更加关心软件是否人性化好用，功能齐全等等，这是要调查清楚的。
第二就是拜访了，为了留下好印象还有为了后期好维护软件还有可以认识一批能帮助我们的人，“搞好关系”是必须的，也是必要的，这里比较考验个人能力和情商。
第三研讨会，终于在 客户中找到有些人能解决业务问题，但是如何定制到合适的时间和合适的地点呢，这是难题，由于种种原因，项目肯定有着个性化的要求，是否统一版本还是各自为战，业务人员哟啊进行激烈的辩论进而产生统一的建议，如果分歧无法说服，那就需要多套方案，使差异缩小至最小，让客户自行选择。这里的例子有着特殊性，不便多分析。
第四需求研讨，在这一方面我们的眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
第五迭代，这是我个人觉得最需要也是最重要的部分一个项目不是一次就能实现的，反复的讨论和循环：需求捕获->需求整理->需求验证->再需求捕获••••••需求捕获和需求整理的内容在博客中也做了详细的解释，需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
第六用例图，大二上半学期学过了用例图，但是至于掌握了什么就只能用呵呵来形容一下，确实自己用例图没有掌握什么，在这个博客中才发现这个用例图的重要性，通过用例图让客户更加清楚认识到用户和过程还有流程怎么样，这样让交付过程更加简洁和方便。
第七还是各种uml图，现在才发现它的重要性，希望以后还可以补回来，确实很便捷。
最后就是评审与签字确认会，当所有工作都完备以后，我们的需求分析工作开始进入最后收尾的阶段。我们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。
引用文章最后一段作为结束：经过数月的分析讨论，最终在一片和谐的气氛中，双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，还是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析必定起到决定性的作用，必定为日后的软件开发扫清了许多许多的地雷。