作者：cfncjl_130 | 来源：互联网 | 2023-05-18 21:04
请做过需求分析的人讲讲需求分析时有哪些风险?这些风险如何控制？
14 个解决方案
结合企业MIS或ERP项目谈一点：
一、初次调研
（1）需求大纲
在做需求分析调研之前自己心中应该先建立一个粗略的系统模型（物流过程和资金流过程），首先落实客户的需求和这个粗略的模型有多大的差异。
（2）数据流分析
研究一下用户提供的各类原始单据、业务报表等数据之间的生成关系，条件是否充分、无矛盾。
（3）建立业务过程模型
建议采用Petri网建立业务过程模型，这里包括业务单据审批流程和物流资金流。Petri网描述这类过程是一种最简单有效的方法。
(4)搜集单据报表的样本
应该搜集客户的各类单据报表的样本，作为编写正式需求规格说明的参考。
所有这些工作都完了，也只是完成了需求的初步调研工作。
二、风险和回避策略
（1）区分用户类型
基本上有两类用户：
第一类对新系统有着明确详细的计划，这类用户你几乎第一次就能把需求作到位。而且这类客户基本上会有专门的高层负责人直接负责这个项目，对其中的规划具体负责。如果你遇到这类用户，那么你是很幸运的。
这类用户在项目验收的时候，项目负责人敢于根据需求规格说明签字负责。你不需要求爷爷告奶奶地让业务部门逐个验收。
第二类用户对信息系统充满美好的期望，但从来没有具体的规划，也没有耐心看你写的书面的各种报告，可以为你写的任何东西签字，但绝不负责。所有的细节都得有你来替他们做，经常是看到可运行的代码后他们会从根本上推翻原来的设想，不满意就不给钱，这类系统失败的机率几乎是100%。不幸的是大部分客户都属于这种类型。
这类用户在项目验收的时候，项目负责人不敢需求规格说明签字负责。你必须得到所有业务部门的签字验收后，才有负责人敢给你验收。
（2）需求由粗到细，步步为营
针对第二类客户说一点教训吧。
一定不要在项目已开始就为他们编写详尽的规格说明，因为这类用户在项目验收的时候不会看这份材料的。需求写得再具体，你也不能保证没有一点含糊的地方。我们曾经有一个项目，就因为需求中出现了一个“等”字，害得我们差一点破产。
对这类用户，一开始就应该以业务部门和使用本系统的业务人员为线索编写验收大纲。只能编写纲领性性的东西。
然后根据大纲选择最关键的业务功能开始系统一个小的增量，细化验收标准，组织该增量的验收。
注意，一定要有书面的验收材料。每个增量一旦验收，除非有充分的理由，客户不得反悔。如果反悔必须增加费用（起码得让他们有愧疚感）。具体过程参考一下RUP方面的资料吧。
当然如果公司让你必须为这类用户些一分完整的需求规格说明，那么你选择辞职或者自杀吧。
哈哈，钻进来一看，居然是 quicmous(快鼠) 同志回复的，又好大一堆字啊，PFPF。：）
俺外行人觉得，初次调研部分提的是VERY好啊，嘿嘿，俺们一直是这么做的。（Petri网没用过，咳咳）
关于客户类型中的第二类，采用先前我们达成一致的“快速原型迭代”的方式，应该是比较有效的控制风险的方法。
“如果反悔必须增加费用（起码得让他们有愧疚感）。”这句是引用，呵呵，俺觉得这句说的十分到位，特别是括号里的内容，俺多罗嗦一句，在让用户有愧疚感的时候，注意沟通技巧，不要激怒用户，一旦用户觉得你得理不饶人，后期工作将增加许多不必要得障碍，愧疚感也将被愤怒抵消。
“当然如果公司让你必须为这类用户些一分完整的需求规格说明，那么你选择辞职或者自杀吧。”最后这句有教唆之嫌疑，咳咳，俺觉得嘛，自杀就不要了，辞职是值得考虑的，咳咳。（开个玩笑，嘿嘿）
我的一些看法：
1、在需求分析阶段有些需求用户也不能完全明确的提出，有些需求是用户在使用过程中才发现的。这种问题只能通过短周期的迭代开发来解决。
2、做需求时注意交流的方法，每一个需求都要从不同的角度进行描述，因为同样的概念，不同的人有不同的理解，交流时注意概念的内涵和外延。
3、文档还是需要的，不然项目进行过程中，分析人员突然辞职怎么办？难道在进行一次需求调研？
4、做需求的过程，是需求人员和客户互相交流的过程，客户要给需求人员讲解业务知识，需求人员要给客户讲解开发过程的知识。
5、需求分析时还要避免摸棱两可的需求描述，避免遗漏关键的需求，还要控制需求的范围。
学习，需求真是太重要了，楼上的高手们都看过哪些书，列举一二。当然最重要的还是经验。
我觉得不需要看什么书的，关键全都在需求调研者的工作方式，要能够随机应变，沟通时能够设身处地的考虑多方面的内容，将客户的不合理因素逐渐淡化、消磨掉，将主动权慢慢掌握在自己的手上，在充分了解客户业务需求的基础上尽量让客户随着你的指挥棒转，这是需求调研能够获得成功的关键。
1.技术上的风险[分析需求时需要规避]
2.规模上的风险[应用需求和系统需求的分离,维护费用考虑]
我们的客户在抱怨：给你说一点需求，就做一点，就不能多替我们想一想，为什么要我们不停的提需求，你们才做。
我们的程序员在抱怨：程序都做完了，又提新需求，做完了又要改，烦死了，不能一次提完。
。。。。。。
为什么会这样？问题到底出在哪里？
问大家一下，如果发生了这样问题，一般是怎么解决的？
比如你本来作了很合理的计划，也执行得不错，程序差不多写了一半，客户的需求又变了，不管你使用什么开发办法，这时进度肯定是要延期的，这时是不是要重先进行设计，还是按原来的计划走啊？
我们的客户在抱怨：给你说一点需求，就做一点，就不能多替我们想一想，为什么要我们不停的提需求，你们才做。
我们的程序员在抱怨：程序都做完了，又提新需求，做完了又要改，烦死了，不能一次提完。
软件工程！我一直忽略的问题！现在新建一个群 9949057 希望各位感兴趣的同仁一起加入 ！
“比如你本来作了很合理的计划，也执行得不错，程序差不多写了一半，客户的需求又变了，不管你使用什么开发办法，这时进度肯定是要延期的，这时是不是要重先进行设计，还是按原来的计划走啊？”
如果按照原来的计划走，做出来的东西肯定不是用户想要的。以后的麻烦会更大，你应该庆幸程序还没有写完，现在改比程序写完改更方便。需要做的是和客户更深入的沟通，找出这次需求变更的原因，避免下次再发生类似的事情。
京公网安备 11010802041100号