需求定义最佳实践;
需求定义任务概述：
需求定义的时机：
就是定义项目的业务需求，也就是明确项的目的和范围。但是在许多的项目中，通常不愿意在这方面下功夫，因为时间比较宝贵，而且这件事看起来是多么的多此一举的事情。但是这样的做法最终的结果是欲速则不达，反而浪费更多的时间。
需求定义的理念与策略:
破解混沌不清的项目目标，内部寻根、外部溯源。在需求定义制作项目提案的时候，经常会采用目标->问题->可选方案->建议方案的过程
问题分析的五步法：
在问题定义上达成共识：
所谓的问题分析就是在项目的实际环境中经常会发现可操作性不强的，但是他为需求分析人员提供一个很好的理论指导框架。要让大家达成共识，采用统一的格式写出来就是很有效的手段，在问题定义的领域，有一句经典的名言对问题进行正确的定义，意味着成功解决了一半。
在实际的项目过程中，特别是我们已经有了自己的产品的时候。在和客户沟通时就应该注意如何将客户的需求转换为自己的已经有的产品，而不是简单的全部重新开发。
分析问题背后的问题：
当问题被定义出来之后，就要分析问题背后的问题，也就是寻找问题的本源。鱼骨图是一种以直观的图型找出问题或现象的所有潜在原因的方法。主要有一下几个步骤：
选择问题、头脑风暴、确定原因类型、分配原因、分析根本原则、总结。
确定相关人员和用户：
应按照不同的角度对用户进行划分，然后对每类用户的特点进行分析，以便为后续的需求分析提供相应的信息。
定义解决方案的界限：
解决方案的能力总是有约束的，紫铜的范围总是有限的，在需求定义阶段，对系统的范围进行界定是十分重要的。而大部分书籍都是推荐使用上下文关系图来确定系统的范围，他是假上就是数据流图的顶层图。
确定加在解决方案上的约束：
对于要开发的解决方案，一定会有相关的约束，具体而言，包括对技术开发的约束和项目实施的约束两大类。
需求定义的产物和要素：
需求定义的产物：
根据项目类型的不同，需求定义 的产物大致可以分为两大类分为pos和vision两大类
需求定义的要素：
分为目标、范围、先关人员与用户、相关事宜与假定、
定义需求范围：
划分主题域：
首先判断的是该项目是否需要划分为不同的主题域，如果需要，就通过一张构件图将划分出来的主题域和他们之间的服务接口标识出来。
确定主题域的范围：
很多时候，上下文图的绘制过程中会让人找不到头绪，原因正是头绪过多，因此我们应该在划分完主题域之后，针对每个主题域来绘制上下文图。确定出每个主题域的范围。
标识业务事件和报表：
当上下文图绘制出来之后，整个主题域的范围也就框定出来了，但是他还不足以为后续的需求捕捉、分析与建模活动提供良好的基础，因次我们还需要你进一步的工作，也就是将主题域的内容以业务时间列表和报表标识出来。最后生成需要大纲：