IT服务战略阶段中有个需求管理流程，之所以把它放在战略阶段，是因为需求是个源头，如果在做事情之前还没有弄清服务对象是谁、到底需要什么、以及什么时候需要、希望通过何种方式获得，那么就无法为业务创造价值，技术成果也就无法称其为服务。
在ITIL V3中，IT部门被提到了一个战略的高度，这是希望IT部门能够更早地获得业务需求、更准确地理解业务需求，甚至能够通过信息化的技术手段引领业务需求。好的需求管理，往往需要好的需求分析和好的需求定义。
需求分析是一个业务与技术相互理解的过程。信息化对于业务人员来说是一个非常专业的领域，同样，业务对于技术人员来说也是个陌生的领域，故无法奢望双方在短期内能够获得很好的了解。基于这种情况，如果业务和技术双方又无法进行良好的沟通，仅仅通过从业务人员那里获得的模糊的、支离破碎的信息，技术人员是难以形成明确的需求列表。那么谁应该主动一点呢？既然IT作为一个服务组织，那么就应该主动地去了解业务需求，同时还要认识到还有责任帮助业务人员了解技术，这样，需求分析就应该是一种IT和业务之间，相互探讨、相互交流的过程。首先，技术人员从业务人员获取需求，然后消化理解并转化为技术语言，接下来技术人员应以业务人员能够理解的方式去描述业务需求，同时，获得业务人员的修改和补充，之后再由技术人员消化、理解和转化，通过多轮的迭代，直到双方取得了全面一致的认可。需求分析的成果是一个清晰的需求清单，这个清单描述了什么类型的业务用户需要使用什么样的功能。有时候可以通过一个讲故事的方式描述一个具体的需求，具体格式是，As a <Role>, I want to <Activity>, so that <Business Value>，也就是作为一个（角色）， 要做什么（动作），以便于（业务价值）。
需求定义是一个深化业务需求并向技术关联的过程，业务需求的解决方案应该是技术能够提供怎么的支持。由此可见，技术人员应该基于需求清单，进一步将其转化成相应的技术功能清单，并且将这些功能与现有的应用系统和模块进行关联。这样我们看到需求就不再是一点，而是一条线或者一个面，从业务需求到技术功能、再到应用系统，无论其中那个环节发生了变化，其他环节都能够得到信息反馈，从而实现需求变化的有效控制，这种变化也可以通过变更管理流程进行控制。这种需求关联性的另外一个好处就是，能够避免需求重复或者需求冲突，在很大程度上确保了需求的一致性。当识别出技术功能后，另外一个工作就是评估技术复杂性，找出那些不易实现的、或者实施成本较高的技术功能。然后，结合业务的优先级平衡技术功能，如果属于刚性需求，即使再难也要确保能够实现，如果不是刚性需求，则应该考虑规避技术风险。
技术人员应时刻站在业务的角度思考需求，从开始的需求分析到后面的需求定义，都要紧紧围绕业务去理解和评估，哪些属于核心需求、哪些属于辅助需求、应该投入多少努力，只要这样IT服务才能在成本有效的情况实现业务价值。

IT服务战略阶段中有个需求管理流程，之所以把它放在战略阶段，是因为需求是个源头，如果在做事情之前还没有弄清服务对象是谁、到底需要什么、以及什么时候需要、希望通过何种方式获得，那么就无法为业务创造价值，技术成果也就无法称其为服务。
在ITIL V3中，IT部门被提到了一个战略的高度，这是希望IT部门能够更早地获得业务需求、更准确地理解业务需求，甚至能够通过信息化的技术手段引领业务需求。好的需求管理，往往需要好的需求分析和好的需求定义。
需求分析是一个业务与技术相互理解的过程。信息化对于业务人员来说是一个非常专业的领域，同样，业务对于技术人员来说也是个陌生的领域，故无法奢望双方在短期内能够获得很好的了解。基于这种情况，如果业务和技术双方又无法进行良好的沟通，仅仅通过从业务人员那里获得的模糊的、支离破碎的信息，技术人员是难以形成明确的需求列表。那么谁应该主动一点呢？既然IT作为一个服务组织，那么就应该主动地去了解业务需求，同时还要认识到还有责任帮助业务人员了解技术，这样，需求分析就应该是一种IT和业务之间，相互探讨、相互交流的过程。首先，技术人员从业务人员获取需求，然后消化理解并转化为技术语言，接下来技术人员应以业务人员能够理解的方式去描述业务需求，同时，获得业务人员的修改和补充，之后再由技术人员消化、理解和转化，通过多轮的迭代，直到双方取得了全面一致的认可。需求分析的成果是一个清晰的需求清单，这个清单描述了什么类型的业务用户需要使用什么样的功能。有时候可以通过一个讲故事的方式描述一个具体的需求，具体格式是，As a <Role>, I want to <Activity>, so that <Business Value>，也就是作为一个（角色）， 要做什么（动作），以便于（业务价值）。
需求定义是一个深化业务需求并向技术关联的过程，业务需求的解决方案应该是技术能够提供怎么的支持。由此可见，技术人员应该基于需求清单，进一步将其转化成相应的技术功能清单，并且将这些功能与现有的应用系统和模块进行关联。这样我们看到需求就不再是一点，而是一条线或者一个面，从业务需求到技术功能、再到应用系统，无论其中那个环节发生了变化，其他环节都能够得到信息反馈，从而实现需求变化的有效控制，这种变化也可以通过变更管理流程进行控制。这种需求关联性的另外一个好处就是，能够避免需求重复或者需求冲突，在很大程度上确保了需求的一致性。当识别出技术功能后，另外一个工作就是评估技术复杂性，找出那些不易实现的、或者实施成本较高的技术功能。然后，结合业务的优先级平衡技术功能，如果属于刚性需求，即使再难也要确保能够实现，如果不是刚性需求，则应该考虑规避技术风险。
技术人员应时刻站在业务的角度思考需求，从开始的需求分析到后面的需求定义，都要紧紧围绕业务去理解和评估，哪些属于核心需求、哪些属于辅助需求、应该投入多少努力，只要这样IT服务才能在成本有效的情况实现业务价值。