3.10 确定系统需求
确定系统需求即确定系统用例。方法以根据业务用例实现场景分析为输入，分析每个系统Actor的系统用例。每个系统用例一定是一个完整的事件流，注意业务用例和系统用例的区别，业务用例是一个完整的业务目标，而系统用例是一个完整的事件流，是业务目标中的一个环节，如客户代表申请开户是一个完整的系统用例，但不是一个完整的业务目标，其包括多个页面操作。
3.11 用例实现分析
对每个系统用例，识别其可能的实现路径，每个实现路径就是一个用例实现，然后针对每个用例实现，分析人机交互，使用活动图绘制用例实现场景。
3.12 分析模型
使用分析对象，实现所有的用例实现场景，识别出三种分析对象。在这个过程中，也可以建立界面原型，和客户进一步达成需求的一致理解。分析模型是需求到设计的桥梁，分析类的层次高于设计实现，需求通过分析类转成计算机语言。后续做系统设计的时候，可直接将分析模型转换成设计模型。
在考虑分析模型的过程中，有可能识别出一些公共模块，比如开户、销户过程中都会有一些业务规则校验，需要引入规则引擎的支持，那么类似规则引擎这样的公共模块需要添加到逻辑架构中去。
3.13 非功能性需求设计
以性能为例讲一下对非功能性需求设计的过程。
1、确定性能目标：要支持多少用户、多少在线用户、多少并发操作、操作响应时间要求等；
2、以一个简单的三层架构为起点，根据性能目标，识别瓶颈。比如，如果数据库撑不住，那么需要考虑最佳的分库设计，如果是逻辑层撑不住，则要考虑负荷分担，状态同步的逻辑层方案设计，如果操作响应时间要求很高，则可根据不同场景，分析其操作的数据的读写特点，采用合适的缓存方案。如要支撑高并发低时延的大数据量查询，Twitter就采用了垂直缓存，raw缓存的设计方案。
3、验证性能设计。抽取典型场景，实现一个prototype来验证性能设计是否满足性能目标。
在质量属性设计中，如果需要新增模块，则需要修改逻辑架构。
有一些约束类需求也是非常重要的，不能遗漏分析。
经过这一个阶段，我们能够得到一个比较完整的逻辑架构，运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作就是编档的工作了。
3.14 架构编档
有了上面的工作作为铺垫，编档就非常容易了，这个就不细讲了。