[Software Architecture]程式開發的非功能性需求
這篇文章的由來是來自在公司內跟一位member一同討論一個現階段要做的議題時，我引導他去做程式關聯切割時想到要把這種概念寫成一篇文章，讓其他人參考。
需求是這樣提的：
1.希望能整合Outlook的mail、聯絡人、行事曆等等資訊到我們的系統中，而這個整合的功能要嵌入Outlook的工具列中，讓使用者可以很直覺的在Outlook中進行操作。
2.我要讓Outlook跟我們的系統間可以做雙向互通，也就是在系統中的聯絡人、行事曆也可以同步回Outlook中。
3.做資料的雙向互通時，必須要依循我們系統的權限邏輯去過濾資料。
4.這個Outlook套件是需要額外計費的。
以上的需求初看並不難，但後續衍生的議題才是真的難題所在，有哪些衍生議題呢？例如：
1.套件如何嵌入Outlook？
2.嵌入後如何與系統溝通？(包含入系統與出系統，帳號權限的管理、資料的取得方式...)
3.如果用Web Service來做溝通，資料過濾的邏輯應該要寫在Web Service中還是Outlook套件中？
4.若需要額外計費，那使用人數的管制該如何限制？
5.其他...
面對這樣的需求，通常我會要求member先畫出架構圖，先定好套件、Web Service、DB、系統跟授權管理間的關聯性，我當時簡單畫了一個草圖，大概是長這個樣子：
畫這張圖的目的是因為：通常功能性的需求都不難完成，而非功能性的需求往往是造成系統發生問題的地方。
什麼叫功能性需求：取得Outlook資料、根據權限過濾資料、授權的方法....
什麼叫非功能性需求：程式與程式間的關聯、佈署的難易度、對現有系統的影響性、維護上的難易度....
我們在追問題時其實並不擔心程式的bug，最怕的反而是這些非功能性的問題，因為維護產品，這些非功能性的東西不是說變就可以變的，前期沒有思考清楚，功能推出後可能是佈署很麻煩、版更很麻煩、造成本來系統的問題、授權管制被破解...
回到主題，上面這張圖是草圖，主要要呈現的是說Outlook與我們系統間的溝通是透過Web Service，不管是寫資料還是讀資料，而我們既有系統間與此套件沒有其他關聯，我既有系統還是只跟資料庫有關聯，而我留了一個授權上的問題讓member去思考，這樣的套件怎麼授權？
以上的圖只是概念圖示，用意在於讓member去思考整體的結構跟要注意的點，當我們把這張圖跟我前面提的非功能性需求一塊談時，你會想到哪些潛在的問題需要進一步被釐清呢？
1.授權管理是一個安全機制，這東西不應該直接跟Client端的Outlook直接做溝通
2.要管制權限、要管制資料進出的內容，這部分會用到系統中一些公用元件，考慮佈署問題，將邏輯寫在Web Service上會比寫在套件中來的好
3.考量對系統的影響性，Web Service管制資料進來的邏輯，應該與系統上的管制相同，避免錯誤的資料進到系統，造成異常
談到這邊，我們又可以再畫一張圖出來：
Web Service在整個功能中反而變成了主角，而Outlook套件只是一個Adapter，授權管理的部分則直接將授權檔放到Web Service可以讀取的到的位置，而系統中的公用元件則佈署到Web Service上(又或者讓系統與Web Service共用虛擬目錄，如此版更時只要版更系統就好)，這樣的設計主要考量點在讓新功能對既有系統的影響較小，如果有影響，也只會是加值。
在系統開發時，將程式關聯與每個程式的角色區分清楚是非常重要的，如果設計方式有偏差，可能會造成一些很難挽救的結果，
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
