现在开始查看我去年的项目，因此我正在编写规范要求文档。现在，碰巧这个项目需要高度的“可用性”——我不知道这是否是正确的英文单词，但我的意思是它应该很容易从用户 PoV 中使用。现在 - 在我目前从事的所有项目中，可用性并不是一个真正重要的因素，所以我可以写一些乱七八糟的东西来解决它。虽然我总是问我们的老师他们会如何指定可用性的要求，但还没有人给我一个我觉得足够好的答案。
我们的老师一直鼓吹对项目的任何要求都应该是“可测试的”，但是您如何测试您的用户界面的可访问性？
假设我有一个实时应用程序正在运行。在这里说“一个条目应该在初始调用后不到 100 毫秒内被删除”并不难。但是要说“用户界面应该是 86% 直观”要困难得多。
我想这是一个难以破解的难题，但我肯定不会是世界上第一个想到这一点的人，更不用说遇到问题了。
...您如何测试您的用户界面是否易于访问？
通过可用性测试。
基本上，你找一堆朋友（因为你没有钱鼓励陌生人参与）给他们一个新用户应该拥有的文档，并要求他们执行系统的关键用例。
理想情况下，您希望您的测试用户至少具有目标用户的一些品质，因此如果您的系统针对的是技术受众，那么您的同学会工作；但是，如果您的系统是针对公众的，那么您将希望让您在艺术、人体动力学等领域的朋友参与其中。
那么如何将其转化为需求呢？您确定您的关键用例并规定它们的可用性（步行可用，几分钟的文档，真正的实际培训......），然后验证您的测试对象可以完成用例而没有太多挫败感，在合理的时间内进行适量的培训。
尝试根据“可测试”需求来定义可用性。
您已经给了自己答案，因为可用性可以用诸如“应在初始调用后 100 毫秒内删除条目”之类的要求来描述。
是什么让用户界面 86% 直观？如果没有某种形式的测量，这是无法回答的。您需要询问哪些功能可以使用户界面直观。与客户和潜在的未来用户交谈。收集功能（或更好地挖掘它们！），这将使使用该软件更容易。
也许您会得到一个功能列表，例如：
对这些功能提出要求。它们是“可测试的”，因此是“可测量的”。如果在验收测试中发现 20 个功能中有 17 个可以正常工作，那么您的成功率为 85%。
编辑：这适用于项目环境，您需要在其中提供测量结果（如在许多商业项目中）。如果您有一个“较软”形式的项目环境，不是每个人都在关注数字，那么过于拘泥于这种形式主义可能会适得其反，因为灵活性和敏捷性可能会受到影响。
我建议您不要量化可用性要求。问题不在于您无法定义指标。例如，你可以说
问题在于您必须花费时间和资源来为您实际可以达到的指标寻找可接受的目标值。什么是查找内容的可接受时间？