在《描述系统功能需求的现代方法》一书中，Alistair Coburn描述了一种编写问题陈述一部分的方法，即用例方法。
这是什么 这是与系统（或企业）的用户交互方案的描述。 该系统同时充当黑匣子（这使得将复杂的设计任务划分为设计交互并确保这种交互成为可能）。 同时，引入了注释标准，以确保易于阅读（包括非参与者），并允许您对利益相关者的目标的完整性和合规性进行一些检查。
用例示例
场景是什么样的，使用通过电子邮件在网站上进行授权的示例：
（系统）登录该站点以访问您的个人帐户。 ~~（海平面）
上下文：未经授权的客户在网站上得到授权，以便网站可以识别并显示其个人信息：使用电子邮件作为登录信息的浏览历史记录，购买记录，当前奖励积分数等。
级别：用户目标
主要演员：客户（我们在线商店的访问者）
范围：客户与在线商店网站的互动
利益相关方和利益：
- 营销人员希望确定最大数量的网站访问者，以便更好地了解个人新闻通讯，
- 安全专家希望防止未经授权访问访问者的个人数据，包括尝试为一个帐户选择密码或搜索密码较弱的帐户，
- 攻击者想获得受害者的奖金，
- 竞争对手希望对产品留下负面反馈，
- 僵尸网络希望获得商店的客户基础，并利用攻击使站点无法运行。
前提条件：访客不能登录。
最低保证：访客将发现登录尝试成功或失败的事实。
成功的保证：访客被授权。
主要方案：
- 客户端开始授权。
- 系统会根据“安全规则第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.v.1系统显示有关在X分钟内阻止该帐户进入的消息，然后进入步骤2。
什么很棒
检查完整性和是否符合目标，即可以将验证要求提供给另一位分析人员，从而在设置任务阶段减少错误。
使用黑匣子之类的系统，您可以与客户共享开发和协调，以实现方法中的自动化。
这是分析师方法的一部分，是可用性的主要组成部分之一。 用户的脚本为他的移动设置了主要路径，这大大减少了设计师和客户的选择自由，并有助于提高设计开发的速度。
在揭示每个交互步骤的例外之处的描述中，这是非常令人愉快的。 整体的IT系统应提供一个或另一个异常处理，部分以手动方式提供，部分以自动方式提供（如上例所示）。
经验表明，考虑不周的异常处理很容易将系统变成非常不便的系统。 我回想起一个故事，那个故事是在苏联时期，它需要获得不同部门的多次批准才能做出决定，而上一个部门说这句话时会很痛苦-您在标点符号上输入了错误的名称或其他错误，请重做所有内容并协调所有内容。
我经常遇到这样的情况：没有为例外而考虑的系统逻辑需要对该系统进行重大更改。 因此，分析师工作的大部分都花在了处理异常上。
与图表不同，文本符号使您可以识别并涵盖更多例外。
练习方法的补充
与用户案例不同，用例不是产品中独立优先的部分。
在这种情况下，请考虑“ 6.a. 找不到与此电子邮件帐户。” 下一步“ 6.a.1。系统显示故障消息并进入步骤2”。 幕后还有哪些负面影响？ 对于客户而言，任何回报都等于将他已经完成的输入数据的所有工作都扔进了垃圾填埋场。 （这在脚本中根本不可见！）可以做什么？ 重建脚本，这样就不会发生。 能做到吗？ 您可以-例如，查看Google中的授权脚本。
方案优化
这本书谈论的是形式化，但是很少讨论这种情况下的优化方法。
但是可以通过优化脚本来增强该方法，而用例形式化方法可以实现这一点。 具体来说，对于每个发生的异常，您都需要考虑一下，确定原因并重新构建脚本，以消除异常或最小化客户的路径。
要订购在线商店，您需要输入送货城市。 可能会发现，对于客户选择的城市而言，由于总体限制或由于相应仓库中商品的缺乏，商店无法交付商品，因为它没有在该地交付商品。
如果仅在设计阶段描述交互方案，则可以编写“通知客户无法交付的内容，并提出更改城市或购物篮的组成”（而且许多新手分析师都停在此）。 但是，如果有很多此类情况，则可以优化方案。
首先要做的是只给我们可以交付的城市。 什么时候做？ 在现场选择产品之前（通过带有规范的ip自动检测城市）。
第二-您只需要选择我们可以交付给客户的商品即可。 什么时候做？ 选择时-在商品磁贴和产品卡上。
这两个更改大大消除了此异常。
测量和公制要求
考虑到最小化异常处理的任务，您可以将任务放在报告中（未描述用例）。 有多少个例外，在什么情况下发生，以及从传入的成功案例中成功了多少个。
但是a。 经验表明，这种形式的方案的报告要求还不够，您需要考虑主要不是以用例形式描述的流程的报告要求。
可用性访问
在我们的实践中，我们将用例描述的描述扩展为实体和数据的特定属性的描述，以供客户进行决策，从而增强了后续的可用性。
对于可用性设计，我们添加了一个输入部分-显示的数据。
在授权方案中，这是系统中客户端授权的事实。 如果客户端是预先授权的，则显示有关成功授权后将导航历史记录和购物篮切换到新帐户的警告。
在一般情况下，这是客户所需信息的映射，以便他可以根据场景决定自己的进一步行动（可能会询问客户是否有足够的这些数据，还需要什么，客户需要什么信息来做出决定）。
如果将输入信息的处理分开进行并形成各种异常，则也有必要将输入信息拆分为输入字段。
在具有客户授权的示例中，如果您用用户名和密码突出显示输入的信息，则应使用单独的步骤更改授权脚本以输入单独的登录名和密码（这在Yandex，Google中完成，但在大多数在线商店中均未完成）。
访问所需的数据转换
数据转换算法的要求也可以从脚本中删除。
范例：
- 为了决定在网上商店购买产品的决定，客户需要在产品卡上知道该产品向其城市运送的可能性，成本，运送条件（根据算法根据仓库中商品的可用性和供应链参数来计算）。
- 当在搜索字符串中输入短语时，算法会向客户端显示搜索提示（由算法形成）。
合计
总体而言，不幸的是，阅读本书之后，尚不清楚如何从分析人员到业务问题再到开发人员的正式TK的所有方法。 本书仅以措词不明确的入站内容以及后续步骤不清楚的方式介绍了该过程的一部分。 就其本身而言，用例对于开发人员而言通常不是完整的陈述。
但是，当交互导致主题中某些事物发生变化时，这是形式化和处理对象与主题交互作用的场景的一种非常好的方法。 它是允许带有明确的异常查找点的可验证需求的少数编写方法之一。
要求分析人员阅读该书，以便他们开始编写可验证的作品。