都會女子的異想世界

今天針對某一個畫面的操作，討論使用者各種輸入狀況的可能性，瑪姬和 KiKi 媽咪的進入點完全相反，KiKi 媽咪經驗多、又是寫程式出身的、邏輯也還不錯，所以習慣大約先歸類了百分之70% 左右，就會推理出邏輯，但因為只想到 70% 案例，所以常會漏一、兩邏輯點。瑪姬不會寫程式，因此習慣用使用者案例的方式去想，但舉了很多很多例子，卻不會整理出邏輯。今天，針對瑪姬的做法，討論了如何彙整後，變成邏輯。

很巧地，回家在看「金字塔原理」時，正好看到這個理論。

原來，這叫做「歸納」（inductive）及「演繹」（deductive）論證法。

所謂的演繹法，是採用一系列連續性的步驟，也就是一步一步的推理，到最後的得到一個結果。如：

凡人皆會死。
蘇格拉底是人。
所以蘇格拉底會死。

所以整個結論是：因為蘇格拉底是人，所以他會死。

所謂的歸納法，是先用一個複數名詞（或公式），來涵蓋所有的論點，然後，再用案例去論證。如：

法國的坦克車在波蘭邊境。
德國的坦克車在波蘭邊境。
俄國的坦克車在波蘭邊境。

所以，得到的推論是，波蘭將受到坦克入侵。

-----------------------------------------------------------------------------------------------------

用以上的方式用在軟體專案需求分析（也可用在任何的問題分析）。

一．演繹法

使用 use case，將客戶的作業，一步一步的寫出來。但所有的作業，總有例外，將 80% 的正常流程寫在 main description 中；20% 的例外狀況寫在 Alternative ，重要的是，Alternative 可能不只一個哦！（使用右腦）

二．歸納法

將 use case 拆解開來，使用 matrix 圖表，將參數寫在 X 及 Y 軸；或是「金字塔原理」的金字塔，組織、分類，寫出邏輯，如：IF…..Then……Else…….如果這樣，那麼會怎麼，不然就那樣。（使用左腦）

三．驗證

將演繹法寫下的案例，套用在歸納法的邏輯中，看會不會有套不上的狀況；若會套不上，表示邏輯有漏洞，若沒有考慮清楚，系統就會漏洞一堆，bug 就出來囉！

這個方法，也可以用來做為問題及解決方法的研究，找出問題漏洞哦！！！