软件需求 | 路径-系统的使用场景

你起身邀我舞蹈

我牵你手双飞转

通过软件用例图，我们把注意力聚焦到系统操作者对系统的操作，开始了系统层级的需求的梳理。在这个部分，我们不单单需要对业务上的需求有认知，也需要对系统能力有所了解。

系统怎么接收请求，怎么反馈，我们需要把系统当成一个具有互动性黑盒子。

同时我们人类怎么和系统互动呢，现在大部分情况下都是通过视听触三个知觉与系统打交道。相信在不远的未来世界，也会有味觉和嗅觉的参与。（例如市场上的八D电影，就提供香味的手段让人在电影中身临其境）

我们从人类世界的非软件系统的互动，过度到人类与软件系统的互动。

举例一个非软件系统的例子：一个人去柜台办理汇款手续，描述汇款的过程：

1. 这个人提交汇款请求【请求】

2. 柜台人员审核资料正确【验证】

3. 柜台人员完成汇款手续办理【改变】

3. 柜台人员向这个人汇款成功信息【回应】

如果这个人在网上办理汇款手续，那么柜台人员的角色，就变成了系统了。他和系统的互动过程，也满足这四个过程：

1. 这个人提交汇款请求【请求】

2. 系统验证信息正确【验证】

3. 系统办理汇款成功【改变】

4. 系统显示汇款成功【回应】

系统和人的交互模式，就是通过请求->处理->响应三个过程。而处理的过程，又可以细分为验证和改变两个部分。

系统交互四步骤

了解了系统的交互模式，我们才能知道，人使用系统的过程，不得不和系统做哪些交互，也就是系统使用场景。我们将这些过程，描述到基本路径和扩展路径上。

基本路径从1开始，往下顺序编号。

扩展路径相当于基本路径执行过程中的分叉小道，从某个编号开始通过a，b...区分小道，然后通过后缀“.1”，“.2”继续编号。

基本路径和扩展路径思维图 基本路径和扩展路径在用例规约的写法

基本路径描述主要系统使用场景。而较少使用，或较为次要的，但是需要考虑的系统使用场景，则放到扩展路径。

例如，我们去淘宝购物，买东西的时候，较多情况，会先选择放到购物车，然后付款。这是购物的主要路径。

但是我们只买一件商品的情况下，也可以直接跳过购物车，直接下单，这就是额外的路径，一般放在扩展路径里面。

另外，当我们把路径和系统使用场景打通了之后，就可以串联C端产品采用的系统使用场景故事，他们其实讲的都是同一件事。

参考书籍：《软件方法（上）》潘加宇