现在开始查看我去年的项目，所以我正在编写规范要求文档。现在，恰好这个项目需要高度的“可用性” - 如果这是英语中的正确单词我不知道，但我的意思是它应该非常容易从用户PoV使用。现在 - 在我迄今为止所做的所有项目中，可用性并不是一个很重要的因素，因此我可以写一些胡言乱语来解决它。我总是问我们的老师他们如何指定可用性的要求，但是没有人给我一个我认为足够好的答案。
我们的老师一直鼓吹对项目提出的任何要求都应该是“可测试的”，但是如何测试用户界面的易用性？
说我运行了一个实时应用程序。在这里说“在初始调用后不到100ms就应该删除一个条目”并不难。但要说“用户界面应该是直观的86％”是很难的。
我想这是一个难以破解的难题，但我肯定不能成为世界上第一个想到这一点的人，更不用说遇到问题了。
答案 0 :(得分：2)
...您如何测试用户界面的易用性？
可用性测试。
基本上，你抓住了一堆朋友（因为你没有钱鼓励陌生人参与）给他们新用户提供的文件并要求他们执行系统的关键用例。
理想情况下，您希望测试用户至少具有目标用户的一些品质，因此如果您的系统针对技术受众，那么您的同学将会工作;但是，如果你的系统是针对普通大众的，那么你就是想让你的朋友参加艺术，人类动力学等参与。
那你怎么把它变成要求呢？您确定了您的关键用例，并规定了它们的可用性（可随时使用，文档中的几分钟，实际的实际培训......）然后验证您的测试对象是否可以完成用例而不会过于沮丧，在合理的时间内接受适量的培训。
答案 1 :(得分：1)
尝试根据“可测试”要求定义可用性。
你已经给了自己答案，因为可用性可以用诸如“在初始调用后不到100毫秒内删除条目”这样的要求来描述。
是什么让用户界面86％直观？没有某种形式的测量，这是无法回答的。您需要询问哪些功能可以使用户界面直观。与客户和潜在的未来用户交谈。收集功能（或更好地挖掘它们！），这将使得使用该软件变得更容易。
也许你会得到一些功能列表：
根据这些功能制定要求。它们是“可测试的”，因此是“可测量的”。如果在验收测试中发现20个功能中有17个正在运行，那么你有85％的成功。
编辑：这适用于需要提供测量的项目环境（如许多商业项目中）。如果你有一个“软”形式的项目环境并不是每个人都在盯着数字，那么过分坚持这种形式主义可能会适得其反，因为灵活性和敏捷性可能会受到影响。
答案 2 :(得分：0)
我建议您不要量化可用性要求。问题不在于您无法定义指标。你可以说，例如，
问题在于您必须花时间和资源为您实际可以覆盖的指标找到可接受的目标值。找到一条内容的可接受时间是多少？