Quality Attribute Scenarios（2）：會不會太理論了一點？

February 02 09:16~10:33

有讀過「Quality Attribute Scenarios（1）：簡介」的鄉民們不曉得是否有一個疑問：｢這個方法真的可以在業界被使用嗎，會不會太理論了一些？｣其實Quality Attribute Scenarios（QAS）的目的就是以撰寫劇本（scenario）的方式來具體化原本很抽象的非功能需求，這一點其實跟agile methods採用stories來描述（功能）需求的精神是很類似的。幫鄉民們複習一下，為什麼agile methods要建議用stories來描述需求而非使用use cases？

• 一個story可以想像成是一個use case的某條執行路徑，也就是說一個use case是某個功能（需求）的一般性（較抽象）的敘述。
• 敏捷方法要求團隊要在較短的週期（2-4周）釋出軟體，如果用use case來描述需求可能會無法在一次開發週期中完成這個use case，因此就把需求寫成更小且更具體的story。
• 假設一個use case被切成四個stories，每個sprint完成兩個stories，那麼經過兩個sprints之後原本可能有點抽象的一個use case就完成了。因此Teddy會覺得story比use case更容易「操作（operational）」。需求的可操作性是一個很重要的特性，如果需求寫得太抽象，那敏捷開發團隊很難在短時間內完成該需求。

套用相同的精神，如果在描述非功能需求時只是說「這個系統需要具備高可用性（high availability）」，這樣的非功能需求對於任何的開發團隊而言都是很難施工的（non-operational）。所以如果把非功能需求寫成scenario（鄉民們可以把scenario和story想成同意字）那麼開發團隊就比較容施工與派工，對於客戶而言也可以根據所寫出來的QAS來驗收系統的非功能需求（不然要如何驗收一個系統是否滿足high availability？）。

就好像story有類似「As a user, I can do xxx so that I can yyy」這樣的固定格式，QAS所規定的六個元素（Source of stimulus、Stimulus、Environment、Artifact、Response、Response measure）也只是幫忙開發人員可以方便寫出QAS。雖然課本（Software Architecture in Practice, 2nd）的QAS是用畫圖的方式表示，但是真正在寫QAS的時候並不一定要畫類似下面的圖，可以用類似下列表格的形式來撰寫：

Quality Attribute	Source of stimulus	Stimulus	Environment	Artifact	Response	Response measure
Availability
…
…
Robustness

或是寫成story的形式，例如：

• 圖(b)：As a boundary component, when a callee throws an exception at runtime, I will transform the exception semantics according to the upper layer’s aspect so that the upper layer can has a meaningful context to handle the exception. 至於Response Measure可以寫在story的how to demo這個欄位。
• 圖(c)：As a application controller, when a callee thorws an exception at runtime, I will perform state-recovery so that the system can continue to run. 同樣的，把Response Measure寫在story的how to demo欄位。

***

友藏內心獨白：搞軟體的人好像變來變去都是那幾招，只是試圖用不同的講法來包裝，還挺會搞行銷的。