初探系統設計概念：基本流程、需求

閱讀Ray Dalio那本時，腦中印象深刻的是「 計劃(設計)永遠優先於執行 」這句話，畢竟 在推崇執行力至上的社會氛圍，常會把花很多時間在設計及思考的行為認定為守舊和保守，但在某方面來說，我更相信經典背後的智慧如 ：”人無遠慮，必有近憂”，這恰恰呼應了Ray Dalio提到的，這算是在「認知模式」層面的想法，鐵定可以套用在各領域，比如專案管理或是產品開發，甚至是這篇想要分享的軟體工程概念(不在文章標題寫上”軟體工程”，是希望….這篇的觀念是可以用來在更高層次來活用的)。

軟體工程是門頗有趣的學科，會發現裡頭其實藏了很多不確定性，甚至可以說是在工程學門裡加入人文色彩。另一方面，這套想法其實也能套用在做其他事情，規劃研究計畫、解決日常問題、臨床問題的處理，其實都能把這些做法稍稍修改套用進去。

傳統的軟體開發：瀑布式開發Waterfall

瀑布式開發，可以想成是為了「一次成功」的開發方式，從客戶需求到完成成品，一次完成。這方法在過往非互聯網時代，開發桌機軟體時，頗適合的，因為使用者的反饋慢，需求變化少，產品週期慢。

瀑布式開發最簡單的流程如下

Requirement => Design => Implementation => Validation => Operation/Maintenance

顧聞思義，一步步地從定義需求、設計軟體架構、小代碼實踐、驗證、操作和維持，在以往的桌機軟體就是以這種模式來進行的，當然，隨者業務的變化特性，鐵定會有不同變形存在，比如 V-model/ Sashimi Model/ RUP model/ Incremental Model/ Spiral Model。

敏捷開發(Agile): 更多偏向心態(mindset)的轉變

如此，隨者軟體使用者的情境改變，開發和產品週期變短變快，所謂的敏捷開發(Agile)概念被提出來，而敏捷開發談的是開發時心態的改變，而非一套死板的實踐方法，強調短週期開發閉環，如scrum開發，其實就是建立在敏捷開發上的實踐版本。

許多的基於這框架下的想法和觀念被提出，其實核心思想都在思考如何在新的開發和產品週期特性下，組建適合的團隊和心態：

1. Lean startup

2. Design thinking

3. Project Aristotle Google

4. Growth Mindset

5. Dan Pink Drive

6. Autonomy Mastery Purpose

簡單來說，就是以漸進式地方式演化和迭代，且盡量每個週期能得到最終使用者的意見回饋，而團隊的建立也必須有良好的內在激勵方式和讓團隊成員有能犯錯的安全感。

開發起手式：需求與規格 Software Requirement Specification

就像任何計畫的關鍵是訂立目標，而軟體的構建是為了滿足需求，和特定規格，所以軟體工程的第一步確立需求和規格。在釐清需求以及規格的過程，是以問題導向為主的方式，這過程會建立清楚地描述，來區分什麼是所設計系統要符合的要件，用什麼判斷設計出的系統是對的還是錯的，而其中會產生出文檔，就是傳統所說的SRS檔案，這件事的重要性在於釐清了需求和規格，才能在經濟上去估算成本，以及工程實做面去降低支出。

需求規格文檔其撰寫的對象有兩個，或者說是兩類語言，一個是用使用者所熟悉的語言(需求)，一個則是開發者的角度(規格)，而通常還會有一部分所謂的non-functional requirement，就是無法歸類在使用者的需求或是根據與此衍生的規格，可分三類：

1. Product Requirement:可能產品大牛有特定的想法，作為開發時候的方向

2. Organization Requirement:在公司內開發的話，會有針對現有使用技術的規格

3. External Requirement:比如醫療軟體上會有法規的要求

而是否有好用的模型可以用來分析需求或是規格呢？那WRSPM model算是蠻傳統好用的

如同這模型所顯示的，右邊的系統是我們要設計出來的，而左邊則代表真實世界(或社會環境)，需求來自於社會環境，而規格則是藉由理解工程的人理解需求後對應出來的。

閱讀參考：

Software Development Processes and Methologies