需求開發(fā)也是有套路的，而且還不只一種。通過《掌握需求過程》一書，我發(fā)現了下面這樣的套路：由事件驅動用例，由用例導出需求。

它由以下幾個步驟組成：

1. 建立工作范圍

軟件是為了幫助用戶更好地完成工作的，所以要開發(fā)用戶需求，就要先了解清楚用戶的工作。而要了解用戶的工作，首先就要建立工作范圍。

工作的范圍必須包括預期的參與者和他要做的工作，也包括工作的相鄰系統(tǒng)。

建立工作范圍，通常的成果就是上下文范圍圖。在圖中以用戶的工作核心，畫出工作的相鄰系統(tǒng)，并給出相鄰系統(tǒng)與工作之間的數據流及其流向。通過這種方式，對工作的范圍作出了界定。

2. 識別影響工作的業(yè)務事件

在建立了工作范圍的基礎之上，就可以分析影響工作的業(yè)務事件。對于業(yè)務事件的描述可以使用列表的形式，如：

3. 研究對業(yè)務事件的響應

業(yè)務事件的響應有以下兩種方式：數據流觸發(fā)，或者時間流逝觸發(fā)。前者，如“顯示導入的數據”事件，就是由“導入數據”事件觸發(fā)的；后者，比如設置了一些定期發(fā)生的事件，“定期備份數據”事件。

研究對業(yè)務事件的響應，不僅要給出每個事件的響應方式，還要考慮產品的目標，上下文范圍，相鄰系統(tǒng)，邊界，外部影響等因素，綜合考慮之后，再來確定對工作來說最佳的響應方式。

4. 確定產品的用例

用例是工作的一部分，由產品完成的那部分響應就是用例。用例正是從業(yè)務事件中推出的，是產品的一組動作序列，這些動作序列都是發(fā)生在某個場景之中。換句話說，用例可以是一個或一組場景，描述場景下的一系列行為。用例的大小，就要看用例包含了多少動作序列。

5. 由用例導出需求

確定了大小合適的用例后，還要將其與參與者聯(lián)系起來。因為這些動作都是由參與者來觸發(fā)的，所以需要理清楚參與者和用例之間的關系。一般我們使用用例圖來表述參與者、用例以及它們之間的關系。用例圖可以使用UML工具來生成。這樣的用例圖就是描述軟件的功能需求的視圖。換言之，軟件的需求已經被導出。

通過上述步驟，我們從了解工作的范圍，識別業(yè)務事件，確定產品的響應，確定產品的用例，最終導出軟件的需求。這樣的開發(fā)用戶需求的套路，是基于對用戶工作場景的了解，能夠發(fā)現用戶真正想要的功能需求，所以，使用這個套路開發(fā)需求，可以在一定程度上提高用戶滿意度。

微信號：IdeaofSE