软件产品设计规范.docxVIP

XXX有限公司产品设计规范 PAGE2 / NUMPAGES2 XXX有限公司 产品设计规范 2022年10月 修订记录 序号 修订内容 修订日期 版本 修订人 1 初稿 2020.12.10 1.0 2 2022.10.10 2.0 3 4 5 6 目录 TOC \o 1-3 \h \z \u 1、总则 4 1.1 业务架构图 4 1.2 业务流与数据流 4 1.3 系统名词解释 4 1.4 系统使用角色 4 1.5 系统或模块业务背景介绍 5 2、系统名称约定 5 3、原型图 6 3.1 系统原型设计工具 6 3.2 系统原型模板 6 3.3 系统原型通用元件库 6 3.4 原型图设计全局约定 6 3.5 原型图部署 8 4、用户故事 9 4.1 用户故事格式 9 4.2 用户故事要素 9 4.3 用户故事模板 10 5 交互信息反馈 10 5.1、数据删除确认 10 5.2、数据提交确认 10 5.3、数据未保存，退出编辑时确认 11 5.4 数据装载提示 12 5.5、退出系统确认 12 6、数据列表 12 三、页面 13 1、查询页 13 2、编辑页面 14 3、详情页面 15 四、按钮 16 五、提示信息 17 1、操作成功信息 17 2、业务信息 17 3、异常信息 17 六、交互 17 七、数据字典 18 1、如何创建数据字典 18 2、数据字典规范 18 1、总则 对于需要交付给客户的项目，一份规范、美观的产品原型或需求文档，既能体现我们的专业度，更是企业的脸面。同时可以清晰明确地指导开发，减少沟通成本，特制定此规范。 1.1 业务架构图 每个系统都需要绘制业务总体架构图，从顶层到底层，都具备了哪些功能或业务模块，能够总览系统全局，并列出整个系统模块清单，包括模块结构、命名等。 1.2 业务流与数据流 对于业务流程比较复杂的模块，应先梳理相关的业务流与数据流，理顺后绘制相应的流程图或时序图，确保大流程及数据流向的准确。 1.3 系统名词解释 对于专业性较强，特别是行业内专属的一些名词，须对这些名词进行介绍，以方便开发或相关人员更好理解需求。 1.4 系统使用角色 对于使用系统的角色，须做相应的介绍，可全局了解系统的用户，对开发或架构设计人员在设计系统时有所帮助。 1.5 系统或模块业务背景介绍 对于复杂或业务较为难理解的模块，应提供业务背景介绍，以帮助相关人员更好地理解需求。 2、系统名称约定 为了方便团队成员以统一的业务语言进行沟通，特对各系统的名称进行约定。 序号 简称 中文全称 英文全称 1 OMP xxx智能运营管理平台 Operation Management Platform 2 AMS xxx平台后台管理系统 Authority Management System 3 4 5 6 7 8 9 10 11 12 13 14 15 表1 3、原型图 3.1 系统原型设计工具 不论是Web系统还是移动App，统一采用Axure RP 9.0进行原型图的设计。 3.2 系统原型模板 为了统一原型图的设计风格，提供了模板，在设计时可进行参考。 Web： http://192.168.0.xxx:8080/Sample/Web App（Android）： http://192.168.0.xxx:8080/Sample/Android App（iOS）： http://192.168.0.xxx:8080/Sample/iOS 3.3 系统原型通用元件库 为了统一原型图的设计风格，提供了原型图通用元件库。 地址： \\192.168.0.xxx\prototype\Library 用户名：xxx 密码：xxx# 3.4 原型图设计全局约定 1、描述 对于原型图设计的描述，统一采用便笺，便笺以外的文字会被视为页面元素，如图1所示。 图1 - 便笺描述 2、页面组件注释 通过注释的方式对页面组件进行描述，如图2所示。 图2 – 页面组件注释 组件的注释涉及以下方面： （1）数据类型（文本、数值、日期等）； （2）数据来源（注明来自数据字典或其他业务模块的数据等）； （3）是否必填； （4）格式要求； （5）计算公式 3、每个原型图只说明一个用户故事（功能点） 每个模块应拆分为多个用户故事（功能点），每个用户故事用一个原型图进行描述。例如用户管理模块，细分为查询、新增、修改、重置密码、查看详情五个用户故事，如图3所示。 图3 – 功能点 4、提示信息 在每一步的交互过程中，涉及的提