软件需求分析方法论（转）
一、概述
现代社会，各行各业都会使用软件系统，但如何开发一套成功的软件系统呢？这涉及到很多方面，比如软件开发企业的技术水平，企业本身的管理能力，领导是否的支持，愿意付出的软件成本预算等等，但其中很重要的一个问题就是软件的需求分析是否到位？如果开发出的软件不符合企业的实际需要，那实施起来会碰到很麻烦，最终有可能会导致软件系统失败。
那么如何避免出现这种需求分析不到位的问题呢？无论是做为企业信息化部的需求分析人员还是专业软件开发公司的需求分析人员，都要花大量时间去调研、思考讨论、确认软件的需求问题，这里提供一些需求分析最核心的方法，给大家提供一个思考框架，带着这套方法去做需求分析，事半功倍。
二、需求分析方法
一个完整的软件需求分析，至少包括以下四个方面：需求调研、需求分析、需求确认、需求管理。我们先进行需求调研，调研完成后要对调研收集到的信息进行需求分析，需求分析完成后，我们要跟相关人员做需求确认，纠正理解偏差，最后我们要对需求进行管理，避免需求太多或变更频繁导致混乱。
1、需求调研
需求来源于那里？最直接的来源就是系统的用户及相关干系人了，因此我们必须先去了解他们的需求，也就是需要我们进行需求调研。那如何做一个高质量的需求调研呢？
首先我们需要做好调研准备，制定一个调研计划。比如先了解软件涉及的行业背景，基本业务，调研对象，需要问的问题，调研时间安排等
其次，我们根据实际情况，掌握使用不同的调研方法。基本的调研方法有以下几种：
- 用户访谈：最有效的方法就是找用户直接沟通，最好找那些了解业务的用户，可以问的基本问题有：a、现在的业务是如何处理的？b、系统上线后想要达到什么效果？c、有没有特别想要实现的功能？ d、有没有可供参考的文档资料?等等
- 查阅文档：有些系统丰常复杂，不是一二句话可以说清的，最好查阅相关的资料文档。可请相关用户提供和自己网上查找。
- 现场观摩：到现场实地观察一下现在的用户是如何处理他们的业务的，碰到什么问题，思考如何使用系统提高他们的效率。
2、需求分析
做完需求调研后我们就要进行需求分析，如果只把用户的需求记录下来直接转发给开发人员开发，这样是不行的，因为用户提的是业务需求，开发人员拿到是不能直接开发的，我们必须先把业务需求转化成软件功能需求，另外，用户的提交的需求，有些是不合理的，有些是没说出来的需求，有些需求其实有更好的解决办法的，我们也必须进行分析。需求分析最核心的在以下几个方面：
- 角色分析：系统涉及到那些角色？各个角色要使用系统完成什么任务？
- 业务流程分析：各个角色之间如何衔接？通过一个什么流程把任务串起来？
- 页面分析：为帮助各个角色完成任务需要设计那些页面？各个页面的页面元素是什么？
- 接口分析：是不是要跟其他系统做接口？相互之间传递什么数据？
- 查询报表：用户需要那些统计报表？
3、需求确认
做完需求分析后，我们要跟用户做需求确认，以减少双方理解的偏差，简单的需求，我们口头确认就可以，但复杂的需求一定要使用：需求文档+原型两种确认方法。
- 原型法：原型现在是普通使用的一种需求确认的方法，因为系统页面涉及的元素太多，光靠口头描述是无法描述清楚的，只有把页面画出来，用户看到了，才提的出问题。
- 需求规格说明书：需求基本确认后，要写成软件需求规格说明书，以文字，表格，图形的方式把需求记录下来，做为需求确认，后期开发、测试的依据。也是后期需求变更的依据。
4、需求管理
跟用户确定了基本需求后，就可以进行后期的开发，这时候需求人员并不是就没事了，我们还需要对需求进行管理，需求管理基本包括基线管理，需求变更管理，需求跟踪。
- 基线管理：如果是比较大的系统，不是短期就可以做完的，我们要先确定那些功能先开发，那些后开发，我们分阶段去开发实施，确定了基线后，这些基线需求基本上是不能轻易改变的。
- 需求变更：软件在开发或使用过程中，难免会有变更，比如之前在需求调研中没考虑到的问题，客户业务有变化等等，由需求人员统一收集客户的变更需求(客户不能要求开发人员直接改，这样会造成混乱)，并成立变更委员会，成员主要由需求人员，客户代表，项目经理，技术负责人组成，职责是评估变更的必要性，可行性，造成的影响，综合考后给出意见。
- 需求跟踪：一个需求一般要经历开发，测试，体验，上线，运维等几个阶段，我们要跟踪需求的状态，并在体验，上线，运维阶段都要参与进去，保证按计划实现需求目标。
我们进行软件需分析一般都会经历以上阶段，循环往复，当然实际工作中各阶段不会分的这么清，比如有些需求我们可以边调研，边分析，边确认，而不是等到下一阶段统一确认。按照以上方法，经过几次实践，你会完成一次合格的需求分析，项目成功的概率也会大大增加了。
