我所在的小組開發的專案是：線上電力監測系統。（沒錯，一聽名字就很專業。）在三番幾次，輪番轟炸指導老師後，終於搞明白了要做什麼，簡單點來說，就是要創新SCADA系統。（什麼是SCADA系統呢？問得好，請自行百度）

但是光是知道了要做什麼還不行，重要的是要把知道的進行文字化描述，有規範地整理出來。寫需求文件的時候，才深刻理解了所謂的“只可意會不可言傳”，當然，這個“言傳”是有條理地說給紙聽。

（廢話有點多了，開始正題）

需求的設計，我是根據功能的分類來進行設計的，一開始我覺得把功能需求給說清就行了，其他的一些規定，提示什麼的可以參照需求文件案例來寫，但是，我漏了一個個非常非常重要的東西，那就是使用者角色。（BTW:因為設計資料庫的時候沒有認真考慮過使用者角色之間的關係，被小班討論的老師給罵了）系統整體的設計是要考慮，系統給誰來用，誰能用系統做什麼，系統的功能有哪些。而我注意到了系統的功能有哪些，其實本質上，軟體工程的設計是與人打交道的過程，必不可少的要考慮使用者群體，以及相應需求，還有使用者體驗，要站在使用者的視角來看問題，這點我一直都做得不夠好。

有時候，有些功能需求可能很複雜，很難用言語去描述，那麼我們就可以用各種圖來輔助表述。例如用例圖，活動圖等，類圖和時序圖主要是給開發人員使用和理解。現在就得說到用例圖和活動圖的設計了，我也把它們嵌到了需求文件的相應位置。關於用例圖，要說明白誰做了什麼，這個一定是要用主謂賓的句子結構完成的，並且，謂語動詞儘量要求用強動詞。有人可能會問了，什麼是強動詞，什麼是弱動詞？我的理解：弱動詞=無比正確的廢話，意思就是，這個動詞無論放在哪裡，放在我這個專案的這個用例圖，或者放在其他專案的其他用例圖，它都正確，但是不準確。那麼我們如何選擇強動詞呢，這個要靠積累與天賦，畢竟我也沒做好，沒資格談。此外，要考慮主體之間的關係（是否繼承派生），以及活動之間的關係（include還是extend），include是指指向的活動必須完成，指出的活動才算完成，extend則可以理解為即使指向的活動未完成，指出的活動也可以完成。

下面可以分析一下我做的用例圖：(starUML編輯的）

關於活動圖，對於複雜的活動，可以用活動圖來輔助描述，但不是所有的活動都需要活動圖，一些簡單的活動並不需要活動圖。活動圖要分清分支和判定點兩個概念，分支可以表現並行，活動圖面向物件，同時也是是內部處理驅動的流程，下面貼上我的其中一個活動圖，它結合了一些簡單的活動。

 總而言之，需求分析與設計是一個非常重要，也非常花時間的過程，從專案開始到結束，跨度非常大，而我們的需求也在不斷地修改中（當然，開發期間有一段穩固期）。