吉宁博士观点
在应用系统建设中，需求管理不是项目前期的一个环节，而是贯穿整个项目的关键流程。在系统建设中，特别是在需求管理过程中有三类人非常关键：即作为“甲方中的乙方”的信息中心的人员、作为“甲方中的甲方”的业务部门的人员、以及作为“乙方中的甲方”的IT厂商的咨询顾问和项目经理。值得指出的是信息中心不应该是技术研发中心，而是信息化应用和管理中心。在具体进行需求管理时，应该着重注意四点策略、理清三种关系，才能为需求管理的成功提供有力的保证。
四大策略
*明确职责避免缺位
在需求管理中，需要明确需求管理流程，并对每个相关部门所应有的责任与权利进行界定，同时要建立有效的监管措施，使流程中的每个环节都能发挥有效作用。要避免两种情况的缺位现象，一种是“甲方中的乙方”的缺位，即信息中心还能达到梳理、分析业务需求并为作为乙方的IT厂商进行诠释的能力或者没有尽职的履行这样的职责；第二种是“乙方中的甲方”的缺位，开发商或者集成商的咨询顾问或项目经理可以被称为信息化项目服务的灵魂，往往项目的失败是由于咨询顾问或项目经理没有很好的理解项目需求并且将项目需求传达给项目组成员所导致的。
*需求应分层沟通和确认
在获取需求的阶段，遇到最多的就是乙方的需求分析人员抱怨甲方不同层级的人员不懂这方面不明白那方面，而出现这种情况的根本原因在于需求分析人员没有搞明白应该跟不同层级的人分别问什么。需求获取应该跟不同层级的人带着不同的目的采取不同的策略和沟通方式去进行。对甲方的领导层级，获取的应该是整体的施政理念或业务战略；对中层领导即部门主管，应该了解业务流程层面的需求；对于具体的业务操作层面的细节，则需要多听取具体的业务操作人员的意见。在形成需求文档和签字确认的时候，也应该根据不同层级有所区分：概要性的文档，像经营战略取向、业务流程层面不需要做事无具细的记录，只需要记录概要性的点即可，重在抽象强调整体性，这类文档应该是领导层与中层确认的；对于操作层面的功能和交互的详细需求文档，则由具体操作业务人员进行确认，对于这种操作流程的需求文档最好能形成直观的系统原型进行确认。
*分步实施和先易后难
我们通常说信息化要统筹规划分步实施，采用迭代的方式进行建设，这同样会影响到需求管理，一开始就试图把一个庞大的系统的所有需求细节都搞清楚确定下来是不太现实的。信息化建设应该从易入难，从最少争议，最能产生明显效果的地方入手，这样需求比较能搞清楚，也比较容易调动项目团队的积极性，也能得到相关利益方的支持。等到效果出来以后，相关利益方感受到了信息化对自己的好处之后，再啃硬骨头就要好很多，他们配合进行需求分析的积极性也会高很多。
*需求环节和开发实施环节的分离
建筑工程一直是软件工程学习的榜样，建设工程的各个环节已经细分得比较清楚了，在建筑之前，有专门的单位进行规划设计，而且能够具体到详细的图纸，甲方也会向规划设计支付费用。而目前的信息化项目则没有区分得如此清楚，在项目招标的时候甲方往往仅能提供简单的需求，而IT厂商为了承接项目免费进行需求分析，并提供建设方案。这种惯例显然会导致乙方急于签订合同而不会静下心来认真详细的进行需求分析，而且往往会出现为了拿下单子随意承诺而不考虑其可行性或成本控制的问题，就导致很多问题都会在招标后暴露，所以信息化项目也应该像建筑项目学习，进行分拆招标，并且每个环节做好相应的衔接工作，毕竟每个开发商的能力与专长是有限的。
三种关系牵动需求
*业务部门与信息中心
信息化项目并不仅仅是信息中心的项目，而应该是信息中心与业务部门共同分享权利与责任。同时，信息中心与业务中心的紧密合作，并不仅限于需求阶段，在项目的整个生命周期各阶段都需要两个部门的配合。
*主管领导之间
在一个单位中，如果主要业务部门与信息中心由一个共同的单位领导主管，那么两个部门协调中出现的问题，就相对容易解决。但是如果不是同一个主管领导，那么协调工作就需要从高层开始，而且往往需要从两个部门的战略、目标等等方面首先达成一致。
*用户与厂商
应用系统项目不同于硬件购买，用户与厂商之间应该是长期的战略合作伙伴关系，并且在需求阶段就应该让厂商参与其中，相互之间长期的深入的了解有助于两者之间的合作。同时，用户在选择厂商时，更应该关注厂商的服务能力，特别是在税制改革的大环境下，厂商是否有后续服务随需而变的能力就显得格外重要。
