通过专业实践探讨需求分析的感悟与体会

     正式接触软件需求分析可能只有一个学期多一点的时间, 一直听说做一个软件最重要的是需求, 开始的时候不太在意这句话,以为只要代码实现了就没有多大的问题了。直到接触到了现实的项目才发现这句话真的是深藏不露啊。
     记得专业实践是帮一个老师做一个项目&＃xff0c;用户是某个部队&＃xff0c;项目是一个政治教育评估系统&＃xff0c;最早的时候好像并没有给出太多的要求&＃xff0c;只是说做出一个他们想要的教育评估系统的中心部分就可以了&＃xff0c;因为不能和用户直接交流&＃xff0c;没办法直接接触到用户的想法&＃xff0c;只有通过指导老师来做中间桥梁。记得那一段时间&＃xff0c;过得真是“痛苦”。。。
     第一个版本诞生以后&＃xff0c;以为可以交差了&＃xff0c;没想到&＃xff0c;用户中途改需求了&＃xff0c;加了一些功能&＃xff0c;这个软件的原型算是“作废”了&＃xff0c;唉&＃xff0c;一时间&＃xff0c;有一种“白做了”的感觉。。没办法&＃xff0c;谁让我们答应了老师要完成呢。。。
    接受了改变后&＃xff0c;我们又一次重新分析了用户的需求&＃xff0c;又一个原型产生了&＃xff0c;没想到。。。。
    一次又一次的改变原有的计划&＃xff0c;一次又一次地改变原有的需求&＃xff0c;基本上每一次都是往原有的功能上添加别的功能&＃xff0c;当时真的有一种“学生是廉价的劳动力”这种感觉&＃xff0c;一度都想放弃这个项目。不知道是什么力量在支持&＃xff0c;我们还是一直走了下来。
    记得当时那一段时间&＃xff0c;事情特别多&＃xff0c;所有的学科都到了期末交大作业的时候&＃xff0c;一堆一堆的“项目”堆在手边&＃xff0c;这头有人催做这个项目&＃xff0c;那头有人催做那个项目&＃xff0c;那一段时间可以说是我大学里过得最累的时候&＃xff0c;不知道熬了多少个通宵&＃xff0c;身体啊&＃xff0c;那个时候真的被忘到了脑后&＃xff0e;&＃xff0e;&＃xff0e;&＃xff0e;
    中间的太多过程不想再提了&＃xff0c;换过语言&＃xff0c;改了N个版本&＃xff0c;与老师辩论了N次&＃xff0c;几乎每一次的开会都是战战兢兢 的&＃xff0c;唉。。。
    其实我想说的是做需求分析真的很重要&＃xff0c;一个好的软件首先要先弄清楚用户的要求&＃xff0c;一般的用户往往不能很直接地提出他的要求&＃xff0c;基本上他们自己也说不清楚他们想到的到底是什么样的软件&＃xff0c;他们只能说出他们最想要的功能是什么&＃xff0c;大部分的用户都是想直接通过使用一个初始版本的软件来决定该版本的软件有什么缺陷。。。。
    有一句话说的真的很有道理“用户最喜欢做的就是——变化&＃xff0c;变化&＃xff0c;再变化”
     做为一个IT人&＃xff0c;我们能做的应该就是“说服自己拥抱变化”吧。。。。

    需求分析的20条法则
1、    分析人员要使用符合客户语言习惯的表达 　
2、    分析人员要了解客户的业务及目标 　　
3、    分析人员必须编写软件需求报告 　
4、    要求得到需求工作结果的解释说明 　　
5、    开发人员要尊重客户的意见 　
6、    开发人员要对需求及产品实施提出建议和解决方案 　
7、    描述产品使用特性 　　
8、    允许重用已有的软件组件 　
9、    要求对变更的代价提供真实可靠的评估
10、 获得满足客户功能和质量要求的系统 　
11、 给分析人员讲解您的业务
12      抽出时间清楚地说明并完善需求 　
13、 准确而详细地说明需求 　
14、 及时作出决定 　　
15、 尊重开发人员的需求可行性及成本评估
16、 划分需求的优先级
17、 评审需求文档和原型 　
18、 需求变更要立即联系 　
19、 遵照开发小组处理需求变更的过程 　
20、 尊重开发人员采用的需求分析过程 　

希望这些法则能给所有在做需求分析工作的朋友们一点帮助