统一的敏捷需求流程

软件设计与建模经验可以用以下口诀：

由外而内

层次分明

动静结合

逐步求精

分析产品需求，首先应该设计最大的逻辑边界开始，由外而内，逐步深入。而最大的一个设计范围是业务边界。业务边界通常指向一个组织，也就是当前产品所属的运营企业或机构边界，产品位于该边界之内。

针对Bob做的都是业务分析，主要对当前组织有哪些业务需求与业务流程进行设计与分析。通常产品本身就是一个系统，分析产品应该具有哪些功能与特性，针对的是系统的边界，针对Bos做的是系统需求分析。分析视野从产品外部的业务边界缩小到产品本身的系统边界，从业务分析到系统需求分析，即是一个由外而内的过程

产品的功能需求也是有大小的，而用例也是有粒度分别的。画图时，一般把大粒度的图放上面，小粒度的需求放下面，就构成了需求或用例的层级

一个系统的所有功能需求几乎都可以采用用例来表示。一个用例描述了用户在使用一个系统功能的过程中，与系统之间发生的各种交互行为，包括信息数据的交换、事件的发生、动作的执行以及状态的改变等。需求分析，仅仅描述动态行为，常常是不够的。例如购物流程中，常用到的一些核心领域类，有顾客（会员）、订单、商品（规格）等。

功能的动态行为，一般人都是可以想到的，产品经理通常都会画图BPMN在文档里面（不管画的是否完整、准确），但是关注静态方面，工作这么多年，几乎没有在需求文档里面见过。大多数开发都是CRUD，直接面向数据表来实现，未尝不是一种悲哀。

但是与程序设计阶段的类图不同的是，需求分析时的类图描述的是许多业务领域（如电商领域）中的信息实体，他们代表的是自然世界中被动地被其他对象所使用的数据，所以这些类通常只有数据或者特性，而没有任何行为，并不是软件世界中可以运行的类。

“逐步求精”，说明需求分析时一个从粗略到精细、逐步递增演进的自然过程。对于一些复杂的功能，需要把它的用例纲要也写出来，至少包含用例的前态、后态、触发条件以及基本流，还包括一些特殊的扩展条件及如何处理这些扩展和异常情况的大致描述。用例纲要是介于用例简述与用例详述之间的一个中间状态