《軟體需求模式》閱讀筆記02

2022-05-05 19:09:13 字數 2482 閱讀 1086

《軟體需求模式》第3、4章閱讀筆記

其中第3章描述了需求模式扮演的角色,解釋了每個模式的一些具體內容和具體結構。而第4章則介紹了何時以及如何去使用需求模式,如何從原有的模式創造出新的模式或者直接編寫新的模式。

第3章首先為我們解釋了需求模式的概念:定義一種特定型別需求的方法。需求模式就是為我們提供一種需求定義的方法,我們省去自己去從頭定義需求的時間。我們使用需求模式可以1.合理利用它的指導,2.節省開發時間3.可以促進同型別需求的一致性。

而需求模式也是包含一定要素的:

1基本細節:包括模式宣告,就是宣告一些模式版本號,模式上次修改日期,需求方法等資訊;所屬領域,就是描述這個需求模式隸屬於哪乙個領域;相關模式,就是描述和其他相關模式之間的一些關係;預期頻率:描述需求規格中這個模式可能需要用到多少次;模式分類,他就是列出模式覆蓋的主要需求型別的分類;模式作者。

2適用性:描述需求模式的適用情況,它的語言必須是明確的,並且能夠清楚的描述模式的適用環境。

3討論:這部分主要考慮的如何編寫這種需求,以及編寫這種需求時需要注意的一些事情。

4內容:要求以條目的形式列出這種型別的需求必須傳達那些資訊

5模板:需求模板的目的是可以複製它作為需求描述的出發點。

6例項:每個模式必須包含至少乙個或多個例項,用來演示在實踐中如何使用模式

7額外需求:需求只說了必須要說的是不夠的。還需要「額外需求」來描述那些需要額外考慮,以及在什麼情況下需要考慮。其中額外需求有兩種:跟隨性需求,就是擴充套件原有需求,在原來的後面,定義一些附加的事情。普遍性需求,普遍性需求是適用這種型別的所有需求,並且針對整個系統只定義一次。

8開發考慮:這主要是幫助設計和實現軟體的開發人員慢走這型別的需求,他提供了提示和建議,指出了開發人員不要忘記的一些事情。

9測試考慮:它主要是為了使用者驗收測試而編寫,需要注意傳達以下資訊:評審這類需求需要注意的地方;總體上指導如何測試這種型別的需求;提醒一些需要注意的地方以及如何處理。

另外我們還要注意領域的概念。就是我們的需求模式不是整塊的展現出來,我們需要給每乙個需求模式分配乙個領域,讓領域內的所有模式共享它。而為了把需求描述的更清楚,我們則需要用到基礎架構,它的角色是指導和建議如何定義乙個特定系統的基礎架構的需求。

當然當幾個需求模式具有共同的特性時,可以建立乙個需求模式組,描述他們共同的方面,而不必在每個模式中重複。

需求模式之間的關係主要有兩種,引用:乙個需求模式可以在定義中提到另乙個模式。主要是這個需求可能包含有另乙個需求的相關資訊。擴充套件:乙個需求可以以另乙個需求為依據進行開發。

我們還要學會對需求進行分類,提煉需求,轉移需求模式,分心需求模式用例等

第4章就是叫我們如何使用和編寫需求模式

那麼我們何時需要使用需求模式呢?1當定義需求時,看是否存在需求模式可以指導定義需求。2當考慮需求是否完全時,觀察主題覆蓋的整套模式,看看是否有遺漏或新增什麼東西。3當評審需求規格時,模式可以幫助檢查需求的質量,確定還有那些主題沒有定義、理解特定需求的意義和內涵。4當評估系統的規模及工作量時,基於需求,使用模式可以對實現的複雜性有更準確的感覺。5當實現需求的時候,模式可以使你更深刻的理解需求的意圖,其中「開發考慮」就是為開發人員設計,幫助開發人員更好的程式設計6當測試需求的時候,模式中的「測試考慮」就是為軟體測試人員而寫,幫助測試人員做測試。使用需求模式有以下好處:需求更容易閱讀、需求更容易與同型別其他需求做比較、可以判斷是否有遺漏、編寫需求更容易、讀者可以參考編寫的模式獲得更多的資訊、編寫需求規格時可以參考模式。但是還要注意一些問題:可能被誘導疏於思考、可能濫用模式、很多需求可能措辭相似。

接下來為我們講的是裁剪需求模式,因為需求的措辭很大程度上取決於個人的偏好,因此沒有過多的限制,而且以客戶的語言程式設計編寫需求規格是並且永遠是最重要的。由於種種原因,需求模板中使用的語言應該與使用模式的需求規格中一致。由於這些原因,我們有必要對需求模式進行裁剪。需要注意的是,模式的基礎是一樣的:裁剪只是對使用模式產生的需求做一些調整,然後每一次裁剪乙個需求模式時要建立乙個新的需求模式宣告。

編寫新的需求模式:在工作中發現一些型別的需求總是反覆出現,以一致的方式編寫會受益,或者只是有時候定義的很糟糕,那就別再猶豫,不要畏懼為他們編寫乙個需求模式。

如何發現潛在的需求模式,系統化:研究每乙個目標需求並盡量對其分類:是什麼型別的需求?如果有模式可以適用,記錄下來然後繼續。如果現有的模式不是很合適,研究需求看是否可以設計乙個新的,更專用的模式。機會化:當定義乙個需求時,你可能意識到會有同樣型別的需求出現,如果覺得編寫這種需求很棘手,也許就值得編寫乙個模式幫助其他人解決類似的問題——並促進一致性。

如何編寫需求模式:1是否足夠的價值?在開始編寫模式之前,一定要考慮努力是否有回報;2建立模式的骨架,骨架包括所有要求的標題和「基本細節」部分條目;3編寫模式的「適用性」部分,描述模式是為了什麼,必須盡可能精確。4收集需求例項,構造所有能找到的例項列表。 5檢查需求例項,決定他們的共同之處,以及如何變化。 6描述需求可能包含的資訊。提煉例項的內容組成一套獨特的片段,給每一項資訊乙個簡潔的描述性名稱。7編寫需求模板 ;8編寫剩下的「討論」和「內容」部分;9開發潛在的額外需求例項的列表;10確定額外需求的候選主題 ;11編寫「額外需求」部分;12編寫「開發考慮」部分;13編寫「測試考慮」部分;14是否值得;15評審模式。

《軟體需求模式》閱讀筆記02

這本書就是介紹軟體需求模式的,所以我們要知道什麼是需求模式。為了傳達需求模式需要描述什麼時候使用模式以及基於模式如何編寫需求,還可以提示如何實現以及如何測試這種需求的資訊,每個需求模式還包含以下的要素 1 基本細節,就是模式宣告 自己的領域 相關模式 預期使用頻率 模式分類以及模式作者。2 適用性,...

軟體需求模式閱讀筆記02

接著讀 軟體需求模式 這本書,可以說前兩章的內容就是在說一些基礎的內容,然後第三章說明了本書的重點內容 軟體模式。需求模式需要描述什麼時候使用模式以及基於模式如何編寫需求。需求模式包括這幾個要素 基本細節 適用性 討論 內容 模板 例項 額外需求 開發考慮 測試考慮。基本細節用於描述模式中一些簡短的...

軟體需求閱讀筆記02

如果乙個專案缺乏明確的規劃和良好的資訊交流途徑,那將是十分糟糕的。如果專案的參與者持有不同的目標和優先權,那麼他們只能各抒己見,無心工作。如果專案的風險承擔者在產品所能滿足的業務需要和產品所能提供的利益問題上不能達成一致的意見,那麼需求決不會穩定。乙個清晰的專案檢視和範圍過於分散在多個地方開發,在這...