轉載的話:
更是一種思維方式和觀念, 而不再是純粹的軟體需求分析.
轉自 http://www.programmer.com.cn/4425/
文 / 潘加宇
通過可樂、投注站、喝水等幾個生動的執行個體，展示了理清軟體功能主要為誰服務的重要性。随後得出了結論：需求要具體，設計要抽象。或者說，需求，要把産品當項目做；設計，要把項目當産品做。
執行者（Actor）的意義
一個老頭找到PS可樂公司，告訴他們的主管說：“我可是你們的忠誠客戶啊！我喝過的可樂罐排成線，可以從蘋果園排到通州。現在我老了，我對你們的可樂下一個版本提出如下需求：第一，我有胃病，下一個版本不要放碳酸氣；第二，我有糖尿病，下一個版本不要放糖。”PS可樂公司的主管很感動，哇，這麼棒的顧客，把需求提得那麼具體，省去我們調研需求的好多時間，好，下個版本就這麼辦！
會有這樣的場景嗎？不會的。老頭老太太可以買可樂喝，甚至可以買給自己的狗喝，PS可樂公司不會攔着。問題在于，老頭老太太提的要求，或者他們的狗提的要求，PS可樂公司不會放在重要的位置來考慮，因為可樂的目标客戶是年輕人。可惜，很多時候我問開發人員：“可樂賣給誰？”得到的回答大多是“賣給消費者”、“賣給想喝可樂的人”——對做出好賣的可樂沒有幫助的、正确而無用的廢話。
我啰嗦這麼一大堆，其實就是想說，從“可樂可以喝”到“年輕人喝可樂”，多出來的這個“人”背後的意義不簡單。
軟體系統也一樣。如圖1所示，需求的表達方式，從“系統提供定義推廣規則的功能”變成“投注站老闆使用系統來定義推廣規則”，重要的意義就在于發現了執行者（Actor）這個小人。電腦開着，投注站老闆上洗手間去了，有人路過也可以使用投注站系統來定義推廣規則，但“定義推廣規則”這個用例所包含的各種功能需求和非功能需求，更看重的是投注站老闆的意見，而不是路人的意見。
圖1 用例和執行者：賣給誰和賣什麼
和之前的需求技術相比，用例技術（包括執行者和用例）的不同之處就在于發現了“賣”——需求是研究軟體怎樣好賣的技能。以前有觀點以為執行者映射了權限管理，意味着系統需要有權限控制，其實這是一種誤解。一罐可樂打開在那裡，豬路過也可以喝，可樂本身并沒有“防豬”的權限管理，但豬仍然不是執行者，因為豬不是可樂的目标客戶，PS可樂公司不會因為豬喝得不爽就改變可樂的功能和性能。當然，如果你做的是這樣一種“可樂”，豬喝了可樂可以長得更快，那就是另一回事了。不過，你能想到“豬喝的可樂”，不也是拜了執行者思維之賜嗎？
從所有人到一群人
為什麼賣給誰這麼重要？因為競争使得産品分類越來越細，不再有針對所有人的産品了。在原始人眼裡，喝水是很簡單的事情，靠着河就喝河水，靠着泉就喝泉水。随着市場的發展，喝水變得越來越複雜，如圖2所示。
圖2 不斷分化的水，每一種水針對不同的人群
軟體的分化也是如此，見圖3。程式員想用QQ完全可以用，沒人攔着，但他們的意見對QQ的需求影響有多大呢？
圖3 軟體的分化，MSN、QQ、旺旺針對不同的人群
是以，通過思考執行者來理清楚“這個功能主要是為誰服務”非常重要。不過，思考出這個小人不容易，特别是當要開發的系統所服務的組織不是一個有明顯崗位分工的正式組織（例如國土資源局），而是一個松散人群（例如玉米、房奴、驢友）的時候。經常有開發人員問：如果隻是做一個網站展示企業和産品資訊，要不要模組化呢？确實，象完成作業一樣做一個展示企業和産品資訊的網站容易，可是，網站要做到能給企業帶來利潤，企業下次還找你，那就需要做艱苦的調研和模組化。光是“網站給誰看”這個問題，就已經使很多人栽倒了，給“春哥”和給“著姐”看的網站能一樣嗎？
給執行者命名的時候，要拒絕淡而無味的命名，以及正确而無用的廢話。看看對執行者的命名，就可以看出開發人員是否具備探索需求所需的市場思維。有時為了想這個小人的名字，要絞盡腦汁，這樣的需求才有味道、有價值。
起淡而無味的名字，原因除了開發人員對涉衆缺少調研之外，其他原因也可能是開發人員忍不住“透過現象看本質”——“單證人員”等各種人員都可以從“使用者”繼承下來，這犯了從設計的角度找需求的錯誤。設計時可以用“使用者”，這樣許多特征都可以複用，但做需求時是不考慮複用的。
圖4 拒絕淡而無味的命名
我們去小吃攤上買馄饨，老闆給我們餃子或鍋貼，還辯解說“都是面和菜肉的組合”，這樣可以嗎？我在之前的文章中說過：利潤＝需求－設計。小吃攤老闆的賺錢之道就是用少量的材料（設計元件）靈活組合出不同的需求（用例）賣給不同的顧客。
需求要具體，設計要抽象。或者說，需求，要把産品當項目做；設計，要把項目當産品做。
從一群人到一個人
既然需求要具體，定位到目标人群後，有時甚至還要定位到一個人，假裝這個用例專門為他而做。
例如，某個功能為男性提供，那麼如何調研詳細的需求？是對男性群體做大規模調查，還是從CSDN員工裡随機抽取一位男性來深入訪談、觀察？一種方法是問：哪個男人最像男人？得到具體的人物“春哥”，然後，假裝這個用例就是專門為春哥而做，這就是互動設計中用到的Persona方法。
如果一下子想不出來哪個最像，可以通過比較，慢慢逼近答案。例如，說“客戶是醫院”還不夠，還要問，“協和醫院”還是“大興中醫院”更像你的系統所服務的醫院？
做這樣的思考是很有意思的：哪一種水果最像水果？橙還是棗？從科學的角度說這兩種水果是平等的，但我們說到水果時，想到更多的是橙還是棗？哪一種友善面最像友善面？哪一種CT機最像CT機？哪一個SNS網站最像SNS網站？哪一個程式員最像程式員？
目前，介紹GoF23個設計模式的書非常多。大多數書籍在講述時按照建立型、行為型、結構型的順序進行。在這23個模式中，有一個模式經常會放在前言先行介紹，作為例子展示設計模式的魅力，您知道是哪一個嗎？也就是說，哪一個設計模式最像設計模式？
從台上人到台下人
再繼續往下探讨，執行者的原意是“演員”，演員在台上如何表演，由台下各類觀衆的口味綜合決定。軟體的需求也是一樣，由各類涉衆的利益綜合決定，通過執行者和系統的互動演繹出來。将執行者和涉衆分開之後，涉衆一定是人，執行者可以不是人，也就是說，銀幕上演的是喜羊羊和灰太狼，也同樣要考慮觀衆的口味，而用例之前的需求技術所使用的“使用者”這個詞，相當于把演員和觀衆混在一起了。關于執行者、涉衆和用例的進一步探讨，留待下文“這個圈圈不簡單”。
作者簡介：潘加宇，UMLChina首席專家。1999年建立UMLChina，潛心研究需求和設計技能。2002年開始對外提供UML需求和設計的技術指導和訓練服務。
（本文來自《程式員》雜志10年11期）