我正在编写系统需求文档，需要包含与系统可用性相关的非功能性需求，但我不确定表达此功能的最佳方式。
“系统应该易于使用”对我来说似乎有点模糊，而且不可测试。是否有任何与程序可用性相关的“官方”标准/指南？
答案 0 :(得分：17)
通常，我们会尝试使用“易于使用”的特定于应用程序的定义。例如，对于我们当前的项目，易于使用意味着：
- 系统中的所有延迟时间超过0.5秒都会产生一个对话框，上面写着“请稍等。”
- 只需不到3次点击，即可从主窗口访问任何给定的系统功能。
- 只需键盘就可以完成任何给定的任务，无需鼠标。
- 系统中的所有按钮都将遵循既定的按钮约定（链接到已建立的按钮约定，包括尺寸，命名，位置等）。
- 所有屏幕都有一个帮助按钮。给定屏幕上的每个帮助按钮必须为屏幕上的每个控件提供至少一个“主题”。
-etc。
这些东西是可测试的，并且合在一起构成了“非常好”的可用性标准。也就是说，没有什么可以替代实际用户尝试它。
答案 1 :(得分：3)
可用性要求很难，因为知道您的系统是否可用的唯一方法是让真正的用户试用它。您如何知道您的要求是否得到满足？要做到这一点，您需要正式的可用性指标。这些指标必须以某种方式从可用性测试的结果中提取出来，如果您将可用性测试抽象到您刚刚获得指标的程度，那么您就错过了它的实用性。
有些项目如“必须能够通过Y次点击进行X”或“系统必须以Z毫秒或更短时间响应”才有用，但它们实际上是与可用性有关的功能要求，而不是可用性要求。他们自己。很可能（如果不可能）您可以设计和实现满足所有这些正式要求的系统，并且仍然令用户感到沮丧。同样，唯一的方法是通过可用性测试。
答案 2 :(得分：2)
嗯，'系统应该易于使用'正是那种令设计人员和开发人员感到沮丧的文档，所以让我们看看我们是否可以做得比我们好一点？ ：）
首先，您可能会发现坐下来准确想象预期用户是谁是有帮助的。给他们一个背景，给他们一些颜色，然后将它们发送到你想象的应用程序，并尝试弄清楚他们作为个人将如何与它进行交互。
请记住，不同的用户关注可用性的不同方面。如果您使用该应用程序，请不要只关注您认为 会遵循的故事路径。
接下来，将网站分解为可用性组件可能会有所帮助。它有很多照片吗？如果是这样，那么向用户展示大量图片的最佳方式是什么。它是否具有深层嵌套的菜单结构？可能有比sitetree更好的方法来帮助用户浏览他们的方式吗？ 可用性设计模式将在这里帮助您。可以找到可用性设计模式的良好资源here和here。设计模式很好，因为它们清楚地向每个人解释了某些功能应该如何工作。
花点时间考虑可访问性和可用性。网站如何使用javascript关闭始终是一个非常好的起点，对于那些倾向于非常厌倦观看他们的设计师在页面上的另一个<a>链接而非常厌倦的开发人员可以提供很大的帮助。需要提交表格。
请记住，可用性是关于清晰度的，它始于与构建系统的人员的清晰沟通。如果你不能清楚地说出你想要构建什么，你期望开发人员如何构建一些功能强大的东西？如果必要的话，花些额外的时间来制作原型纸。
我的回复可能有点过于“网络”，对你来说非常有用，但我希望它能在我的咆哮中提供一些有用的花絮。
答案 3 :(得分：2)
衡量标准＆amp;用例。
我们有许多角色来封装我们不同的客户类型。
我们有用户poweruser（乔治，他是一个书呆子，大学类型），非技术人员（弗兰克，几乎不能使用计算器）和介于两者之间的人（苏西，她知道如何上网和可以与技术支持人员交谈，但不要问她是什么emacs）。
基于我们说：
现在，对于指标，我们还有可用性研究指南，例如10个人中，8个应该能够在不查看帮助的情况下访问功能Y，或者能够在30秒内完成。
这些都是主观的，但它可能会帮助你朝着正确的方向前进。此外，它可以帮助您与“只是希望它工作和轻松”的非开发人员类型交谈。
在软件文章中阅读Joel也没有什么坏处。
答案 4 :(得分：1)
在我可以找到的需求文档中包含可用性要求的最明确的方法是：制作大量的屏幕模型（并将它们与执行的操作的“流程”连接起来，例如通过从一个箭头点开始image1上的项目到image2上的相关下一项目等）。如果人们真正看到某些东西应该起作用，那么它就更容易理解，并且留下更少的解释空间。
答案 5 :(得分：0)
Here关于人机接口的GNOME文档。这是作为如何指定的示例，而非指定的（因为我不同意他们在那里说的所有内容）。