如何谈需求
就要去一家药企拉单子了（代表公司……），已经知道的信息 药企需要一个关于药品的 入库 库存 出库的系统
应该如何谈呢 第一次 呵呵 大家都说说吧
个人想到的一些，不知道合适么
1.系统的运行环境，仅限局域网 还是要通过Internet访问
2.系统涉及到的数据量级别
3.用户的计算机水平
现在能想到只有这些 希望有经验的不吝赐教
[解决办法]
客户会对系统功能方面提出一些需求，把这些需求文档化，开发的时候按文档执行
按文档定义一个执行的日期表
[解决办法]
帮顶,同问
个人感觉无非是不能随便承诺,心里没底就不是要打包票,说回去要评估成本,留有余地
[解决办法]
可以参考敏捷的做法,定短周期合同...
[解决办法]
最好多了解一下现行作业流程，比如出库入库记录，药品期限过期警报等等，
清晰了解客户的业务流程，对应的才能够设计软件的具体功能，或者给客户良好的提案。
[解决办法]
如果有可能,带着你的开发团队全部成员去参加..我是说如果有可能的话...
这样的话可以现场进行成本评估,大概会靠谱点,反正是不能随便承诺,尤其是要写进合同里的东东!
越详细越好
针对双方都没有考虑的问题怎么处理?
需求理解偏差导致的成本怎么处理?
如何保证团队做的就是甲方的本意?
[解决办法]
还没接触到需求调研这块，不过感觉应该用我们的专业的观察力与入微的判断，熟练的开场白来深入探讨。。。。
[解决办法]
对于现行业务应该多做了解，方便功能的设计。
除了常规库存管理的功能外，比如药品期限警报之类的功能，也应该考虑。
系统貌似不是很复杂，可以过几天或者一周左右，作个简单的模型，给客户确认，可以避免一部分的需求理解偏差。
[解决办法]
楼上说的都挺好的，我补充一个想法
就是没有一种方法是无敌的，关键看对方，
如果对方是个2货，果断换人谈
如果对方是个搞业务，跟他谈完就需要找个技术继续谈
如果对方是个搞技术，跟他谈完就需要找个业务继续谈
如果对方是技术业务都懂的，那你就轻松了
总而言之，不同人不同方法，目的相同，就是了解业务技术2方面需求，不要指望用户帮你设计软件，是你根据客观现实重建一个逻辑业务模型
[解决办法]
谈之前要有自己的方案
谈的时候，如果“诱导”客户朝自己的方案路线上走
[解决办法]
首先 看看有什么同行业的 软件公司开发的软件
自己先试用一下 有一个概念存在
然后 自己出一份 大的业务书， 给你自己知道的。
然后去别人谈和了解业务
综合自己的 主观别人的 出来一份 需求书
[解决办法]
1 最好找个稍微明白点计算机的人谈
2 客户要把需求文档化。某些特定的东西一定要形成文字，必须形成。
3 客户要能有专门一个人和公司接洽，这个人最好满足1，主要是业务一定要熟悉。公司要有一个人与其交流，需求不明确的时候可以联系
4 做到一定程度要和客户碰个头，看看实现有没有跑偏
最近这项目需求吃亏吃的老大了，做完这项目，发现一个靠谱的能谈好需求的，比一个靠谱的开发可重要太多了。
[解决办法]
一定要在第一时间出界面原型，给对方看，做出来的就是这玩意。让他对着原型提需求。
[解决办法]
我有一点小小的建议，希望对楼主有所帮助
我认为首先应确认跟你谈的人是高技术的还是业务的，在他们公司是什么职位
其次征求对方的看法，对方的需求，对方公司的要求以及对方所需要的结果是什么样的
再者根据自己的经验给他几点建议，然后用最短的时间做出成果来给对方，
[解决办法]
做需求就是开会,让对方提需求,整合后去掉不需要的,重复的,不可先实现的,然后做成需求分析文档,然后各方审核,最后修改,各方满意后,签字确认~~
作需求很讲究的,如何在最短的时间里,高效的获取对方的需求.
[解决办法]
這也太簡單了，你要清楚如下：
1.藥品編碼規則
2.倉庫存儲與管理方式
3.入庫與出庫規則
4.其他基礎資料關聯（如是否要關聯藥品供應商、藥品管理局的一些信息）
。。。。。。。。。。。。。。。
總之沒那麼簡單
[解决办法]
1.找出所有和系统相关的每类人
2.了解系统的目标，达成这些目标的驱动力
3.系统主要功能，包括功能需求和非功能需求(性能，可用性，可伸缩性等)
3.了解系统运行环境，和其他系统之间的接口
[解决办法]
1.找人
2.问他们想用系统干嘛
3.系统运行环境
4.记录各方需求，并排定优先级
5.平衡各方需求，和他们一起复审
6.初步确定
[解决办法]
如果是小单子可以随便了解下他们的特殊需求。 其余的都是固定功能。。 大单子可就有的是学问研究了。 怎么谈才能有合理的价格。不耗时耗力。。
------解决方案--------------------
反正谈需求，切记要找一个完全熟悉公司需求的人谈，最好懂得编程，因为有很多时候，要把编程功能用语言表现出来是很困难的，相对而言，把需求用功能描述起来也很困难，必须双方达到共识，才是铁定的事，如果对方也不确定的话，最好是找上级确定，有必要可以签字，也免于照成与对方的过多纠缠。我现在做的这个项目就是因为需求没谈好，改来改去，改的心烦！有几次想和客户沟通，却差点争吵起来，因为你用编程的思维跟他讲，他听不懂，他用需求跟你讲，你觉得实现起来很不可思议，难以达成共识！每次客户想要改动，吓得程序员一阵心寒！
[解决办法]
一句话，你有没有对应的权利
没权利我们啥也不说，因为没有可说滴，那种根本就是“别人说你就听着，记下”，然后回来报告，接着还是“别人说你就听着，记下”
有权利就先把主要领导，主要负责人，主要功能搞清楚。求同存异，快速开发，快速重构。优先保证他最基础，最想要功能。
现在软件项目永远记住一条“项目是做出来滴，不是纸上画出来滴”，在啥都没有的情况下，你啥都不能谈，谈的越多，误导越多，设计越完美，后面越毛病
[解决办法]
只要涉及药的流通，核心是ＧＳＰ管理，如果不体现ＧＳＰ，你系统做得再好也没戏~
[解决办法]
第一印象的UI及其重要！
[解决办法]
谈需求不要一下子就定了，先谈谈一些，然后整理一下，感觉哪里不妥就接着谈，文档要跟着思想走；
在满足客户的需求下，设计自己的开发流程。
最后再找客户洽谈，定出一个大的方案和走向。剩下的细节可以边开发边思考
[解决办法]
要分情况，看你们是否有现成的产品或方案还是完全无方案。
1.如果有现成的产品或方案：说明你们对这个行业的需求和业务流程有一定的了解，也有自己的一些方案，那么这时如果你们去和客户谈需求，听客户的需求，这时你们的流程整体上应该是差不多的，如果有些不同，可以向客户推你们的流程，这是在流程行得通的情况下，如果你们的流程实在不能满足客户的需求，那就要改流程了，在这种情况下主要是二次开发或客户化修改。
2.如果你们完全没这方面的经验：那么事情就多了，你们要主要是听他们讲流程，记录，讨论，根据他们的需求建立模型。。。
