應用程式設計的基本步驟（迭代編程）

文章目錄

• 怎麼做找用例

（此文所指設計是指批量銷售的產品，而非定製話的個案）

很多有兩到三年開發經驗的程式員很想提高自己的應用程式設計分析能力，希望可以以後做系統分析師，可是這項技能很難從書本或者網路直接的學習到，身邊又沒有合適的老師，所以經常無所適從，往往是設計模式比他們的架構師背的還熟，可是就是什麼也設計不好。

寫這些系列的文章，並不打算讓你從程式員可以“突變”成分析師，只是為你提供學習的方向和零碎的技巧。

好，言歸正傳，我們怎麼做分析，剛開始的時候，你不要想著一下子接收一個系統過來，即使再小（麻雀雖小，五髒俱全）也不好。比較容易接手的項目是一些獨立的小模組，他們看起來功能單一，你所需要考慮的面就小的多。

現在就假設你已經“光榮”的接到這個模組的設計任務，有些人可能已經迫不及待的編碼的一番（這個功能太簡單了），呵呵，不是太好，雖然我也是搞極限編程的，但是也不推薦一點不做系統分析。還是按部就班一二三：

• 找合理的功能用例；
• 分析排列用例的重要層級；
• 設計出滿足準系統的第一個版本（沒有文檔嗎？是的，基本上只有用例）；
• 使用用例測試；
• 加入部分未實現的用例，重構目前的版本，再來一個輪迴。
• 直到你認為工期就要到了，趕緊收手，或者你很聰明，搞定了所有用例；
• 出文稿吧。

嗯？和書上寫的差不多嗎？當然差不多，我還沒有神奇到可以發明成一種新的設計方法論。事實上，只是幫你複習一下:)。

步驟都一樣，最重要的還是看到底怎麼做。

怎麼做找用例

要找到合理的用例是十分重要的，一般你可以在這些地方找到用例：

• 現有產品的功能，如果你有老版本，那現有的功能怎麼可以丟呢？否則你的功能做的再天花亂墜，客戶還是說：這個都沒有以前的好。
• 競爭者的產品，其實我們的銷售人員在外面推銷的時候，除了花60%的時間陪客戶，10%的時間講我們的功能，還有30%的時間在講競爭者的產品怎麼怎麼的不好，你看我這個功能他們就沒有。能夠將競爭者好的設計“吸收”進來，會給你減少很多麻煩。
• 來自以前的不管是做好的，還是未做好的二次開發案例，既然存在這些案例，就表示事實存在這些需求。
• 好吧，如果你真的時間好充足，精力好旺盛，老闆也獲批准的話，你還有一個選擇，挑幾個你的典型使用者，到客戶那邊去，像個空氣人一樣的在那裡看他們怎麼工作的。千萬不要拿個本子，露出微笑的面孔，來一句：請問，您有什麼需求啊。

哦，你一定發現了，我把與客戶交流放在最後了，這是不是大忌？這個問題我就要講講找用例的注意事項了：

• 你面對的客戶是他所在行業的專業人員，不是“軟體專業人員”，你才是“人才”，你問他需求，搞錯了吧？所以到客戶那裡是用自己的主觀去“悟”別人的需求。他們提出的需求是外行的需求，你要自己悟出來成內行的需求。
• 用例切記防止需求膨脹，需求膨脹主要表現有：
• 暫時不要的功能，未來8年的功能基本就不要考慮了；
• 過分的效能和負載，明明是幾百人的小廠，卻想辦法要搞一個Server Load Balancer，上千線上使用者並行作業；
• 過多的相容性，你的產品明明就只賣1萬塊錢，你卻要搞SQLServer和Oracle兩個版本出來；
• 客戶隨口的“強烈”需求。這個就不要說了，好多文章發過此類警告。
• 用例必須是簡單的，對於總結出來的用例，必須非常的簡單，如果太複雜，建議再拆分成幾個更簡單的用例。簡單的用例能夠減少交流時的歧義。

網上有很多的需求用例的模板，可以參考拿來用用，一般最重要的是：輸入和輸出，需要描述的很準確。

好了，文章也一樣，還是短一點的好，我將有空的時候再繼續寫：如何將需求用例轉化為代碼。