序言 世界著名IT咨询公司Gartner在评选“2020年全球十大技术趋势”时将RPA排在了首位，且预测2020年开始往后RPA每年的全球市场规模将以100%的复合增长率增加，预计2022年将达到50亿美金的规模。...
序言
世界著名IT咨询公司Gartner在评选“2020年全球十大技术趋势”时将RPA排在了首位，且预测2020年开始往后RPA每年的全球市场规模将以100%的复合增长率增加，预计2022年将达到50亿美金的规模。全球500强公司近半数已经采用RPA技术用于解放公司的人力成本，著名投资公司红杉资本和软银也纷纷在此市场占道，究竟此种技术具备什么样的特性能够被市场认可其价值？
RPA基础理念及应用优势
2019年可谓是中国RPA行业的元年，不管是创业市场还是资本市场，其热度都较往年有非常迅速的提升。
RPA的全称为：Robotic Process Automation，即机器人流程自动化。首先从这三个关键英文单词来解析：Robotic即机器人，这里的机器人是一个仅是一个虚拟的概念，并非需要一个实体机器人，机器人是这项技术在业务流程中的执行体，简单说就是“执行单元”；Process
即流程，它对应的是业务的逻辑，通常我们将业务需求梳理成一个流程图，这样确保需求能被转化为被执行的流程，再通过前文的机器人来执行这一定制的业务流程或规范，比如我们熟知的网络爬虫即是RPA的一个轻型应用的例子；Automation即自动化，通过前文提及的机器人来执行设定好的业务流程，减少人工反复操作即是为了实现自动化目的。
简言之，该项技术的核心作用是将工作信息流与业务交互通过机器人来按照设定的流程去执行，从而将业务需求被执行的过程变得自动化且标准化。**这个流程也可以理解为一项任务，如果任务流程足够复杂或交互信息过多，则人力成本很高，而通过机器人来替代人工去自动化的完成任务，可以高效解决问题，解放冗余劳动力。
RPA技术从理论上来讲将来会适用于大部分成熟行业的业务流程，由于当前阶段的RPA技术应用总体尚处于场景探索、需求挖掘和产品匹配的早期应用阶段，从目前的技术实践经验来看，现有的RPA技术主要适用于高重复性、逻辑明确且稳定性要求相对较低的流程，高重复性、逻辑明确、稳定性三项也是目前检验RPA技术可行性的基础项和主要条件：
1.高重复性
RPA当前适用的流程必须符合高重复性。从开发来讲，一个流程的实现需要相应的时间成本、开发成本和人力成本，若某项业务流程只是一次性的需或是使用频率极低，那对应的人力成本反而显得不太重要；相反若一个业务流程是高重复性的，那对应的各项成本的节缩和对效率的要求就显得非常重要，RPA在替代人力和减少重复开发上发挥的重要也显而易见。同时，机器人可以自动化的沉淀各项业务信息流，以帮助业务团队在最短时间内搜集确认测试数据，缩短开发周期。
2.逻辑明确
逻辑明确即需要该项业务流程必须是有一定规则或规章套路，若一个业务流程散乱无章，需要人为或者深层经验去主观校审，则其本身不适用于RPA技术。
3.稳定性
RPA技术可以理解为一项操作软件的软件，在实验业务流程自动化的过程中需要反复性的去执行多项软件的功能，也就是跨不同软件去实现业务信息流的交互，如客户端、浏览器、网站等。跨软件执行的过程需要各界面的元素或操作点位匹配到RPA中将要操作的组件，所以一个稳定的流程实现可以降低维护成本。
提及RPA技术与AI，两者在实现业务流程的自动化时会有一定的技术交互，如机器人，但是不能混为一谈，RPA技术广布于业务的各项流程和职能单元中，
如果说RPA就是机器人的神经网络，那AI是机器人的大脑。AI是研究、开发用于模拟、延展和扩张人类智能的一种理论、途径、技术及应用于系统的一项科学技术，AI会从了解智能的实质层面出发，并创造出一种全新的能跟人类智能相仿的方式去做出敏捷反应的智能机器，主要研究包括机器人、语义识别、图像识别、自然语言处理和专家系统等。总而言之，AI技术研究的核心目标是使机器、网络能够胜任通常需要人类智能而非经验记忆才能完成的复杂工作，同时RPA在应用层面上的效率提升也需要AI在机器人技术层面相应提升。
从RPA技术的基础理念和实施条件中，相信大家能够很好的理解RPA的特点及优势，这也是RPA能够给企业创造非凡价值的主要原因：
1.机器人自动化处理
通过用户界面（UI）或脚本语言（Script）就能实现由机器人代替重复人工任务的自动化处理。
2.基于明确的逻辑或规则操作
流程必须有明确的、可被数字化的触发指令和输入，流程不支持无法提前定义的例外情况。
3.以外挂的形式部署于现有业务系统
基于规则在用户界面进行自动化操作，非侵入式模式不影响原有IT基础架构。
4.模拟用户手工操作及交互
机器人可以执行企业职能化工作部分的日常基本操作，如鼠标点击、键盘输入、复制/粘贴等一系列日常电脑操作。
RPA的优势来源除了上述这些众所周知的特点属性外，对于遵循业务规则的高度严肃性（优良的操守品质）、对现有业务系统的非侵入性（非耦合型）连接都是RPA的突出优势，以下为RPA在业务场景应用过程中所主要带来的优势与价值：
1.7*24小时不间断工作，优秀的操作守则
2.替财会、商品批量上架等职能流程中的重复性工作
3.基于明确的逻辑操作，做到无差别化，最大程度降低人的主观因素干扰
4.解放企业的人力资源与使用效率，降低用工用工成本与人员流动性风险
5.每一个任务和信息流都可沉淀、监控并被记录，有助于运用留存数据帮助企业改善业务流程
6.非侵入式的接入现有业务系统，不必重构原有的IT设施基础架构，不影响业务系统的稳定性
7.帮助企业开启业务流程与多元信息交互的自动化视角，识别业务流程中的风险及可优化点
RPA的技术框架与应用场景
从技术层面来讲，总体而言RPA其实不算新技术，可以理解为一项集合自动化测试技术以帮助企业实现信息化、流程化的融合技术，但是它通过多方面结合，使它能够独立出来成为一个产业，专门为企业解决业务流程问题。RPA 技术自 2012-2015 年后在国外开始商业落地，中国从2019年开始火热掀起商业落地潮，目前市场上的明星公司有阿里云RPA、UiPath、Uibot、Blue
Prism、Automation Anywhere等。
典型的RPA平台在技术框架搭建上至少会包含开发工具、运行工具与控制台等三个基础组成部分，即所谓“RPA三件套”。对宏观技术角度的理解将会帮助我们去理解应用场景。
RPA技术框架，制图来源博主“fatroywang ”
且
从RPA技术特性来看，可以梳理出以下“十大典型应用场景”：
1.网站信息爬取
拥有固定规则的业务场景是RPA的理想选择，例如，股票交易网站，期货交易网站，商品交易网站，新闻和媒体网站（基于关键字）等。
2.客户订单处理
RPA可以将放置在许多电子商务网站上的订单放置在实际存储库中以进行调度，并保持与面向客户订单不同的库存记录，将数据输入过程移交给 RPA 解决方案，订单的整个过程将自始至终实现自动化能更好地保持数据的准确性。
3.客户服务查询处理
若是商业性服务公司，如在面对收件箱中的数千封电子邮件以进行响应时， RPA可以帮助将常见问题或电子邮件可以分为几组，并且 RPA 解决方案可以提供对此类电子邮件的自动化响应。
4.系统间数据搬运
若公司没有足够的时间来管理其数据以进行备份或还原的问题，则可通过 为 RPA 提供所需的凭据、源代码和目标详细信息以自动化整个任务，且还可以监视其整个过程。
5.财务薪酬核算处理
薪资、报销等处理就是典例，传统企业的薪资处理等工作都需要逐月进行大量的人工干预且过程重复，使用 RPA 系统从手写的时间表中提取所需的详细信息，并从其规定的 CTC 中计算薪水并同时支付。
6.表单自动化处理
企业在处理任何初始程序才能在其系统中触发的表格时，则进行RPA自动化操作自动读取表单，然后由机器人完成向处理这些表单的应用程序的手动数据输入。
7.客户端配置文件更新
客户群遍布地区广泛的企业，需要频繁调用后端数据库且容易在整个应用程序处理中引起问题，若这些请求由 RPA 控制则可以按批处理请求、而非一个接一个地处理，且可按照规定的后端系统的负载去确保整个应用程序具有更佳的性能。
8.高级续订管理
如高端电商行业，当客户在线或离线支付商品费用时，可由RPA机器人向客户提供商品支付电子化收据与保质单据，并且7 x24小时不间断无需任何人工干预完成客户订单的续订。
9.承保与索赔处理
适用于保险行业，RPA 可将潜在客户信息自动化的进行分类登记以实现在没有任何人为干预的情况下进行处理，以达到降本增效的目的；同时在客户索赔环节，可以通过 RPA 机器人读取表格，来自动输入处理对应索赔声明的应用程序的数据。
10.异常报备处理
广泛适用于银行等金融业以及其他任何行业领域的异常业务信息，可以使用一组确定的规则进行预定义，并且基于规则由RPA机器人来处理这些异常且进行相应分类管理。
以上的应用场景仅是从业务范畴做出的典例分析，从各行业、产业领域而言，涉及相应业务范畴的理论上都适用于RPA技术进行优化改革。
发展趋势与资本市场关注热度
目前阿里云、IBM、微软、谷歌、Oracle、SAP等名牌大厂也优先将RPA集成于BPM解决方案之后，一众云计算、SaaS、企服软件、人工智能、系统集成等厂商纷纷跟进，可以看出RPA未来上云与做成SaaS化的商城展业模式是第一大必然趋势。
近两年，阿里云RPA、UiPth、AA等巨头已经将RPA部署到其云服务器上，由此能够服务更多具有跨域、跨网需求的客户，RPA上云后都顺理成章的变成了SaaS化平台，便进一步催生了RPA商城的诞生。在RPA商城，开发者将RPA机器人、插件、模板发布到市场，RPA商业合伙伙伴以及企业用户可以下载应用。这种模式下既能节省RPA厂商的资源成本，又能让RPA产品在各个领域迅速落地，还有益于RPA产品的快速迭代与完善；重要的是，它还能为企业节省IT资源的投入以及免于技术团队搭建，按需订阅的方式又能满足企业的弹性需求。现在来看，SaaS化的RPA几乎是每个RPA产品的最终形态。
从技术未来的演变与业务场景的应用趋势来看，未来RPA技术将于AI深度融合是第二大必然趋势，RPA将成为当代业务流程自动化、信息数字化及智能化的焦点。
RPA与AI的范畴区分不是很明显，所有当技术足够成熟之后，为了满足更复杂从业务流程场景，自然会应用AI技术；同时，人工智能平台也正在通过RPA产品，将AI的算力以及数据分析、处理及挖掘能力赋能给更多企业，RPA已经成为AI技术落地重要载体。GartnerI在其报告中预测，未来几年中将会有超过40%的组织将通过融合AI技术的RPA产品，来解决更复杂的业务流程管理问题。
两年开始，RPA技术开始正在走进公共部门，全球各地的政府都将意识到RPA在政府服务中的重要价值，进入公共部门及智慧政务领域是RPA的第三大发展趋势。在欧洲，2019年2月欧洲议会开始支持RPA作为公共部门转型的推动者，早在2015年英国就在其国家税务领域进行RPA试点项目、到2017年已有很多政府部门在应用RPA；日本的一些地区政府，同样也在2019年2月开始使用RPA助力政务提效。而在中国，智慧政务正在轰轰烈烈的推进中，利用AI技术手段提高政府部门在办公、监管、服务和决策等多方面的智能化水平，已经成为共识；此背景下，政务服务的“一网通办”，就是RPA在政务智能化服务的典型应用。
随着应用市场规模的增大，用户需求会刺激更多的RPA项目诞生。虽然就当前而言，通用型RPA厂商、云计算厂商、大型企管厂商及老牌RPA厂商，构成了RPA的主流市场；但是，从资本投资热度兴起的角度来看，我们可以遇见将会有越来越多的RPA项目创业团队和RPA培训等第三方服务商的出现，这也是RPA的第四大发展趋势，毕竟春江水暖鸭先知。
如果说2018年7月Automation
Anywhere的A轮融资，像一颗信号弹照亮了全球RPA领域，并让在泥泞中摸爬滚打十数年的老牌RPA企业看到希望曙光，那2019年5月UiPath的D轮融资并且估值达到70亿美金而一跃成为全球估值最高的RPA企业，就像一枚重磅TNT炸药，爆破了全球RPA行业，并由此引爆了全球RPA行业的投资热潮。在中国，原各大厂商（如阿里云RPA团队）中的RPA核心技术、产品团队人员也由此闻声而动，从2019年下半年开始引发了下海创业的热潮，乘着风口赶紧捞金。
国内市场需求显现外加国外明星项目融资热度增加等因素，RPA成为了2019年创投圈的一个小风口，“RPA+AI”则被认为可能成为未来行业的一个更大的风口。根据“王吉伟频道”的测算：做一下大体统计，以美元对人民币汇率按7计算，数千万融资都按3000万计算。保守估计，仅下列表单中2019年国内6个RPA团队的融资来看，其总体市场估值已高达54.2亿人民币。
制表来源见水印
除了VC资本之外，在投资者名单中还能看到了实体企业的身影，像海尔集团旗下的海尔资本就参与了达观数据的A轮融资。随着RPA行业的兴起与各行业产品解决方案的不断落地，将会有更多的传统企业都开始关注RPA应用，这将给RPA创业浪潮及服务生态的建立带来重要动机。
RPA应用风口是属于全球的风口，但是国产RPA团队与国外RPA团队之间虽然融资历程相差也就1年多的时间，但产品的完善程度与企业发展进程却差了很远。
中国RPA发展与国外发展之间的差距在哪儿？
中国当前的RPA业态与前沿应用是怎么样的？
有哪些成功的RPA应用于传统行业的案例？
对此，我们邀请了国内某一线互联网技术企业RPA团队核心成员、RPA产品运营专家、资深行业观察者周蜀南先生于3月7日（本周六）为我们在线解疑答惑。
参与互动分享、更多详情请扫码上方海报内二维码进群互动吧。

银行人的自我分类
我们可以简单的把银行数据人分为两大类：技术数据人和业务数据人。
技术数据人可分为三类
1、所有和数据相关的系统开发岗位和运维岗位
数据相关的系统既包括所有产生数据的业务系统，如核心系统、信贷系统、网银、银行等，也包括各类后端分析系统，报表系统以及存储和加工大量数据的系统，如数据平台、数据仓库、征信平台等。
这类技术数据人在数据人中处于核心地位，他们最了解源系统的表结构，只有他们能写出源系统的数据提取，他们也最为忙碌，尤其是业务系统的相关技术数据人，平时主要负责系统的开发和运维工作，只有在下班后，继续处理数据提取的需求，编写业务系统的数据提取脚本。
2、数据中心的操作岗
这类数据人工作相对单纯，接收脚本、执行脚本、返回数据，他们平时的工作是监控系统的运行情况，在出现异常报警时按照运维手册排查问题，无法解决时上报问题并联系系统开发的同事协助解决。如今，很大一部分精力需要用来处理数据提取的需求。
3、数据分析师
通常是数学或统计学背景，擅长数据分析与建模，在获取到提取的生产数据后进行分析与建模，得到结论，从而指导业务决策。
但随着数据提取需求的爆发式，一个新的岗位应运而生——数据需求岗
大中型银行由于数据提取的需求实在太多，单独设立一个部门或团队来处理数据提取需求，其中就有一部分人专门负责对接业务部门的数据需求。
这个岗位需要充分理解业务需求，把业务需求转化为技术语言，与开发岗沟通，同时还需要验证操作岗取回来的数据是否符合业务需求，以及数据分析师的建模结论是否符合业务预期。
其他还有很多技术数据人，数量不大，甚至没有专门的岗位，但是通常也负责数据相关的重要工作，如数据架构师（通常由系统架构师兼任），数据产品经理，数据、治理及标准管理的相关岗位，数据测试、质量管理相关的岗位，数据采集、外部数据采购相关的岗位，数据安全相关的岗位等等。
为了统一管理，有的银行把相关职能的岗位集中成立了单独的部门，如数据需求、分析、架构、提取等职能的岗位，集中成立数据实验室或大数据中心，专门负责处理各类数据需求；数据管理、治理及标准管理和质量管理相关的岗位，成立数据治理部，推进全行数据治理相关标准的制定、落地和监控；数据采集、测试、安全相关的岗位，成立数据采购部门，扎口全行内外部数据采集的需求。
接着再来聊聊业务数据人
业务数据人通常分散在各业务部门中，目前没有把业务数据人集中形成新部门的做法，因为不同业务条线的需求大相径庭，难以扎口管理。
通常在业务经营分析、监管现场检查、阶段性汇报、新产品可行性分析等环节，甚至是领导提了一句想看某个指标的情况下，需要进行临时性的数据提取需求，或固化为报表需求，由业务数据人编写数据提取或报表需求。
业务数据人通常是业务背景出身，不懂技术，最常用的工具是Excel，因此又被称为“表哥”、“表姐”，在拿到技术部门提取的数据后，通过Excel进行基础的分析，计算一些简单的指标。
业务数据人和技术数据人这个群体，说大不大，说小也不小，他们并非银行原来固有的岗位，而是随着银行对于数据应用和决策的愈发重视而逐步形成的岗位，大部分数据人都有自己的本职工作，在繁忙的业务或开发间隙，兼任数据提取和分析的工作。
可能这么说大家感觉还是比较抽象，到底数据人是在什么情况下需要完成什么样的工作呢？接下来我们就具体看看数据人的主战场在哪里，以及数据人们都从事着怎样的工作。
技术数据人：提不完的数据，写不完的脚本
在大V们的鼓吹下，KOL的洗脑文中，焦虑被源源不断的贩卖给IT民工们，迫使他们通过付费、在线培训、跳槽、转岗来完成个人简历的蜕变，以期达成职业生涯的跃迁。
大家都认为，只要入了数据这行，干上和数据有关的工作，必然是高精尖、高大上的，大数据与人工智能左膀右臂，深度学习、知识图谱信手拈来。
理想很丰满，现实很骨感。
数据分析的工作看似高大上，实则又苦又累，80%的时间花在需求讨论、提取数据、数据清洗、数据整合、缺失值处理以及特征工程部分，只有20%的时间是用来建立模型和评估模型。
外行理解的数据分析，其实类似于Kaggle这种数据建模竞赛的过程，这里的数据集基本都是已经准备好的，需求也很明确，整个数据分析的过程可以简化为从需求讨论直接跳到特征工程。
而实践中，大多数数据达不到数据分析的要求和标准。因为数据都来自于业务系统，而业务系统的建设是按需的，根据市场变化、客户变化等等按需提出并建设，建设的时候很大概率并未考虑后期数据分析的便利性，以及与其他系统的数据标准、规范等是否一致。
在银行，这种现象更为明显，国有大行、股份制和民营银行，科技力量较强，可能会有部分业务系统由行内的开发团队实施，自主实施的业务系统，相对比较容易控制其数据标准。
而其他大多数的银行和金融机构，则缺乏自主建设业务系统的能力，绝大多数业务系统依赖于采购外部供应商的成熟产品。由于每家供应商擅长的领域不同，提供的业务产品自然不尽相同，因此银行内通常的情况是多家供应商的产品系统并存。
在银行没有严格的数据标准和规范的情况下，各家供应商必然是按照各自的标准版本在银行内部署，而各家供应商的数据标准和规范必然是千差万别。
即使银行建立了自己的数据标准和规范，由于通常涉及底层改造，改造难度较大，并且改造后上线也存在一定风险，加上绝大多数银行的业务部门相比科技部门更为强势，对于业务系统的上线时间都有明确要求，多种因素作用下，通常是科技部门妥协，容忍各类标准的供应商产品上线。
这就导致银行内部的数据标准和格式成了一锅大杂烩。
而数据分析，通常是要提取多个业务系统的数据进行处理，加工整合后进行分析的，这就导致数据提取的过程需要面对分散在各处的多源异构数据，再加上数据质量参差不齐，使得数据提取和清洗的过程异常漫长。
后方的需求越来越多，而且越来越急，前方的数据泥潭深不可测，导致的后果，就是技术数据人们满心欢喜的进入数据领域，绝大多数人被分配到的任务80%以上都是数据提取，另外不到20%的任务是沟通数据提取的需求，因为这部分需要的人实在太多了，花的时间实在太长了。
只有极少数的人，从事的是数据分析和建模的工作，并且他们的工作里，大部分的时间也是在处理数据。
最后的建立模型和评估，是皇冠上的珍珠，固然璀璨夺目，但是没有前期工作完成的皇冠底座，珍珠也难以独自闪耀。除了数据科学的自身特点导致数据提取异常缓慢之外，银行的组织架构也是一个不可忽视的因素。
体量越大的银行，分工越细，业务的数据需求提出来以后，有人专门对接需求进行分析，有人专门编写脚本，有人专门负责执行，有人负责处理执行结果反馈给业务部门。
越贴近数据的人，距离业务需求反而越远，最初的需求经过层层转述，信息逐步衰减，误差逐步增大，导致最后的结果通常不能满足业务需要。
再加上银行内部各扫门前雪，宁可无功，但求无过等“文化”的影响，使得数据提取这种跨多个部门、经过多个节点的复杂流程变得更加不可控。
业务数据人：提不完的需求，做不完的报表
看完技术数据人的苦衷，业务数据人们按捺不住了。
“弄得好像都是业务数据人乱提需求一样，业务数据人也很苦的好吗？
在银行，通常业务部门比较强势，因为业务部门是利润中心，而科技部门是成本中心（现在的数据部门通常划归到科技部门），能赚钱的嗓门大，可同时压力也大。
为了完成KPI，经常需要提取各类业务指标；
为了了解客户情况，经常需要查询客户信息和交易历史；
为了解决客户投诉，经常需要提取各类操作日志；
为了设计新产品，经常需要查询各类产品和渠道数据。
技术数据人说，你们需求多我们能理解了，但是为什么经常都要得这么急呢？业务数据人通常会回答：领导要得急呀。
领导为什么总是要得很急？难道都是拍脑袋，今天想要一个数据，明天想要另一个数据，而且都需要马上看到，这样的需求谁满足得了。
其实不是领导拍脑袋，而是市场、客户和监管的变化太快。
市场和客户的变化不难理解，特别是移动互联网时代，互联网巨头们瓜分市场，抢夺客户的速度与原来银行间的竞争相比，不可同日而语。
而银行作为强监管机构，对于监管的要求永远是排在第一优先级的，1104报表、二三类账户、资管新规……
而且监管经常周五临下班出新规，搞得大家要周末加班学习监管最新指示。
外部有了变化，第一冲击的是直接对客的部门，包括网点、客服等，第二冲击是业务部门，最后才会传导到科技部门，因此科技部门不理解业务的急迫是情有可原的。
领导要得急，科技反应慢，为难的就是业务部门的基层员工，在数据领域就是表哥表姐们。
科技数据还没回来，领导又在催，能不能先用以前提的数据做个趋势分析呢？
提取的数据应该和分行填报能匹配，要么先收集一下分行填报的结果？
给分行的填表模板必须做好校验，不然填的数字五花八门。
这个数据经常要提，能不能就固化成报表需求了？
这张报表要跨几个系统拉数据，暂时没办法做报表，能不能写个宏把几个报表的数据整合了？
这几个场景里，有很多业务数据人的痛点，比如历史数据的管理，数出多门的问题，手工填报的准确性，共性需求的提炼，多数据源的打通等等，解决方法可看报表。
但大部分业务数据人还是习惯用Excel来处理数据。虽然Excel很强大，可以应付绝大多数需求，但是在历史数据的管理、手工填报准确性以及多数据源打通等环节依旧力不从心。
上次看到一个段子，说所有数字化转型的需求，最后都会收敛为两个功能：导入Excel和导出Excel。听起来很可笑，但是在很多地方确实是现实。
结语
以上就是技术数据人和业务数据人的生存现状。
看起来大家都有痛点，难道就没办法解决了吗？
银行的大多数问题都是组织架构的问题，具体到数据领域，目前来看，主要有三种数据团队组织架构：
大多数银行仍采用集中式架构，技术数据人专职在数据团队，业务数据人基本还是兼职。
这种模式下，存在技术数据人远离一线需求、沟通成本高、资源分配不均等劣势。
互联网公司普遍采用分散式植入各部门的数据团队架构，但也存在信息孤岛、数据标准不统一、重复“造轮子”等缺点。
因此，目前一些领先银行已经开始采用混合式组织架构，存在独立的数据团队，在各业务部门也有专职的数据人，他们双线考核，同时汇报给业务条线和数据团队。
改变组织架构以后，大家看问题的角度不同，立场不同，目标一致，很多问题就迎刃而解了。
当然，依然还有很多痛点没法通过组织架构的调整解决，这里先抛个砖，后续的文章里会慢慢探讨解决思路，这里分享2篇我觉得不错的实际。
源：GClover

原标题：一份全面的“需求分析说明书”是怎样的？
对于需求分析说明书（又名需求规格说明书），有很多刚入行的小白对此有很多的迷惑，在这里我就接着多年的工作经验，并拿出曾经给负责的一个项目撰写的需求分析说明书来作为案例给大家展示一下，写得不好，其中也有很多欠缺之处，愿朋友们看过之后能够给出很好的批评，咱们在这里相互学习、共同进步！
第一章 引言 1. 修订记录
2. 撰写目的
本需求分析说明书主要以剖析的方式对“XXXXXXX管理平台”做全面细致的用户需求分析，明确所要研发的系统应具有的模块、功能与界面内的详细需求，以供业主能够确认项目的基本功能和具体性能，和业主达成一个立场，从而形成一致的理解和确定，是系统分析人员及后续的系统设计人员能够更加清楚地了解用户的具体需求，使得后面的设计、研发工作的基础。
本说明书的预期读者是：项目管理人员、系统设计人员、研发人员、文案、测试人员、业主。
3. 需求背景
3.1 所建议开发系统的名称
XXXXXXX管理平台
3.2 参与方信息
XXXX信息科技有限公司
3.3 背景及必要性
近年来，随着经济社会和城市建设的快速发展，市政基础设施行业发展越来越快，投资规模也越来越大。
市政工程项目具有规模大、作业人员多、材料设备种类繁多、工序复杂、环境复杂、管理条线多、管理强度大、质量与安全隐患大等特点，使得工程项目管理要求及难度非常大。
目前相比制造、金融等行业，建筑业的信息化程度整体较低。传统的依靠人力来处理信息的管理方法已很难实现精细化、高效的项目管理，更无法适应建筑业快速发展的要求。因此，建筑企业纷纷进行信息化建设，通过信息技术的应用来强化企业的集约化管理，基于信息化系统的协同工作来提升项目的管理水平。
走在信息化前沿的各大企业，均将信息产业作为新兴业务板块，投入大量资源成立独立的公司以助力集团的数字化转型，进而驱动主营业务的发展。
如宝钢集团1996年就成立了宝钢软件公司，发展至今宝信软件在工信部发布的2018年中国软件业务收入前百家企业名单中排名第35位，为企业提供IT规划咨询、MES、ERP、BI等管理信息化整体解决方案以及个性化的软件定制服务。
行业内，华东建筑集团股份有限公司也于2018年底成立了华建数创（上海）科技有限公司，着力建设“互联网+设计”、“数字化+建筑”、“智慧化+工程”等三大业务引擎，意图发展成为工程行业互联网平台公司。
信息化已成为各大建筑企业发展战略的重要组成部分，加强信息化基础设施建设，推进管理信息系统升级换代，推动多方协同工作与数据共享，探索大数据技术的集成应用，已成为本行业发展的必然趋势。
3.4 集团建设工程项目信息化管理现状
3.4.1 项目信息化管理系统使用现状
在平台规划之前，我们首先对上海隧道、路桥集团和市政集团三家子公司在建工程项目的信息系统使用情况进行了调研。
从调研结果可以看出来，政府主管部门和业主对于项目管理信息化的要求不断提高，我们也应该相应地提升项目管理的信息化和智能化程度。
各子公司和项目经理对于信息化管理存在迫切需求，都在尝试开发或购买相关的信息管理系统来提高管理的能力和效率。
但目前不管是集团还是子公司，都没有统一的管理规定和开发标准，系统的应用深度参差不齐。众多的系统架构各异，数据也难以共享。同时各级的管理单位均有数据填报要求，项目没有实现业务数字化，数据都要人工进行分头填报，填报工作量大，存在多头填报、上报数据质量无法保证等问题。
3.4.2 集团现有项目管理系统基础
对于集团而言，项目管理已经有了一定的信息化基础，开发和全面推广了XX系统、XXXX平台、XXXXXX系统和XXX平台，取得了显著的效果，但使用中也暴露了一些不足，主要体现在：
XX系统经过几年的推广使用，培养了项目用户的使用习惯，形成了日报、周报、月报审阅制度，涵盖了项目信息、项目筹划、进度、风险、安全等重要管理功能。但XX系统是从上级监管的角度开发，以项目数据填报的形式为主，没有提供给项目经理进行业务管理的功能。每个项目只能通过项目经理的账号来进行所有数据的填报，无法将工作分解给项目相应的管理人员。而多数项目经理将数据填报工作分配给信息员，上报数据的完整性和准确性都有待提高。同时，XX的开发时间较早，受底层框架限制，再进行功能的扩展如新增项目成本管理、动态评估等功能非常困难；
XXXX系统和XXXXXX系统都是针对项目安全管理开发的专项应用系统。这两个系统与XX系统相互独立，建管与安全分离，数据没有联通。通过XX系统和XXXX系统抓取的安全隐患和整改情况无法直接同步到XX系统，项目上需要再次人工填报；
XXXXX平台采购系统逐步将项目大宗材料采购行为整合到了平台上，材料采购是项目管理的重要方面，与成本管理、供应商管理均有密切关系，目前该系统也是独立的，没有进行对接和整合。
因此，本项目拟融合集团现有系统功能，建立统一的集团建设工程管理体系和监管平台；开发项目端，为项目的全方位管理提供工具；实现系统间的数据共享和交互，为数据分析和辅助决策提供支持，实现业务数据化、数据业务化，通过项目业务的数字化开展来获取大量数据，通过数据的挖掘分析为项目提供价值。
3.5 建设必要性分析
现阶段，国家已将信息化建设提升到前所未有的高度，建设部指出建筑业信息化是建筑业发展战略的重要组成部分，也是建筑业转变发展方式、提质增效、节能减排的必然要求，对建筑业绿色发展、提高人民生活品质具有重要意义。
住建部《2016-2020年建筑业信息化发展纲要》提出，“十三五”时期全面提高建筑业信息化水平，着力增强BIM、大数据、智能化、移动通讯、云计算、物联网等信息技术集成应用能力，建筑业数字化、网络化、智能化取得突破性进展，初步建成一体化行业监管和服务平台，数据资源利用水平和信息服务能力明显提升，形成一批具有较强信息技术创新能力和信息化应用达到国际先进水平的建筑企业及具有关键自主知识产权的建筑业信息技术企业。
《工程勘察设计行业发展“十三五”规划》及国家大数据战略、“互联网+”行动等相关要求，推动信息化与建筑业的深度融合发展，促进BIM、物联网、云计算、移动互联网、大数据、智能化等信息技术的集成应用能力，实现工程建设项目全生命周期数据共享和信息化管理，推动建造方式创新，助力企业转型升级，促进企业提升核心竞争力，实现业态创新。
作为基础设施领域的龙头企业，集团更应积极探索 “互联网+”协同工作模式，实现全过程信息化，强化企业知识管理，支撑智慧企业建设，以实现跨越式发展。
4. 术语与定义
系统或者平台：如果没有特别的指出，则本文中述写的系统或者平台只指XXXXXXX管理平台。
用户：被授权使用或负责维护应用信息系统的人员。
用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。
权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。
角色：应用信息系统中用于描述用户权限特征的权限类别名称。
5. 参考资料
《项目可行性建设方案》
《项目开发计划说明书》
6. 假定和约束
假定：用户能够提供系统全面上线的测试环境，以及能够实地的参与到需求的核准工作中；
约束：本系统的全面上线日期为2019.07.31；
第二章 任务描述 1. 目标
本项目将建立“XXXXXXX管理平台”，以项目为基点，通过平台提供覆盖建设工程的进度、质量、安全、成本、人员、设备、材料等要素的管理工具，项目业务应用数字化后产生大量数据，为集团、子公司、分公司各级的监管提供数据支撑。
同时以分级管理为导向，挖掘分析和可视化展示数据，通过数据应用为业务带来价值，基于平台实现集团建设工程的管理标准化，业务规范化，监控智能化，数据可视化，经验智库化，资源共享化。
2. 主要建设内容
XXXXXXX管理平台的主要建设任务包括以下几部分：
2.1 前期调研及总体规划
前期调研和总体规划阶段，将针对集团建设工程监管的实际情况进行深入的调研和需求分析，为项目的方案设计提供必需的基础资料。
调研目前政府相关主管部门、集团、子公司下发的管理办法和规定，在平台的设计里体现相应的管控要求和标准，对于目前尚未形成标准的，通过平台能够建立一套可行的通用管理流程。
对项目经理进行调研，了解目前项目的管理现状和信息化的需求。各位项目经理共性的需求包括在XX的基础上深化进度和风险模块，新增成本管理、知识库和项目过程资料管理等功能需求，并希望能够改变XX系统由项目经理进行数据填报的模式，将数据填报模式变为项目管理模式，相应的项目人员都能够使用系统开展工作，项目经理能够通过系统来管理项目和相应岗位人员的工作情况。
对集团的业务部门、子公司和分公司分别进行调研，了解他们对于项目的监管需求和数据分析展示需求，进行相应管理端模块的设计。
对项目上正在使用的系统（如XXXXX项目管理系统、技术管理系统等）、将与本平台进行对接和整合的系统（如XXXX平台、XXXXXX管理系统等）进行专题的深入调研。
根据调研结果，对平台进行顶层架构设计、数据库总体架构设计、数据信息汇集机制设计和平台主数据标准设计。
2.2 工程项目管控标准体系建设
建立集团建设工程项目的管控标准体系，基于平台实现六个统一：统一的流程管理体系；统一的业务框架体系；统一的项目进度体系；统一的项目评价体系；统一的信息发布与交流体系；统一的知识管理体系。
2.2.1 工程项目管控中心数据库建设
工程项目管控中心数据库汇集了相关的各类项目静态数据、动态业务数据、智能监测数据、环境数据等。
对各类数据的数据源、入库方式、数据量和数据更新频率进行分析，制订合理的数据标准和数据库结构，实现海量数据存储和数据预处理，并实现高效的多源异构数据融合、查询统计、智能分析预警等功能，同时提供标准的API接口，为外部系统的数据接入和共享提供支持。
2.2.2 工程项目智能管控平台开发
平台考虑集团、子公司、分公司和项目的不同需求，功能主要包括：
建设项目智能管控平台（项目端）：项目端平台主要通过对项目现场进度、质量、安全、风险、成本以及“人、机、料、法、环”等具体管理需求对各建设工程全要素进行精细化管理，以及信息的采集、汇聚、分析和应用，业务需求侧重于为项目提供全过程的管控功能；
建设项目智能管控平台（管理端）：管理端平台以项目端为基础，通过统一后台实时接入项目端的各类数据，实现多项目的集中管控、信息分类查询、统计分析等功能，满足管理者对各工程项目快速定位、分析预警、审核评价、决策分析等管控功能上的需要。同时管理端平台全面兼容项目端的信息查看功能，有助于各级管理单位及时准确掌握现场信息，更加高效合理的判断和决策。
2.2.3 工程实施及应用
本项目将深入探索信息化技术对建设工程全方位、全时段、全过程的即时监控管理功能，力争建立一套简单、高效、实用的监督管理和项目自检信息化流程。
为保证平台的稳定性和可靠性，首批拟在各子公司分别选择1-2个新建项目，对平台的各项功能进行多样本的充分试用。运行稳定后在集团全面推广，并将XX系统中的历史数据全部迁移至本平台，将存量项目逐步迁移至新平台。
3. 建设进度阶段
2018.10-2019.04 计划、需求、设计阶段：编撰各项计划书；主要进行需求的分析和现状的调研；制作思维导图；进行平台的总体架构高保真原型（UE、UI）设计；
2019.04-2019.12 研发、测试阶段：根据需求分析、原型设计、以及项目开发计划书，实施相关工作，如下：
04-2019.08 第一阶段：XXXXXXX管理平台业务应用模块的开发和部署；中心数据库设计和基础架构的搭建；系统首页、项目筹划、进度管理、风险管理、人员管理功能模块的建设，试点工程实施方案设计，从而实现首批试点工程实施和数据上线为主等。除此之外还包括对已经上线的内容的单元测试和部分集成化测试；
08-2019.10 第二阶段：在第一阶段的基础之上，完成安全管理、材料采购、设备管理、供应商管理、视频监控、动态评价功能模块的研发，以及对完成的功能模块进行单元测试和部分集成化测试；
10-2019.12
第三阶段：在第一、第二阶段的基础上，完成XXXXXXX管理平台剩余功能模块的数据分析和内容开发，包括移动APP的开发，从而实现平台的全面上线；外部系统数据接口开发；原有XX系统历史数据接入；集团工程项目的全面深化实施应用、日常监管项目数据上线；相关标准规范体系和知识库建设完成。并生成目标系统，并确认是否达成项目目标。
4. 条件与限制
必须保证程序正常的连接到服务器，并保持网络的畅通。
第三章 功能需求 1. 总体功能架构
平台考虑不同层级的用户的需求，分为项目端和管理端。
平台一共有17个主要功能模块，对于项目端，我们提供项目经理工作台，能够一目了然地在首页上看到自己项目的总体情况，并为项目经理提供知识库进行参考。以及为项目提供一个全要素的项目管理工具，包括筹划、进度、质量、安全、风险、成本、人员、材料、设备、供应商、报表、文档，项目上不同岗位的管理人员能够各司其职，项目经理进行总体的把控和管理。
对于分公司和子公司来说，是处于执行管理的角色。平台主要是提供对多个项目的总览、业务的监督检查、流程审核、预警管理、报表审阅、绩效考核等功能。
集团主要是进行监管，因此提供给集团用户的功能偏重于数据分析总览、重大风险预警、管理行为、报表审阅和项目的动态评价。
高层级的用户可以穿透到项目端，进行详细的数据的查看。
2. 建设项目智能管控平台
管理端旨在为决策层、管理层提供业务监控和决策支持，平台从业务系统最底层直接获取数据，以各业态项目管理过程产生的一手数据为基础，用最直接、最直观、最及时的方式展示管理关键要素信息，并实现各类结构化数据的集中汇总、统计、分析与多维度展示。
管理端平台包括PC版、大屏展示版和移动APP。
3. 功能需求分析
项目端重点在于实现业务的全面管理，为项目经理提供标准化的工具、知识和决策辅助，并提供数字化工地智能监控数据全兼容的支持。
项目端的建立，首先为工程项目管理提供应用服务，同时为平台采集大量的业务数据，自动生成各类报表，为项目监管与决策服务。
3.1 功能模块结构图
3.2 模块划分
3.2.1 我的工作台
3.2.1.1 模块描述
平台从各模块得到的数据在我的工作台会得到更加精炼的整合，在这里利用图、表的方式来展示项目中的重要信息，具有一定的针对性和实时性，其相当于对每一个功能模块整理出来的信息梗概，并将这些信息进行了统一规划，形成一个具有一定操作性和层次性的并给用户以明朗和具有全局观的数据可视化窗口。
3.2.1.2 需求分析
3.2.1.3 用例矩阵
3.2.1.4 界面描述
第四章 数据需求 1. 数据描述
1.1 数据来源及流向示意图
平台中的数据来源分为内部和外部两大部分。
1.2 内部数据
内部数据包括项目现场的业务数据、自动化监控数据和项目知识库。业务数据来源于项目过程管理，包括项目的筹划信息、进度数据、质量数据、安全数据、施工风险数据、供应商数据等。
自动化监控数据来源于项目智能监控设备，包括设备监控数据、施工监测数据、安全讲评台数据、用电监控数据、人员出入及定位数据、环境监测数据、视频监控数据等。
知识库初始来源于集团现有经验和知识的梳理，并在项目过程中不断补充和完善。
1.3 外部数据
外部数据包括来自既有信息系统（如主数据系统、人力资源系统、阳光采购平台、资金管理系统）的工程基本信息和专题信息，以及通过离线方式导入的地理信息数据及其他数据。
以上数据均在平台数据标准的约束下进入数据中心，通过中心数据库与应用系统形成数据交换，并在此基础上开发标准化数据接口，将数据共享给其他需要的外部系统。
2. 逻辑描述
对数据进行逻辑描述时可把数据分为表态数据和动态数据两种。
进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。
2.1 表态（静态）数据
表态数据就是所谓的静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。
列出所有作为控制或参考用的静态数据元素如下表所示：
2.2 内部生成数据
列出向用户或开发单位中的维护调试人员提供的内部生成数据。
2.3 动态数据
所谓动态数据，包括所有在运行中要不断或者在特定的条件下而发生变化的数据，以及在运行中要输入、输出的数据。
2.3.1 输入数据
2.3.2 输出数据
3. 数据词典
对平台中所出现的各个实体的属性进行整理，使其形成数据词典，以此可以来作为后继研发过程中数据结构设计、数据库设计、数据库表结构设计的主要参考来源。
并说明对数据要求的制约，逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。
对于在设计和开发中确定是临界性的限制更要明确指出。
3.1 功能模块一（案例）
3.1.1 项目表（表名：project）
4. 数据采集
4.1 要求和范围
按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。
具体的内容包括：
输入数据的来源，例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；
数据输入（指把数据输入处理系统内部）所用的媒体和硬设备。如果只有指定的输入点的输入才是合法的，则必须对此加以说明；
接受者说明输出数据的接受者；
输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接收到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，均应具体说明；
数据值的范围给出每一个数据元的合法值的范围；
量纲给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意；
更新和处理的频度给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。
4.2 数据采集对象列表
4.3 输入的承担者
4.4 预处理
5. 数据结构与程序的关系
6. 数据库设计需求
6.1 需求概述
建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。
数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。
6.2 外部设计需求
6.2.1 标识符和状态
数据库表前缀：根据模块名定义（如用户模块：sys_）
用户名：root
密码：待定
权限：全部
有效时间：开发阶段
说明：系统正式发布后，可能更改数据库用户/密码。
6.2.2 使用它的程序
本系统主要利用java作为后端的应用开发工具，使用MySQL作为后台的数据库， Linux或Windows均可作为系统平台。
6.2.3 约定
所有命名一定要具有描述性，杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有日期格式都采用date格式。
除特别说明外，所有字段默认都设置不充许为空， 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合，例如用户表User中name字段设置普通所以，则缩影名称命名方式为user_name_index。
6.2.4 专门指导
对本系统的开发者、使用这、测试员和维护人员，提出以下参考意见：
在使用数据库时，首先要参考上面的约定内容，做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限，请参考本系统其他相关文档。
数据库的后台管理员没用等级差异，可根据实际情况添加删除管理员。
6.2.5 支持软件
操作系统： Linux / Windows
数据库系统：MySQL
查询浏览工具：Navicat Premium
命令行工具：mysql
注意：mysql 命令行环境下对中文支持不好，可能无法书写带有中文的 SQL 语句。
6.3 结构设计需求
6.3.1 概念结构设计需求
概念数据库的设计是进行具体数据库设计的第一步，概念数据库设计的好坏直接影响到逻辑数据库的设计，影响到整个数据库的好坏。
我们已经得到了系统的数据流程图和数据字典，现在就是要结合数据规范化的理论，用一种模型将用户的数据要求明确地表示出来。
概念数据库的设计应该极易于转换为逻辑数据库模式，又容易被用户所理解。概念数据库设计中最主要的就是采用实体-关系数据模型来确定数据库的结构。
数据是表达信息的一种重要的量化符号，是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性，而不是描述个别的数据。
一般来说，数据模型包含两方面内容：
数据的静态特性：主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性;
数据的动态特性：主要包括对数据进行操作的方法。
在数据库系统设计中，建立反映客观信息的数据模型，是设计中最为重要的，也最基本的步骤之一。
数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁，也是数据库设计人员与用户之间进行交流的共同基础。
概念数据库中采用的实体-关系模型，与传统的数据模型有所不同。实体-关系模型是面向现实世界，而不是面向实现方法的，它主要是用使用方便，因而在数据库系统应用的设计中，得到了广泛应用。
实体-关系模型可以用来说明数据库中实体的等级和属性。以下是实体-关系模型中的重要标识：
在数据库中存在的实体；
实体的属性；
实体之间的关系；
6.3.2 逻辑结构设计需求
项目结构实体、实体属性ER图如下：
用户权限实体、实体属性ER图如下：
进度计划权限实体、实体属性ER图如下：
6.3.3 物理结构设计需求
（1）定义数据库、表及字段的命名规范
数据库、表及字段的命名要遵守可读性原则；
数据库、表及字段的命名要遵守表意性原则；
数据库、表及字段的命名要遵守长名原则；
（2）选择合适的存储引擎
（3）为表中的字段选择合适的数据类型
（4）建立数据库结构
6.4 运用设计需求
6.4.1 表名的命名规范
表名以英文单词、单词缩写、简写、下划线构成，总长度要求小于30位。
6.4.2 表字段的命名规范
字段名以英文单词、单词缩写、简写、下划线构成，总长度要求不超过30位。
字段名以名词或名词短语，字段采用单数形式。若表名由多个单词组成，则取各个单词的缩写组成，单词缩写间使用下划线作为分隔
若某个字段是引用某个表的外键，则字段名应尽量与源表的字段名保持一致，一面混淆
6.5 安全保密设计需求
6.5.1 防止用户直接操作数据库的方法
通过把关键应用服务器和数据库服务器进行分离，防止用户对数据库服务器的直接操作，保证数据库安全。
6.5.2 应用系统的用户口令进行加密
在软件系统中，对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。
用户口令相比较，相同的话系统将该用户的操作权限分配给用户，用户再根据所分配的权限对系统进行操作。
由以上过程可知，用户口令在传输过程中容易被窃取泄漏，另外如果数据库被非法进入则其中保存的口令能够被非法查看。
因此，在传输过程中和数据库中的口令记录字段不应使用明文传递和保存，应该在口令被传递前对其明文口令使用有效的主流技术对传输数据进行加密部分描述的加密算法进行加密，在加密后传输到系统。
系统将用户提交的经过加密的口令数据保存的加密口令进行比较，相一致则进行后续操作。通过以上措施和过程，证了加密口令即使被窃取仍无法得到原始口令。
6.5.3 对用户进行权限识别和分级
在集团建设智能管控平台中，不同的业务不同的人员处理，并且对于不同的操作人员其所能够访问的数据是不同的。
为了保障各功能模块的授权使用和数据不被非法访问，系统划分了不同的操作权限和数据读写等级。系统管理人员可以方便、灵活的将这些权限登记分配给某一个或某一类用户。
当用户登陆时，系统在用户身份验证通过后取得用户的权限，根据用户权限显示相应的功能菜单。
当用户对数据进行读、写、删除后浏览操作时，系统判断用户对该数据的访问权限确定是否允许该操作的执行。
第五章 性能需求 1. 数据性能
平台支持不低于400个在建工地的数据汇集和分析计算，系统应满足如下技术指标：
1.1 数据类型支持
统除支持一般结构性事务数据外，还需要支持主要二三维地理信息格式（shp、tiff、dem、3ds、max等），支持GPS、GLONASS、北斗等卫星定位数据，主要视频协议的接入。
1.2 数据量支持
系统对GIS数据的支持能力不小于20TB；对图片、视频等非结构化数据的支持能力不小于200TB；对结构化数据的存储和查询数据量支持能力不小于500GB。
1.3 数据库性能要求
根据本系统数据的特点，采用标准MYSQL语句，以便将来的扩展和移植。
系统将采用数据库建模工具，根据系统功能模块的设计，构建出整个数据库。在构建数据库时，也会定义好数据库表的约束、关联以及索引。
针对系统的具体特点和系统要求，我们在进行数据库方案设计时对数据库平台提出下列性能方面的要求：
标准化程度高，符合标准ANSI SQL 92语言的规范；
支持对称处理和多线程技术，支持XML/CORBA，支持数据分区；
可在多种操作系统，HP、IBM等服务器下运行，独立性强，对系统结构影响比较小；
高级语言、汉化功能先进，易于方便使用，支持汉字，GB18030标准；
支持主流的网络协议，如TCP/IP、IPX/SPX、NETBIOS、DECNET、SNA等。
能支持同构、异构网络分布操作，支持松散耦合及海量并行处理；
有足够的并发控制，授权控制和事务处理能力及恢复能力；
与异种数据源有良好的可互操作性；
具有可靠的数据安全保密措施以及故障恢复能力；
具有SMP和MPP功能，具有快速的并发用户查询速度，并发控制稳定可靠；
具有很强的容错能力，错误恢复能力，错误记录及预警能力，具备异地容灾能力；
允许行级锁，具有死锁自动解出功能而无需额外的数据一致性校验；
具有强大的复制能力，支持主从式、级连式、对等式以及N-向复制，并支持复制日志技术，具有分布式模式管理能力；
具有完整的安全性（帐号安全，系统级权限，对象安全性，审查等），细粒度化的访问控制，适合于多层环境的安全模式的能力；
拥有支持MIS的功能强大的开发工具，提供数据仓库和数据挖掘的工具。
2. 并发性
2.1 数据库并发
数据库支持超过500个用户的并发访问能力。
2.2 访问并发
管理端平台具备不少于100个访问并发的能力。
2.3 传输并发
系统业务功能包括附件和图片的传输的时候，需提供稳定快速的传输效率，以及支持多附件多图片并发上传和下载的能力。
3. 响应特性
3.1 查询响应
一般数据查询响应时间<5秒。
3.2 制表速度
一般固定表格制表不超过10秒钟，复杂统计汇集表格不超过5分钟。
4. 架构特性
4.1 可靠性
系统需提供7*24的不间断服务。
4.2 稳定性
系统需合理的利用资源，保证前后台数据操作的效率，以及在数据响应和界面承载方面都要达到不会出现界面混乱、数据报错、触发按钮功能缺失、操作频繁或者快速容易崩溃的问题。
4.3 兼容性
前端方面具有兼容各大主流浏览器的能力。
4.4 灵活性
PC端前端自适应方面具有能够适配主流笔记本、台式电脑的能力，手机APP能够适应主流手机屏幕尺寸。
4.5 扩展性
系统应便于新业务或者新功能的生成和实现第三方系统与平台的连接。另外系统提供动态页面定制组件，能够有效的帮助运营方生成产品和服务表单，方便管理人员扩充分类目录等信息，并在权限管理、用户管理上有高度的灵活性、合理性。
4.6 诊断性
通过详细信息资料的方式确保用户身份的可靠性，线上实施管理操作时，需确认用户的身份。为了防止操作失误，应该将用户的操作过程信息以日志形式保存，以作为失误诊断的原始依据。
4.7 扩充性
保证已有平台和系统的兼容性及对未来发展的适应性，使系统可在原有的基础升级改造和更新，并应当充分考虑技术进步因素的影响。
4.8 开放性
平台不是一个封闭的系统，今后必须通过接口和其他平台或系统相连，在平台建设中应充分考虑与外界信息系统交换的需求，保证既能满足基本功能的需要，有具有与外界系统进行信息交换与处理的能力。
4.9 可伸缩性
要求在不用修改系统架构的情况下，通过增加或增强相应的设备即可实现系统功能的扩展支持，包括垂直扩展和水平扩展。
4.9.1 纵向伸缩
能够通过增加硬件资源提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。
4.9.2 横向伸缩
能够通过增加应用服务器及实现应用服务器负载均衡、多节点等措施提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。
4.10 可交换性
系统应符合开放的原则，充分考虑各种业务需求有机结合，建立完善的系统整体构架，可与外部系统进行通讯并可提供标准的接口。既能实现业主业务，还可以完成数据交换、信息共享功能。
4.11 经济性
系统应具备高性价比，能对系统资源的使用进行优化，在实现系统功能的前提下，尽量节省硬件资源的开销。
4.12 安全性
主要体现在能够通过冗余措施加以保证，具体包括线路冗余、设备备份措施；
能够在外网与Internet互连区采用安全可靠的防火墙；
能够建立完整的网络防毒机制，以及建立严格完善的防毒管理规范；
能够确保必须的网络服务的安全和可靠性。如DNS；对其它网络基本服务，限制使用范围，建立严格的使用管理规定，防止被黑客利用，绝对禁止匿名FTP服务，对需要使用又必须保证安全的场合，要经过身份认证、访问授权和审计记录机制的控制；
能够在Internet互联区域及与内网互连区域设置防火墙。并采用防黑客攻击软件实现安全漏洞的扫描，结合系统管理及时修补安全漏洞；提供网络实时入侵检测，在一定程度上实现对内网与外网的入侵阻隔；做好攻击的跟踪审计；
能够防止网站数据被非法篡改，并且在被篡改之后能够及时的恢复。
4.13 业务驱动性
项目实施以提供业务支持为首要因素。应从业务实际需要出发，选择重点与关键的环节进行信息化管理与控制，在信息化价值和灵活性、管理工作量之间取得良好的平衡，保证在系统实施后能提高工作效率、降低成本。
4.14 集成性
系统具有良好的集成性，对流程审批、数据获取、信息集成等功能提供标准接口，以实现与其他相关系统的功能和数据集成。
4.15 可层次性
系统可以统一各个层次管理规范，统一数据结构、数据表达方式、数据访问方式。
4.16 可模块化性
系统须提供通用的组件支持，能够减少重复开发工作，保证产品和项目的质量，缩短应用系统的开发周期，有利于系统的扩展。在统一的数据环境下集成化开发各个模块，模块的划分应独立于当前的组织机构，各个模块之间的数据交换是结构化的、公用的，从而也是高效的和完整的，最大限度消除冗余和不一致。
4.17 可维护性
方案和产品的架构须紧密跟踪国家信息安全、业主标准和国际主流技术标准，开放性好，便于系统的升级维护、以及与各种信息系统进行集成。
4.18 先进实用性
系统规划和设计理念可对照现有技术先进、成熟的产品，提高用户体验，以减少系统开发的周期和成本；功能定位充分考虑平台服务对象的需求。
第六章 文档附录 1. 运行需求
1.1 用户界面需求
1.1.1 字体
PingFang SC、Helvetics Neue、Arial、Hiragino Sans GB、Microsoft Yahei、微软雅黑、STHeiti、华文细黑、sans-serif，正常体/400微粗体，（12至20）px，黑色/白色（打印文字不在此限）。
1.1.2 风格
采用全屏网页设计，扁平化、视差化的化繁为简的设计思维，让整个网站的整体性、统一性、灵活性、自适应性、流畅性得到了相对的提高，也使得平台的功能处理和管理能力在这些特点的加持之下得到综合性的展示。
1.1.3 色值
主题色值：深蓝、白、黑；
协调色值：灰、天蓝、红；
文本色值：浅黑、天蓝、红；
按钮色值：天蓝、草绿、灰；
线框色值：天蓝、灰。
1.1.4 尺寸
在合理的布局下尽可能多的显示控件内的内容。
1.1.5 布局
按照操作流程或浏览顺序自左至右、由上而下的排放各种控件，使界面整体协调、简洁、美观大方。
1.1.6 自适应父对象的尺寸改变
控件应具有自适应父对象的尺寸改变的能力，当父对象的尺寸发生变化时，控件应能自动改变自己的尺寸并使界面保持整体协调，尽量减少因父对象的尺寸改变而带来的操作或浏览上的不便。
1.2 内部接口
考虑安全的问题，以供系统内部调用的接口。
1.3 外部接口
1.3.1 硬件接口
硬件接口是软件所使用硬件设备的基本需求，在这里平台支持打印功能，应有对接相关打印设备的需求。
1.3.2 软件接口
平台可以对接其他软件系统外放的接口，以此来获得相关功能模块所需的数据信息，需要对接的软件系统分别为工程管理（XX）、隐患排查系统、项目跟踪管理系统（CRM）、视频监控管理系统等。
1.3.3 用户接口
有系统系统、有导入导出需求用户的基本需求。
1.3.4 通讯接口
遵循TCP/IP通信协议接口，要求开发人员使用规定的通讯接口，有协同系统的通讯标准需求，至少能够支持用手机信息进行互动的通讯方式。
1.4 故障处理
1.4.1 发现问题
需要有完善的监控系统、可以对网络，服务器CPU、负载、IO、内存、连接数（文件句柄数）以及应用系统性能、异常日志进行全面访问。
1.4.2 定位问题
需要有分析问题发生的根源能力，思考是否对网络、硬件、应用进行升级，或者超过系统的承载量导致问题的发生。
1.4.3 解决问题
需要在故障发生之后有尽快处理问题的效率，不仅能够恢复系统的正常运行，而且可以降低因系统故障对平台造成的损失。
1.4.4 消除影响
恢复应急过程中可以对系统进行临时性的改变，用简单的方式尽快的采取补救的措施，从而降低对用户的影响。
1.4.5 回顾问题
分析问题的发生原因，该如何解决，怎么避免问题再次发生，并做好此次故障发生之前的预防错失。
1.4.6 采取措施
对问题发生的原因，避免方法采取行动、执行相应的措施。
1.5 运行环境
操作系统：
服务器：
浏览器：国内主流浏览器，比如Google chrome、火狐浏览器、360安全/极速浏览器、QQ浏览器、IE10以上的版本浏览器等。
1.6 开发环境
开发系统：
开发环境：
开发语言：
数据库：
2. 结语
以第一章引言中参考资料所列出的文档内容为基础，结合XXXXXXX管理平台高保真原型（UE、UI）设计，根据这篇需求分析文档记录的内容为接引，从而来进行研发工作的推进，并以这篇文档为基础，通过全面性的论述来理清平台的需求，从而为以后项目的实际实施（研发和测试）提供可靠的依据或者参考。
本文由 @卧枕江山 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议返回搜狐，查看更多
责任编辑：