需求分析是至关重要的，对于每个系统而言，需求是生命线，是一切后续工作的源头，笔者在大量的项目实践中发现成功的项目往往在需求定义上相对比较清晰，双方的沟通很顺畅，而死搅难缠的项目往往在需求阶段就能发现苗头，沟通上也困难重重，从某种意义上来讲，一个系统的开发其实就是系统开发商与客户的一次“恋爱”行为，系统从某种程度上就是双方“恋爱”的结果，能否有好的结果，取决于双方是否投入了充足的精力，是否有高度统一的认识以及一致的协调配合，在这里笔者个人非常反对如下两种片面的认识，

->系统开发是开发供应商（俗称“乙方”）的事情。这种思路在客户（“甲方”）中很普遍存在，甲方很多时候都认为签好合同付好钱后就等待系统上线了，这个对于跨行业过来对IT几无了解的客户存在得极为普遍，其实客户在整个过程中起着极为关键的作用，可以毫不夸张地讲，一个系统的成功是甲方的成熟度+乙方的成熟度的和值能够达到成熟的结果。

->需求是调研出来的，这种思路在开发商（“乙方”）中普遍存在，开发人员总是认为需求应该是客户的事情，这些认识都是片面与有害的，需求来源于调研，但又要基于现实的模型进行适度的优化并且设计后的出来的结果，这个也是很多系统失败的一个极为重要的原因，毕竟电脑系统的操作跟纸张操作模型存在着巨大的差距。

很多的项目经理，做了很多年的项目，然而对于需求的重要作用，依然认识不清，当项目成功的时候，归于客户“好说话”，当项目碰到困难或者失败的时候，归于客户“不讲道理”，当然鉴于国内目前的信息业现状，我们只能说应用科学合理的管理方式来提高项目的成功概率，但确实无法保证项目百分之百成功。

笔者认为，为了确保一个项目的需求阶段能够取得成功，如下方面是必不可少的：

a. 合同中有关工作任务的定义，即俗称的SOW定义必须很清晰，很多的开发公司的合同在这块定义极度不清晰，笔者见过的最极端的例子就是只有寥寥数语来简单介绍此合同对应的工作范围，如果各位有幸碰到这样的合同，唯一能做的就是紧紧拉住客户关系，烧香拜佛了，乞求客户控制需求欲望了，不要将一个几十万的MIS系统演变为一个数百万的ERP系统了。 那什么样的定义才能称为清晰的范围定义呢？ 笔者认为必须满足如下标准：

1.流程定义清晰，板块划分明确； 如果无法划分的部分建议不要放到合同中，否则害人也害己；

2.角色分明，功能点定义明确；如果都不知道有几个用户需要使用此系统，那角色定义以及功能点定义肯定就是一塌糊涂；

3.必须量化每个功能点，建议大家使用业务信息字段数量以及页面数量、流程数量、报表数量的定义放到此SOW，量化是最好的去模糊手段；

b. 定义好项目的管理组织结构，梳理好双方的项目管理组织结构，建立通畅的项目沟通渠道，并且将决策人员在关键点确认上必须予以加入，此处理论上很好解释，实践中的难处在于如何真实地确定这些实际的内容，笔者的建议是直接咨询付款决定人由他/她来直接告诉你这个结构是最为合适的；

c. 控制好需求确认流程以及需求变更流程，并且严格形成文档， 此处的流程与文档是需求的关键环节，很多的年轻项目经理，由于阅历比较浅，总是依赖于口头上的确认，以至于日后发生争执时，只能顿足捶胸地说，悔当初没能记下来这个那个；其实严格的流程是保证效率的关键，而文档是证据管理的根子，同时证据管理又是项目管理的关键环节，忽视证据管理的项目管理失败是在所难免的；

d. 跟客户的干系人必须讲清楚项目的最终目标是什么，很多时候这些关键控制人总是热衷于尽力提需求，总是尽力将系统变为一个尽善尽美的系统，这个时候必须得统一大家的思路，双方的目标不是构建尽善尽美的系统，而是构建一个可用、适用系统，能够满足大多数目前能够看到的清晰需求（在合同当中严格定义过的系统），另外特别需要强调的是，尽善尽美的系统本来就不存在，人类对事物的认识总是按照哲学规律在逐步深入的，此处笔者常用的例子就是乔布斯做iPhone与iPad，在此之前他失败过多少回，何况iPhone/iPad也经历了这么多代，如果他老人家能构造一个近乎完美的iPhone，哪儿还来iPhone3, iPhone4, iPhone5这么多代的发展呢？

结合本文的主题，假如我来架构12306网站，如何来实施需求调研工程呢？笔者根据自己的经验，大体可以分为如下几方面：

功能需求：

从12306设计的功能角度来看，主要需实现如下2大块业务：

主营业务需求： 此处包含了如下几个大块的基本需求。

客运服务需求，此处系统需求的核心是构建一个以用户为中心，围绕用户在铁路旅行方面的服务需求来进行展开的各项服务，其基础服务包含如下几块：

出行服务： 用户注册、车票预订、退票服务、余票查询、列车时刻表查询、车次查询、发到站查询、票价查询、中转查询、车站经过、车次查询、起售时间查询、正晚点查询、客票代售点、铁路旅程规划等；

接行服务： 车次查询、列车时刻表查询、发到站查询、正晚点查询、旅客信息查询、列车信息、乘务服务信息查询、接行信息服务等；

托运服务： 提供货物交运、状态监控、到站提取、安全保证服务等；

用户支付服务： 便捷支付（主流银行以及网银支付）、支付账单、对账查询、退款、支付投诉等各种支付服务；

货运服务需求，此处系统需求的核心是构建一个以服务于货运主的货运需求为核心的各项服务，其基础服务包含如下几块：

货运服务：其中包含整车、散货、小件物品运输业务办理、跟货运相关的理赔业务的办理等；

货运信息服务：其中包含货运路线、车辆运输参数、运输能力、运价、保价、运输时刻信息、货物安全保障信息、运输方案等各种运输信息服务，其目的是帮助货主寻求合适的运输方案，提供便捷的货运服务；

支付服务： 企业支付服务（含线上与线下支付服务），个人支付服务、支付安全等；

信息发布需求，此处提供是铁路运输相关的各类法律、法规、发文、消息、新闻等各类信息；

后台管理需求，包含如下几部分：

客运管理后台，提供各类客运相关的基础数据譬如列车班次信息、时刻表信息、票价信息、车票分配策略调控、列车运行时刻信息、各种起售时刻信息等；
货运管理后台，提供各类货运相关的基础数据譬如列车的车辆运输参数、线路信息、运力、运能、时刻、运价等各类跟货运相关的信息；

信息发布管理后台，提供跟铁路运输相关的各种法规、规程、信息集装、新闻、公告信息等的录入、维护等；

各类角色的管理，提供各种级别的角色管理，并且这些角色还需要跟各列车车次以及路局等直接相关联；

其他系统级别的后台管理服务，譬如用户管理、用户投诉、角色管理、系统维护服务、系统监控服务等；

增值业务需求：

目前的12306网站暂时不提供此类业务，但笔者认为凭借着铁路在全国齐全的路网以及运价、运能的优势，在中长途的货物运输上面，公路以及民航几乎无力与其进行全面竞争，因此此处的增值业务还是大有作为的。

物流增值服务： 考虑到铁路的布局全面性，因此建设现代化的大型物流基地，培养形成一批网络化、链条化、规模化、具有知名品牌的大型现代物流企业，为目前的货运服务提供延伸的现代物流服务而不仅仅局限于铁路运输服务是非常有切入价值的，此块增值业务为其最大的增值服务；

电子商务服务： 由于铁路几乎掌握全国70%以上的大宗货物运输服务，因此对于供需双方的信息以及货物信息以及季节性具有非常强的全局掌握性，由此引发的信息匹配增值服务也可以极大地服务于各大型制造、物流、贸易类型的企业，由此而引发的各类电子商务增值服务也是独具天然优势的；

其他类型的增值服务： 针对服务的个人、企业等提供各类增值服务，譬如各类出行方案挖掘、VIP服务、运输类数据挖掘带来的运输方案优化等各类增值服务将极大地带动铁路的运营活力的发挥，同时为铁路带来大量的增值收益。

性能需求：

精度方面的需求： 其中包括了用户的数据精度，特别是时间、金额、密码等重要敏感数据的精度要求以及各类计量规则方面的需求（含四舍五入规则等），依照铁道部的要求制定出相应的精度方面的要求；

响应时间与时间特性方面的需求： 由于此系统服务的用户数量非常巨大，初步估算都是在数千万并发用户级别，并且考虑到后面的交易系统依然沿用了诸多旧的交易系统，因此在响应时间方面过去的基于TPS的计算模型比较难于精确地预估到在响应速度方面的需求，此处笔者建议通过原型系统的演绎方式来做，具体地来说先投入一部分资金依照目前的核心业务需求开发出一个原型交易系统，依照铁道路内部的系统架构来部署一个小型测试系统（譬如20台服务器规模）实施测试，然后做适量的服务器增减来测算CPU/Memory/Disk IOPS/Network bandwidth与用户数量的变化关系曲线图来测试用户的响应时间等方面的需求，逐步求精，但在实际的用户需求规划时依然需要坚持平时用户的单个页面响应速度<2秒，高峰时<5s这样的计算与设计标准，达到优良的用户体验；

安全性需求：

1.外部安全需求

防黑客入侵，需要防止黑客从外部入侵的如下几种手段：

利用操作系统以及防火墙的漏洞等进行入侵获取高级别的权限；

利用特洛伊木马程序来感染并且获取系统的高级别权限或者窃取敏感的交易数据；

口令猜测，通过暴力破解以及字典攻击等方式来实施管理员口令猜测，以期实现对系统的入侵；

缓冲区溢出攻击技术；

扫描探测技术；

防拒绝服务攻击(DDOS)，多人同时向主机提出Web请求，在流量到达一定的程度之后导致系统无法为真实正常的用户提供访问服务；

防页面注入攻击，通过HTML、Javascript、SQL等人为地构造计算逻辑来攻入系统导致系统的崩溃或者数据异常；

防IP伪装技术，通过截获、分析数据传送包来分析同时构造新的数据包发送到服务器来实施攻击；

2.内部安全需求

防止数据丢失与被盗的安全机制，需要杜绝生产环境下的数据丢失以及被盗，建立起一整套数据的储运、销毁等的数据安全保障机制；

防止管理员密码遗失与被盗的安全机制，对于管理员密码，必须以一定强度的加密格式予以安全存放，同时建立严格的管理制度，禁止管理员私自将自己的密码在未经流程许可的前提下告知他人等行为发生，避免密码的传播与遗失、被盗等情形；

防止交易数据篡改，特别是要防止超级管理员（含应用管理员与数据库管理员）在未经许可的流程下私自篡改系统数据，另外更改数据的行为系统都要有可以审核的记录，特别是账户与交易信息必须具备修正历史可供查阅；

高可用性方面需求（HA)： 可以确定的是在高可用的规划方面，应该将此系统的定位确定在7*12小时的可用度在99.9%这个级别，用户的系统可访问度定义在95%以上，这样整体的高可用能够达到大多数用户的心理预期。

系统接口方面的需求：12306系统由于关联了众多的铁路局的内部管理系统以及调度系统，另外也关联了众多的支付接口，因此系统的接口部分内容极为众多，大体上按照性质可以划分为两个大类 即内部系统接口以及外部系统结构，另外按照提供与调用的关系 分为12306提供给其他系统的接口与调用其他系统的接口， 对于提供接口，需要明确接口标准，建议采用Restful格式来提供给其他系统并且对于普通信息可以走HTTP通道，而交易信息必须走HTTPS通道来实施，对于调用其他系统的接口将依照既有系统的接口形式来逐个细化实施；

软件的其他部分需求： 其他方面的需求主要包括如下几块：

运行环境方面的需求： 这当中包括了服务器端的硬件环境（服务器）、软件环境（操作系统、数据库、应用服务器、中间件）、网络环境（包括数据中心的布局以及分布式设计、网络连接以及容量设计）等方面的需求；另外对于客户端，需要明确指出支持的浏览器的种类以及版本、需要安装的安全组件（插件）等。 笔者特别需要提到的是很多需求调研都忘记确认运行环境， 结果到上线前用户使用Firefox甚至IE6等来检验发现根本无法进行验证运行的情况，其中的苦只有自己能够知晓了。

系统可维护方面的需求： 其中包括Bug修复流程、系统发布流程、系统升级部署流程、系统扩容流程方面的需求，考虑到此系统的服务器数量众多、地域分布有一定的广度，因此在设计此部分维护性需求时必须考虑到凡此种种情况。

系统可监控性方面的需求： 其中包含服务器端的常规监控（CPU/Memory/Disk I/O)以及网络流量监控，另外需要特别增加对于交易事务队列以及请求队列的队列长度、去化速度等方面的监控，从HTTP方面需要监控每个request的去化速度以及队列长度，从而从各个方面全面地了解系统的当前性能指标。

其他需求包含了可移植性、可扩张性等各个方面的需求。

需求文档的写法： 此处列出需求文档的全部目录结构供大家参考，具体的文档内容就不贴出来了。

1. 引言

1.1 编写的目的

1.2 背景说明

1.3 术语定义

2. 任务概述

2.1 目标描述

2.2 功能性需求

2.3 业务信息定义

2.4 约束条件

3. 数据流图

3.1 全局数据流图

3.2 各子块数据流图

4. 系统接口

4.1 用户接口

4.2 硬件接口

4.3 软件接口

5. 性能需求

5.1 精度要求

5.2 时间特征

5.3 灵活性

6. 软件属性

6.1 可使用性

6.2 系统安全性

6.3 可维护性

6.4 可移植性

7. 系统配置需求

7.1系统硬件和软件配置

7.2网络配置

7.3网络拓扑图

8. 其他需求

8.1 数据库需求

8.2 故障及其处理需求

可以毫不夸张地说，需求确定的清晰程度以及双方的认可度，直接决定最终项目的成败与否，很多的同事总是抱怨客户在最后不讲道理，不留情面，其实仔细分析发现项目开始的时候项目组就已经沟通很不充分了，存在了巨大的隐患，留给整个项目的执行是无穷尽的遗憾。

项目需求的沟通可以简单、形象地总结为一句话： 需求调研就是了解在什么环境下（服务器、客户端环境、网络环境）实现怎么样的一个系统（功能列表），其可用度如何（性能、安全、可靠度）？

理论虽是如此，可实际执行的时候大家还是发现存在如下的诸多问题：

1. 跟客户的一个领导将需求讨论清楚了，可是后面换了新领导，整个思路全变了，系统也必须大改， 如何控制需求？

2. 跟客户下面的项目管理人员定义得很清楚了，可是等到最后给高层领导一看，才发现需求根本偏向了，怎么办？

3. 在设计、开发过程中，客户总是想方设法变着法子来添加需求，还会有种种这样那样子的理由，需求想控也控不住；

4. 碰到极端客户，就算你一开始跟他谈得很好，也签字认可了，到了后面一翻脸就说，这事儿我还得改，否则我就不打算让你上线？

如此种种，令很多理论派PMP的管理人员手足无措，也不知何从处理，根据笔者的个人经验来看，如果真的出现上述情况了，那我们还得必须考虑一下，任何项目管理都是寄生于企业的管理生态与社会的交往生态当中，此处从PMP的经典理论已经无法来解决上述问题了，必须升华为管理生态以及客户关系生态来解决了，此时项目经理必须借助销售以及公司的其他各种途径来突破解决此问题了。