現在開始審視我的去年項目，所以我正在制定規範要求文檔。現在，恰巧這個項目需要高度的「可用性」 - 我不知道這是否是英文中的正確詞彙，但我的意思是，從用戶PoV中使用它應該非常容易。現在 - 在我迄今爲止所做的所有項目中，可用性並不是一個真正的重要因素，所以我只能寫一些胡言亂語來解決它。我總是問我們的老師他們會如何指定可用性的要求，但沒有人給我一個我覺得足夠好的答案。如何在規格要求文件中測量「可用性」？
我們的老師總是鼓吹項目的任何要求都應該是「可測試的」，但是您如何測試您的用戶界面的易用性？
說我有一個實時應用程序運行。在這裏不太容易說「在最初的通話之後的100毫秒內應該刪除一個條目」。但是要說「用戶界面應該是86％直觀的」更難。
我想這是一個難以解決的問題，但我肯定不能成爲世界上第一個想到這個問題的人，更不用說有問題了。
嘗試根據「可測試」要求來定義可用性。
您已經給了自己一個答案，因爲可用性可以用「在初始調用後不到100毫秒內刪除條目」等要求來描述。
什麼讓用戶界面86％直觀？沒有某種形式的測量就無法回答這個問題。您需要問哪些功能可以使用戶界面直觀。與客戶和潛在的未來用戶交談。收集功能（或更好地挖掘它們！），這將使這些軟件更容易工作。
也許你得到像功能的列表：該部門的組織必須以分層樹視圖中顯示
滿足這些要求。它們是「可測試的」，因此是「可測量的」。如果在驗收測試中發現20個功能中有17個功能正在工作，則您的成功率爲85％。
編輯：這項工作在項目環境中，您需要提供測量（如在許多商業項目中）。如果你有一個「更柔和」的項目環境形式，並非每個人都在關注數字，那麼過分堅持這種形式主義可能會適得其反，因爲靈活性和靈活性可能會因此而受到影響。
...你如何測試用戶界面的容易訪問？
通過可用性測試。
基本上，你抓住了一羣朋友（因爲你沒有任何錢鼓勵陌生人蔘與）給他們一個新用戶的文檔，並要求他們執行系統的關鍵用例。
理想情況下，您希望您的測試用戶至少具有目標用戶的某些素質，因此如果您的系統針對的是技術人員，那麼您的同學將會工作;但是，如果您的系統針對的是普通大衆，那麼您將希望讓您的朋友參與Arts，Human Kinetics等。
那麼你怎麼把它變成需求呢？您可以確定您的關鍵用例，並規定它們應該如何使用（可以隨時使用，用文檔記錄幾分鐘，真正的實際培訓......），然後驗證您的測試對象是否可以完成使用案例而沒有太多的挫敗感並在合理的時間內接受適量的培訓。
我建議你不要量化可用性要求。問題不在於您無法定義指標。你可以說，例如，該
問題是，你必須花費時間和資源來找到可以接受的指標的可接受目標值。什麼是可以接受的時間來找到一段內容？
使用朋友是一個壞主意。您的測試人員應該落入目標受衆。但總體思路是正確的 - 可用性測試可用於識別用戶界面的問題。 – 2009-06-30 22:30:24
@Thomas我建議你使用你的朋友，因爲作爲一名學生，你不會在課程的時間跨度和預算爲0的情況下找到其他任何人。實際情況是有人，除了開發人員坐下來試着使用你開發的系統是非常好，因爲即使你沒有錢也沒有時間，你需要嘗試適應它。 – 2009-06-30 22:45:52