縱談軟體預構（二）——需求確立

         今天從服務談起，21世紀的今天，事事講究服務，在IT界，服務這個概念也日漸興起，越來越多的概念都涉及到了這個詞:Service。從Web service，到SOA，Service可謂是無處不在。

         在我眼中，軟體業就是一門服務行業，軟體開發的目標用最簡單的一句話來概括——用最短的時間開發出最好的軟體，這句話是我整個“軟體預構”系列的核心，重點依舊是那兩個詞：最快，最好！

         好了，中心確立，那現在就從這兩個點展開談起。

         先說快，談到快，相信大家腦中都會浮現出這樣一個概念——快速原型。快速原型的最大特點就在需求階段，舉個例子，在做需求時，我喜歡帶著一個業務熟練的美工人員，使用者每提出一個需求，我會立即要求美工用最快的速度開發出一個介面，交給使用者審核，使用者談完需求時，再要求美工用最短的時間開發出一個系統的整體設計圖，無論是用Photoshop，還是標準設計，總之可以遞交給使用者。

         有一句話叫“一圖值千言”，對於使用者來說，他不會關心你的內部實現結構，在他看來，介面就是程式，介面完工，基本上就意味著整個項目幾近完工。因此，我很推崇一句話，叫“代碼未動，介面先行”。

         最快說過，下面是最好。對於使用者來說，什麼是最好？你可以介面難看，可以效率略低，但是對於使用者來說，如果你的軟體不能滿足他的功能性需求，那你的軟體就一文不值。就像使用者明明想要一個拼音IME，就算你把五筆IME做的再智能，使用者也不會買賬。那如何能夠讓軟體最大限度地滿足使用者的功能性需求呢？我的一貫做法是文字用例，在我看來，文字用例比使用案例圖更能清晰地反映使用者的需求，也更容易讓人接受，畢竟你在紙上畫一個圓，有人認為是太陽，有人認為是雞蛋。可是你在紙上寫下“太陽”兩個字，沒有人會把這兩個字念成“雞蛋”。

         編寫文字用例，要清楚地記下使用者所描述的每一個步驟，然後分析每一步，詢問使用者如果某一步出錯應當如何處理。舉個例子，比如說一個足球遊戲，使用者這樣描述一個過人的過程：

        1.運動員做假動作

        2.運動員將球向反方向踢出

        3.運動員追球

         好了，這時你就該詢問使用者：

        1.運動員在做假動作時摔倒了怎麼辦？

        2.運動員如果沒有踢到球怎麼辦？

        也就是說任何一種情況你都要考慮到錯誤和異常。

        接下來要弄清楚使用者的每一個概念，仍然以足球遊戲做例子，使用者提到了假動作這個概念，我們也許會自然地給這個詞下這個概念：假裝去踢球但是沒有去踢。但是我們想過沒有，究竟是向左踢還是向右踢，究竟是假射還是假傳。因此這個概念有著很大的歧義，要明確。

        好了，要點說到這，下面總結下，記得曾經在大學時有過這樣一門課：軟體需求分析與設計。老師對需求下了這樣一個定義,需求就是要知道使用者需要什麼！

        最後說下文檔的問題，“軟體工程”學強調步步有文檔，文檔的作用我個人理解無外乎二：

        1。為層與層之間的人員提供了一個向上透明訪問的介面，比如說需求文檔，設計人員可以不去訪問具體的需求人員，更不用於客戶打交道，他只需要調用需求文檔這個介面就可以了。

        2.  也就是這個系列的主題，“預構”。再次回顧一下預構的含義。就是利用經驗的積累而得到的洞察力去開發新的解決方案。周六去參加了一個Sun科技日，演講者說了這樣一句話,翻譯成中文是這樣：“開源是當今的潮流”。開源一個最大的好處就是可以把成果分享給他人學習，預構也是一樣，文檔交給他人，他人也可以從文檔中擷取經驗。

         因此，我對文檔的評判標準是，能讓他人看懂的文檔就是好文檔。借用這個格式對全文進行總結：能徹底清楚客戶需求的需求分析就是一個好的需求分析。