本书描述了一种编写问题陈述部分的方法，即用例方法。
这是什么？ 这是对用户与系统（或与业务）交互场景的描述。 在这种情况下，系统充当黑匣子（这使得可以将复杂的设计任务划分为设计交互并确保这种交互）。 同时，引入了符号标准，这确保了易于阅读（包括非参与者），并允许对完整性和是否符合利益相关者的目标进行一些检查。
用例示例
以通过电子邮件在网站上进行授权为例，该场景是什么样的：
（系统）登录网站访问您的个人账户。 ~~（海平面）
语境： 未经授权的客户使用电子邮件作为登录名登录网站，以便网站识别他并显示他的个人信息：浏览历史记录、购买历史记录、当前奖励积分数等。
级别： 用户目标
主要人物： 客户（我们在线商店的访客）
范围： 客户与在线商店网站的交互
利益相关者和利益：
- 营销人员希望识别最大数量的网站访问者，以扩大个人邮件的覆盖范围，
- 安全专家希望确保不存在未经授权访问访问者个人数据的情况，包括尝试猜测一个帐户的密码或搜索密码较弱的帐户，
- 攻击者想要获得受害者的奖金，
- 竞争对手希望对产品留下负面评论，
- 僵尸网络想要获取商店的客户群，并利用攻击使网站无法运行。
前提条件： 访客不得获得授权。
最低保证： 访问者将知道授权尝试是成功还是失败。
成功的保证： 访客已获得授权。
主要场景：
- 客户端发起授权。
- 系统根据“安全规则第23条”确认客户端未获得授权，并且不超过给定会话（搜索多个帐户的弱密码）的不成功授权尝试次数。
- 系统增加授权尝试次数的计数器。
- 系统向客户端显示授权表。
- 客户输入他的电子邮件和密码。
- 根据“安全规则第 24 条”，系统会确认系统中存在具有此类电子邮件的客户端，并且密码匹配，并且该帐户的登录尝试次数未超过。
- 系统对客户进行授权，并将本次会话的浏览历史和购物篮添加到该客户帐户的最后一个会话中。
- 系统显示授权成功消息，并移至客户端因授权而中断的脚本步骤。 在这种情况下，页面上的数据将根据个人帐户数据重新加载。
扩展：
2.a. 客户端已获得授权：
2.a.1. 系统通知客户端先前执行的授权的事实，并提出中断脚本或转到步骤 4，如果步骤 6 成功完成，则执行步骤 7 并进行说明：
2.a.7. 系统解绑旧账户下的客户端，对新账户下的客户端进行授权，而本次交互会话的浏览记录和购物车保留在旧账户中，不会转移到新账户中。 接下来，转到步骤 8。
2.b 授权尝试次数已超过“安全规则第 23 条”规定的阈值：
2.b.1 转到步骤4，授权表上额外显示验证码
2.b.6 系统确认验证码输入正确
2.b.6.1 验证码输入错误：
2.b.6.1.1。 系统也会增加该帐户的不成功授权尝试的计数器
2.b.6.1.2。 系统显示失败信息并返回步骤2
6.a. 未找到包含此电子邮件的帐户：
6.a.1 系统显示一条有关失败的消息，并提供一个选择：转到步骤 2 或转到“用户注册”场景并保存输入的电子邮件，
6.b. 此电子邮件帐户的密码与输入的密码不匹配：
6.b.1 系统增加该帐户登录尝试失败的计数器。
6.b.2 系统显示有关失败的消息，并提供进入“密码恢复”场景或进入步骤 2 的选择。
6.c：此帐户的登录尝试计数器已超过“安全规则 24”的阈值。
6.c.1 系统显示帐户登录被阻止 X 分钟的消息，然后继续步骤 2。
有什么很棒的
检查完整性和是否符合目标，也就是说，您可以将需求交给另一位分析师进行验证，从而减少在问题制定阶段出现的错误。
使用黑匣子系统可以让您将自动化内容的开发和与客户的协调与实施方法分开。
它是分析师路径的一部分，是可用性的主要部分之一。 用户的场景定义了他运动的主要路径，这大大减少了设计师和客户的选择自由度，有助于提高设计开发的速度。
我对描述中标识每个交互步骤的例外情况的地方感到非常满意。 一个完整的 IT 系统必须提供某种异常处理，有些是手动的，有些是自动的（如上例所示）。
经验表明，考虑不周的异常处理很容易使系统变得非常不方便。 我记得在苏联时期的故事，为了做出决定，你必须获得不同服务部门的多次批准，当最后一个服务部门说 - 但你的申请名称错误或其他错误时，这是多么痛苦标点符号，重做一切并重新协调一切。
我经常遇到这样的情况：没有考虑到异常的系统的操作逻辑需要对系统进行大量的重新设计。 因此，分析师的大部分工作都花在异常处理上。
与图表相反，文本表示法允许识别和涵盖更多例外情况。
从实践中添加方法
与用户故事不同，用例不是声明中独立确定优先级的部分。
在上述场景中，考虑异常“6.a.” 未找到包含此电子邮件的帐户。” 以及下一步“6.a.1 系统显示失败消息并继续执行步骤 2”。 幕后留下了哪些负面的东西？ 对于客户来说，任何回报都等于他输入数据所做的所有工作都被扔进了垃圾填埋场。 （只是在脚本中看不到！）可以做什么？ 重建脚本以避免这种情况发生。 是否有可能做到这一点？ 作为示例，您可以查看 Google 授权脚本。
场景优化
这本书讨论了形式化，但很少谈到优化此类场景的方法。
但是可以通过优化场景来加强该方法，并且用例形式化方法允许做到这一点。 具体来说，您需要考虑发生的每个异常，确定原因并重建脚本，以消除异常或最小化客户旅程。
从网上商店下订单时，您必须输入送货城市。 可能会出现商店无法将货物运送到客户选择的城市的情况，因为没有运送到那里，或者由于尺寸限制，或者由于相应仓库缺货。
如果简单描述注册阶段的交互场景，我们可以写“通知客户无法送货，并提出更换城市或购物车内容”（很多新手分析师就到此为止）。 但如果这样的情况很多，那么场景就可以优化了。
您需要做的第一件事就是让您只选择我们可以送货的城市。 什么时候做这个？ 在网站上选择产品之前（通过 IP 自动检测城市并进行说明）。
其次，我们只需要选择我们可以交付给客户的货物。 什么时候做这个？ 选择时 - 在产品图块和产品卡上。
这两项更改对于消除此异常大有帮助。
测量和指标的要求
当考虑最小化异常处理的任务时，可以设置报告任务（未描述用例）。 有多少个异常，在什么情况下发生，加上有多少传入场景成功通过。
可惜。 经验表明，这种形式的场景报告要求是不够的；有必要考虑主要不以用例形式描述的流程的报告要求。
获得可用性
在我们的实践中，我们扩展了用例描述形式，对实体和数据的特定属性进行描述，供客户端做出决策，从而增强了后续的可用性。
为了可用性设计，我们添加了一个输入部分 - 显示数据。
在有授权的场景下，这是客户端在系统中被授权的事实。 如果客户端已预授权，则在成功授权后显示有关将导航历史记录和购物车切换到新帐户的警告。
一般来说，这是向客户展示必要的信息，以便他可以根据场景做出他进一步行动的决定（你可以问客户这些数据是否足够，还需要什么，信息有什么作用）客户需要做出决定）。
如果输入的信息被单独处理并且形成不同的异常，那么将输入的信息划分到输入字段中也是值得的。
在客户端授权的示例中，如果将输入的信息分为登录名和密码，那么值得更改授权脚本以突出显示输入单独的登录名和单独的密码的阶段（这是在 Yandex、Google 中完成的，但是大多数在线商店都没有这样做）。
达到所需的数据转换
您还可以从脚本中提取数据转换算法的要求。
Примеры：
- 为了做出在网上商店购买产品的决定，客户需要在产品卡上了解该产品的可能性、成本、到达其城市的交货时间（这些是根据该产品的可用性通过算法计算出来的）仓库和供应链参数）。
- 当在搜索行中输入短语时，客户端会根据算法显示搜索建议（由算法生成......）。
在总
总的来说，不幸的是，读完这本书后，并不清楚如何从分析师到业务问题，再到开发人员的正式技术规范。 书上只讲述了部分流程，输入步骤不清楚，后续步骤也不清楚。 用例本身通常并不是开发人员的完整陈述。
尽管如此，当交互导致主体中的某些内容发生变化时，这是一种形式化和处理对象与主体之间的交互场景的非常好的方法。 它是少数允许具有显式异常搜索点的可验证需求的编写方法之一。
这本书是分析师开始编写可测试策略的必读之书。
来源： habr.com