文档介绍：. .
. v 体系下建立起来的"用户故事树〞〔需求树〕还能：
直接分配到开发任务中
直接生成代码构造
直接用于构造化管理变更、增强、重构、缺陷等
. .
. v .
- -
- 总结
直接与测试用例匹配
而为一人年的工作量进展这种需求分析，只需要1小时左右。
第一步：业务愿景——利用"角色-业务图〞来支撑产品愿景
愿景〔Vision〕是用户对产品的核心期望。
培训中使用"角色-业务图〞〔简称RB图〕来表达和落实愿景。
比方在配图中："购物子系统〞核心愿景是"建立一种有保障的网上购物方式〞；图中使用"确认收货-转账〞的第三方监管业务实现。这样软件开发人员就能得到确切的技术方案，而不是面对描述非常虚的愿景；而技术方案实现后，又能支撑愿景。
有了愿景，产品就不会简单停留在"能用〞的状态，而是要积极增加可以实现愿景的功能。
现场演练与指导：建立角色业务图〔20分钟〕
案例分享：RB图详细规那么与最正确实践
第二步：业务数据——利用"实体-关系图〞开掘业务数据
此容将客户愿景转化为"对某些的业务数据的操作〞，从而逐渐进入开发人员可理解的畴；同时业务数据还是早期功能点估算的核心元素。
具体分析工具是实体-关系图〔简称ER图〕，而业务数据对应其中的实体〔图中方框〕。
实体-关系图〔教学过程中进展了简化〕中分析了实体及其依赖关系，通过适当定义，不但可以保障不会遗漏实体，甚至能直接协助进展早期估算和局部设计工作。
重要！在敏捷开发中，我们将业务数据作为史诗故事进展开发。
比方在配图中，所有实体〔5个矩形〕均包含一组"增删改查〞或类似的操作〔就是第三步中的用户故事〕，由此可知此图包含１６５人天左右的工作量／３数据库主表和２关系表／５组增删改查操作页面。
现场演练与指导：建立实体关系图〔30分钟〕
案例分享：ER图详细规那么与最正确实践
第三步：业务操作——利用"用例-流程图〞分析业务操作
. .
. v .
- -
- 总结
借助精益需求建模方法〔"用例-流程图〞，一种由User Case和状态图结合演进产生的新图形，简称UCF图〕，找到一个最小的、完备的业务操作集合，作为一次交付所能发布的最新功能集合。在精益开发中，这个集合称之为MVP， Minimum Viable Product最小可用产品。
用例-流程图的"一致性〞非常好，即两个不同的分析人员针对同一需求的分析结果，无论用例的数量、名称、乃至排列顺序都惊人地相似。
重要！在敏捷开发中，我们将业务操作作为用户故事。
右图是QUML中的"增查查改删〞模板中，通过将需求分解为增加-查看所有-查看单个-修改-删除五层，并将不同角色执行的操作放在其正下方〔共有操作放在中间〕，需求分析人员可以迅速而无遗漏地获得所有用户故事。
同时，图中由业务逻辑连接的各个业务操作〔即椭圆形区域〕形成一个MVP，多一个操作那么是多余的，少一个那么不能完整交付。这对于每个迭代能持续交付至关重要。
现场演练与指导：建立用例流程图〔60分钟〕
案例分享：UCF图详细规那么与最正确实践
第四步：需求树——建立构造化的需求
传统用户故事组织方法均呈现"列表构造〞，在用户故事数量庞