工程物资云平台_SaaS产品设计说明书（PRD）_施工企业工程项目物资材料管理软件系统

EMCloud 企 业 工 程 物 资 管 理 系 统 需 求 规 格 说 明 书

文档编号：SS-02-EMCloud                 编制单位：产品研发部
修订人：  xxx                        修订日期：2019年09月15日   
公司：   xxx

文档目录如下：
一文档介绍
1.1编制目的
1.2文档范围
1.3阅读对象
1.4参考文献
1.5名词解释

二产品介绍
2.1业务背景
2.2产品概述
2.3产品目标
2.4用户群体
2.5业务范围
2.6 roadmap
2.7数据字典
2.8标准或规范

三可行性分析
3.1技术上的可行性
3.2经济上的可行性

四效益成本分析
4.1市场分析
4.2效益预测/盈利预测
4.3销售策略

五功能需求
5.1整体概述
5.1.1关键业务
5.1.2功能总览
5.2详细介绍
5.2.1登录及首页
5.2.2配置管理
5.2.3管理员工具
5.2.4后台管理登录
5.2.5物资预算管理
5.2.6采购管理
5.2.7合同/订单管理
5.2.8库存管理
5.2.9其他物资管理
5.2.10财务管理
5.2.11统计分析
5.3整合需求

六非功能需求
6.1软硬件环境需求
6.2营销需求
6.3规则变更需求
6.4产品服务需求
6.5法务需求
6.6文档帮助需求
6.7安全性需求
6.7.1物理安全
6.7.2网络安全
6.7.3主机安全
6.7.4应用安全
6.7.5数据安全及备份恢复
6.8兼容性需求
6.8.1操作系统兼容
6.8.2浏览器兼容
6.8.3其它兼容
6.9性能需求
6.9.1响应需求
6.9.2可靠性需求
6.9.3可维护性需求
6.9.4可扩展性需求
6.9.5易用性需求
6.9.6技术成熟与先进性需求
6.10测试需求

七上线、下线需求
7.1上线需求
7.2验收标准
7.3下线需求

八运营计划

正文如下：
 
一文档介绍
1.1编制目的
本文档是将xxxxxx科技有限公司（以下简称“xxx”）规划的工程物资管理系统SAAS云平台产品（以下简称“本产品”）实现设计、编码、测试、交付的说明性文档。
通过本文档描述的产品需求说明，指导技术人员在更好的理解本产品商务需求与市场需求基础上，进行系统设计与开发工作。
1.2文档范围
本文的的范围包括文档介绍、产品介绍、效益成本分析、可行性分析、功能需求、非功能需求、上下线需求、运营计划、其他需要说明的问题。
1.3阅读对象
文档的阅读对象包括但不仅限于以下人员：
产品总监、产品经理、系统架构师、设计人员、开发人员、测试人员、运维人员、销售人员等。
1.4参考文献
[1]叶伟 等著， 《互联网时代的软件革命SaaS架构设计》， 电子工业出版社，2009-09-01
[2]（美）福克斯，（美）帕特木 著，《SaaS软件工程：云计算时代的敏捷开发》北京：清华大学出版社
[3] LeszekA.Maciaszek著 王素琴 译，《需求分析与系统设计》，机械工业出版社，2009年09月
[4]段英文，刘敬严 著，《施工企业物资管理》，中国财富出版社，2017年08月
[5]张欣 著，《工程物资仓储管理》，西南交通大学出版社，2010年08月
[6]赵林度，钱英 著，《开发的物资管理信息系统》，中国石化总公司情报研究所，2000年06月
[7]基于二维码技术的自动化仓库管理系统的设计[J].计算机与数字工程，2013，41（12）：2020-2023.
[8]刘悦，刘明业.QRCode二维条码数据编码的研究[J].北京理工大学学报，2005，
[9]郝金强.基于树型设备编码的可视化仓储管理系统的设计与开发[D].上海交通大学，2011.
[10]施菁菁.基于ERP的电力物资仓储管理系统研究[D].华北电力大学，2015.
[11]周晓明.SAPEWM高级仓储管理解决方案[J].无线互联科技，2014（8）.
[12]郑庚.我国中小企业商品仓储管理探讨[J].现代交际，2013（1）.
1.5名词解释
工程：泛指某项需要投入巨大人力和物力的工作。可以理解为基础建筑或其他生产、制造部门用比较大的人力、物力、技艺来进行的某一项可以交付工作内容，如土木工程、机械工程、化学工程、采矿工程、水利工程、市政工程或者其他基建工程等。也指具体的建设工程项目。
SaaS: 软件即服务（Software-as-a-Service）的英文简称。它是一种通过Internet提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。
多租户技术：多租户技术（英语：multi-tenancy technology）或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。多租户简单来说是指一个单独的实例可以为多个组织服务。多租户技术为共用的数据中心内如何以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。
物资预算：在工程或者项目前期，根据施工图纸、设计图或者其他为实现工程目标而约定的物资总投入计划。它包括了物资具体名称、规格型号、单价、数量等信息。
直进直出：代表一种物资流动形式，与物资一般入库出库形式不同的一直表现。它表示物资不会进入库存，直接在登记后领出使用。这类物资不会直接纳入库存管理，但依旧会进入物资成本核算/投资完成中。
甲供物资：是属于工程过程中需要使用和管理的物资，由甲方按照合同约定，按照计划向乙方供应，甲方承担物资价格风险，出特殊约定外乙方承担物资数量风险和管理职能。乙方需要向甲方提供物资的领用、使用、库存情况。一般会在某一道工序或者工程完成后进行核算。
乙供物资：区别于甲供物资，也指自主采购。由乙方按照合同约定，自主采购为实现工程目标的物资，乙方承担采购费用和管理职能。
BRD: 商业需求文档（Business Requirement Document）的英文简称。基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，其内容涉及市场分析，销售策略，盈利预测等。
MRD: 市场需求文档（Market Requirement Document）的英文简称。对规划某个产品进行市场层面的说明。它既对不断积累的市场数据整合和记录，也对后续工作的方向说明和工作指导。
PRD: 产品需求文档（Product Requirement Document）的英文简称。将规划的产品从“概念化”转化为“图纸化”的一个设计兼指导性文档。对MRD中内容进行指标化和技术化，使得技术人员在更好的理解BRD和MRD基础上，准确实现产品设计、编码、测试、交付工作。
潜在需求：有相当一部分消费者可能对某物有一种强烈的渴求，而现实产品或服务却又无法满足这需求。
 
二产品介绍
2.1业务背景
工程项目中物资的费用占工程成本的60～70%，合理地组织物资的计划、供应与使用，保证物资从生产企业按品种、数量、质量、期限进入工程中，减少流转环节，防止积压浪费，对缩短工程工期，加快工程进度，降低工程成本有重要意义。
当下，无论大小工程、项目都开始展现出工艺复杂、管理严格、周期紧迫等特点。这样的情况下，对物资数据信息做到全面、准确、及时掌握，及时进行成本分析和控制，做好物资管理工作，显得极其重要。
物资管理是指工程全过程中，通过对物资的入库、出库、库存的动态管理，与物资计划对比来控制物资的使用，达到及时了解物资用量、及时补充物资需求、降低物资成本和避免物资浪费。
因为传统的物资管理方法在实际使用过程中已经暴露出不少问题，尤其是在信息数据的准确性、及时性、全面性方面。而依托了现代信息化技术手段的各种应用系统正在展现出它强大的优势和经济效益。我们可以预见信息化技术的发展不仅仅会引起工程物资管理手段的变革，它最终会带来一种管理方式、管理观念的变革。完善、高效、适用的计算机管理信息系统也必将在各工程企业得到普遍广泛的应用。

2.2产品概述
本产品是基于SaaS模式进行设计的围绕工程、项目中物资进行全过程管理的信息化系统。根据企业在工程物资管理上的行为和特点，依托信息化技术手段和软硬件环境，集预算、采购、入库、出库、核算、统计于一体，最大化为企业做好物资管理工作。
产品应用系统部署在云服务器上，客户可以通过互联网在Web端和移动端访问产品系统享受服务。客户不再需要像传统信息化系统承担硬件建设费用、网络接入费用、运维升级费用，更不会面临系统建设失败的风险。
本产品业务成熟、使用便捷、安全可靠，且产品功能设计完成后一成不变的，根据市场需求不断完善，进步。
2.3产品目标
作为公司的核心SaaS产品之一，本系统围绕给客户企业带来成功为目标，系统主要解决客户的物资管理问题和经济效益问题两个方面。
在物资管理方面，通过信息化技术手段管理好物资全过程的数据，保证物资过程管理合理、规范、准确、及时，并为企业决策和资金方面提供依据。
在经济效益方面， 不但可以让客户通过使用我们的系统，降低物资管理的人力成本、资源成本、进度成本、库存成本，还保证客户为使用软件而需要支付的信息化软硬件成本和风险成本极低。

2.4用户群体
面向工程类企业的物资管理工作，包括的用户群体是所有要参与物资管理的各部门及个人，包括公司领导、物资使用部门、采购中心、仓库管理员、预算员、财务部门等。
公司领导审核工程整体材料预算、采购计划、物资统计分析；物资使用部门进行物资申请及领用；采购中心汇总各部门采购申请进行采购活动，签订采购合同，仓库管理员负责到货验收、物资仓储管理、报表提交等；预算员定义工程的物资总预算且实时跟踪分析实际执行情况；财务部门管理物资合同的收付款、发票、税额及盘点等。

2.5业务范围
产品业务范围主要围绕工程物资管理进行建设，包括：
基础信息维护：企业组织机构维护、流程定义、项目定义、仓库维护、物资库维护、预警设置；
物资预算：物资预算维护，预算物资执行情况表；区分甲供物资和乙供物资管理；
采购计划：物资申请、物资采购计划、物资合同、供应商维护及评价；
物资应用管理：到货验收、入库、出库、退库、退货、直进直出、调拨、盘点、报损、库存等；
财务管理：采购合同查询、付款单、收款单、发票管理、往来账款、财务统计（供货、合同额、应付、已付、未付、发票、税额等）；
统计分析：物资预算执行情况对比分析、大类成本对比分析、供应商评价分析、账款分析、成本分析、库存分析等，物资结算，物资价格动态走势分析等；

2.6 roadmap

图2-6-1 产品roadmap

2.7数据字典
在本产品中，可以建立数据字典的数据都将会在功能详情设计中有一定的体现，在功能详情设置完成之后，编制全面的数据字典说明文档。数据字典的强大功能将是本产品的亮点之一，必须全面、合理化设计。
设计过程中，对数据字典的设计必须围绕以下目标：
一，系统维护人员即可改变系统的某一些行为（功能），不需要开发人员的介入。使得系统的变化更快，能及时响应客户和市场不断变化和个性化的合理需求。
二，提高系统的灵活性、通用性，减少了主体和属性的耦合度。
三，能够简化主体类的业务逻辑。
四，能减少对系统程序的改动，使数据库、程序和页面更稳定。特别是数据量大的时候，能大幅减少开发工作量。
五，使数据库表结构和程序结构条理上更清楚，更容易理解，在可开发性、可扩展性、可维护性、系统强壮性上具备优势。
详细的数据字典见功能详情章节的数据字典部分。

2.8标准或规范
在按国家标准进行设计、开发的同时，还必须满足现行的我国的财政、审计、电子、建设网络通讯、计算机和工程行业相应标准、规范，当两者有矛盾时，按较高标准执行。
必须满足有关安全、文档及其它方面现行的国家强制性标准和规程（规定）。
如果本技术规范中存在某些要求高于本章规定标准要求的，则以本技术规范的要求为准。
《计算机软件工程规范国家标准》
《计算机开放系统互连国家标准》
《信息系统安全技术国家标准》
《信息分类与编码国家标准》
《计算机图形国家标准》
《信息技术开放系统互连OSI登记机构的操作规程》
《计算机信息系统安全保护等级划分准则》
《微型计算机通用规范》
《计算机软件开发规范(GB8566-88)》
GB18030-2000 信息交换用汉字编码字符集基本集的扩充
GB1526－89 信息处理－数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文字编制符及约定
GB/T 8117-2008 电站汽轮机热力性能验收试验规程
GB/T 10184 -1988 电站锅炉性能试验规程
GB/T 8566¬—2007信息技术 软件生存周期过程
GB/T 8567¬—2006计算机软件文档编制规范
GB/T 9385-2008 计算机软件需求规格说明
GB/T 9386-2008 计算机软件测试文档编制规范
GB/T 13702-1992 计算机软件分类与代码
GB/T 11457-2006 信息技术 软件工程术语
GB/T 12504-1990计算机软件质量保证计划规范
GB/T 12505-1990计算机软件配置管理计划规范
GB/T 14079-1993 软件维护指南
GB/T 14394-2008计算机软件可靠性和可维护性管理
GB/T 15532-2008 计算机软件测试规范
GB/T 15538-1995 软件工程标准分类法
GB/T 15853-1995 软件支持环境
GB/T 17544-1998 信息技术 软件包 质量要求和测试
GB/T 17859-1999 计算机信息系统安全防护等级划分准则
GB/T 18221-2000 信息技术 程序设计语言、环境与系统软件借口 独立于语言的数据类型
GB/T 19003-2008 软件工程GB/T19001—2000应用于计算机软件的指南
GB/T 20918-2007 信息技术 软件生存周期过程 风险管理
IEEE802.X 局域网标准
TCP/IP 用于网络的一组通讯协议，包括传输控制协议和网际协议
GB 4943.1-2011 信息技术设备 安全
其他相关标准
在上述标准和规范中凡出现标准间差异时，应以就高不就低的原则执行。

三可行性分析
3.1技术上的可行性
对客户企业而言，基于Web端和移动端使用的系统，已经不存在技术上的困难，高速、稳定的网络环境，高配置而价格低廉的PC或者移动端就可以提供可靠的支持。
对我们而言，硬件技术上，阿里、亚马逊等企业在PAAS方面展现出了可行的硬件环境和网络环境。软件技术上，而且基于云服务的各微架构发展的也越来越稳定和强大，这些都为为系统的开发提供了必要的技术保障。
3.1.1多租户技术
为什么要用多租户技术? 通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。通过在多个租户之间的资源复用，运营管理维护资源，有效节省开发应用的成本。而且，在租户之间共享应用程序的单个实例，可以实现当应用程序升级时，所有租户可以同时升级。同时，因为多个租户共享一份系统的核心代码，因此当系统升级时，只需要升级相同的核心代码即可。
技术实现形式如何选择？技术上选择形式三种：独立数据库、共享数据库/隔离数据架构、共享数据库/共享数据架构。第一种成本高，第二种和第三种恢复数据库比较麻烦，但是从成本考虑我们选择第三种（但一定要在设计时，做好更好的安全保障和数据库恢复机制）。具体描述：租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。TenantiD是实现多租户技术中的单个租户标识编号。备份还原方案：多种对象形式备份、还原方法优化：准确、可操作；性能方面：考虑表分区等数据库性能优化技术、考虑数据安全管理；后台创建客户信息单的时候生成的TenantiD数据。
在这种情况下，所有租户共享数据表存放数据，不同租户的数据通过 TenantID 鉴别器来区分。但目前的 Hibernate 4 还不支持这个多租户鉴别器策略，要在 5.0 才支持。可选的替代方案是使用 Hibernate Filter。
为了区分多个租户，在 Schema 的每个数据表需要添加一个字段 TenantID 以判定数据是属于哪个租户的。详细实现参考：多租户实现技术。
3.1.2 产品开发模式
随着当前信息技术发展，项目系统的开发从传统的web开发模式（MVC）逐步转向了前后端分离的开发模式。本产品采用主流的前后端分离的开发模式，纯技术的优缺点在此不做扩展性分析，主要解决传统web开发模式不能实现的以下问题：
1，前端做很大部分的数据处理工作，对服务器的压力减小到最小；
2，保证本产品后续可持续性优化的工作量在最低；
3，最好的解决后端框架对前端性能优化方面的影响；
4，前后端独立工作，职责清晰，工作无穿插，可以提供开发效率；
5，对各种移动端服务的良好支持；
6，最大化支持分布式部署及发挥出分布式部署后的优势；
7，为后续微服务架构扩展提供基础；
8，有利于SEO；
总的来说，通过前后端分离，让后端开发人员专注在处理三高（高并发，高可用，高性能），安全，存储，业务等，让前端人员专注在处理页面表现，速度流畅，兼容性，用户体验等。但是要注意，本产品的权限特点，后端和前端之间要做好页面的安全性控制，防止通过前端页面的越权访问和数据泄露。
技术路线选择上，前端：负责View和Controller层；后端：只负责Model层，业务处理/数据等。

3.1.3系统架构选择
单体式架构和微服务架构两种主流形式，对于单体式架构而言其缺点是非常明显，对我们产品而言，最大的问题就是可持续开发性（扩展性、可靠性、低耦合）很差。
如果选择微服务架构，面临以下几个问题：1，分布式系统的复杂性 2，分区的数据库架构 3，微服务之间的依赖控制 4，微服务应用本身的复杂度 5，微服务划分的依据合理性
整体上，还是建议选择单体式架构。另外如果采用微服务架构，是选择spring cloud还是dubbo？
前后端分离：nood.js/vue.js+java+db(Mysql？)。后端人员：三高（高并发，高可用，高性能），安全，存储，业务等等。前端人员：页面表现，速度流畅，兼容性，用户体验等等。
分布式部署/集群：nginx（web服务器）+tomcat（应用服务器），集群没必要
负载均衡/反向代理：软件负载均衡/硬件负载均衡，软件负载均衡（nginx），路由模式。
客户端身份验证:移动端的用户验证，会话key选择上的session和token，做基于seesionid+token的身份验证。
3.1.3版本升级的数据可延续性
产品版本包括基础版、标准版、扩展版、商务版、定制版。
基础版：主要业务包括物资的到货、入库、出库、库存等业务。适用于仓库管理员进行使用，建立标准编码物资库、保证仓库管理的及时、准确，且能保存单据并为领导提供统计数据。一个企业用户只能拥有唯一的仓库管理员，可以有多个项目。
标准版：主要业务包括系统全部的功能，标准编码、预算、申请、采购、合同、支付、到货、入库、出库、统计、流程等。
扩展版：在标准版的基础上，组织机构形式上可以设立下属子公司/分公司且可以独立管理，统计分级上可以完成按照总公司/子公司或分公司/项目三层分级统计和数据权限过滤。理论上下属公司的添加无个数限制，同比增长费用。
商务版：商务版可细分为标准商务版和扩展商务版，商务版的核心是在采购计划审核完成后，采购员可以自制询价单，提交到供应商商务平台，供应商可以获取询价单中的内容进行报价，如采购员对报价满意，则暴露主体信息进行联系。也就是提供一个真实的网上询价平台。核心目标：为采购员提供更好的询价渠道和方式，也展现出更好的价格对比优势；为供应商提供给多的客户渠道，形成更多的订单。
定制版：客户在使用前面各版本产品相对较长的时间后，可以提出为满足自身企业需求下的定制化产品需求。
就本需求规格说明书的设计上来看，各版本如果存在升级或者降级的情况，数据上应该可以保证延续性和约束性。

3.2经济上的可行性
本系统开发所需的成本适中。开源免费的开发工具，付费的数据库服务，付费的云服务器，进度内的总人工成本，综合分析在可控范围内。
通过以上从技术、经济方面的研究与调查，我们可以确定基于云服务的物资管理系统是可行的。
 
四效益成本分析
4.1市场分析
4.1.1物资管理在信息化发展中的现状
计算机的发明应用，被视为人类的第三次重大的科学技术革命，是一次飞跃。过去的革命最高成就就是“用机器制造机器”，是手的延长，而计算机的出现却能做到“用机器控制机器”，是脑的延伸。计算机是提高生产效率的主要工具及途径。
由于种种原因，我国的信息资源建设水平远远落后于信息基础设施的建设的水平。长期以来，我国信息资源的开发管理未能与信息资源的增长同步进行。而物资管理在社会大生产中占用重要地位，其计算机化在发达国家已达到95%以上，而我国在全国范围内推广计算机在管理中的应用，是在80年代初开始的。起步虽晚，但发展快。特别是微型计算机的出现和普及，为信息处理提供了物美价廉的手段，对于推动我国管理信息处理现代化起到了重要作用。
在这样的现状下，通过建立物资管理信息系统使物资管理工作更加规范化、程序化，提高其处理工作的速度和准确性，也便于动态查询，提高决策水平，是国内各工程企业追求的目标，对为这些企业提供服务的供应商来说，是非常广阔的市场需求。

4.1.2企业物资管理系统建设的现状
目前，市场上各种各样的物资管理系统层出不穷，但是各企业在使用过程中却不理想，其核心原因是缺少物资管理与信息化管理都非常专业的人才，导致信息化技术没有完美的应用于物资管理行业，其次不同企业不同的物资管理模式和需求也导致了传统软件企业的成本急剧增加，很难在成本与产品中得到平衡点。最终，项目失败或者交付的产品不能得到良好的应用。
用户研究表明，在传统物资管理系统不利的大环境下，各企业也不在愿意为物资系统建设承担太多的风险成本。但是从用户消费规模和同比增速的数据上来看，物资管理系统依旧展现着强劲的市场需求和企业的迫切需求。
随着产品发展情况分析，为了解决这一问题，不仅仅要解决技术上的困境，更要让企业在物资系统建设上的成本投入降到最低，目前的软件行业传统服务方案已经无法从这个困境中走出。
从2010年开始，互联网技术的快速发展，尤其是在云服务方面展现出的强大经济效益，这一困境出现了转机。随着近今年新型服务模式影响下，直接甩掉了企业需要支付高额建设成本的问题，再基于互联网强大的共享特点，为物资管理系统进一步成熟、稳定、可靠提供了良好的发展基础。可以预见，SaaS云服务下的物资管理系统市场前景广阔。

4.2效益预测/盈利预测
效益预测假设条件：
1、一般假设
（1）公司所在地及中国的社会经济环境不产生大的变更，所遵循的国家现行法律、法规、制度及社会政治和经济政策与现时无重大变化；
　（2）针对评估基准日资产的实际状况，假设企业持续经营；
　（3）假设公司的经营者是负责的，且公司管理层有能力担当其职务；
　（4）除非另有说明，假设公司完全遵守所有有关的法律和法规；
　（5）假设公司提供的历年财务资料所采取的会计政策和编写此份报告时所采用的会计政策在重要方面基本一致。
　 2、特殊假设
　（1）假设公司在现有的管理方式和管理水平的基础上，经营范围、方式与现时方向保持一致；
　（2）假设其资产使用效率得到有效发挥；
　（3）有关信贷利率、汇率、赋税基准及税率，政策性征收费用等不发生重大变化；
　（4）消费市场需求将保持一定同幅度增长；
　（5）假设折现年限内将不会遇到重大的销售货款回收方面的问题（即坏账情况）；
　（6）无其他人力不可抗拒因素及不可预见因素对企业造成重大不利影响。
4-2-1 效益预测分析表
新产品经济效益分析报告
名称 工程物资管理系统SaaS云平台产品
版本 V1.0
用户 工程企业客户群
销售价格（含税） x元/套 市场规划（年销售套） y套 年销售额 x*y元
生产设备 PAAS服务器 设备来源 外购（阿里云） 价格 待定
生产设备 移动端 设备来源 外购 价格 待定
生产设备 二维码打印机 设备来源 外购 价格 待定
新增设备/工具 无 造价 无 　 　
新增投资额 无 　 　 　 　
成本核算
序号 生产期成本（N个月） 公司年度后续成本（M个月）
项目 内容 金额（元） 内容 金额（元）
1 直接材料 购买设备 200000.00 购买设备 0.00
2 辅助材料 无 0.00 无 0.00
3 直接人工 开发人员成本 650000.00 开发人员、销售人员、其他人员 1200000.00
4 其他费用 管理费、市场费、其它 300000.00 管理费、市场费、其它 250000.00
5 年持续运维费用 开发、运维 250000.00 开发、运维 0.00
合计 xxx0000.00
效益测算 根据以上测算，产品在生产期和运维期（年度）的成本为120万元，产品单套售价平均在x元，在销售量达到120/x套时可以开始盈利，后续产品的成本投入直线下降，后续销售利润空间巨大。
结论 经济效益可观。但考虑到公司发展及产品后续技术支撑工作的成本巨大，作为B2C端的SaaS服务模式下的软件销售压力大，月销售额需要达到100万元。

4.3销售策略
销售策略是指实施销售计划的各种因素，包括：产品、价格、广告、渠道、促销及立地条件，是一种为了达成销售目的之各种手段的最适组合而非最佳组合。销售策略即公司产品/服务投放市场的理念。
结合SaaS产品特点及市场分析，定义的销售形式包括但不限于：
1、电话销售：由SEO专员专岗营销，通过各种形式（官网、推广、营销号、推文等）获取流量，通过流量获取意向客户信息，电话联系获取机会。
2、关系销售：在公司核心成员在行业关系网下，积极推进产品的销售工作。

五功能需求
5.1整体概述
5.1.1初始化流程
1、系统后台版本定义：可以设置不同的版本，进行功能模块的授权。（基础版、标准版、扩展版、商务版、定制版），本产品设计文档是实现基础版、标准版、扩展版。
2、系统后台客户信息维护后，形成客户Id，此Id是客户的唯一标识，是客户数据在同库同表的情况下进行数据隔离的关键点。且必须提供按客户为单位的数据备份及还原解决方案（可执行的操作）。
3、客户信息维护完成时，形成系统管理员（客户），系统管理员（客户）的手机号是登录的唯一账号。
4、系统管理员（客户）登录系统后，获得自己被授权版本的组织机构创建权限，进行组织机构创建。被添加的公司管理层领导用户可以通过手机号登录系统。
5、系统管理员（客户）进行项目定义，定义的项目是系统进行管理的最小组织单元。同时维护好项目经理。项目经理可以通过手机号登录系统。
6、项目经理进行项目部人员组建，设置各个物资管理相关角色的人员。被设置的人员可以通过手机号登录系统。至此，系统的组织机构、人员、角色建立完成。
7、系统管理员（客户）维护物资编码库（也可以设置物资编码人员进行维护），维护审批流程、维护数据项。这三项基础配置，都由系统默认设置完成，客户根据需要自行再次定义，也可以不定义，直接使用产品的默认设置。至此，系统的全部基础配置完成，各人员可以正常使用系统。
5.1.2业务功能流程
1、物资预算员按照项目维护物资预算。预算审核完成后，可以围绕预算进行物资申请。
2、物资使用人员提出物资申请。申请审核完成后，可以进行物资的采购计划报批。
3、物资采购人员汇总物资申请进行物资采购计划编制并报批。审核完成后，可以进行物资采购合同的签订。
4、采购人员/合同管理员进行采购合同/采购订单的起草，并报审。审批通过的合同进行后续合同的履行和到货验收业务。
5、仓库管理员维护项目仓库，进行到货验收，登记后进行后续的仓库管理，包括入库、出库、调拨、报损等。
6、采购人员/合同管理员根据到货验收情况及合同付款条款，提出付款申请，审核通过后财务进行支付处理。
7、各级人员可以根据自己需求实现不同的统计查询结果。详细见统计业务模块。
5.1.3其它说明
1、物资编码库维护，产品自身按照工程物资分类建立标准库，后台维护管理。每个客户可以获取标准库，对标准库进行完全删除，部分维护，完全自建三种形式去建立自己物资编码库。后续，系统中的所有业务都将围绕物资编码库为基础进行使用。
2、角色权限由系统逻辑设计完成设置（可以在角色权限查看模块查看），降低客户使用系统前的配置难度和工作量，提供更好的产品体验。角色较为复杂，定义如下：
角色类型 角色名称 角色解释 角色权限
后台角色 系统管理员（产品） 本产品系统的最高角色 全部系统可操作和可查询权限
销售员 后台记录客户使用系统申请 使用产品使用申请模块
销售经理 后台记录客户使用系统申请 使用产品使用申请模块
可能存在产品经理、测试、运维等 后续运营待定 　
前台角色 系统管理员（客户） 客户方最高权限人员，客户定义时该角色出现，且与联系人账号绑定 组织机构维护、工程定义及其他管理员工具模块
公司管理员（客户） 客户方子公司/分公司层级最高权限人员，组织机构维护公司信息时该角色出现，且与公司管理员账号绑定 子公司/分公司级管理：工程定义及其他管理员工具模块
总公司管理层 客户方行使查询权限的角色，组织机构维护时，总公司下属员工与该角色绑定 所有业务模块的查询功能，统计模块的查询功能
公司管理层 子公司/分公司级：客户方行使查询权限的角色，组织机构维护时，总公司下属员工与该角色绑定 子公司/分公司级：所有业务模块的查询功能，统计模块的查询功能
物资编码维护人员 客户方物资编码维护人员，可以初始化企业的物资编码库，也是后续物资编码维护的唯一责任人 物资编码库管理
项目经理 项目管理单元中的最高权限角色，项目定义时，该角色出现，且与项目经理账号绑定 项目级业务的全部权限，项目级统计查看权限
预算造价员 项目定义时，该角色出现且与该角色对应的用户对应 物资预算
物资申请人员 项目定义时，该角色出现且与该角色对应的用户对应 物资申请
采购员 项目定义时，该角色出现且与该角色对应的用户对应 物资采购
项目分管领导 项目定义时，该角色出现且与该角色对应的用户对应 同项目经理角色，只是可能不参与具体业务管理
物资合同管理员 项目定义时，该角色出现且与该角色对应的用户对应 合同管理
财务人员 项目定义时，该角色出现且与该角色对应的用户对应 财务管理
仓库管理员 项目定义时，该角色出现且与该角色对应的用户对应 仓库管理
客户不在需要对系统进行角色创建，角色授权，角色用户绑定，系统中进行授权的这个必须进行的操作，全部弱化到客户的实际工作中，例如建立组织机构，例如项目成员组建。
3、数据状态及有效性
系统中的业务具有连续性，所以过程数据不得随意修改，会影响后续业务数据的准确性。
针对这一特性，我们将客户产生的数据划分为两块：配置性数据、业务性数据。
配置性数据包括组织机构、项目定义、数据项、流程定义、仓库维护等基础初始化数据，他们不随物资本身业务的开展而变化。对这一类数据，如果需要发生修改、删除等业务，控制办法为：每个配置性数据在新增保存时形成唯一编号或者Id，后续再引用过程中则只保存唯一编号或者Id（例如公司Id，用户Id，仓库编号等），如需要修改则只能修改数据本身描述而不能修改编号或者Id，这样就保证了数据的一致性和正确性；如需要删除，则判断此数据编号或者Id是否在后续业务中被占用，如有则不能删除，提供停用状态，停用后再新增新的基础配置数据项。所以首先是唯一标识的建立，其次是业务关联的主外键设置，且最好是查询出具体业务说明。那么配置性数据表现出来的特性有：有唯一标识，有状态标识。
业务性数据包括物资预算、申请、采购、库存等，这一类数据一旦形成后，就有可能会被后续业务引用，且引用后会对新业务产生控制影响及统计影响。对这一类数据为了保证数据的有效性、准确性、连续性，提供的解决办法为：流程控制。所有业务数据新增时为未审批状态，可以进行修改删除，下一业务也不引用未审批状态的数据进行使用；数据审批过程中为审批中状态，不可以修改删除，但由于数据可能会被退回删除，所以下一业务也不引用未审批状态的数据进行使用；数据审批完成后，数据状态变成已审批状态，不能进行修改删除，也不能被退回，下一业务可以引用此数据。所以，业务性数据表现出来的特性有：流程状态、过程存储。
引伸问题：流程组件必须成熟先进，便于用户自定义配置（包括是否流程控制业务，流程节点定义），审批页面也必须具备模板标准配置，保证审批的便捷性（查看模板，可参考流程处理界面设计）。也必须针对每个约为提供尽量准确的标准流程，使客户在不配置个性化流程时就能使用系统。同时，配置性模块中存在角色协助的都保留短信提醒功能（创建人员、创建项目后），业务模块通过流程审批完成，且流程审批保留短信提醒功能。另外系统设计提醒功能。
4、物资单据：物资管理中对单据的保存非常重视，所以对物资的业务过程，系统必须提供最专业化的打印模块及打印功能，而打印的存档是对过程数据的存档，所以必须保证数据的正确性。
5、移动端：PC端完成后，进行移动端的设计及开发，配套PC端进行使用，提供更好的业务体验。
6、外部设备：接入标签打印机，在到货后实现对物资的标记，后续可支持扫码出库及全生命周期的查询。
7、业务设计难点攻克：
考虑物资数据的可追溯性（从源头到结束的数据发生过程如何）、可控制性（数据引入的有效性）、可统计性（多维度、细单元的可统计角度），本产品在控制业务过程时有两个关键点。
7.1预算为基础的物资申请、采购、合同签订、到货主线（价格+数量数据）：在此业务主线下，所有物资都以预算为核心源头，掌握物资从预算时的数量、单价控制到最终到货为止。此业务线上的明细都具备从预算开始追踪的条件；如果过程中导入预算外物资，则从导入点开始记录进行追溯，保证了数据最大性的可追溯。（详细参考下图的物资执行动态汇总台账），这一汇总台账也是本主线中所有明细数据引用的基础。

7.2到货验收-入库-出库-库存主线（数量数据）：在此业务主线下，物资在到货验收扔掉价格的问题，全部围绕真正的仓库库存为基础进行管理，保证实物与账目的一致性。（详细参考下图的物资库存动态汇总台账），这一汇总台账也是本主线中所有明细数据引用的基础。
两个主线具有各自的业务核心思想和管理意义，但二者又不是完全分离，通过物资编码库对物资的唯一标识进行关联，可以实现对预算执行情况及物资实际成本形成汇总和统计。

8、所有附件采用文件服务器存储，数据库存储文件位置等信息，且单个附件大小必须有限制（5M）。一方面是缓解数据库压力，另外也保证系统后续空间扩展的难度，这样的存储形式，充分利用硬盘大小扩展优势和新分区硬盘的优势。（程序上要考虑单块硬盘最大空间后的数据存储路径调整功能）
9、提供客户购买页面，包括选择版本、选择企业数、选择购买年限、选择购买短信条数、选择购买数据文件存储空间等。
10、其他人性化业务需求：
10.1删除方法:所有数据的删除，都应该结合业务进行明确的提示。需要把每个自身数据与后续业务关联的地方都进行查询判断。
10.2系统专有名词都必须进行最近解释，帮助判断的说明。
10.3业务连续性必须进行优化性引导。
10.4帮助需求必须全面。
11、其他剩余问题
11.1物资大类问题：甲供物资和乙供物资。–到货分开
11.2仓库大类问题：目前都是项目仓库，公司仓库如何处理。
11.3金额问题：先进先出、平均计价。到货前的业务管理带单价和数量，入库时只考虑数量，那么后续的金额出现浮动，在处理和统计是要充分设计考虑全面。
5.1.4功能总览
首页：系统登录页面、首页面
基础信息维护：企业组织机构维护、流程定义、项目定义、仓库维护、物资库维护、预警设置；
物资预算：物资预算维护，预算物资执行情况表；
采购计划：物资申请、物资采购计划、物资合同、供应商维护及评价；
物资应用管理：到货验收、入库、出库、退库、退货、直进直出、调拨、盘点、报损、库存等；
财务管理：采购合同查询、付款单、收款单、发票管理、往来账款、财务统计（供货、合同额、应付、已付、未付、发票、税额等）；
统计分析：物资预算执行情况对比分析、大类成本对比分析、供应商评价分析、账款分析、成本分析、库存分析等，物资结算，物资价格动态走势分析等；
系统功能维护：数据项维护、帮助、在线咨询、管理员工具（单据控制、流程控制、数据维护、系统日志）
移动端功能：系统功能表单、与二维码打印机的接口
管理员功能：客户信息维护-定义客户版本

5.2详细介绍
本章节详细描述每个功能点的设计，包括业务分析、功能说明、业务关联、业务活动、界面、按钮、字段、权限、过滤、逻辑等。
在详细描述前，对本章节的设计规范做如下说明（当规范与具体设计有冲突时，必须与产品经理沟通确认）：
 统一规范
 界面配色和风格必须一致（不同区域的不同配色/位置/大小）；
 同一意义的功能按钮样式/颜色必须一致；
 操作权限按钮：新增/修改/删除；查询权限按钮：导出/打印/筛选等；用户授权模块授权查询和操作两种权限分别看到和点击的按钮也对应。
 同一样式的界面大小必须一致（特殊情况说明原因除外）；
 每个列表块都必须有序号；
 不可出现换行，长度不够时鼠标停留悬浮显示；
 功能按钮区、查询区必须统一尺寸大小，如功能按钮/查询条件较多，提供展开按钮；
 页面默认数据行高一致；
 每个页面默认展示数据最大行数为xx行，分页显示。允许自定义设置分页显示行数，固定选择值，例如20行，50行，100行（可参考自定义页面显示界面样）。因为业务展示效果原因不分页显示的，提供显眼的下拉展开按钮。
 每个页面必须右上角必须有查看视频演示操作按钮，后台预留视频上传对应页面的功能，如前期因为没有制作视频上传，进行提示“视频还在制作中，如有疑问请咨询系统管理员（客户）”，如有，则弹出视频播放窗口。
 每条数据必须存储创建人id，创建时间（也就是第一次保存的时间，格式2018-10-17-19:23：46），最后修改时间（格式2018-10-17-19:23：46，如没有修改则有创建时间一致）。
 每条数据必须具备创建时创建人所在部门的公司编号/id，用于后续数据操作权限控制，业务数据属于公司数据，不属于个人。
 新增页面必须分为手动维护部分和系统定义部分，新增界面必须有备注和附件字段。
 业务功能模块新增界面数据保存后必须直接跳提示是否提交数据，根据用户选择转到提交流程界面或者返回查询界面。
 业务功能模块查询界面列表字段/行值全部居中（统计页面除外）。
 业务功能模块查询列表界面字段必须是序号/流程状态为第一/二字段，操作栏（如有）必须是最后一个字段，创建日期是倒数第二个字段，创建人是倒数第三个字段。流程状态字段在行值上点击可以弹出流程详情查询界面。
 查询界面的列表字段只要是有规则性的，都可以点击后进行本页的升序/倒序排列。
 查询界面的数据按照时间倒叙排列（最新的数据在最上面），特殊排序规则约定或有排序字段除外。
 每个模块的查询条件区，一般默认全局模糊搜索/项目名称/创建人三个查询条件输入+更多筛选条件。查询值手动输入，条件之间是并值（and）查询。支持回车事件查询。点击更多筛选条件后右侧弹出除已有查询字段以外所有查询字段的查询输入框的界面，界面宽度以覆盖创建人、创建日期、操作三个字段为宜，输入值/回车查询，也可以点击收起按钮隐藏该界面。
 查询页面的列字段宽度为满足各移动端的自适应效果，字段宽度都按照比例（a%）设置，而不是固定值。其中固定五个标准字段（序号（2）/流程状态（5）/创建人（5）/创建日期（7）/操作（11））比例总计（30%），剩下每个业务模块自定义的列表字段宽度总共占页面70%宽度的值。
 在PC端，支持自定义显示字段（可参考自定义页面显示界面样式。备注：自定义字段的宽度计算问题，如果自定义字段部分，定义了8个字段，每个都是10%宽度，那么就是80%宽度，比页面设置的业务字段只能是70%宽度不匹配，此时系统自动计算，每个字段的宽度为10%*70%/80%=8.75%，就是说实际上每个字段的宽度为8.75%；如果自定义了6个字段就是10%*70%/60%=11.7%）。
 数据库表设计必须编写备注说明，例如表字段设计时，字段用前端页面汉字名称备注（例如UserName对应备注：用户姓名；）。
 数据库表必须区分基础系统表和扩展业务表，表命名规则必须是英文，驼峰式（例如组织机构表，命名为Sysem_ Organization；而物资预算表命名为Extend_MaterialBudget）。
 数据库字段命名规则必须是英文，驼峰式（例如项目名称命名为ProjectName不可过长）。
 索引
 每个配置定义的最基础的信息数据单元不允许又第二次存储（例如用户姓名UserName字段的值只允许在用户表中存储，任何其他模块不得存储UserName，只能通过UserId存储后查询出来；例如项目名称只能存储在项目信息表ProjectName字段下，其他模块不能存储，只能通过ProjectId存储后查询出来）。
 物资有编号、分类、名称、规格型号、单位等属性，原则上不能对这些属性进二次存储，只允许在第一次录入物资时进行存储，后续都通过Id进行引用，只存储Id，另外因为id比较长，可以考虑设置一定规则的唯一性的编号，可识别度高。
 每条数据只有自己能进行修改/删除，其他权限通过人员可以查看。
 每个业务模块的数据只有创建人/数据所属公司的下属人员可以查看，如集团需要查看子公司数据，再设计的更高一级统计页面实现汇总统计。
 每个输入必须有校验规则。
 附件支持断点续传。
 所有需要用户等待的界面必须有进度条显示的友好交互效果。
 非选中行数据的操作按钮（新增数据/导出数据）放在顶部的操作按钮区，选择数据行的操作按钮（修改/删除/打印）放在行数据最后，字段值详细解释性查看按钮在行列数据值上，数据值后附加查看两个字用于提示用户可以点击查看详情。
 导出数据是在查询条件下的数据进行导出。
 每行数据可以双击事件查看数据详情（新增界面样式下数据填充好的不可编辑状态），如果双击事件不好实现，则在按钮区添加统一的数据行查看数据详情按钮。
 每个系统定义名词后面都要有解释性说明。
 输入区，字段名称左对齐/右对齐。
 凡主从表关系，设置主外键关联，数据保存/修改/删除时，数据同步且正确。

 标准样式
页面布局区域分布

查询界面参考样式

新增界面样式

弹出框界面样式

提示框界面样式
//待定，友好性，准确性
树形结构界面样式
//待定
自定义页面显示界面样式

5.2.1登录及首页
5.2.1.1业务分析
登录页面是用于与官网的登录链接，也是客户使用系统的第一个访问界面。首页是客户登录进入系统后看到的第一个界面，首页非常重要，整体感受好，交互性强。
5.2.1.2功能说明
登录页面：客户输入账号密码登录，或者注册。
首页：展示系统整体框架、用户引导效果
5.2.1.3业务联系
登录界面客户输入的账号是手机号，作为客户的系统管理员（客户），其手机号由我方技术人员维护好，客户系统管理员（客户）注册密码或者短信验证登陆，后续与系统进行token进行持久化、会话、校验。其他用户在登录时，可以通过手机号登录，但这个用户是哪个企业，有什么权限都由系统管理员（客户）及其他用户在系统内通过人员信息维护决定。另：提供君联首页按钮，点击可以跳转到君联公司官网。
首页上要展示出与当前用户紧密联系的工作引导，也支持自主使用系统。
5.2.1.4业务活动

5.2.1.5登录界面
 界面效果

（配色需要再做优化）
 功能按钮
账号注册：点击时弹出账号注册页面，需要填写姓名、账号（手机号码），输入密码，确认密码，短信验证，提交注册成功后返回登陆界面。
忘记密码：点击进行密码找回，通过手机验证找回。
点击获取验证码：短信登录界面的按钮，点击后校验手机号码基本规则，通过后发送验证码到用户输入的手机中，每60s点击发送一次，验证通过直接登陆系统。
登录按钮：点击登录，出现登录跳转等待提示框“xxx，你好，欢迎登录工程物资云管理系统”，校验该用户是否与企业绑定（判断依据是客户定义模块的数据），如果有绑定则通过进入系统首页。如果没有绑定，则让用户填写企业信息开始试用，填写企业名称（默认版本为标准版），然后客户可以开始试用系统。所以此模块需要接入客户定义模块，形成试用客户数据。
 字段说明
账号密码输入区：输入型字段，无特殊要求，按照统一规范和标准样式。参考界面效果。

 操作权限控制
无。

 数据查询过滤
无。

5.2.1.6首页面
 界面效果

（页面布局大小及色彩需要根据最终交付效果考虑进行优化）
 功能按钮
帮助按钮：右上角的帮助按钮，鼠标移入悬浮菜单栏，包括：系统介绍、操作手册、视频演示、常见问题、在线咨询、售后支持，点击具体菜单打开对应的新页面。
个人设置按钮：右上角的个人设置按钮，鼠标移入悬浮菜单栏，包括：切换企业、修改密码、退出系统。
功能菜单：页面左侧的功能菜单收缩按钮，点击可以将当前用户所对应角色下的完整功能菜单在左侧弹出，点击具体菜单可以打开对应页面，也可以将功能菜单隐藏收回去。
个人工作台：个人工作台中按照用户对应角色，将主要工作任务相关的菜单进行列出，便于用户进入系统后最快的找到需要使用的功能。点击打开对应的功能页面。
登录按钮：点击进行校验，校验通过进入系统首页。

 字段说明
右侧上方待办查询列表输出展示区：下表从上到下为界面字段从左到右的排列顺序，列表字段及行数据都居中显示，流程主题列的值变色，可以点击弹出待办事项的处理页面进行处理。
字段名称 字段显示宽度（%）
序号 5
业务分类 10
流程主题 35
发起人 10
发起时间 15
上一步发送人 10
到达时间 15

右侧下方跟踪查询列表输出展示区：下表从上到下为界面字段从左到右的排列顺序，列表字段及行数据居中显示，流程主题列的值变色，可以点击查看流程任务的最新进展，并且可以标识为不再跟踪。
字段名称 字段显示宽度（%）
序号 5
业务分类 10
流程主题 35
发起人 10
发起时间 15
当前处理人 10
处理时间 15

 操作权限控制
无。

 数据查询过滤
无。
 其他说明
个人工作台
显示用户个人快捷功能菜单，用户所属的角色不同，则显示的快捷功能菜单内容不同。如果用户同时具备多个角色，则取多个角色下快捷功能菜单的合集。
快捷功能菜单点击后打开对应的功能页面。
快捷功能菜单的显示逻辑：系统设置每个角色的快捷功能菜单（来源于系统功能菜单）及显示排序，显示时根据排序显示，体现出逻辑性。
系统管理员（客户）：组织机构维护、项目维护、流程定义/流程任务管理、数据项维护、单据管理、系统日志
项目经理：项目成员组建、物资预算、物资申请、采购计划、采购合同、采购订单、合同付款、合同收款、供应商管理、库存统计、
预算/造价员：物资预算、预算统计
物资申请人员：物资申请
采购员：采购计划、采购合同、采购订单、到货验收、合同付款、合同收款、合同台账、供应商维护、供应商评价
仓库管理员：采购合同、采购订单、到货验收、入库单、出库单、库存管理
分管领导：预算、采购、库存、成本(项目级)
公司管理层：预算、采购、库存、成本（公司级+项目级）
集团管理层：预算、采购、库存、成本（集团级+公司级+项目级）

项目监控
展示项目物资预算执行情况、预算外物资采购情况、分类成本占比情况、价格走势分析等

5.3整合需求
本工程物资管理系统需要与公司/外部其他产品之间的整合需求说明。
详细说明见5.2功能详情界面
表5-3-1 整合需求
产品名称 关系 整合内容 备注
公司官网系统产品 链接 允许互相跳转访问 不需要单点登录
android移动应用端 集成 功能同步 　
ios移动应用端 集成 功能同步 　
二维码生成机后台系统 集成 接口 　
短信提醒 集成 与阿里云的短信提醒功能集成 流程可以推送短信提醒，部分事务也提供短信提醒功能，详细见功能说明

六非功能需求
6.1软硬件环境需求
本产品的软硬件环境需求从服务器端和客户端进行描述。详细见下表。
6-1-1 服务器端软硬件环境要求
服务器端软硬件环境需求
对象 内容 需求描述 备注
硬件环境 硬件服务器要求 1，容灾备份；2，性能稳定可靠cpu内存储存空间 一整套硬件环境自建风险和成本较大
网络环境 网络要求 公网接入，且网络稳定，访问速度足够 　
软件环境 操作系统要求 windows 2008及以上 需要付费授权
商业数据库要求 sqlserver oracle oracle商业用途需要付费
其他环境要求 开发环境 自行准备开源免费工具
综合分析：硬件环境成本较高，建议向PAAS供应商采购；软件环境需要技术层面确定好数据库环境。

6-1-2 客户端软硬件环境要求
客户端软硬件环境需求
对象 内容 需求描述 备注
硬件环境 PC机 CPU：内存： 　
移动端（安卓） 操作系统android4.1及以上 　
移动端（苹果） 操作系统ios8.0及以上 　
其它终端 二维码打印机按照我方要求采购 集成好1-2款二维码打印机
网络环境 网络要求 公网接入，且网络稳定，访问速度足够 　
软件环境 操作系统要求 window7及以上 　
浏览器 IE8.0及以上，360、firefox、google 　
其他环境要求 打印机连接正常、流程控件安装 输出单据
综合分析：一般主流品牌机都可以满足要求，企业的网络环境也完全可以满足要求。

6.2营销需求
根据市场分析和产品定位，本业务的营销需求应该定义为潜在需求，针对潜在需求市场，必须进行开发性营销策略。
开发性营销，一般经历过程为：潜在市场分析定义–开发满足潜在需求的产品–挖掘市场潜在客户—引导客户购买–服务客户。
开发性营销表现在技术层面的需求，主要是开发出能满足潜在需求的产品，其次是帮助引导客户购买产品（因为潜在需求可能很多客户自身还没有意识到该产品对自身的意义）。
6-2-1 产品营销需求表
需求内容 详细描述 应对策略
成本低廉 软硬件成本低，建设成本低，服务费用低，风险成本低 提供云服务（SaaS）
功能成熟 业务功能全面、准确、可配置性高 优秀的PRD+技术实现
上线周期短 最快的时间内使用系统享受服务 明确的信息收集指导文档
操作方便 使用系统简单、操作简单、功能易懂 操作手册
安全可靠 数据安全可靠、系统稳定 备份方案、性能保障、代码质量

6.3规则变更需求
本产品为公司第一套产品，暂无需要变更的具体规则。初步描述不同于传统软件产品的规则包括多租户、版本数据耦合、高并发、安全性高、容错强、自助能力强等。

6.4产品服务需求

服务类型 服务内容 服务方 被服务方 服务起止时间 服务频率 场景描述 服务解决方案
对内 需求收集反馈 销售人员、客服人员 技术人员 需求收集到-需求确认完 实时 服务方从各种形式得到的需求反馈给技术人员 需求跟踪表，明确需求解决方案（处理、不处理）
功能升级交付 技术人员 销售人员、客服人员 功能发布-培训结束 按需 技术人员开发功能完成后交付销售人员、客服人员 培训会及说明文档
对外 售前服务 销售人员、客服人员 客户 合同签订前-合同签订 实时 客户咨询，销售人员售前跟踪 上门服务、电话跟踪
售后服务 人工客服 客户 合同签订后-合同约定的服务截止日期 实时 客户通过在线、电话、邮件等各种形式申请服务，人工客服介入处理 在线支持、电话支持、远程协助

6.5法务需求
暂无。

6.6文档帮助需求
本产品配套文档如下
文档名称 文档内容 阅读对象 编制人
产品需求规格说明书（PRD） 产品设计说明 开发人员 产品经理
产品介绍PPT 产品整体介绍，包括产品特点、技术路线、功能等 销售、客户 产品经理
操作手册 按照不同角色进行说明下的产品操作手册 销售、客户 运维人员
开发文档 后台代码规范、界面设计规范、数据库更新规范、详细设计文档、系统测试报告、产品更新记录 开发人员、产品经理 开发负责人
运维指导文档 系统运维分客户运维指导、产品运维指导 客户、产品运维 运维人员
产品不同版本的说明 产品基础版、标准版、扩展版、商务版、定制版的功能及业务核心说明 开发人员、测试人员、运维人员、销售、客户 产品经理
帮助问题 提供常见问题处理办法，视频演示帮助 客户 运维人员
其他文档 产品亮点介绍、核心功能介绍 销售、客户 产品经理

6.7安全性需求
系统保密性：只有授权的用户才能使用和修改系统的信息，而且必须防止信息的非法、非授权的泄露。
漏洞检测和安全风险评估：识别检测对象的系统资源，分析这一资源被攻击的可能指数，了解支撑系统本身的脆弱性，评估所有存在的安全风险。
可用性和抗毁性：设备备份机制、容错机制，防止在系统出现单点失败时，系统的备份机制保证系统的正常运行。
系统防病毒：网络防病毒系统应给予策略集中管理的方式，使得分布式的企业级病毒防护不再困难，而且提供病毒定义的实时自动更新功能。
6.7.1物理安全
由阿里云提供服务
6.7.2网络安全
由阿里云提供服务
6.7.3主机安全
由阿里云提供服务
6.7.4应用安全
 身份鉴别
本项要求包括：
a) 应提供专用的登录控制模块对登录用户进行身份标识和鉴别；
b) 应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别；
c) 应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用；
d) 应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；
e) 应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数。
 访问控制
本项要求包括：
a) 应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问；
b) 访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作；
c) 应由授权主体配置访问控制策略，并严格限制默认帐户的访问权限；
d) 应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系。
e) 应具有对重要信息资源设置敏感标记的功能；
f) 应依据安全策略严格控制用户对有敏感标记重要信息资源的操作；
 安全审计
本项要求包括：
a) 应提供覆盖到每个用户的安全审计功能，对应用系统重要安全事件进行审计；
b) 应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录；
c) 审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；
d) 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。
 剩余信息保护
本项要求包括：
a) 应保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除，无论这些信息是存放在硬盘上还是在内存中；
b) 应保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除。
 通信完整性
应采用密码技术保证通信过程中数据的完整性。
 通信保密性
本项要求包括：
a) 在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证；
b) 应对通信过程中的整个报文或会话过程进行加密。
 抗抵赖
本项要求包括：
a) 应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能；
b) 应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。
 软件容错
本项要求包括：
a) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求；
b) 应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。
 资源控制
本项要求包括：
a) 当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；
b) 应能够对系统的最大并发会话连接数进行限制；
c) 应能够对单个帐户的多重并发会话进行限制；
d) 应能够对一个时间段内可能的并发会话连接数进行限制；
e) 应能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额；
f) 应能够对系统服务水平降低到预先规定的最小值进行检测和报警；
g) 应提供服务优先级设定功能，并在安装后根据安全策略设定访问帐户或请求进程的优先级，根据优先级分配系统资源。
6.7.5数据安全及备份恢复
 数据完整性
本项要求包括：
a) 应能够检测到系统管理数据、鉴别信息和重要业务数据在传输过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施；
b) 应能够检测到系统管理数据、鉴别信息和重要业务数据在存储过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施。
 数据保密性
本项要求包括：
a) 应采用加密或其他有效措施实现系统管理数据、鉴别信息和重要业务数据传输保密性；
b) 应采用加密或其他保护措施实现系统管理数据、鉴别信息和重要业务数据存储保密性。
 备份和恢复
本项要求包括：
a) 应提供本地数据备份与恢复功能，完全数据备份至少每天一次，备份介质场外存放；
b) 应提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地；
c) 应采用冗余技术设计网络拓扑结构，避免关键节点存在单点故障；
d) 应提供主要网络设备、通信线路和数据处理系统的硬件冗余，保证系统的高可用性。
6.8兼容性需求
本章节描述本产品对客户端的兼容性，服务端的兼容性不再此描述。
6.8.1操作系统兼容
围绕终端进行描述如下：
客户PC端：兼容windows7及以上。
客户移动端：IOS9.0及以上，android4.0及以上。
6.8.2浏览器兼容
IE8及以上，360，google，firefox。
6.8.3其它兼容
分辨率兼容：响应式布局。
6.9性能需求
6.9.1响应需求
在本产品客户数（用户数万级以下）在千级以下时，打开页面和提交事务响应时间小于等于1.5s，查询及统计页面响应时间小于等于3s。
6.9.2可靠性需求
保证数据可靠性，业务流转的可靠性。保证系统运行的稳定。最大程度的降低宕机频率，定制服务器及应用系统的合理化重启计划及解决方案。
6.9.3可维护性需求
系统开发文档准确描述业务功能的实现代码及逻辑设计路径，保证系统后续的可维护性。
6.9.4可扩展性需求
系统开发文档准确描述业务功能的数据存储和提交规则，保证系统后续接口及功能扩展容易。
6.9.5易用性需求
解释性说明必须贯穿所有交互页面。
引导性功能必须贯穿所有业务操作。
操作便捷性必须是最高。
6.9.6技术成熟与先进性需求
技术路线选型必须提供技术成熟及先进性描述文档。
开发过程中提供配套文档说明书。
6.10测试需求
本产品的测试需求包括以下内容：
通用测试需求：系统中通用的功能操作、要求（如通用的功能按钮，页面、规定、名词术语等）进行测试。
功能测试需求：系统中页面、功能、操作的测试需求。
流程测试需求：业务流转逻辑、外部引入功能的测试需求。
性能测试需求：也就是非功能性需求测试。

七上线、下线需求
7.1上线需求
产品在达成某些标准合格后可以上线，包括上线功能，上线时间，有无特殊依据或规定。
上线功能：本文档内内容。
上线时间：2019/1/15。
特殊依据：测试通过。
7.2验收标准
验收时的验收标准暂无。
7.3下线需求
此产品不预定下线日期。
 
八运营计划
整体运营由产品经理和技术负责人进行负责，产品的运营包括：销售支持策略、产品升级方案、客户运维支持。

参考资料：