《編寫有效用例》讀後感1

1、完整正式的用例格式：（1）單列文字（不是乙個**）（2）步驟編號（3）沒有條件語句（4）擴充套件部分的編號規則是數字和字母的組合

2、圖形符號有兩個可用性方面的問題，第一，終端使用者和業務執行者不可能熟悉這些符號，也不會有耐心來學習這些符號；第二，圖形不能完全表示你所需要的意思。用例本身就是文字的，任何圖形都只是為了幫助讀者找到他們所要閱讀的文字。

3、影響用例書寫格式的因素

（1）矛盾的因素：業務環境、社會作用、不同文化

這個列為第一因素真的不為過，特別在中國，地大物博，很多專案可能是北方公司的人到南方做專案，文化背景不同，語言也不是很一致，這個會直接影響需求獲取的精確度

（2）理解層次

本來開發人員和業務人員就存在理解層次不一致的問題，開發人員沒業務人員懂業務知識，業務人員沒開發人員懂軟體開發知識，所以要降低這個因素的影響必須找到乙個共同的具有標準格式的「語言」（如通用的用例格式）和很好的分工與協作方式。

（3）專案相關人員的要求

每個涉眾（即專案相關人員）都有自己關心的方面，所以他們的要求也不相同，所謂眾口難調，在這裡體現的淋漓盡致。

（4）經驗與格式

（5）覆蓋面

（6）一致性

（7）複雜度

（8）完整性

（9）目標與任務——完成什麼與怎樣完成

（10）資源

（11）其他因素

存在著這麼多因素，所以需求調研就不能以一種固定的模式推廣，只能在乙個比較大的框架上，通過調研人員發揮主觀能動性與涉眾一起完成需求的調研，但這些因素是提醒人們在需求調研過程中應該注意的問題。

4、五種專案型別的標準，五種情況：

（1）了解需求，甚至包括用例根本不在最後的需求文件中使用的情況（模板見p108）

你的用例通常作為乙個黑盒，大多數都是使用者目標級別。你可以用乙個較高層的用例來描述語境，但是你最好不要經常使用海平面級別以下的用例。

（2）業務過程建模（模板見p108）

閱讀這些用例的人往往是一些高層人員、部門經理和高階執行官，因此盡量使這些用例可讀性強，減少細節的內容。步驟的編號突出了活動的時間順序。一定要在擴充套件中描述錯誤的處理，這樣才能揭示重要的業務規則。

（3）設計和量化系統需求（模板見p109）

當你為估計系統大小和結構而分析需求時，使用這個模板。以後，你可以細化需求知道完成這個完整的用例。

（4）在乙個短期、高強度的專案中編寫功能需求（模板見p110）

由於時間和經濟的原因，需要避免編碼的開銷和編寫完整模板；因此你可以使用非正式的格式。但你還是必須了解前置條件、保證條件和擴充套件。

（5）在乙個長期、大型專案中，在增量式開發開始時編寫詳細的功能需求。（模板見p110）

當你收集行為需求，並且需要完整正式的用例格式中的所有資訊時，可以使用上述模板。這種模板可能應用在大型、關鍵、昂貴的專案中；或者應用在有固定預算的專案中；或者應用在開發組分步在不用地方，在增量式開發的開始階段需要擴充和檢查以前設計的量化用例時；或者這樣做時你的習慣