2)危機預防
系統故障和用戶錯誤發生了,程序應具備將其后果降到最低的能力。
――沒有備份工具
對開發人員而言,為了一個文件做一個額外備份應該不是一件困難的事。如果你正在修改一個文件,計算機應當保留原始版本的一個副本,因此如果你的更改有錯誤,還能返回到一個已知的好的版本。
――不能撤銷
撤銷一個你已經發出的編輯命令,至少是一步?;謴捅粍h除的文件是一種受限制的撤銷,它能讓你恢復錯誤刪除的數據。撤銷是可取的,恢復被刪除文件也應是必須的。
――沒有“你確定嗎?“的提示
提交一個大量數據清除的工作,或者提出一個清除少量數據但是會影響其他作業的命令或者很容易錯誤提交的命令,都需要程序在用戶操作時進行確認,不聲不響地進行將會帶來安全方面的隱患(尤其是在后臺進行暗箱操作時,這種危險性更高)。
――沒有增量保存
當輸入大量文本或數據時,你應該能告訴程序相隔一定時間對你的工作進行保存,至少應該提供用戶此類選項。對于突發的掉電和硬件損壞情況這樣做將是非常有好處的。
3)由用戶進行的錯誤處理
人們可以捕獲自己的錯誤,而經驗告訴我們,他們還容易犯其他的錯誤。他們應能自理修復錯誤,并建立自己的錯誤檢查機制。
――沒有用戶能指定的過濾器
當設計數據錄入表格和電子表格模板時,你應該能夠讓每個區域指定什么樣的數據類型有效、程序應忽略或拒絕什么。例如,你可以讓程序拒絕數字、字母、不在某個特定范圍內的數值,一個有效日期或者與磁盤上匹配的日期等等。
――難用的錯誤更正
修改一個錯誤應該很容易。不應該因為犯了錯誤的數據錄入而讓整個系統重新啟動。在輸入一串數據時,你應該能在不重新輸入剩余部分的情況下,更正錯誤的數據。
――不能包括注釋
當設計數據錄入表格,電子模板,專家系統時,你應該能夠為未來參考和調試輸入注釋信息,這是很必要的。
――不能顯示變量之間的關系
錄入表格、電子模板中有些變量是相互關聯的,應該能很容易的檢查任意變量對其他變量的依賴性。這在設計時應該被周密考慮到。在大多數的財務管理系統中,這類應用是較普遍的。
4)其他問題
――隱私和安全性
對于某些特定的程序,需要考慮數據的充分安全性,保護公司,集體或個人的機密和隱私。在多用戶系統上,你應該能很好的隱藏你的文件(一般都是通過加密手段實現的),并且能很好的鎖定你的文件不被篡改或閱讀。
――安全性的困擾
一個程序的安全性控制應盡可能謹慎考慮與實施。
――隱藏菜單
很多程序在頂端、底部或屏幕邊緣顯示一個菜單(包括我以前測試的大多數應用程序)。它們使用屏幕的剩余部分作為數據錄入和處理的區域。菜單只是記憶的輔助物。一旦用戶了解了他所需要的所有命令后,就應該給予用戶充分的自由,讓其選擇是否需要保留菜單的權力。
――不支持標準O/S特征
例如:如果系統使用了子目錄,那么程序就應該能引用其他子目錄。如果操作系統提供了通配符(比如*),那么程序也應該能使用。
――不允許長名稱
應當允許使用長名稱(只要不是太離譜),畢竟,內存不足和編譯器反應遲鈍的時代已經成為過去了。別讓自己的程序也成了文物。
5、程序僵化
程序有靈活與固定之分。靈活的程序更顯個性化一些,而固定僵化的程序一般都是由于業務流程的關系而不得不如此。如借還書的過程,必先借了才能還。別給用戶太多的自由,否則程序看起來會讓人覺得松散,也不要把程序定得死死的,那看上去給人太多壓力了。
1)用戶可調整性
――不能關掉噪音
犯錯誤時,許多程序都會給出“咄”的警告聲。而如果每次接觸鍵盤都發聲,這簡直是不能容忍的――特別是在公共場所。必須關閉沒有必要的噪音,至少程序要提供這類控制選項。
――不能關閉大小寫區分
一個能區分大小寫的系統應該允許你告訴它忽略大小寫的問題。
原文轉自:http://www.uml.org.cn/Test/200711195.asp