1,265
社区成员
发帖
与我相关
我的任务
分享怎么做好需求呀？？？
总以为做需求是和客户交流，明白客户的意图，设计出能够解决客户所要求的一套软件系统，可这样做需求对吗？？？？
1。客户不明白他们自己的业务规则
当我发现这个问题的时候就想要在和他们的交流沟通这制订相应的业务规则，他们也没有自己的比较完善的组织机构
2。客户总会为些细节性的东西考虑一大堆，老走弯路
上午做需求确认，客户说他们的计算机坏了，不能上网，主板暴了，我当时就晕了，我说那样就别做系统，我们是不是应该先把系统的边界和假设及约束条件定出来了
3。经理总是给自己提出一些问题
我们的经理总说这个不好，那个不行，这个不好办，那个怎么办，我要晕了，需求阶段连这些都想进去了，这样肯定很难进阶的呀
我要晕了，我讲解，另一个同事做记录，以问答的方式来记录，讲解思路，这样对吗？到底要怎么做呀，我晕了。
希望有做项目管理和需求的高手和我呀，在此谢了，留下我的联系方式，共同进步
qq:28843163
msn:xiaofeng_cn@hotmail.com
1。客户不明白他们自己的业务规则
当我发现这个问题的时候就想要在和他们的交流沟通这制订相应的业务规则，他们也没有自己的比较完善的组织机构
2。客户总会为些细节性的东西考虑一大堆，老走弯路
上午做需求确认，客户说他们的计算机坏了，不能上网，主板暴了，我当时就晕了，我说那样就别做系统，我们是不是应该先把系统的边界和假设及约束条件定出来了
3。经理总是给自己提出一些问题
我们的经理总说这个不好，那个不行，这个不好办，那个怎么办，我要晕了，需求阶段连这些都想进去了，这样肯定很难进阶的呀
我要晕了，我讲解，另一个同事做记录，以问答的方式来记录，讲解思路，这样对吗？到底要怎么做呀，我晕了。
希望有做项目管理和需求的高手和我呀，在此谢了，留下我的联系方式，共同进步
qq:28843163
msn:xiaofeng_cn@hotmail.com
...全文
请发表友善的回复…
发表回复
lmdhit 2003-07-15
- 打赏
- 举报
呵呵！需求是这么大的难题啊！
tulipllyy 2003-07-10
- 打赏
- 举报
给客户做需求是实施项目的第一步.首先,你要尽量找到一个熟悉自己工作流程的客户人员(即使他是个电脑百痴),然后充分发挥你的沟通能力,要他把自己的工作流程和需求写给你,因为你不懂他们的业务听他们介绍还不如看他们写的东西,这样你就拿到了第一手资料,然后根据客户的要求对项目进行小部分的改动(只要不违背老板的意思)就OK了!!当然要想项目实施到位的话,部分的公关和打点都是必不可少的啊!!!
laobai 2003-07-09
- 打赏
- 举报
就三条：
干过业务
编过软件
善于沟通
干过业务=了解客户的实际需求=没干过，但有足够的领域知识和方法从客户那里获得需求
编过软件=不一定很大，但至少知道软件是怎么造出来（一般我对需求人员的要求是至少会一们编程语言，不是精通、熟练，会即可）
善于沟通=和客户沟通能力、和设计、实现的沟通能力、和团队领导的沟通能力
干过业务
编过软件
善于沟通
干过业务=了解客户的实际需求=没干过，但有足够的领域知识和方法从客户那里获得需求
编过软件=不一定很大，但至少知道软件是怎么造出来（一般我对需求人员的要求是至少会一们编程语言，不是精通、熟练，会即可）
善于沟通=和客户沟通能力、和设计、实现的沟通能力、和团队领导的沟通能力
cherrycxy 2003-07-09
- 打赏
- 举报
我们的项目也有这样的问题，我认为面对连自己都不知道做什么的客户，是需要我们引导的，在需求阶段暴露足够的问题，如果在此期间客户出现什么主板这样的问题，可以适当解决，建立好的关系。
按照您的说法，需求是公司业务逻辑问题，最好把所有部门集合，看看大家都是怎样描述的，毕竟使用的是各个部门的人员。
然后确定需求，制作成需求规格说明书，由客户仔细查看，并讲解，如果没有问题就签字画押。以后再出现变化就是需求变更，那是需要另付费用的。
按照您的说法，需求是公司业务逻辑问题，最好把所有部门集合，看看大家都是怎样描述的，毕竟使用的是各个部门的人员。
然后确定需求，制作成需求规格说明书，由客户仔细查看，并讲解，如果没有问题就签字画押。以后再出现变化就是需求变更，那是需要另付费用的。
itrain 2003-07-09
- 打赏
- 举报
gz
clamp_chen 2003-07-08
- 打赏
- 举报
对于需求人员来说，应该是做完一个项目的需求就应该有资格去做客户做的事情，
顶多熟练度有差异。
顶多熟练度有差异。
zxl_l 2003-07-08
- 打赏
- 举报
“客户不明白他们自己的业务规则”哪客户平时是什么完成工作，拿到工资的？？？
先调研客户的业务需求，通过对客户业务需求的分析，告诉客户软件系统如何实现原手工进行的业务。
先调研客户的业务需求，通过对客户业务需求的分析，告诉客户软件系统如何实现原手工进行的业务。
zxl_l 2003-07-08
- 打赏
- 举报
"因为这个系统运行的环境和前提是有计算机，计算机是坏的"这同进行需求调研和分析有什么关联？你要进行的是客户业务功能、处理过程、开展业务时需从什么地方获得那些信息，处理过程中需录入那些信息及需从什么地方获得那些信息，业务完成时生成那些信息，阶段性生成那些报表等，同客户‘计算机是坏的’有什么关系？？？？
愉快的登山者 2003-07-08
- 打赏
- 举报
1。实施项目的必要性和可行性分析：
如为提高管理水平，提高企业形象了；企业目前已经具备了上项目的条件了，上完项目可以为企业创造更多的利润，更大的商业机会等。
2。项目所需环境分析：
硬件环境，网络要求，最好有结构示意图
3。用户的业务流程分析；
4。业务与系统功能的关系；
5。一些具体的业务功能处理说明和要求；
6。其他还需要了解，及让用户详细说明的问题
如为提高管理水平，提高企业形象了；企业目前已经具备了上项目的条件了，上完项目可以为企业创造更多的利润，更大的商业机会等。
2。项目所需环境分析：
硬件环境，网络要求，最好有结构示意图
3。用户的业务流程分析；
4。业务与系统功能的关系；
5。一些具体的业务功能处理说明和要求；
6。其他还需要了解，及让用户详细说明的问题
silkeen 2003-07-03
- 打赏
- 举报
up
WebDB 2003-07-02
- 打赏
- 举报
建议看看《软件需求》这本书。。。
书名：软件需求
定价: ￥19.00
原书名: software requirements
原出版社 Microsoft Press
作者: Karl E.Wiegers
译者: 陆丽娜 王忠民 王志敏
书号: 7-111-08127-7
页码: 170
开本:
丛书名 计算机科学丛书
出版社: 机械工业出版社
出版日期: 2000-7-1
本书讲述了软件开发中一个至关重要的问题—软件需求问题。软件开发人员及用户往往容易忽略信息沟通，导致软件开发出来后，不能很好地满足用户的需要。而返工则不仅在技术上给开发人员带来巨大的麻烦，而且软件性能深受影响且造成人力、物力的浪费。所以在开发周期早期提高项目需求分析的质量，减少重复劳动，通过控制项目范围的扩展及需求变更来达到按计划完成预定目标是当前我国软件业急需解决的问题—这也是本书讨论的主要内容。
原书信息：http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0735606315/reader/1/103-6607299-6839069
书名：软件需求
定价: ￥19.00
原书名: software requirements
原出版社 Microsoft Press
作者: Karl E.Wiegers
译者: 陆丽娜 王忠民 王志敏
书号: 7-111-08127-7
页码: 170
开本:
丛书名 计算机科学丛书
出版社: 机械工业出版社
出版日期: 2000-7-1
本书讲述了软件开发中一个至关重要的问题—软件需求问题。软件开发人员及用户往往容易忽略信息沟通，导致软件开发出来后，不能很好地满足用户的需要。而返工则不仅在技术上给开发人员带来巨大的麻烦，而且软件性能深受影响且造成人力、物力的浪费。所以在开发周期早期提高项目需求分析的质量，减少重复劳动，通过控制项目范围的扩展及需求变更来达到按计划完成预定目标是当前我国软件业急需解决的问题—这也是本书讨论的主要内容。
原书信息：http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0735606315/reader/1/103-6607299-6839069
meemee 2003-07-02
- 打赏
- 举报
做需求的确很麻烦，但它是项目成功的最关键一步，绝大多数项目失败的主要原因就是需求管理出了问题。所以无论如何，你应该花时间和精力把需求工作做好。
对技术不是非常在行的客户，对你并不一定就是坏事。因为这样的客户会非常依赖你的能力，如果你能够很好地跟他沟通，引导，使他能够对你产生信任，觉得你是这领域的专家，这对你的项目是非常有好处的。你可以很大程度上左右他的意见，让他按照你的想法走。客户是上帝不错，但并不等于百分之百听从客户的，因为很多时候，连他自己都不知道自己想要什么。作为技术专家，你有责任引导客户，对于不可行的需求，或是不必要的需求，应该设法说服客户，当客户真正理解了之后，是会感激你的。
需求收集的一个关键，是尽可能的全面，这就要求你把所有可能对项目产生影响的人都考虑进去，这里面也许就包括你的经理。有时候不同人之间的需求会互相矛盾，这就需要你从中周旋。所以收集需求的人自身的沟通能力非常重要。
把需求分优先级，是控制需求变更的一个好办法。跟客户协商好，什么需求是最关键，并且首要完成的，什么需求是辅助性的，在第二阶段可以完成，什么需求是最不重要，但能锦上添花的。当项目进行过程中，需求发生变化的时候，调整需求优先级和进度。
多与客户和对项目有影响力的人沟通，将需求的状态和变化通知他们，这样才不会有意外发生。
仅供参考。
对技术不是非常在行的客户，对你并不一定就是坏事。因为这样的客户会非常依赖你的能力，如果你能够很好地跟他沟通，引导，使他能够对你产生信任，觉得你是这领域的专家，这对你的项目是非常有好处的。你可以很大程度上左右他的意见，让他按照你的想法走。客户是上帝不错，但并不等于百分之百听从客户的，因为很多时候，连他自己都不知道自己想要什么。作为技术专家，你有责任引导客户，对于不可行的需求，或是不必要的需求，应该设法说服客户，当客户真正理解了之后，是会感激你的。
需求收集的一个关键，是尽可能的全面，这就要求你把所有可能对项目产生影响的人都考虑进去，这里面也许就包括你的经理。有时候不同人之间的需求会互相矛盾，这就需要你从中周旋。所以收集需求的人自身的沟通能力非常重要。
把需求分优先级，是控制需求变更的一个好办法。跟客户协商好，什么需求是最关键，并且首要完成的，什么需求是辅助性的，在第二阶段可以完成，什么需求是最不重要，但能锦上添花的。当项目进行过程中，需求发生变化的时候，调整需求优先级和进度。
多与客户和对项目有影响力的人沟通，将需求的状态和变化通知他们，这样才不会有意外发生。
仅供参考。
digital1 2003-07-02
- 打赏
- 举报
同意rtdb(东临碣石)
我做过两个跟用户打叫道的项目，每个项目看的书都有一百多本（做税务软件的时候连税务会计都学了）
关于特殊业务的实现，最好能描述成几个基本业务的组合，给出详细的操作帮助，不要费劲的编写，往往这种业务量很多，而且也比较麻烦。
再有就是提问，你对业务了解的越多提问就越详细
在获取需求的时候可以考虑软件实现的问题，然后会从软件的方面理解业务，也有助于需求的理解。
我做过两个跟用户打叫道的项目，每个项目看的书都有一百多本（做税务软件的时候连税务会计都学了）
关于特殊业务的实现，最好能描述成几个基本业务的组合，给出详细的操作帮助，不要费劲的编写，往往这种业务量很多，而且也比较麻烦。
再有就是提问，你对业务了解的越多提问就越详细
在获取需求的时候可以考虑软件实现的问题，然后会从软件的方面理解业务，也有助于需求的理解。
firesyang 2003-07-02
- 打赏
- 举报
最主要的是你要了解一个项目的所有相关业务知识，否则一定会发现很多漏洞，需求会不断变更。
shirley1981 2003-07-01
- 打赏
- 举报
同意楼上的……
rtdb 2003-07-01
- 打赏
- 举报
我作需求时的一个感觉：
我觉得不应该和客户（我是指最终使用系统的人）
讨论应该完成什么功能， UI是什么样子的之类，
这些应和他们的技术人员和领导来讨论。
和最终用户就做一件事： 学习他的相关业务！
凡是将来有可能和你的系统相关的业务，全要学。
不到最后你比用户还明白业务， 需求就不算完。
学完基本业务，重点还要放在那种一年也没几次的特别业务，
这类业务，往往只有老人才明白。
我认为在理想情况下，
要想真正的完成需求，
只有当你成为行业专家后。
我觉得不应该和客户（我是指最终使用系统的人）
讨论应该完成什么功能， UI是什么样子的之类，
这些应和他们的技术人员和领导来讨论。
和最终用户就做一件事： 学习他的相关业务！
凡是将来有可能和你的系统相关的业务，全要学。
不到最后你比用户还明白业务， 需求就不算完。
学完基本业务，重点还要放在那种一年也没几次的特别业务，
这类业务，往往只有老人才明白。
我认为在理想情况下，
要想真正的完成需求，
只有当你成为行业专家后。
nrcrjb 2003-07-01
- 打赏
- 举报
以下是本人的一点小小的工作经验，觉得不到之处千万不要泼俺冷水噢：）
其实很大程度上客户的需求还是需要你来引导的。
许多人做需求时都害怕引导客户，以为这样就可以减少开发的工作量了。一开始做需求的时候我也是这么想，可是后来的几次经历让我尝到了教训。不过引导客户却需要相当的技巧，你不能太深入的启发他，又不能一点都不启发。什么时候才能恰到好处，这时就体现出一个需求分析高手的水平了。
你必须深入了解用户的业务操作流程，同时你还需要分析用户的业务管理流程，很多的时候用户并没有一个很好的思路怎样通过软件来管理他们现有的业务。这时，一定需要与用户进行多次的探讨和不断的确认。我就曾经碰到过这样的用户，他提出的需求连我这个局外人都觉得有很大问题，根本就没有办法称之为“管理系统”。可是由于多方面的因素，我们当时没有提出我们的整改意见，而是一味的追随了客户错误的需求，导致项目后期的重复劳动，才发现用户其实还是在一步一步地向我们当初的设想迈进。而到了这个时候重新来过，需要付出更大的代价。
另外正如楼上讲的，做需求一定需要足够的耐心和信心，并且还有相当的理性和分析力。
一开始时，就应该让用户对这个软件能干什么有个初步的印象，千万不能让用户觉得它什么事情都能干！我想只要做过需求分析的人都应该遇到过这种情况。一定要灌输给用户“一等价钱一等货”的观念，并且要让用户对于该软件的价值观能够与我们尽量保持一致。
然后要有铁杵磨成针的精神，需求不怕时间长，就怕需求质量不高。但是可千万别花了时间做出来的需求仍然质量不高，那就没有辙了:(
其实很大程度上客户的需求还是需要你来引导的。
许多人做需求时都害怕引导客户，以为这样就可以减少开发的工作量了。一开始做需求的时候我也是这么想，可是后来的几次经历让我尝到了教训。不过引导客户却需要相当的技巧，你不能太深入的启发他，又不能一点都不启发。什么时候才能恰到好处，这时就体现出一个需求分析高手的水平了。
你必须深入了解用户的业务操作流程，同时你还需要分析用户的业务管理流程，很多的时候用户并没有一个很好的思路怎样通过软件来管理他们现有的业务。这时，一定需要与用户进行多次的探讨和不断的确认。我就曾经碰到过这样的用户，他提出的需求连我这个局外人都觉得有很大问题，根本就没有办法称之为“管理系统”。可是由于多方面的因素，我们当时没有提出我们的整改意见，而是一味的追随了客户错误的需求，导致项目后期的重复劳动，才发现用户其实还是在一步一步地向我们当初的设想迈进。而到了这个时候重新来过，需要付出更大的代价。
另外正如楼上讲的，做需求一定需要足够的耐心和信心，并且还有相当的理性和分析力。
一开始时，就应该让用户对这个软件能干什么有个初步的印象，千万不能让用户觉得它什么事情都能干！我想只要做过需求分析的人都应该遇到过这种情况。一定要灌输给用户“一等价钱一等货”的观念，并且要让用户对于该软件的价值观能够与我们尽量保持一致。
然后要有铁杵磨成针的精神，需求不怕时间长，就怕需求质量不高。但是可千万别花了时间做出来的需求仍然质量不高，那就没有辙了:(
sxzz 2003-06-11
- 打赏
- 举报
第一，跟客户建立良好的关系，否则一切都是白答
第二，要有BPR思想，否则简单重复没出路
第三，要有耐心，否则容易被气死
第四，尽量了解客户的想法，对错不论，关键是你自己判断
还要注意以下三条原则
1，领导的意见是决定性的
2，中层的意见是关键性的
3，基层的意见是技术性的
第二，要有BPR思想，否则简单重复没出路
第三，要有耐心，否则容易被气死
第四，尽量了解客户的想法，对错不论，关键是你自己判断
还要注意以下三条原则
1，领导的意见是决定性的
2，中层的意见是关键性的
3，基层的意见是技术性的
irene1977 2003-06-11
- 打赏
- 举报
我也老是碰到这种问题，郁闷啊。
客户是上帝，又不能得罪，但是他们提出的需求真是没法实现啊
客户是上帝，又不能得罪，但是他们提出的需求真是没法实现啊
leng_cn 2003-06-10
- 打赏
- 举报
我也知道的，可是我已经受不了他们了，前期没有一个说明性的文档，因为这个系统运行的环境和前提是有计算机，计算机是坏的，而其他种种情况我认为是系统的一个扩展，在前期我只能是按照你提出的需求，并且你满足了运行系统所必须的条件的情况下所开发的系统，可他们连没有计算机都说要怎么办，我都晕了
加载更多回复（1）
