標籤:
在前面瞭解了什麼是需求,什麼是需求模式之後,接下來就應該學習如何使用和編寫需求模式。我們不僅到瞭解需求模式的含義,更要學會在什麼情況下使用需求模式。在定義系統期間,有兩種場合使用需求模式:1.當定義需求時,看是否存在一個模式可以指導如何定義這種需求。2.當考慮系統需求是否完全時,瀏覽主題覆蓋的整套模式——看是否有遺漏,或者是否需要添加什麼東西。3.當評審需求規格時,模式可以協助檢查需求的品質,確定還有哪些主題沒有定義,理解特定需求的意義和內涵。4.當評估系統的規模以及開發所需的工作量時,基於需求,使用模式可以對實現的複雜性有更準確的感覺。5.當實現需求時,模式可以使你更深刻地理解需求的意圖。6.當測試需求時,用於建議測試這種需求的方法。需求模式並不是能夠滿足所有的需求,使用模式只是儘可能的做到更好。
如何編寫入模式是我們更加關注和學習的。首先我們應該學會發現潛在的需求模式,在完成的需求中搜尋模式是捕獲需求模式的第一步。有兩種方法找到目標:系統化——有系統地徹查一個領域,檢查大部分目標;機會化——捕獲偶然發現的任何目標。書中還介紹了如何建立新領域,這一部分是編寫需求模式的開端。所謂是萬事開頭難,這也是這麼個道理。每件事情的開頭總是最難的,但也是最重要的。好的開端是成功的一半。
編寫入模式的步驟:1.是否有足夠的價值;2.建立模式的骨架;3.編寫入模式的“適用性”部分;4.收集需求執行個體;5.檢查需求執行個體;6.描述需求可能包含的資訊;7.編寫需求模板;8.編寫剩下的“討論”和“內容”部分;9.開發潛在的額外需求執行個體的列表;10.確定額外需求的候選主題;11.編寫“額外需求”部分;12.編寫“開發考慮”部分;13.編寫“測試考慮”部分;14.是否值得?15.評審模式。雖然編寫需求模式的步驟有了,但是我們在實際項目中還是要視情況而定,不能照本宣科,也不要機械地照搬。需要每個階段投入認真的思考。
書中介紹了37個需求模式。被分為8個領域。當編寫需求規格時,列一個可以用於正在定義的這種系統的所有需求模式的名單時有用的,可以更方便的找到想要的。不是所有的模式都可以適用於所有的系統,所以建立一個只和自己的系統有關的模式的名單還是值得做的。
《軟體需求模式》閱讀筆記之二