用户原始需求得到总体方案构想（即系统原理）以及关键技术方案（阐述关键需求实现技术）。
最后基于系统总体方案及关键技术实现方案分解系统需求即SR，最后到AR，Story，task。
注意在单个子系统的当前所有AR明确之后，需要对子系统作详细设计。即软件模块化或组件化设计
也可以直接从SR到Story，task。
这种情况就基于story做软件设计。story的粒度通常较小。要求开发人员能够在10天内完成开发。
我们讨论大型系统的需求分析方法。
通常大型系统采用用例加上用户故事的需求分析方法
用例是对系统之间或以及一或多个用户之间交互的一般表述。执行者要么是用户，要么是系统。用例多一个主要成功场景与多个扩展场景组成。每个场景代表了从执行者发起请求开始到响应的一条完整路径。
用户故事可以基于用户主要成功场景划分。通过故事验收测试去覆盖扩展场景
在用例复杂度高时，也可每个用例划分多个故事。
在基于story流程去做任务拆分。
这种流程主要是
用例到用户故事到任务
这种适合于微服务或简单一点的系统。即系统到模块或组件的两层体系。互联网个人应用大多可以可以采用这种
还有一种是
用例（SR即系统需求）到 AR （子系统需求）再到Story(基于AR的） 最后到task。
这种方式适合大型系统子系统架构。流程较长的系统。这样每个子系统基于AR去做Story分析可以让每个子系统更加聚焦完成自己系统的需求分解。以及各个子系统分工协作。
