“什么是需求的最初形式？”这是和网友讨论的时候引发的问题，我的观点是：最容易理解的需求描述形式就是需求的最初形式。如果你是一个需求分析师（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内置了规则分析引擎，采用多种策略对用户请求进行识别，以打击黄牛，保证公平”

文章虽然很长，但是元芳看得很快，不久就看完了。他抬起头看了看墙上的钟，上网差不多到时间了，于是结帐离开了网吧。

后记

票虽然到手了，但是怎么回去呢？元芳漫无目的地在城市里乱走，不知道怎么七拐八拐，竟然走上了高架。正当想着要往回走的时候，一阵低沉的发动机声音慢慢地靠了过来，原来是几辆载重汽车，轰轰地从元芳的身边擦过，差点儿将他挂到。“我擦！”元芳咕哝了一句，想离开路面的远一点。可是没等他走到桥栏杆那边，桥面的震动变得越来越剧烈了。“不好！”，话还没出口，桥面就整个侧翻了过来。“完了”，元芳心想，“这下真的回不去了”。

各位看官，如果你能够有幸看到当时现场视频监控的话，你一定会看到桥上那个唯一的行人在坠落的一刹那，周边出现了一道闪光，然后就消失了。不过后来有记者提出这个问题的时候，路桥公司发言人辟谣说这个其实是对面翻车时候车窗玻璃反光正好照到摄像头镜头上的灰尘所致，这次事故中并没有行人受伤。