产品定义模板.docx

产品定义模板.docx

《产品定义模板.docx》由会员分享，可在线阅读，更多相关《产品定义模板.docx（14页珍藏版）》请在冰豆网上搜索。

产品定义模板

产品定义文档-模板

文档修改历史

序号

版本修改记录

版本

修改人

修改时间

1

创建版本

V1.0

刘友兵

2

3

4

1.引言

1.1.编写目的

1.2.项目背景

1.3.参考文献

2.术语介绍

名称

解释

3.概述

3.1.产品综述

产品简介

产品名称

产品定位

产品特点

3.2.使用场景

场景

方式

3.3.市场分析

3.3.1.现状分析（调研报告）

通过现状痛点分析、市场调研报告找到产品的核心价值。

可参照《需求规格说明书》《需求分析报告》

3.3.2.目标用户分析

芸芸众生，我们去寻找谁？

可参照《需求规格说明书》《需求分析报告》

用户分析

行业

职业

年龄

消费能力

心理层面

…

…

3.3.3.用户需求分析

可参照《需求规格说明书》《需求分析报告》

痛点

解决方案

3.4.解决方案

3.5.产品目标

3.5.1.产品目标

产品最终需要达到的目标或产物

3.5.2.产品形态

产品最终的形态介绍

3.5.3.产品参数

产品最终的详细参数信息。

如产品名称、适用行业、技术参数等

4.产品架构

4.1.网络拓扑图

网络部署拓扑图

4.2.产品结构图

产品结构思维导图

4.3.业务架构图（俯视架构）

业务架构是对领域模型进行设计，是对整个系统的业务进行拆分，把现实的业务转化为抽象的对象。

包括业务规划、业务模块、业务流程。

4.4.应用架构图（逻辑架构）

应用架构也称为逻辑架构，是硬件到应用的抽象。

如：

数据层、服务层、应用层、渠道层等。

应用分层包括水平分层（横向）、垂直分层（纵向）。

4.5.业务流程图

对整个产品核心业务的流程介绍

4.6.系统架构图（技术架构）

5.功能需求

5.1.XXX管理系统

5.1.1.XXX功能

5.1.1.1.功能描述

5.1.1.2.业务流程

5.1.1.3.详细功能

5.1.1.3.1.查询

1.查询条件

2.列表

3.消息提示

5.1.1.3.2.新增

5.1.1.3.3.修改

5.1.1.3.4.删除

5.1.1.4.界面交互

5.1.2.全局功能

5.1.2.1.消息提示

5.1.2.2.数据交互

1.数据提交

2.数据加载

3.页面刷新

5.1.2.3.公共界面

1.系统异常

2.数据库连接异常

3.网络异常

5.2.XXX移动APP

5.2.1.XXX功能

5.2.1.1.功能描述

5.2.1.2.业务流程

5.2.1.3.详细功能

5.2.1.4.界面交互

5.2.2.全局功能

5.2.2.1.功能权限

功能使用权限，如登录、未登录情况

5.2.2.2.消息提示

5.2.2.3.键盘说明

1.选择手机号验证时，点击手机号码与验证码时输入框底部弹出数字键盘。

2.点击其他输入框页面底部弹出字母全键盘。

5.2.2.4.数据交互

1.数据提交

2.数据加载

3.页面刷新

如：

上拉刷新、下拉加载

5.2.2.5.公共界面

1.页面异常

2.网络异常

6.非功能性需求

6.1.界面要求

1.一致性

坚持以用户体验为中心设计原则，界面直观、简洁，操作方便快捷，用户接触软件后对界面上对应的功能一目了然、不需要太多培训就可以方便使用本应用系统。

Ø字体

保持字体及颜色一致，避免一套主题出现多个字体；

不可修改的字段，统一用灰色文字显示。

Ø对齐

保持页面内元素对齐方式的一致，如无特殊情况应避免同一页面出现多种数据对齐方式。

Ø表单录入

在包含必须与选填的页面中，必须在必填项旁边给出醒目标识（*）；

各类型数据输入需限制文本类型，并做格式校验如电话号码输入只允许输入数字、邮箱地址需要包含“@”等，在用户输入有误时给出明确提示。

Ø鼠标手势

可点击的按钮、链接需要切换鼠标手势至手型；

Ø保持功能及内容描述一致

避免同一功能描述使用多个词汇，如编辑和修改，新增和增加，删除和清除混用等。

建议在项目开发阶段建立一个产品词典，包括产品中常用术语及描述，设计或开发人员严格按照产品词典中的术语词汇来展示文字信息。

2.准确性

Ø使用一致的标记、标准缩写和颜色，显示信息的含义应该非常明确，用户不必再参考其它信息源。

Ø显示有意义的出错信息，而不是单纯的程序错误代码。

Ø避免使用文本输入框来放置不可编辑的文字内容，不要文本将输入框当成标签使用。

Ø使用缩进和文本来辅助理解。

Ø使用用户语言词汇，而不是单纯的专业计算机术语。

Ø高效地使用显示器的显示空间，但要避免空间过于拥挤。

Ø保持语言的一致性，如“确定”对应“取消”,“是”对应“否”。

3.布局

在进行UI设计时需要充分考虑布局的合理化问题，遵循用户从上而下，自左向右浏览、操作习惯，避免常用业务功能按键排列过于分散，以造成用户鼠标移动距离过长的弊端。

多做“减法”运算，将不常用的功能区块隐藏，以保持界面的简洁，使用户专注于主要业务操作流程，有利于提高软件的易用性及可用性。

Ø菜单

保持菜单简洁性及分类的准确性。

Ø按钮

确认操作按钮放置左边，取消或关闭按钮放置于右边。

Ø功能

未完成功能必须隐藏处理，不要置于页面内容中，以免引起误会。

Ø排版

所有文字内容排版避免贴边显示（页面边缘），尽量保持10-20像素的间距并在垂直方向上居中对齐；各控件元素间也保持至少10像素以上的间距，并确保控件元素不紧贴于页面边沿。

Ø表格数据列表

字符型数据保持左对齐，数值型右对齐（方便阅读对比），并根据字段要求，统一显示小数位位数。

Ø滚动条

页面布局设计时应避免出现横向滚动条。

Ø页面导航（面包屑导航）

在页面显眼位置应该出现面包屑导航栏，让用户知道当前所在页面的位置，并明确导航结构。

Ø信息提示窗口

信息提示窗口应位于当前页面的居中位置，并适当弱化背景层以减少信息干扰，让用户把注意力集中在当前的信息提示窗口。

一般做法是在信息提示窗口的背面加一个半透明颜色填充的遮罩层

6.2.环境要求

6.2.1.软件环境要求

需求名称

详细要求

6.2.2.硬件环境要求

需求名称

详细要求

6.3.适用性要求

6.4.产品质量要求

主要质量属性

详细要求

正确性

健壮性

可靠性

易用性

清晰性

安全性

可扩展性

兼容性

可移植性

…

6.5.兼容性要求

6.5.1.设备兼容性

6.5.2.品牌兼容性

6.5.3.协议兼容性

6.5.4.网络兼容性

6.5.5.系统兼容性

编号

系统

版本

测试侧重

1

Windows7

64位

主测

2

Windows10

64位

主测

3

WindowsServer2008R2

64位

主测

4

centos

6.5及以上

主测

6.5.6.手机兼容性

编号

系统

版本

型号（品牌）

1

iOS

9.0及以上

iPhone5（C）/5（S）、iPhone6（S）/7/8（4.7英寸）、iPhone6（S）/7/8（5.5英寸）、iPhoneX（5.8英寸）

2

Android

4.0及以上

Vivo、oppp、小米、华为、三星、荣耀、魅族、金立、联想、中兴

6.5.7.浏览器兼容性

6.6.性能要求

指标大类

指标小类

指标

说明

资源使

用率

磁盘I/O

磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用%DiskTime（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能

内存使用率

内存利用率=（1-空闲内存/总内存大小）*100%，一般至少有10%可用内存，内存使用率可接受上限为85%

CPU占用率

用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85%

带宽

一般使用计数器BytesTotal/sec来度量，BytesTotal/sec表示为发送和接收字节的速率，包括帧字符在内。

判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较

并发处理

并发用户

某一物理时刻同时向系统提交请求的用户数

在线用户

某段时间内访问系统的用户数，这些用户并不一定同时向系统提交请求

接口并发

某一物理时刻同时向系统接口提交的请求数

吞吐量

指单位时间内系统处理用户的请求数。

从业务角度看，吞吐量可以用：

请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量从网络角度看，吞吐量可以用：

字节/秒来衡量

响应时间

平均响应时间

系统处理事务的响应时间的平均值。

事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。

对于系统快速响应类页面，一般响应时间为3秒左右。

服务端响应时间：

服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间可以度量服务器的处理能力。

网络响应时间：

网络硬件传输交易请求和交易结果所耗费的时间

客户端响应时间：

客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web应用来说，比如Javaapplet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。

       那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。

细分的目的是为了方便定位性能瓶颈出现在哪个节点上

稳定性

事务成功率

单位时间内系统可以成功完成多少个定义的事务

超时错误率

主要指事务由于超时或系统内部其它错误导致失败占总事务的比率

其它

根据实际的系统要求可增加

6.7.安全性要求

6.7.1.应用安全

6.7.2.数据安全

6.7.3.主机安全

6.7.4.网络安全

6.7.5.密钥管理

6.7.6.客户（用户）信息认证与保密

6.7.7.终端安全

6.8.产品指标

6.8.1.硬件指标

名称

指标

说明

稳定性

温度

湿度

防尘

防潮

使用寿命

…

6.8.2.软件指标

7.接口

8.系统参数配置

8.1.系统参数数据字典

编码

类型名称

说明

0

1

2

3

4

8.2.系统异常数据字典

8.3.系统角色数据字典

9.上线部署

暂无

10.附录