usability - 正式表达可用性要求的最佳方式是什么？

Question

我正在编写系统需求文档，需要包含与系统可用性相关的非功能性需求，但我不确定表达这一点的最佳方式。

“系统应易于使用”对我来说似乎有点模糊，不可测试。是否有任何与程序可用性相关的“官方”标准/指南可以遵守？

Answer 1

通常，我们会尝试制定一个特定于应用程序的“易于使用”的定义。例如，对于我们当前的项目，易于使用意味着：

- 系统中所有超过 0.5 秒的延迟都会产生一个对话框，上面写着“请稍候”。

- 只需单击 3 次，即可从主窗口访问任何给定的系统功能。

- 无需鼠标，只需键盘即可完成任何给定任务。

- 系统中的所有按钮都将遵守已建立的按钮约定（链接到已建立的关于大小、命名、位置等的按钮约定）

- 所有屏幕都有一个帮助按钮。给定屏幕上的每个帮助按钮必须为屏幕上的每个控件提供至少一个“主题”。

-ETC。

这些东西是可测试的，并且综合起来，构成了一个“相当不错”的可用性标准。也就是说，没有什么可以替代实际用户的尝试。

Answer 2

可用性要求很难，因为了解您的系统是否可用的唯一方法是让真实用户试用。你怎么知道你的要求是否得到满足？为此，您需要正式的可用性指标。这些指标必须以某种方式从可用性测试的结果中提取出来，如果你将可用性测试抽象到你只是得到指标的地步，你就错过了它的用处。

诸如“必须能够通过 Y 多次点击完成 X”或“系统必须在 Z 毫秒或更短的时间内响应”这样的项目很有用，但它们实际上是与可用性有关的功能要求，而不是可用性要求本身。很有可能（如果不可能的话）您可以设计和实现一个满足所有这些正式要求但仍然让用户感到沮丧的系统。同样，知道的唯一方法是通过可用性测试。

Answer 3

好吧，“系统应该易于使用”正是那种让设计人员和开发人员都感到沮丧的文档，所以让我们看看我们是否可以做得更好一点，好吗？:)

首先，您可能会发现坐下来准确想象目标用户是谁很有帮助。给他们一个背景，给他们一点颜色，然后将它们发送到你想象的应用程序中，并尝试弄清楚他们作为个人想要如何与之交互。

请记住，不同的用户关注可用性的不同方面。如果您使用该应用程序，不要只专注于您认为会遵循的故事路径。

接下来，将站点分解为可用性组件可能会有所帮助。它有很多图片吗？如果是这样，向用户呈现大量图片的最佳方式是什么。它有深度嵌套的菜单结构吗？是否有比站点树更好的方法来帮助您的用户导航？可用性设计模式将在这里为您提供帮助。可以在此处和此处找到有关可用性设计模式的良好资源。设计模式很好，因为它们清楚地向所有相关人员解释了某些功能应该如何工作。

花点时间考虑可访问性和可用性。网站如何在关闭 javascript 的情况下工作始终是一个很好的起点，对于那些往往厌倦了看着他们的设计师<a>在需要提交表单的页面上粘贴另一个链接的开发人员来说，这将是一个很大的帮助.

请记住，可用性与清晰度有关，它始于与构建系统的人员进行清晰的沟通。如果您不能清楚地说明您想要构建什么，您如何期望开发人员构建一些功能性的东西？如果需要，请花额外的时间来制作原型。

我的回复可能有点过于“网络”，对您没有太大用处，但我希望它在我的咆哮中提供一些有用的花絮。

Answer 4

指标和用例。

我们有许多角色来封装我们不同的客户类型。

我们有用户超级用户（乔治，他是个书呆子，大学类型），非技术人员（弗兰克，他几乎不会使用计算器）和介于两者之间的人（苏西，她知道如何上网并且可以与技术人员交谈支持但不要问她emacs是什么）。

基于此，我们说：

• 对于功能 X，George 应该能够在不使用帮助或暂停超过几秒钟的情况下访问它，Suzie 可能需要查看帮助但可能不会，如果 Frank 这样做更好，因为他没有有很大的耐心。

现在，对于指标，我们还有可用性研究指南，比如 10 个人中，有 8 个人应该能够在不查看帮助的情况下访问功能 Y，或者能够在 30 秒内完成。

这些确实是主观的，但它可能会帮助您朝着正确的方向前进。另外，它可以帮助您与“只希望它工作并且简单”的非开发人员类型交谈。

阅读 Joel 关于软件的文章也不会有什么坏处。

Answer 5

我能找到的在需求文档中包含可用性需求的最明确的方法是：制作大量的屏幕模型（并将它们与所执行操作的“流程”联系起来，例如通过在 image1 的一个项目中添加一个箭头到 image2 等相关的下一项）。如果人们真正看到了某些东西应该如何工作，那么它会更容易理解并且解释的空间更少。

Answer 6

这是 GNOME 关于人机交互的文档。这旨在作为如何指定的示例，而不是指定什么（因为我不同意他们在那里所说的一切）。