從使用者需求，談架構設計
前言 軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 Design Pattern 來解決問題、如何快速開發等等，只不過，真正有用的軟體是對客戶有用的軟體、能替客戶解決問題的軟體，才是真正有價值的軟體。 如果，您有非常妥善的軟體架構設計、並整合的 CI／CD 自動化整合測試部署、交付流程，也整合了 Containers 等相關技術，但是 CI／CD 過去卻不是使用者所想要的軟體，那你頂多只是做到了可快速的不斷的交付軟體直到客戶滿意為止，但，如果一開始的需求方向就錯誤了，那就不是 CI／CD 自動化整合測試部署、交付流程所能夠解決的問題，因為你的核心架構可能都需要重新翻寫。 當然，並不是說上述架構設計、自動化測試整合部署流程不重要，架構設計、自動化測試整合部署流程固然很重要，只是，相形之下，做出客戶需要的軟體，後續的各種軟體架構設計、自動化測試作業也才有真正的價值。 關於軟體架構設計 事實上，真實世界中的軟體架構設計應該必須由使用者需求出發，正確收集到使用者的需求，也才能夠正確地做出最佳的架構設計，就專案而言，所以，如果您在分析、與紀錄使用者需求所使用的方式，能與開發團隊相同，且一致的語言 (透明化)，這一致的語言可能還包括，你在分析階段所以使用的 notations 表示法，甚至到您開始做系統設計 (System Design) 所使用的 Architecture documents 、甚至 implement 所定義的 （Programming rule/Coding Standard）等，都在這個的範圍內，也可以說，如果您分析工具如果是建築於團隊開發的共同規範之上，那麼不管你們是團隊進行內部溝通（SA對SD／SD對PG），或是與使用者溝通，都可以將 Gap 降至最低。 在我自己的開發團對裡，我們取用 UML 部分的圖形與 notations 來使用，若您運用的恰當，它可以幫助你在分析使用者需求時，釐清、切割清楚什麼是使用者最關心的，因為，這其實都會與你之後的架構設計息息相關。 為什麼我這麼說呢？ 我下面分幾點為各位說明： (1). 在進行架構設計時，如果要避免「過度設計」，使用 UML 的 Boundary 可明確規範出哪些是系統內、哪