软件开发中的需求定义，是软件产生过程中的重要阶段，也是软件开发管理中的难题。
先来看看 K.E. 维格斯在《软件需求》中的一个例子：
Contoso 制药公司的高级管理长官 Gerhard , 会见 C o n t o s o 公司的信息系统开发小组的项目负责人 C y n t h i a 。“我们需要建立一套化学制品跟踪信息系统”， G e r h a r d 说道。“该系统可以记录库房或某个实验室中已有的化学药品，这样，化学专家可以直接从楼下的某人那里拿到所需的药品，而不必再买一瓶新的。另外，卫生保健部门也得为联邦政府写些关于化学药品的使用报告。你们小组能在五个月内开发出该系统吗？”
“我已经明白这个项目的重要性了， G e r h a r d ” C y n t h i a 说，“但在我制定计划前，我们必须收集一些系统的需求。”
G e r h a r d 觉得很奇怪“你的意思是什么？我不是刚告诉你我的需求了吗？”
“实际上，你只说明了整个项目的概念与目标，” C y n t h i a 解释道，“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要开发一个新的软件系统，这样可节省许多钱。”
“那些化学专家都非常忙” G e r h a r d 说道，“他们没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？”
C y n t h i a 尽力解释从使用新系统的用户处收集需求的合理性。“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。未真正明白这些问题就匆忙开始编码，结果会很难让人对产品满意。”
“行了，行了，我们没有那么多时间” G e r h a r d 坚持道。“我来告诉你需求，请马上开始开发系统。随时将你们的进展情况告诉我。”
这样的情况，估计会经常出现在企业的信息化系统开发、实施过程中。这叫“上面一张嘴，下面累断腿。”
由于不同行业、不同规模、不同应用深度的企业的信息化需求不同，很多现成的产品实际上是根本无法完全满足企业的个性化需求。企业的 IT 部门（计算机中心）免不了要对采购的信息化系统进行二次开发或是自己针对某些应用进行开发，或是对某些产品进行集成开发。
此时，开发需求的定义就成了一个让 CIO 很棘手的问题。企业老板往往会把自己的个人想法作为软件目标，把简单的概念作为软件需求，甚至也可能把个人喜好作为需要实现的用户体验，希望 IT 部门能够在很短的时间按他想法把系统给他“变”出来。这个时候，其他的业务主管领导或业务部门负责人往往会附和大老板的意见，反正“信息化是一把手工程”。
其实，从这个角度来说，信息化不能是一把手工程。信息化是一把手工程，既意味着信息化需要获得一把手的支持才能取得成功，但也意味着信息化完全由一把手说了算存在着巨大的风险。强调信息化是一把手工程，是由于企业的信息化规划、选型、实施都缺乏科学的理论作为指导，缺乏有效的方法去付诸实施，在不得已的情况下由领导直接拍板，反正责任由领导负，领导说了大家都不会反对。这实际上是信息化主管推卸责任，让一把手承担随意与盲目的信息化带来的风险。
因为一把手不是超人，对于很多业务的具体细节未必就了解得很清楚。一把手其实更多的是关心最终的数据，他并不关心流程或者并不一定熟悉流程。
再看看另外一组调查数据：在企业中， 85% 的 CIO 把自己定位为部门经理级，只有 15% 的 CIO 自认是企业副总级。与之匹配的是，只有 4.17% 的 CIO 在战略决策中拥有决策权，大多数的 CIO 在战略决策中只拥有建议权。即使在 CIO 工作范畴内的 IT 投资权上，也只有 7.65% 的 CIO 拥有决策权，更多的 CIO 只拥有建议权。
前几天参加了 e-works 组织的武汉制造企业 CIO 沙龙。会上，很多来自于制造企业第一线的 CIO 纷纷介绍了企业在信息化应用、信息化管理、信息化实施等各方面的经验。其中，有一家企业 CIO 在介绍经验时提出，为了更好的了解企业的业务流程，他们信息中心把技术人员派到各个部门去上班，完全作为每个部门的员工，与其他员工一样工作，去熟悉每个部门的具体运作。
从企业需求获取的角度来讲，这算是最直接、也可能是最有效的需求获取、需求验证模式了。不管怎么样，这至少还能保证所获取的需求是来自于信息化第一线的。只有把来自于生产、管理第一线的要求，与技术人员、开发人员的专业经验相结合，进行科学、合理的论证，才可能真正形成为能够满足企业实际业务的软件需求。
确实，对任何企业而言，谈需求不能只看一把手或领导们的脸色，而应该更多地听听来自基层员工的声音。在软件需求定义问题上，要做到民主与集中的统一。