互联网产品需求说明书范本(PRD文档)
PRD产品需求规格说明书标准模版
系统需求规格说明书- XX系统-XX需求版本：V0.9发布日期2017年05月03日文档描述目录1引言 (5)1.1背景 (5)1.2目标 (5)1.3范围 (5)1.4干系人 (5)1.5术语缩略语 (5)1.6规范性文件 (6)2业务需求说明 (6)2.1用户说明 (6)2.2业务期望 (6)2.3业务流程 (6)2.4业务规则 (6)3功能概述 (6)3.1需求树分解 (6)3.2多系统间功能流程描述 (7)3.2.1XX系统改造描述 (8)3.2.2YY系统改造描述 (8)3.2.3AA系统改造描述 (8)3.2.4BB系统改造描述 (8)3.3接口清单 (9)4本系统需求概述 (9)4.1系统流程图 (9)4.1.1XXXX流程图 (11)4.1.2XXXX流程图 (11)4.2关键业务逻辑或算法 (11)4.3需求功能清单 (11)4.4数据字典 (12)5功能需求 (12)5.1XXX功能模块 (12)5.1.1执行者 (12)5.1.2条件说明 (12)5.1.3菜单索引 (12)5.1.4主界面原型 (12)5.1.5流程及规则说明 (13)5.1.6用例/操作说明 (13)5.1.6.1用例/操作XXX1说明 (13)5.1.6.2用例/操作XXX2说明 (14)6用户角色及权限 (14)7历史数据处理 (15)8非功能需求 (15)8.1运行环境和资源要求 (15)8.2设计和实现约束 (15)8.3性能需求 (15)8.4安全性需求 (15)8.5版本发布需求 (15)8.6质量标准需求 (15)8.7维护服务支持需求 (16)9附件列表 (16)10待确定问题列表 (16)1引言1.1背景【描述需求的背景来源、现状分析】1.2目标【描述需求实现的目的、此需求实现后带来的优势，确认目标读者】1.3范围【描述需求实现具体范围界定，涉及的业务部门及用户，解决的业务问题。
包含：业务范围界定、使用部门范围界定、系统集成范围界定等】具体对应关系见下表：1.4干系人1.5术语缩略语【描述文中涉及到的相关业务术语，行业术语、缩略语，并做简要解释】【如果没有，可以裁剪。
完整word版)PRD产品需求文档经典模板
完整word版)PRD产品需求文档经典模板产品需求文档模板产品需求文档的定义：此文档的目的是收集、分析和定义>的需要和特性。
它包括相关方和目标用户需要的功能和这些需要存在的原因，以及详细地说明所确定的产品的关键外部业务流程、接口和非功能性特性的需求、设计约束。
此文档用来让读者了解产品的外部黑盒概念，并指导《架构设计说明书》和《软件需求说明书》。
一个产品只有一份《产品需求文档》，对于分解的对内项目部分可以以《xxxx产品需求文档—yyyy分册》来撰写。
文档版本号：文档密级：产品名：编写人：文档编号：归属部门/项目：子系统名：编写日期：修订记录：版本号修订人修订日期修订描述PRD文档模板目录一、简介1、目的2、范围简介：本文档旨在收集、分析和定义>的需要和特性。
通过详细说明产品的关键业务流程、接口和非功能性特性的需求，以及设计约束，让读者了解产品的外部黑盒概念，并指导后续的架构设计和软件需求说明书。
目的：本文档的目的是收集、分析和定义>的需要和特性。
范围：本文档包括相关方和目标用户需要的功能和这些需要存在的原因。
同时，详细说明所确定的产品的关键外部业务流程、接口和非功能性特性的需求、设计约束。
二、产品概述本产品是一款基于云计算技术的企业级管理系统，旨在帮助企业实现信息化管理，提高工作效率和管理水平。
该系统具备多种功能模块，包括人事管理、财务管理、项目管理、客户管理等，能够满足企业不同部门的管理需求。
三、流程图1、业务流程图（推荐使用泳道图）本系统的业务流程图主要包括以下泳道：人事管理、财务管理、项目管理、客户管理。
在每个泳道中，都包含了该部门的具体业务流程，如人事管理泳道中包括招聘、培训、考核等流程。
2、状态图（理清状态流转）本系统的状态图主要用于描述不同状态之间的流转关系，如项目状态的变化、人员状态的变化等。
通过状态图，可以清晰地了解系统中各个状态之间的关系，帮助用户更好地管理和控制业务流程。
互联网产品需求说明书范本(PRD文档)
《产品需求说明书》模板项目名称： XXXXXXX项目负责人： XXXXXXX批准人/日期： XXXXXXX/2009.04.28[注：以下提供的模板内容给写作者提供一个参考，产品不同表述的内容可能不尽相同，网站需求书写人员需要根据实际情况增减。
其中用方括号括起来以蓝色斜体显示的文本，用于说明，在正式发布文档之前应该将其删除。
按正式样式输入的段落文字要用5号字、黑色、宋体字。
]目录1. 变动历史 (2)2. 文档说明 (2)2.1. 文档介绍 (3)2.2. 读者对象 (3)2.3. 名词解释 (3)3. 需求概要 (3)3.1. 目标 (3)3.2. 产品结构流程图 (4)3.3. 关联及潜在关联 (4)3.4. 未来版本预期 (4)3.5. 错误及异常处理 (4)3.6. 页面路径 (4)3.7. 功能点列表 (5)4. 详细需求-XXXXXXX（如注册/登录） (5)4.1. 需求概述 (5)4.1.1结构图或流程图 (5)4.1.2数据项规划 (5)4.2. 用例说明 (6)4.4.1新闻浏览 (6)4.4.2会员登陆 (6)4.3. 页面图（visio） (7)4.4.1页面1 (8)4.4.2页面2 (8)4.4.3页面3 (8)1.变动历史[ 记录本文档的修改历史，包括作者、日期、版本号、变动原因原因。
[方式]表格2.文档说明[根据本需求文档要阐述的内容，对其作总体的概述。
使开发人员及测试人员对需求文档阐述的内容有一个整体的了解，使之成为工作的基础和宗旨。
]2.1.文档介绍[大体介绍一下文档包含的内容]此需求文档的编写是为<XXXXXX>项目的设计与开发作基础主要包括：前台页面后台管理邮件发送2.2.读者对象本文档读者对象：技术开发人员、测试人员2.3.名词解释[通用名字解释。
]如手动更新：热门关键字：3.需求概要[这部分针对文档要描述的产品，主要阐述整体或部分的概览性质的需求描述。
产品需求说明书PRD实用模板完整版
实用文档版本号V2.1产品需求说明书编写人：编写时间：修订控制页目录1概述 (5)1.1名词说明 (5)1.2产品概述及目标 (5)1.3产品roadmap (5)1.4产品风险 (6)2使用者需求 (6)2.1需求描述 (6)3可选方案 (6)4效益成本分析 (7)4.1效益预测 (7)4.2产品技术中心成本 (7)4.3非产品技术中心的支持成本 (8)5功能需求 (8)5.1功能总览 (8)5.2功能详情 (12)5.3整合需求 (13)5.4BETA测试需求 (13)6非功能需求 (14)产品营销需求 (1414)规则变更需求 (14)产品服务需求 (14)法务需求 (15)财务需求 (15)帮助需求 (15)安全性需求 (15)7上、下线需求 (15)7.1上线时限需求 (15)7.2下线需求（活动类需求必须明确下线时间） (15)8运营计划 (15)请与以下部门讨论PRD 序号XXX 部门沟通内容1.□市场部：XXX ⏹协助设定产品的RaodMap⏹协助设定target customer：使用者⏹协助评估：营销/推广需求⏹协助设定商业目标2.□销售部：XXX ⏹协助设定产品的RaodMap⏹协助设定target customer：使用者⏹协助评估：营销/推广需求⏹协助设定商业目标3.□技术支持部：客服服务XXX ⏹讨论客服如何支持：客服需求⏹协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不当使用风险⏹预测客服成本、工作量4.□技术支持部:网络安全XXX⏹评估安全性5.□技术研发部：系统分析师XXX ⏹讨论以确定方案的规模评估、推出计划⏹进行技术可行性分析，提出关键问题的技术解决方案⏹评估系统规模，数据量，所需资源等⏹协助评估风险6.□技术研发部：项目经理XXX ⏹协助确定产品发布日期⏹协助确定产品成本⏹协助评估风险7.□产品部：用户体验设计之交互设计师XXX ⏹协助制作Demo⏹协助确定use flow：用户使用方式⏹协助确定UI UE的方向风格8.□财务分析中心：财务组XXX ⏹请评估财务需求⏹协助评估风险9.□数据分析组:XXX⏹协助确定如何度量产品目标10.□行政管理中心：法务部XXX ⏹协助评估法务问题并检视合作伙伴：使用者数据需求、法务需求、版权、隐私权等需求⏹协助评估风险：诈欺/数据窜改风险、不当使用风险1概述1.1名词说明1.2产品概述及目标온라인상에서고객의사업자행동을사업자학습최초입자의시장지배사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업자사업1.3产品roadmap请描述产品发展的各个阶段，可以用图表等多种方式表述。
产品需求说明书(PRD)模板-精简版
Confidential(公司内部文档)XXXX需求规格说明书需求规格说明书目录1 前言 (4)1.1编写目的 (4)1.2文档约定 (4)1.3术语和缩略词 (5)1.4参考资料 (5)2 项目概述 (5)2.1项目背景 (5)2.2项目目标 (6)2.3需求范围 (6)2.4总体框架 (6)2.5组织机构 (6)2.6用户特点 (6)2.7设计约束 (7)3 功能性需求 (7)3.1总体流程 (7)3.2角色定义 (7)3.3系统功能 (7)3.4功能描述 (8)4 非功能性需求 (10)4.1软件需求 (10)4.2硬件需求 (11)5 风险分析 (12)6 其他说明 (12)1 前言1.1 编写目的[说明编写这份需求规格说明书的目的，指出预期的读者（一般包括评审人员、软件设计人员、软件开发人员，针对具体情况，还可能包括客户），它是软件开发的基础。
]示例：1.准确全面定义、阐述xx业务需求，明确xx系统的目标和功能。
2.为有关业务部门和技术部门提供对这个系统的统一的文字的理解。
为业务部门判断系统是否满足其业务需要提供文字依据，为技术部门监督项目功能提供统一标准。
3.在xx系统之前尽可能周密考虑全部需求及设计要求，减少以后可能的重新设计、重新编码、重新测试等工作。
4.为设计项目方案、编制计划进度提供文字依据。
5.为对项目的完成进行确认和验证提供基准。
本需求规格说明书合法读者对象为：软件开发项目管理者、设计师、测试工程师、技术人员、业务人员。
1.2 文档约定[描述编写文档时所采用的字体标准或排版约定，包括标题和正文的字体和字号约定。
完成文档编写后，文档编写完成后本部分须裁剪]字体大小约定：标题1 宋体三号加粗标题2 宋体小三号加粗标题3 宋体四号加粗标题4 宋体小四号加粗标题5 宋体小四号正文宋体五号段落约定：文章中每段落需抬头，即段落开头需有两字元的缩排，单倍行距。
表与图编号约定：文中所有表、图须按章节编号，如：第四章节第二个表，编号为：表4-2。
产品需求说明书(规格最全的PRD)
版本号0.6TOP接入系统产品需求说明书编写人：编写时间：修订控制页目录1概述 (5)1.1名词说明 (5)1.2产品概述及目标 (5)1.3产品roadmap (6)1.4产品风险 (6)2使用者需求 (7)2.1需求描述 (7)3可选方案 (7)4效益成本分析 (7)4.1效益预测 (7)4.2产品技术中心成本 (8)4.3非产品技术中心的支持成本 (8)5功能需求 (9)5.1功能总览 (9)5.2功能详情 (10)5.3整合需求 (26)5.4BETA测试需求 (27)6非功能需求 (27)产品营销需求 (27)规则变更需求 (27)产品服务需求 (27)法务需求 (28)财务需求 (28)帮助需求 (28)安全性需求 (28)7上、下线需求 (28)7.1上线时限需求 (28)7.2下线需求（活动类需求必须明确下线时间） (28)8运营计划 (29)请与以下部门讨论PRD 序号OK？部门沟通内容1.□运营中心：商城、集市、二手闲置、门户⏹协助设定产品的RaodMap⏹协助设定target customer：使用者⏹协助评估：营销/推广需求⏹协助设定商业目标2.□运营中心：网站运营⏹协助设定产品的RaodMap⏹协助设定target customer：使用者⏹协助评估：营销/推广需求⏹协助设定商业目标3.□客户中心：客服服务部⏹讨论客服如何支持：客服需求⏹协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不当使用风险⏹预测客服成本、工作量4.□客户中心：网络安全部⏹评估安全性5.□产品技术中心：系统分析师虚拟团队⏹讨论以确定方案的规模评估、推出计划⏹进行技术可行性分析，提出关键问题的技术解决方案⏹评估系统规模，数据量，所需资源等⏹协助评估风险6.□产品技术中心：项目经理⏹协助确定产品发布日期⏹协助确定产品成本⏹协助评估风险7.□产品技术中心：用户体验设计之交互设计师⏹协助制作Demo⏹协助确定use flow：用户使用方式8.□财务分析中心：财务组⏹请评估财务需求⏹协助评估风险9.□财务分析部：数据分析组⏹协助确定如何度量产品目标10.□行政管理中心：法务部⏹协助评估法务问题并检视合作伙伴：使用者数据需求、法务需求、版权、隐私权等需求⏹协助评估风险：诈欺/数据窜改风险、不当使用风险11.□规则委员会⏹协助评估规则变更的影响12.□支付宝⏹协助确定接口、合作方式等13.□阿里软件⏹协助确定接口、合作方式等1概述1.1名词说明介绍本文档中会使用到的专用名词，如：新名词、产品内实体单位，请尽量使用大众可理解的名词1.2产品概述及目标请以三到五段文字摘要说明您所提出的新服务(包含推出新产品、现有产品重新设计或升级、现有服务推出新功能)及目标；请包括：1、产品背景说明；xx开放平台是建立大xx的关键要素之一。
产品需求说明书PRD
产品需求说明书P R D(共21页) -本页仅作为预览文档封面，使用时请删除本页-＊＊＊＊＊＊＊＊＊＊＊＊产品需求说明书产品编号：文档编号：文件修改控制目录一、产品业务需求......................................... 错误!未定义书签。
1、产品的需求人....................................... 错误!未定义书签。
2、系统使用人......................................... 错误!未定义书签。
3、系统实现目标....................................... 错误!未定义书签。
二、产品功能需求......................................... 错误!未定义书签。
(一) 经销商系统....................................... 错误!未定义书签。
1、产品流程、规则说明................................. 错误!未定义书签。
2、产品系统结构....................................... 错误!未定义书签。
3、系统功能说明....................................... 错误!未定义书签。
1) 登录............................................. 错误!未定义书签。
2)车辆拍卖监控..................................... 错误!未定义书签。
3) 成交明细......................................... 错误!未定义书签。
4) 车辆来源登记..................................... 错误!未定义书签。
正确的写产品需求文档(PRD)
正确的写产品需求文档（PRD）宗旨：通过工具—把思想有逻辑、有细节的合理的组织到一起！互联网行业，蓬勃兴起，很多从事产品工作。
不管是生手、新手、老手还是高手，我也想和大家分享一下产品需求文档的一些心得，希望能帮助大家(pa/pm)更好的提高自身水平、提高工作效率。
我这里只是简单的从需求的实施环节进行描述。
之前的需求的调查、需求的获取、需求的比较分析取舍等等都不再阐述了。
1、熟悉项目发生的相关业务行为。
言下之意，就是说：我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。
简而言之，得要求：面向业务（对象），进行业务行为（设计），也是需求的开始，推荐工具：Ration rose ★★★★说明：通过use case 可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。
工程师看的明白、产品人员也看得明白。
2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一很笼统的说，就是；流程问题流程就是逻辑，你只有制定合理的、符合业务实际情况。
符合系统实现（可实现、容易或稳定实现）的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。
不管是进销存、还是SAP原理其实都是相通的。
推荐工具：Visio 2007 ★★★★★说明：Visio是个老掉牙的工具了，从微软手里出到了07版本，它该有的模型都有了，通过visio 你可以直接的把整站流程框束在文档上。
不论你开发怎么样的系统，需求什么样的环境，都可以一一标明出来。
你的流程图的好坏直接会影响工程师实现你指定产品的实现方式。
所以强调一点，产品人员要熟悉计算机开发，熟悉人机交互，熟悉一些常用的开发方式，这样有助于很好的和团队做融合，更好的框架更容易扩展。
3、把项目条目化，条理化，目录结构具体规定好。
有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
《产品需求说明书》模板
项目名称： XXXXXXX
项目负责人： XXXXXXX
批准人/日期： XXXXXXX/2009.04.28
[注：以下提供的模板内容给写作者提供一个参考，产品不同表述的内容可能不尽相同，网站需求书写人员需要根据实际情况增减。
其中用方括号括起来以蓝色斜体显示的文本，用于说明，在正式发布文档之前应该将其删除。
按正式样式输入的段落文字要用5号字、黑色、宋体字。
]
目录
1. 变动历史 (2)
2. 文档说明 (2)
2.1. 文档介绍 (3)
2.2. 读者对象 (3)
2.3. 名词解释 (3)
3. 需求概要 (3)
3.1. 目标 (3)
3.2. 产品结构流程图 (4)
3.3. 关联及潜在关联 (4)
3.4. 未来版本预期 (4)
3.5. 错误及异常处理 (4)
3.6. 页面路径 (4)
3.7. 功能点列表 (5)
4. 详细需求-XXXXXXX（如注册/登录） (5)
4.1. 需求概述 (5)
4.1.1结构图或流程图 (5)
4.1.2数据项规划 (5)
4.2. 用例说明 (6)
4.4.1新闻浏览 (6)
4.4.2会员登陆 (6)
4.3. 页面图（visio） (7)
4.4.1页面1 (8)
4.4.2页面2 (8)
4.4.3页面3 (8)
1.变动历史
[ 记录本文档的修改历史，包括作者、日期、版本号、变动原因原因。
[方式]表格
2.文档说明
[根据本需求文档要阐述的内容，对其作总体的概述。
使开发人员及测试人员对需求文
档阐述的内容有一个整体的了解，使之成为工作的基础和宗旨。
]
2.1.文档介绍
[大体介绍一下文档包含的内容]
此需求文档的编写是为<XXXXXX>项目的设计与开发作基础
主要包括：
前台页面
后台管理
邮件发送
2.2.读者对象
本文档读者对象：技术开发人员、测试人员
2.3.名词解释
[通用名字解释。
]
如
手动更新：
热门关键字：
3.需求概要
[这部分针对文档要描述的产品，主要阐述整体或部分的概览性质的需求描述。
]
3.1.时间表
耗费XX/人时
3.2.目标及校验-项目负责人
校验时间
表格时间点校验人
[项目预期要达到的最终的目的、运营目标及数据目标等。
需要和项目负责人沟通确定。
] 网站指标
[主要给出网站在运营开始以及在一定时段内的运营指标
（1）要求网站支持用户数。
（2）支持同时在线数和并发访问量。
（3）峰值访问量。
（4）数据量及数据增长率。
例：
预计：网站1.0版支持百万级用户。
同时在线：100万×20% = 20万用户
并发访问：20万×1‰= 200 用户
数据指标
[主要给出网站数据量指标。
包括：
（1）文章或者数据资源的存储数量以及容量。
（2）单位时间的增长量
（3）数据长远规划原则
以一个b2c网站为例
用户平均2交易/用户.周
网站交易量：
1000万用户×50% ×2交易/用户.周×50周= 50000万交易/年3.3.产品结构流程图
[对整个产品绘制结构图，如果是用户交互性的，要绘制流程图。
] 3.4.关联及潜在关联
3.5.未来版本预期
3.6.错误及异常处理
错误接收人，处理方法
3.7.页面路径
例子:
3.8.功能点列表
描述整个产品主要功能，难点功能、列举
如
●内容发布及管理
妈妈说官方信息；媒体报道；广告服务、案例分析等内容采编发布管理
●友情链接自助申请
●新闻订阅
按照填写的邮箱列表，发送新闻。
退订功能
4.详细需求-XXXXXXX（如注册/登录）
[比如注册/登录可以放在一个块里写需求。
]
4.1.需求概述
4.1.1结构图或流程图
[该模块结构图，或户交互性流程图。
]
4.1.2数据项规划
如果产品或某一个模块中包含数据项，需要定义数据项，包括：
（1）数据项名称
（2）数据项描述：定义数据项的含义
（3）数据约束：如果有能力，可以进一步规定数据项的数据约束。
（4）数决约束的分类：
非空约束：“是否必填”；“是否必选”；或两者兼之。
元素约束：对输入框，输入内容的组成元素选择的范围，如：不区分大小写(A-Z, a-z, 0-9,-,_)，必须包含“@”和“.”。
长度约束：对输入框，输入内容的上下限，如：不超过255个字符。
格式约束：输入内容的结构性要求，如：日期格式：yyyy-mm-dd。
唯一约束：数据项的值在是否允许相同，如：用户ID。
关联约束：其他数据项对当前数据项的限定，如：不能早于开始日期，必须大于当前日期2005-7-22。
例：
4.2.用例说明
[比较重要的功能模块，并且业务比较复杂，需要对此模块进行用例说明。
如果模块的功能很简单，这部分可以略掉。
]
4.4.1新闻浏览
[例子：简单用例]
使用角色：会员、游客
前提条件：
初始页面：媒体报道
过程说明（基本流程）：
1、用户选择<媒体报道>可查看媒体报道新闻浏览
2、点击左侧按年月归类，可查看某年或某月的新闻
3、通过翻页，可查看更多新闻
4、点击新闻标题可以查看新闻的具体内容
4.4.2会员登陆
[例子：复杂用例]
会员通过该模块登录进入
使用角色：注册会员
前提条件：无
初始页面：登录页面（链接到本文档后面相关visio图）或其他登录入口
过程说明（基本流程）：
1.用户向系统提出登录请求
2.系统进入登录页面，让用户输入登录名和密码，并有为用户忘记密码提供另一种解
决途径的链接——“忘记密码”
3.用户输入会员登陆名和密码后，提交信息
4.系统接收信息，验证输入登录名是否存在、验证密码是否正确，如果正确，则登录
成功，进入管理中心，本用例结束；如果会员登录名不存在或密码不正确，则报错误信息提示用户“您输入的登录名不存在，或密码不正确，请确认后重新登录”，重复3）、4）步骤
过程说明（备选流程）：
A.找回密码：
3a1) 在基本流步骤3）中，如果用户点击找回密码链接
3a2) 系统进入找回密码页面，要求用户输入其注册邮箱
3a3) 用户填写信息后，点击确定，提交信息
3a4) 系统判断用户邮箱是否存在，如果存在则发送邮件到用户邮箱，并提示用户
查收邮件，用户可以通过该邮件进入系统重设密码，本用例结束；如果不存在则
提示用户输入的登录用户名不存在，重复3a3)、3a4)步骤
B.重设密码：
3a4a1)用户在备选流程A 3a4)步骤中点击邮件里的重设密码链接
3a4a2)系统进入重设密码页面，页面提供用户输入新密码和确认密码
3a4a3)用户输入密码后，确认提交
3a4a4)系统验证新密码和确认密码是否相同、密码是否符合要求，如果通过验
证，系统更新用户密码，并提示用户密码设置成功，本用例结束；如果不通过，
则提示用户错误原因，重复3a4a3)、3a4a4)步骤
后置条件：无
其它说明：无
4.3.页面图（axure截图）
[将axure页面统一归类在这里，其它地方通过链接到此处查看界面。
并对axure或html页面中的每个模块做详细功能描述。
]
4.4.1页面1 4.4.2页面2 4.4.3页面3。