{需求.1004.08}需求設計書 (All in one 版本)
| 前面幾篇的需求訪談,一直著墨在收集利害關係人的 需求 (問題).接著就是運用SA的腦袋設計出 解決方案 。當專案是以WaterFall的方式進行，設計者視本書為不可動搖之根本，因為只要一改動，勢必需從頭改到尾（設計>開發>測試>驗收），但自從有了Iteration的概念後，讓我發現本書其實加了靈活性後，只對目前擁有的資訊做設計，做好版本控制及追蹤，其實結案的日子反而不像以前的案子遠在天邊。 在撰寫需求設計書時，除了手邊以往的範本外，還有 2 本工具書推薦： 1. 使用案例實作實務 Writing Effective Use Cases. Cockburn著 趙光正譯 此書是我以前leader的藏書，雖然是一本泛黃的老書，但裡頭的知識卻非常的豐富，很值得花時間去研讀，由其是第三部分-給忙碌者的一些寫作提示，雖然不見得可以一招半式打天下，但經過依現實狀況的微調後，目前回饋的反應都蠻好的，可惜的是中譯本應該是賣的不太好，所以沒有再版，不知道原文新版有沒有什麼好料。 2. 寫給SA的UML/MDA實務手冊 邱郁惠著 一個完整範例貫穿全書，內容大小適中，可以當小說整本看完，之後有任何問題也可以很快的找到你要的章節。如果你為UML而瘋狂，卻以為是她是OO的全部，一定要花很多時間把1.4 重要的OO及UML概念讀透，當然你也能跟邱老師請教。推UML Blog 案子常常有時很大有時小，之前跟前輩討論發現各大廠的best practice指的是買最多軟硬體，但不見得合適你這個專案，所以Size一直是專案管理的大問題，我們一直在追尋的就是適合的文件格式及範例來做為需求設計的文件，所以當案子很小的時候，我習慣於將需求一股腦的放進使用案例中，但就犯了Cockburn 寫作提示16的大忌，所以提供的例子好不好用，合不合用就待各位看官自己斟酌。以下為 All in one的版本:優點是什麼都有, 缺點是易失焦. 1. 文件說明 ... (略) 2. 參與者一覽表
3. 需求設計 3.1 授予人員權限 3.1.1 標準作業流程 3.1.2 流程狀態說明
3.1.3 使用案例 UC001 申請授予人員權限 簡述: 一般使用者申請系統角色之權限 主要參與者: 一般使用者 UC圖: 參考畫面: 主要成功情節: (ps. 這是Cockburn不喜歡的寫作版本)
擴充情節: a. 不論一般使用者做了幾次勾選取消的動作, 點擊［放棄］後皆需回復為初始之資料. b. 若該員已有申請授予人員權限簽核流程尚未結束，則不可做任何編輯的動作. 2a. 未得到一般使用者的識別身份時, 結束使用案例, 並導至登入系統. 3a. 若無原有之角色, 需提示"查無資料" ... (略)
欄位說明
按鍵說明
最後引用Cockburn: |
