前置需求分析作業

背景
　客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。

需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
　過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
　預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
　請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…

運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
　(1).先討論這件事的程度，意思是說，也許根本可以不理他…
　(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
　(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
　(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
　(1).系統需求分析 (這個步驟可能也會重覆好幾次)
　　將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
　　A.對四個面向分別討論已知及未知項目
　　B.連結各面向關係，檢視彼此衝突
　　C.重覆A、B動作，直到沒有疑慮
　　D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
　　E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
　(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
　(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…

參考事項－需求分析
　需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。

1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。

2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。

3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。

4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…

從實務到理論-2

在上一篇文章中，雖然強調了「第一步，先將自己的實務理論化」，不過卻沒有明確指出「實務理論化」這件事情，在整個論述裏所佔有之地位。所以，本篇補述希望試著說明所提之論述之整體架構意象，讓大家能對這篇文章有更深入的了解。

先談談這份論述所希望表達的事項。這裏其實是先假設，「從理論到實務」是很重要的 (或是說，不斷的改革與創新是很重要的) ，而為了這個很重要的事，我們 (公司或是個人) ，真實面對理論實務化之執行時，對於所遇到之障礙、困擾，反省檢討策略之執行改進方向之際，應該可以從更深層的原點而反思。或是這麼說吧：「如果我們反省檢討時發現，相似的問題總是不斷被發現，而相似的解決方法也總是被當成策略結論，那麼，很有可能，這個問題是來自於更深層的關鍵原因」。

另外，在前一篇文章「從數學而上」裏，隱含著一種「危機與轉機」的意念，而這個意念背後，其所想要表達的，即在於「觀念轉換」的重要性與困難性。觀念轉換本身就是一個意味不明之表徵；要轉什麼? 要換什麼? 怎麼轉? 怎麼換? 上述幾個問號，對於我們這群以舊有的「行為取向主義」之教學方式所教出來的學生，要求重新反思原有先備知識的建構過程與動機，進而從中推尋出資訊鏈結關係之可行的不同架構模式 (創新與創意) ，這幾乎可以說是強人所難。所以，說台灣人創意不足，或是說台灣產業不願投資研發，唯一可以根治的方法，大概也只能期待 "十年樹木，百年樹人" 了。

當然，這樣想太悲觀，也許可以試著找尋其他的方法，來幫助我們思考「從危機到轉機的關鍵轉捩點」。什麼方法呢? 假設，關鍵轉捩點之所以不易被發覺，其實是因為這個轉捩點被隱藏在資訊與資訊的鏈結之中：從一個資訊單體演生轉化成為另一個資訊單體的鏈結過程，我稱為"知識跳躍" (也許也可以稱為"成見"，只是覺得單就"成見"二字的原意，似乎不足以表達) 。如果，假設，"知識跳躍"之問題的解決，可以改善"觀念轉換擁塞"之情形，那麼，希望，"實務理論化"，可以幫助思考與發現我們的"知識跳躍"問題，進而幫助改善我們創新思考不足的情形，從而幫助我們找尋「從危機到轉機的關鍵轉捩點」。至於，什麼是"知識跳躍"，建議可以從"建構式數學"裏去思考答案，如果有機會，再討論吧....

從實務到理論-1

只要有人類的生活，就會有問題的產生；只要有問題，就會有人思考如果解決問題。於是，當人們在思考問題之解決時，或是在尋找改進的方向時，最初最原始的開始，一定是從實務處理上，做抽絲剝繭的分析，將問題發生的進程，切割成為各自小的單元体，然後再逐一找尋問題發生所觸動之關鍵因子，從而尋求問題解決或改進之方法。事實上，對應在程式撰寫，當發現程式有問題，不也是用相類似的方法除蟲嗎!?

好了，當問題能夠獲致解決，接下來的思考方向便是「如何將這個問題的解決方法傳承下去」。在過去，智慧還不算是財產的時候，多數人大都是抱著藏私之心，守著祖傳祕方，等著後繼有。到了現代，情形當然是大有不同，可是，有關「如何傳承」這個基本的問題仍然存在。寫下來，大概是最快最有效的方法了。其實，打從人類有文字以來，用這個方法所傳承下來的過去的知識與經驗，在在與我們生活有著切合的相依性。打從我們開始學習，從小學開始，歷史、地理、國文、數學，都是文字傳承經驗的確切實例。所以，寫文件，很重要...(不過，我討厭寫文件)

再繼續衍生下去，當我們處理了傳承的問題，接下來遇到的就是「如何有效的傳承」。我們從「寫文件」這件事來思考 (假設寫文件真的是有益的) ，「如何寫一篇他人看得懂的文件」、「他人是否能依照文件內之描述來處理問題」、「他人是否能快速的從文章裏找到所需的解」。寫作文，我們講求「起承轉合」。之所以如此要求，是因為這樣子的效果，最能夠迎合人類接收訊息時的情緒轉化，使得訊息的傳達與吸收，能得到最高效率 (有關學習與教育的問題，在很多知識建構主義理論裏，可以找到論証，這裏先不細說) 。回過頭來，不討論作文怎麼寫，而來討論一份「資訊系統技術文件」，從我們現行的作業裏，就可以找到我們的解決之道「文件格式化」。我想，我們不需要在這裏多做說明，為什麼文件要有標準格式；為什麼文件規定要有某某章節...(雖然，我覺得，很煩!)

我們再回頭來看，在上一段的論述中，討論「如何有效的傳承」論點時，我們舉了例子「文件格式化」。在這個例子裏，其實就隱藏著本文的重點論述：「文件如何被格式化」，或是這麼說「如何決定文件要有哪些章節」。假設，我們是時代的先驅；假設，我們是全世界第一家資訊系統開發公司；假設，我們是第一群發現與思考「文件格式化」問題的人。我們該怎麼做? 分析實務進程，切割領域單元，釐清個體關係，然後為不同的單元個體命名，而這些單元體的名稱，就成了文件章節名稱的基礎。

理論必需搭配實務，我想，這句話，大家應該多能心有所感。理論研究的起始，本就是從實務而生，即便有些理論是架構在其他的理論上而演生，其最原始的基礎，依然在於實務。對現代社會而言，「實務理論化」本身就是一種專門學問的研究。通常、一般、大多數人，多是只知如何用，而不知為何可以用 (反過來，一般人在面對理論時，則容易有 "知道 Why，卻不知 How" 的感慨) 。記得以前求學時，好像曾經聽過這麼一個故事 (我不記得是從哪裏聽到的了) --當年，孫中山先生在倡導三民主義時，曾提倡「知難行易」說，因為當時很多人反應聽不懂三民主義，所以不知如何執行。國父舉了這麼一個例子：「大家都知道錢可以用，但很少人知道錢為何可以用」。當初聽到這個例子的時候，我還真的想了很久，思考著錢為何可以用。當然，後來是有想通為什麼，不過，在這個例子的後面，值得我們反思的問題在於，我們的實務作業上，是不是有很多情形，都是知 How，但不知 Why?

「理論必需搭配實務」，所可以反思的方向，即是「實務是否可以理論化」。當然，在上一段的論述裏說「實務理論化本身就是一種專門學問的研究」，這其實是社會分工精緻化的必然結果。所以，真的想把實務經驗化做理論論述，不是一件簡單的事。畢竟，實務情形總是複雜的，幾乎不可能 (絕對不可能) 用單一的理論構面架構而成。所以，一個「策略規劃」理論，可以有五、有九說，相不相信還可以有十三說、八百說....如前面所述，理論的研究可以說是實務的分解過程，至於這項理論的論述是否足夠完整，則取決於實務項目的採樣數與有效性。所以理論不可能完整表述實務過程，正因為如此，一個人的實務經驗，才會擁有超越書本、超越文件、超越理論研究的終極價值。 (終極價值：在人類被機器淘汰前，都應該不至抹滅的價值)

再一次強調，理論研究的目的，本就不是用來取代實務，而是為了提高知識傳承效率、降低學習門檻、加快進入實務的速度，所產生的實務改進方向指標，這個指標，才是理論存在的目的。什麼是理論，而什麼是實務? 就現代角度來看，理論研究應是學者、教授所處理之事務，而實務則被認為執行者所擔負的責任。這個論點，個人覺得並沒有錯。當我們思考「錢為何可用」的時，就應該會發現，分工的細緻化，是這個社會不斷演進的必然過程。只是，這樣子分工的結果，容易導至"好高騖遠"的理論對上"表面功夫"的實務情形，就是我們現在這個樣子!!

好了，不管我們同不同意上一段論述的結論，我們都應該可以、懂得省思自己。我們問自己，什麼樣的理論是會讓人可以實務的理論：答案應該很簡單，有實務經驗的人所提出的理論。反過，怎麼做可以做到理論實務化：第一步，先將自己的實務理論化。

後記：為何要思考「從實務到理論」
假設我們收到一個客戶提出的需求，希望我們幫忙改進客戶的資訊系統。接到這樣的需求訊息，第一步應該會先考量：是要修改原有系統，還是要重新建立新的系統!? (假設我們已經確定必需接受這個需求) 。做系統開發的人，應該多有感觸，有時候，重新建立一個系統，可能要比修改原有系統來的有效率。可惜，這樣子的情形，不大可能發生在組織身上。假設，今天組織要有所變革、組織要有所進步、組織要有所成長，直接把人換掉說不定是最有效的方法，卻也是最難以實現的方法。化做個人來看，成年人學習效率一般都不如年青人，其中的最大障礙，其實是在於「既有成見」。二十世紀以後，受到胡塞爾的現象學、海德洛的存在哲學、高達美的詮釋學等等的影嚮，產生了有別於以往實証主義學習法的「建構主義」論 (有興趣者，建議可先看看皮亞傑的認知建構論) 。「建構主義提出知識是由學習者所自行主動建構的，而非被動的由外界灌輸；知識是建構的歷程，並強調學生先前或先備知識的重要性，主張學習者學習時，應整理統合新的與舊有先備的知識。」 (以上文章取自「科技與學習--理論與實務」一書，心理出版社--沈中偉著)。 上述文章所提的先備知識，其實也就是既有成見的原始相貌，而新舊知識的統整能力，其實也就是一個人學習能力的指標。所以一個年紀愈大的人，擁有的先備知識愈豐富，其新舊知識的統合自然就必需花費更多的時間與精力。所以，很多老師在面對成人教學前，常會希望學員能拋棄成見，將心思放空，就是期望能減少新舊知識的統合所產生的摩擦，以增加學習效率。只是，以現在新的建構主義理論來看，這是不應該也不可能辦到的。這就像是公司要學習一個新的理論技術，要求公司放棄現有的執行模式一樣，乾脆另外開一家新公司算了....