填充需求细节
　　第三个阶段是填充细节阶段，该阶段的任务是填充每个用例的实现细节，以便于开发人员进行具体的实现。往往产品人员在考虑需求范围的时候只考虑到功能性需求，在这个阶段要对非功能性需求以及设计约束进行更细致的补充。这个阶段的任务是对用例模型、领域模型标示出用例、领域类的细节进行填充。对于组织行为需求的用例，我们要填充用例的事件流；对于组织数据(结构)需求的领域类，我们要填充它的字段与格式。很多产品人员在归纳用例的时候会采用“先人后事”的思路，这种方式很容易陷入误区。我们应该讲人（角色，参与者）和事（场景，用例）分开考虑，在确定他们的关联时，要先事后人地考虑。用例说明可以分为两个层次，第一个层次重点关注业务活动的变化以及其中的约束条件，另外一个层次是交互/界面在视觉层次上的建模和细化。这两个层次其实是纵深对应的关系，先考虑业务和规则，再考虑前端的交互和界面展示。在这个阶段不单单是对业务的考虑，同时前置条件，后置条件，基本事件流程，拓展事件流程，子事件流程都是用例的核心部分。


　　
　　图6 填充需求细节

　　总结
　　在需求分析、架构系统的时候，往往我们产品人员会把大量的时间花在探索“怎么做”，很少对现实业务的整个过程进行思考。SERU需求分析的核心是从“人，事，物，接口”四条主线着手，沿着业务的脉络（业务主题域－业务事件/流程报表－业务活动－业务步骤）进行有机的分解，再以建模（构建－流程图－用例－事件流）的方式实现定向的需求分析。先从广义上对问题进行系统的拆分，以子系统的方式单独成一个封闭的集合，接下来考虑集合与集合之间的关系，后完善集合内部符合业务流转的玩法。实际上我认为这个过程很像古代治国的方式，三个步骤对应着确定边界，国与国之间的延展，国内的治理。或许徐峰老师自身体现的也是一种设计系统架构的兵家思想。