老翅寒暑

    “什么是需求的最初形式？”這是和網友討論的時候引發的問題，我的觀點是：最容易理解的需求描述形式就是需求的最初形式。如果你是一個需求分析師（BA），客戶嘴里說出來的需求被稱為是“原始需求”，這一類原始需求是沒有經過整理的，而且是沒有章法、次序顛倒甚至邏輯混亂的。BA需要把這些原始需求整理成一個各方都可以接受并理解的需求描述形式。

    這是正規需求過程的第一個產出，如我在“需求與設計過程（1）”中講的那樣，人腦處理是非線性過程，大家千萬不要在原始需求整理的時候只出一個東西，你可以并行出N個東西，比如數據詞典、類圖、用例圖等，想到什么就做什么。需求的整理只是主要工作之一而已，不是唯一的工作。

    一般在原始需求獲得之后，BA就會開始整理“用戶故事（User Story）”或者“用例圖”，甚至直接開始寫“用例描述規約”。可是從我的實踐中發現，無論是User Story還是Use Case，他們都缺少場景描述。但是人腦要充分理解需求，恰恰要依賴場景，場景可以把一個一個貌似獨立的需求故事串聯起來，形成具有豐富意涵的大故事。有些同學可能認為需求場景描述的東西使用分層的需求故事或用例也一樣可以實現，但是我發現我看這些東西10分鐘內基本都會開始打哈欠，你呢？因為分析的需要，我們需要干巴巴的需求故事，但是如果需要和多方進行溝通，我認為“需求小說”是最好的形式。

    所以，我們如果要在需求中加入場景，那么這個需求就可能是如下的這個樣子。我拿12306ng項目的作為例子，寫得可能文藝了一些（因為我想借此鼓勵用戶的反饋），實際上的用戶需求，用普通的寫法就可以了。

前言

     元芳一覺醒來，發現自己穿越了，正在火車站的售票處。看著一條條長龍匯成的人山人海，他一下子蒙了，過了好久才明白過來。昨天下班前，狄大人突然問：“元芳，如果我十一回老家一趟的話，你有什么看法”？元芳不由得菊花一緊，“看你妹啊！”，心里這么想著，連忙緊步上前：“那就由卑職給大人安排一下行程”。這叫“有沒有金剛鉆，都得攬這個瓷器活”，就算是公務員，也有不好當的時候。結果昨晚一直在想這個事情，到凌晨才迷迷糊糊睡著，然后就被售票處的嘈雜聲吵醒了。“做什么清官啊？連個火車票的后門都不走！”，元芳嘀咕了一句，狠狠地盯了售票處三個字一眼，走了出去，“還非要十一前到”。雖然他和狄大人關系很不錯，但是牢騷還是要發的。

     出門不遠就是個黑網吧，元芳決定到這里試一下。這次他沒有拿出他的捕頭證件，他還記得上次去網吧上網前登記時候，老板看著他證件的那種驚恐的眼神和慘叫：“警察來啦！！！”，結果害得他差點被奪門而出的人群踩死。

     在昏暗的燈光下，元芳好不容易找到一個位置。例行的開機和C盤還原步驟之后，深度版XP的藍色水滴背景出現在眼前。雖然元芳在衙門有過相關的培訓，可是一雙弄慣了刀槍劍戟的手，使喚個鼠標總覺得不順手。折騰半天，看著屏幕上白白的瀏覽器底色，他終于決定找個幫手。于是，抬起頭來前后左右看了一看。這一看不要緊，元芳差點兒笑出聲來，原來左右兩臺機器屏幕上都打開同一個網頁，碩大的“中國鐵路客戶服務中心”在頁面的頂部不停地閃著。

     搭訕是元芳的強項，且因為還沒有到7點，大家也都在等放票，所以沒說幾句，大家也就熟絡起來。右邊的小伙子稱作小白，因為有點急事要去上海，準備買到票之后立刻出發。左邊的小伙子叫小明，他則是有著充分的準備，就是要來搶回家票的。當元芳說了他的困難之后，小明和小白都表示可以指導元芳，在簡單的培訓之后，元芳決定再看看兩位“老師”的操作再說。

快速訂票的小白

     小白話語不多，但是卻在不停地看著時間和刷屏。他沒有登錄12306，因為他不太喜歡把自己的隱私暴露在網絡上，所以這次他采用直接購買的方式。

     所謂的“簡便購買通道”就是一個免登錄的通道。小白直接通過輸入出發和到達地的方式查詢到了他要的車次，然后直接進入訂票環節去提交訂單。但是因為時間還沒有到，所以他簡單地停留在了車次查詢結果頁面上，因為沒有登錄，所以也不存在會話超時的問題。在等待的時間里，小白拿著一張報紙，邊看邊回答元芳的提問。

     很快，時間到了。為了保險起見，小白刷新了一下他的查詢，然后迅速地點擊了一下車次列表后方的“快速訂票”，直接進入了訂單填寫頁面。因為實行實名制購票，所以除了車次和票的張數已經自動填好了之外，小白還需要選擇席別（當然是臥鋪了），然后填好自己的身份證信息和手機信息，不過他沒有寫自己的郵箱，從防止隱私泄露的角度看，當然是提供信息越少越好了。最后當然不能忘記要填寫一個CAPTCHA驗證碼，就提交了訂單。

     訂單提交完成之后，立刻跳轉到了網銀支付頁面，在選擇自己的支付方式之后，小白完成了支付。

     看著頁面跳出的支付成功頁面，小白長吁了一口氣。這時，他的手機也響了起來，訂票成功的短信也收到了。元芳下意識地看了一下時間，從填寫訂單到訂票完成，前后不過5分鐘的時間。接著就是簡單的收拾一下，小白和元芳打了個招呼，起身趕火車去了。

     小白用的電腦沒有關閉，元芳看到支付成功頁面下方的一串訂票序列號數字，20121223-03665436，心里不由得“咦”了一下，怎么這串日期數字這么熟悉呢？

搶票的小明

     小明是來搶票的，不僅為了他自己，也為了他一幫工友。為了搶票成功，小明已經在前幾天做了好多準備工作，包括注冊用戶帳號，把訂票需要的線路和乘車人信息等一些常用的內容預先錄入到12306中。為了學習如何訂票，他甚至訂了一張最便宜的票然后再退掉。

     小明和小白最大的不同，就是他很喜歡說話，也喜歡幫助人，訂票的每一步操作，他都會詳細地解釋給元芳聽，所以在他的指導下，元芳很快就學會了訂票。

     小明首先輸入用戶名和密碼登錄了網站，然后在收藏夾中找到了保存的車次，因為工友眾多，所以他保存了好多個車次的信息。小明的第一張票當然是訂給自己的。他熟練地從收藏夾找到了自己的車次，順手點擊查詢了一下該車次的余票信息，發現還有許多，于是直接點擊“訂票”。

     進入訂單填寫界面，車次信息和該車次的余票信息展示在頁面上，之前錄好的常用聯系人信息，也變成復選框羅列在頁面上。小明快速地勾選了自己和女朋友的姓名，因為一個訂單只允許購買5個人的車票，所以乘車人信息很快就選滿無法繼續添加了。

     接下來當然就是提交訂單了，小明為了加快速度，已經將票款預存到網站了，所以只需要選擇使用預存款支付，就完成了支付動作。完成支付之后，系統立刻跳轉到出票成功頁面，顯示了訂單號，同時，手機和郵件也分別收到了相應的通知。

     因為工友眾多，加上一個帳號同一天只能預訂5張票，所以小明采取了兩個策略進行訂票，一個是將工友分批在不同時間回家，通過同一個賬戶訂票；另一個策略是使用多個注冊用戶分別訂同一天的票。所以小明在不同的賬戶之間切來切去，把元芳看得眼花繚亂。

     很快，小明就遇到了麻煩：他發現訂票頁面進不去了，頁面上始終是這樣的一行文字：“防黃牛策略檢測到你的行為異常，所有的已訂票已經被凍結，請和客服中心010-12345678聯系，提交相關補充資料！被凍結的訂單號是：20121223-00156544,20121223-00156790,20121223-00158311”。小明慌了，用家鄉話連打了幾個電話之后，氣急敗壞地離開了網吧，連和元芳打個招呼都忘記了。

訂票的元芳

     看著小明離去的背影，元芳嘆了口氣。看了兩個人的訂票操作，自己覺得學得也差不多了，但是沒有人在身邊，總覺得有點不安穩。沒辦法，先走走看。

     于是，元芳打開了訂票頁面。第一步驟當然是注冊用戶帳號了，而且元芳想要保留一個注冊的用戶，以便以后穿越的時候使用。用戶注冊需要登記用戶的登錄名、密碼和驗證方式。這里的登錄名可以是自己的昵稱、手機號碼或電子郵件地址三種之一，驗證方式可以是手機也可以是電子郵件。因為元芳沒有手機，所以臨時注冊了一個電子郵件充數。用戶注冊完畢之后，界面提示說已經往電子郵件地址發送了一個激活鏈接。

     元芳打開他的郵箱，點擊了注冊驗證郵件中的鏈接，頁面跳轉到了注冊成功頁面，大大的“恭喜”字樣閃爍在眼前。在重新登錄12306之后，元芳開始尋找可以乘坐的車次。尋找所需的車次有幾種方式，一種是輸入起始和到達地點就可以查到可用的車次列表，然后由用戶從中選擇；一種則是通過旅程規劃功能來規劃線路。因為有學習的意圖，所以元芳想兩個功能都用一下。通過起止地點方式查詢車次很簡單，輸入起止地點的拼音或者漢字，頁面就有提示，點選“查詢”之后，出現一個符合條件的所有車次列表，列表中有車次，起止地點，起止時間，每個列表項之后有“訂票”和“查詢余票”按鈕。

     旅程規劃則是比較復雜，首先需要錄入旅程的人員名單，到達的每一個站，以及到站停留的時間，另外還可以指定旅程的策略，比如是否介意白天坐車、時間是否比較嚴格等。系統會根據這些信息設計一個買票和乘車的計劃，用戶可以將這個計劃和12306的其他用戶進行共享，也可以修改、刪除、保存這些計劃。當然，也可以對計劃中的某個旅程直接進行訂票。

     元芳在車次里邊選了一個最快的，選好車票之后，開始填寫訂單，當然訂的是狄大人的票，所以元芳選擇了往返票的屬性，填寫了回程日期。仔細檢查過幾遍之后，小心翼翼地按下了“提交訂單”按鈕。可是誰想到彈出的界面告知“所訂車票已經售完”，然后列出了幾個可以替代的車次和這些車次的余票。元芳無奈，只得選了可替代車次中最快的那輛。訂單中除了車次有變化之外，所有填入的信息都還保留著。元芳再次仔細地看了一眼CAPTCHA驗證碼，填寫之后，提交訂單。

     這次訂單成功提交，進入了支付頁面，面對滿屏幕的銀行名字，元芳一下子蒙了。再加上他沒有銀行卡，所以直接找到網吧老板給他現金，讓老板在他的機器上登錄并代為支付了。然后元芳進入“我的訂單”，看到訂單的支付狀態已經是完成。在“我的車票”里，車票信息列表中顏色分明，所有已經乘坐的車票是灰色，已經購買但是未使用的車票是黑色，而已經退款的車票顏色則是淡紅色。所有的車票按照時間歸類，顯得十分清爽。尤其是在已經購買但未使用的車票分類后加插了一個“乘車須知”，用簡短的幾句話把乘車的注意事項說明白了。元芳好奇地點了一下乘車須知里的連接，結果跳轉到了一個圖文并茂的乘車詳細規則介紹頁面。看完了介紹，元芳對如何乘車也心里有了一個底。

報紙的八股新聞

     車票訂完了，現在周邊也沒幾個人。元芳整理了一下桌子，準備離開。臨走前四處查看了一番有沒有遺漏的東西，結果眼光落到了小白桌上的報紙上，小白離開的時候忘記帶上了。報紙上正巧是對12306工程師的一個采訪，于是元芳就依舊坐下來，拿起報紙看了起來。

     “12306的新架構是在第一代系統的基礎上總結而成，充分利用了云計算的可伸縮能力，達到了性能和費用的新的平衡。在用戶接入的最前端，是N臺高端負載平衡機組成的平衡光纖網絡，各個負載平衡機之間不僅可以共享緩存數據，也可以互為備份，消除了負載平衡的單點故障，更重要的是把動靜態數據請求完全分離到不同的機器上進行處理。”

     “用戶的所有請求在通過負載平衡網絡之后，平均分散到后臺的各種類型的處理機器上。靜態業務處理云負責處理所有的靜態資源請求，而動態業務處理云則處理所有需要程序處理的請求。動態業務處理云會根據需要，將數據查詢的請求發給數據處理云。而數據處理云則根據具體的數據處理類型，分別調用后臺的NoSQL、數據庫或者鐵道部的票池隊列。所有的云都會根據業務量的變化，動態地擴展或收縮。”

     “除了用戶訪問數量大，后臺的資金流動量也十分巨大，后臺資金處理模塊和銀行的對賬十分頻繁，因為資金問題引發的客戶服務請求也十分巨大，進而引發了客服系統的性能要求和系統后臺對客服的支持需求。”

     “為了滿足網站的性能要求，設計團隊對每一個數據的實時性進行了仔細的分析，針對不同的數據性質，設計了不同的存放策略。比如線路的余票信息就是一個NoSQL緩存中的概略數，而用戶提交的訂單信息則會通過MQ傳遞到訂單處理模塊”

     “在安全性上，有專門的安全團隊負責審查整個設計和代碼，確保漏洞及早被發現。在公平性上，12306內置了規則分析引擎，采用多種策略對用戶請求進行識別，以打擊黃牛，保證公平”

     文章雖然很長，但是元芳看得很快，不久就看完了。他抬起頭看了看墻上的鐘，上網差不多到時間了，于是結帳離開了網吧。

后記

     票雖然到手了，但是怎么回去呢？元芳漫無目的地在城市里亂走，不知道怎么七拐八拐，竟然走上了高架。正當想著要往回走的時候，一陣低沉的發動機聲音慢慢地靠了過來，原來是幾輛載重汽車，轟轟地從元芳的身邊擦過，差點兒將他掛到。“我擦！”元芳咕噥了一句，想離開路面的遠一點。可是沒等他走到橋欄桿那邊，橋面的震動變得越來越劇烈了。“不好！”，話還沒出口，橋面就整個側翻了過來。“完了”，元芳心想，“這下真的回不去了”。

     各位看官，如果你能夠有幸看到當時現場視頻監控的話，你一定會看到橋上那個唯一的行人在墜落的一剎那，周邊出現了一道閃光，然后就消失了。不過后來有記者提出這個問題的時候，路橋公司發言人辟謠說這個其實是對面翻車時候車窗玻璃反光正好照到攝像頭鏡頭上的灰塵所致，這次事故中并沒有行人受傷。