OTQPPMT21 需求确认书.docx
- 文档编号:24229415
- 上传时间:2023-05-25
- 格式:DOCX
- 页数:10
- 大小:86.25KB
OTQPPMT21 需求确认书.docx
《OTQPPMT21 需求确认书.docx》由会员分享,可在线阅读,更多相关《OTQPPMT21 需求确认书.docx(10页珍藏版)》请在冰豆网上搜索。
OTQPPMT21需求确认书
[某某项目]
需求确认书
Ver:
客户方签字:
项目负责人签字:
目录
1概述4
1.1编写目的4
1.2项目背景4
1.3文档团队4
1.4项目管理团队5
1.5项目假设与约束5
2项目前景与范围5
2.1项目前景5
2.2项目范围5
3需求概述6
3.1角色(用户)分析6
3.2产品特性6
3.3功能列表7
3.4权限列表7
4功能性需求7
5非功能性需求9
5.1指标参数9
5.1.1性能参数9
5.1.2并发用户数10
5.1.3数据容量10
5.2硬件服务器及网络需求10
5.2.1网络拓扑10
5.2.2软硬件环境10
5.2.3网络需求11
5.3扩展性11
5.4安全性11
5.5可管理性11
5.6可支持性11
5.7可用性/可靠性11
5.8运营培训需求11
5.9兼容性要求12
6附录12
6.1修改记录12
1概述
1.1编写目的
[简要说明文件的主要内容及编写此文件希望达到的目的。
下边是一个示例:
本文档包含合众人寿保险股份有限公司电子商务网站一期工程(以后简称本项目、一期工程)的功能性需求以及非功能性需求方面的内容。
由合众人寿项目小组以及佳诚公司项目研发小组根据项目招标书共同整理完成,经双方经手人联合签字后作为项目开发、测试、验收的最主要依据文献。
本文档中所有出现界面原型部分,仅作为功能、流程等之辅助说明用途,不作为最终界面验收依据。
界面相关的约束由界面原型文档补充说明。
]
1.2项目背景
[描述项目的常规背景。
示例:
项目名称:
合众人寿电子商务网站一期
项目的提出方:
合众人寿保险股份有限公司
项目目标:
为合众人寿保险股份有限公司以信息发布为基础的基本网上交流平台,并为后续电子商务平台建设提供基础平台
]
1.3文档团队
[文档编写团队。
建议由项目组PM负责本文档编写。
]
1.4项目管理团队
[项目初期建立的项目管理团队成员。
列出双方接口人、CCB成员、双方项目负责人]
1.5项目假设与约束
[列出文档编写中已知的约束条件和假设]
2项目前景与范围
2.1项目前景
[从商业价值角度说明项目实施后的前景,项目成果的预期,项目成果所能带来的价值、效果等等。
如果已经编写项目章程可以从项目章程中复制。
]
2.2项目范围
[以列表方式写出项目需要完成的需求、功能、性能要求等等;在与客户交流中明确不实现的范围在“超出范围”列出。
]
项目范围:
超出范围:
3需求概述
3.1角色(用户)分析
[全面分析项目成果的用户特点,期望等等,如果有图表,也可以贴出。
建议采用交互式设计技术。
示例(未采用交互设计技术):
本项目的用户分为匿名用户、个人客户、团险HR客户、管理员几类。
匿名用户所有浏览网上的且未登录的用户。
匿名用户可以留言、报案。
个人是已经购买合众产品并且已经拿到客户密码的用户;
团险HR客户是指团险的经办人。
个人客户和团险HR客户在逻辑上继承自匿名客户,即这两类客户除了享受专属的客户服务功能外,也可享受为到匿名客户提供的所有服务。
管理员是有权进行后台管理的所有人员的统称,按照其具体工作职责的不同,可以更详细的划分专属管理员,所有权限分配都可以由网站的总管理员进行设定。
]
3.2产品特性
[从概要性角度简要说明产品的特性和范围。
可以使用图表概述,详细的功能列表见3.3节,详细的需求见4.功能性需求。
示例:
]
3.3功能列表
[详细列出项目需要实现的功能,并标出优先级(高[1]、中[2]、低[3])。
3.4权限列表
[以列表方式排列用户角色与功能列表,表明每个角色所具备的系统权限。
如果系统中不涉及到此部分,请删除。
]
4功能性需求
[详细说明功能性需求。
每个功能需求均应包含用例描述、序列图;创新类项目(或Scrum生命周期)建议采用场景(backlog)驱动的方式编写,每个场景以故事的形式描述最终用户(结合3.1的用户分析)使用的具体场景,每个场景可以推演出多个需求。
每个需求都要详细描述出用例说明、序列图。
请注意:
界面设计属于设计,不属于需求。
如果用户强烈要求,应以功能示意图的形式列出,避免陷入界面设计细节。
示例1:
用例名:
转账
Ø干系人利益
银行:
安全、准确、节约运营成本
银行客户:
安全、快捷
Ø基本路径
1.银行客户选择“转账”业务类型;
2.系统提示输入转入账户;
3.银行客户输入转入账户;
4.系统请求银行系统校验转入账户的有效性;
5.系统提示转入账户部分姓名信息,提醒银行客户确认;
6.银行客户确认;
7.系统提示输入转账金额;
8.银行客户输入转账金额并确认;
9.系统校验本次转账是否符合转账条件(是否超过转账金额限制,转出账户金额是否足够);
10.系统请求银行系统变更转出储蓄账户和转入储蓄账户的储蓄金额;
11.系统激活“打印凭条”用例的扩展点;
12.银行客户选择“退卡”;
13.系统退出储蓄卡;
14.银行客户取回储蓄卡;
Ø扩展路径
5.1银行客户输入的转入账户不对或非本行账户,可重新输入;
8.1转账金额超过每日最高转账金额,系统提示;
8.2银行客户的储蓄金额少于转出金额,系统提示;
11.1如果用户选择“打印凭条”,系统进入“打印凭条”用例;
Ø业务规则
●输入账户有效性:
只能给本行账户转账;
●系统每日最高转账金额为200000;
●30秒内无人取吐出的储蓄卡,系统自动吞回;
]
5非功能性需求
[本章主要说明系统的非功能性需求,这些需求对系统的完整性、质量、可维护、可管理等方面往往具有关键性的影响。
请项目团队重视并认真测算、收集。
所有指标务必符合SMART原则,即:
明确、可衡量、可接受、实际(有理由,有依据)、时效。
]
5.1指标参数
5.1.1性能参数
[给出明确的性能指标要求。
如:
在网络情况完全稳定、可靠的情况下,应达到以下指标:
并发用户数支持
平均并发请求数:
8-12个/秒
峰值并发请求数:
18-20个/秒
响应速度
平均并发时的响应速度:
200-300毫秒/请求
峰值并发时的响应速度:
800-1000毫秒/请求]
5.1.2并发用户数
[根据业务发展情况,测算出并发用户数量。
如:
预计每天100000笔业务,中国移动7000多万用户,按照1%,10%计算系统容量。
计算公式:
100000笔/12小时/60分/60秒约等于2.4笔/秒;
注:
客户使用时间大多集中在白天,所以按照12小时计算;]
5.1.3数据容量
[根据业务发展预测项目成果必须能够满足的最大数据容量。
按照中国移动7000多万用户1%、10%计算,按一份客户资料1K计算,分别为684M,6836M。
按每笔业务产生1k数据计算,每日交易产生数据量:
交易量*每笔交易数据量=100000*1K=100M
按照中国移动用户10%投保,每天产生100000笔交易,交易数据保存半年计算:
数据库容量=用户资料+每日产生数量*182天
=6836M+100M*182
=25036M(约为25G)]
5.2硬件服务器及网络需求
5.2.1网络拓扑
[重点画出项目成果将来运行的网络环境。
注意:
这里是对现有网络环境的分析,是系统的限制因素。
]
5.2.2软硬件环境
[说明项目成果所需要的软硬件环境要求、限制等。
]
5.2.3网络需求
[写明对网络的要求,如速度、域名等的要求。
]
5.3扩展性
[以业务需求为基础,描述关于可扩展性方面的需求。
]
5.4安全性
[以业务需求为基础,描述运营方面的安全需求和产品必须满足的标准。
]
5.5可管理性
[此部分详细描述解决方案中应该加入的可管理特性。
这一部分应该包含在可管理性与发布产品时限之间作出权衡的标准。
以及包含业务规则、系统需求、用户需求等关于可管理性的约束问题。
]
5.6可支持性
[这一章节详细描述解决方案在支持方面的需求。
包括支持所需的技能等。
可以从日志记录、错误处理、诊断工具和故障恢复方面思考。
]
5.7可用性/可靠性
[这一部分详细记录解决方案在可用性和可靠性方面的期望,并以业务需求的可用性和可靠性作为基础。
。
]
5.8运营培训需求
[运营所需技能和培训。
]
5.9兼容性要求
[项目成果必须兼容的软硬件环境、操作习惯等方面的要求。
]
6附录
6.1修改记录
版本
修改人
修改时间
修改内容
核准
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OTQPPMT21 需求确认书 需求 确认书
![提示](https://static.bdocx.com/images/bang_tan.gif)