RDR01需求分析说明书.docx
《RDR01需求分析说明书.docx》由会员分享，可在线阅读，更多相关《RDR01需求分析说明书.docx（12页珍藏版）》请在冰豆网上搜索。
RDR01需求分析说明书
{项目名称}
需求分析说明书
文件编号：
RD-R-01
文件状态：
[√]草稿
[]正式发布
[]正在修改
文件标识
Company-Project-RD
当前版本
X.Y
作者
审 批
完成日期
Year-Month-Day
审批日期
江苏起日信息科技有限公司
变更记录
版本号
变更日期
变更类型
变更人
变更摘要
备注
1.文档介绍
1.1文档编写目的
[本文档描述项目的需求分析说明，从用户需求分析出发到产品规格分析，对客户要求开发的产品进行分析说明，以达到客户{客户单位全称}（以下简称为{客户或{客户单位简称}）、开发单位起日信息技术有限公司（以下简称为开发单位或起日信息）之间明确产品的功能与要求的目的。
]
[本文档经客户与开发单位之间签字确认后，是进行产品交付验收时的依据。
]
[本文档根据裁剪指南，包括了用户需求分析说明书及产品规格说明书二方面的内容。
]
1.2文档范围
[文档范围包括：
产品介绍，产品面向的用户群体，产品应当遵守的标准与规范，产品范围，产品中的角色，产品的用户需求分析、产品规格分析说明及相关附件。
本文档附件包括：
业务需求调查报告{可以没有}
输入格式：
原始的单据、凭证。
{一般用EXCEL表绘制}
输出格式：
重要复杂的显示内容、打印的报表。
{一般用EXCEL表接近全真绘制}
{数据项词典：
可以在输入、输出表中注明，也可以用PowerDesigner工具设计或表格等方式设计。
每个数据项包括：
名称、数据类型、长度及小数据点位数、内容说明，如有限制条件等可说明）}
]
1.3读者对象
[客户：
产品负责人、计算机技术负责人、使用部门参与业务和功能确定的人员。
]
[开发单位：
项目高级经理、项目经理、需求分析员、概要设计员、集成测试员、质量保证员、项目评估专家、本项目业务负责人及项目经理指定的其它成员。
]
1.4参考文档
{提示：
列出本文档的所有参考文献（可以是非正式出版物），格式如下：
}
[标识符]作者，文献名称，出版单位（或归属单位），日期
1.5术语与缩写解释
缩写、术语
解释
…
《》
可用于表示单证、表格的名称
“”
可用于表示模块名称、功能名称
1.6本文标识等说明（实际说明书中本节需删除）
[ ]中内容表示可以选择直接使用，{ }中内容是解释说明。
实际说明书中这引动符号均需删除。
一级标题根据需要可以换页。
本文中“产品”根据需要可以换为“项目”。
范本参考：
CMMI参考资料中的“需求分析_下棋_范本.doc”。
2.产品介绍
{需求分析第一部分：
有点象市场部产品简介}
2.1产品概述
{提示：
（1）概要说明产品是什么，什么用途，主要特点等。
}
2.2背景说明
{提示：
介绍产品的开发的起因，原有系统使用情况，需要解决的问题等。
}
2.3产品面向的用户群体
用户特征
{描述本产品面向的用户（客户、最终用户）的特征。
}
产品好处
{说明本产品将给他们带来什么好处？
｝
产品使用可能性
{客户、最终用户选择本产品的可能性有多大？
如果是项目开发，本节可删除。
}
2.4产品范围
{提示：
说清楚产品范围的好处是：
（1）有助于判断什么是需求，什么不是需求；
（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。
}
适用的领域
{阐述本产品“适用的领域”和“应当包含的内容”。
}
不适用的领域：
{列出不适用的领域及本产品不包含的内容。
}
2.5产品应当遵循的标准或规范
[产品应遵循以下的标准和规范：
起日ISO9001:
2000QM/FS-2006（A版） 质量标准体系
起日CMMIML-3v1.2 软件能力成熟度集成模型标准]
{以下内容包括在上述标准之中，可以不列}
[GB8567-88计算机软件产品开发文件编制指南
GB/T12505-90计算机软件配置管理计划规范
GB/T12504-90计算机软件质量保证计划规范]
3.用户需求分析
{需求分析第二部分：
有点象用户单位的业务管理规定}
{通过业务流程示意图及简要的文字说明等方式，描述产品完成的主要的处理流程。
要描述出用户心目中的产品可以帮助他们完成的工作。
特别注意：
用户需求的描述要尽量使用用户日常处理业务时的语言与词汇，避免使用非常明显的计算机述语。
注意以下几点：
1.建议采用Visio进行业务流程描述。
图示规范建议：
圆形表示业务处理，方型或文件表示输入、输出、中间处理或保存的数据、单据、报表、显示等。
业务流程用实线表示，信息流程用虚线表示。
2.并不是每一个层次的每一个业务都需要用流程图来描述。
能用文字、表格表示清楚不一定用流程图。
3.输入单证、输出表格、要求显示内容等需求描述：
建议用附件《需求分析说明书-输入输出表单、格式》EXCEL报表绘制出来。
也可以用其它制图工具、图形化原型开发工具，达到直观、准确、方便、全面地展示后用户，以便他们能尽量清楚地了解到开发后的产品，使他们可以很方便地参与到需求讨论确定中来。
4.必须说明所有数据项：
需求中不管是输入、输出的数据项，必须对每个数据项给出其名称、类型（字符、数字、日期等类型，以及总长度、小数点位数）、限制说明等。
一般建议在其EXCEL 中对应说明，也可以在word文档中就近说明，也可以用PowerDesigner说明。
}
3.1业务主流程
[本项目业务主流程如下：
各主流程说明如下：
1、商务处理：
业务员与客户签订销售协议。
2、开票处理：
根据协议价格，开票员为客户购货开发票。
3、库存管理：
客户凭发票到仓库领货。
4、回款管理：
根据发票、出货情况，业务员进行回款管理。
5、业务考核管理：
销售负责人根据商务协议、回款情况对业务员进行考核。
}
[下面描述各业务处理的详细流程：
]
3.2业务模块１
业务模块１１
{可以采用流程图、文字说明、表单式样来描述}
业务模块１２
………
3.3{开票处理}
{开票处理业务流程}
{开票处理业务流程如下：
购货人填写《发货申请单》（见附件XXXXX）。
申核人根据与该购货人所属单位的《商业协议及客户档案》（见附件XXXXXX）进行审核，是否同意为其开票。
如果同意，审核人在《发货申请单》上盖同意章，购货人凭单到开票处，由开票员进行开出《购货发票》（见附件XXXXXXX）。
………｝
业务模块１１
{开发票}
｛
开发票的流程如下：
销售开票分为有申请开票和无申请开票。
有申请开票：
开票员打开窗口后，系统将列出所有的已审核过的申请单以及对应药品可供库存，开票员可以选择开票（可以一张申请单开多张发票），系统将根据销售方式和所购货物的不同自动填写相关的数据，如计量单位、税额、价税合计、开票日期、应收款起始日期（等于开票日期）等，并打上开票标识，如果属于直销则增值税为零；
无申请开票：
需要选择开票单位和开票药品品种，操作方式和发货申请基本相同。
如有商业合同不符，本次申请作废。
效库存不足，允许开票员把对应的申请单打上退回标志，审批意见一栏填写‘库存不足’的提示。
打印发票格式统一为增值税发票格式。
}
………
3.4……...
4.产品规格说明
{需求分析第三部分：
有点象软件的用户操作手册。
注意以下几点：
1.功能总框图可以用visio的组织图来画。
2.输入、输出一般要指明附件中编号。
3.功能必须有编号。
一般建议一级功能用二个字母表示，以下各级前二位与一级功能相同。
}
4.1产品中的角色
{提示：
阐述本产品的各种角色及其职责。
各种角色的具体行为将在功能性需求中描述。
}
角色名称
职责描述
[业务处理员]
[业务审核员]
[系统管理员]
[完成系统用户管理、数据备份、系统初始化、年度数据结转的工作]
4.2
产品主要功能
{可以采用功能框图或文字说明、图表文字对照等方式说明主要的产品需求功能模块，一般至少描述清楚一级功能模块。
为方便需求功能跟踪，建议每个需求功能可以给一个唯一的编码。
编码建议如下：
一级功能二位，一级以下的功能模块前二位编码与一级功能相同。
每个功能模块中如果业务处理内容较多，尽量分段说明，以得阅读与设计。
显示的总控框图为一个示例：
｝
[总控模块要求：
通过用户名、口令登录后，只显示与该用户有权操作的一级功能菜单。
]
[下面详细描述各功能模块：
]
功能模块１１
{可以采用功能块编号、文字说明、表单式样来描述}
功能模块１２
………
4.3{开票处理KP}
功能模块１１
功能模块１２
{开票KPDY
本功能只能开票员操作。
4.3.1.1.有《发货申请单》处理KPDY1
开票员可以根据发票号、批号、客户、开票时间的一个或多个条件组合查找相应的《发货申请单》原始发票内容。
查找到后，可以显示对应《发货申请单》的全部内容。
4.3.1.2.无《发货申请单》处理KPDY2
开票员可以输入客户名称、企业税号，输入或查找到药品名称，输入购买药品数量，直接计算出金额。
4.3.1.3.打印发票KPDY3
上述信息确认，打印。
如果申请客户与商业协议不符合，则显示提示信息退出操作。
如果库存不够，则显示提示信息退出操作。
保存成功，该笔业务的开票日期等于当前系统日期，保存的应收款起始日期为当前系统日期，应收款金额为总金额对应的负值。
保存完成后直接打印出《增值税发票》（附件XXXXXX）。
根据该发货申请，可以多次打印《增值税发票》，但累计数量不得通过《发货申请单》中的数量。
打印中出错，必须通过“发票红冲”功能进行作废对应发票后重新打印。
}
………
4.4……...
5.非功能性需求
5.1用户界面需求
{用户界面：
这是人机接口。
定义用户输入控制（命令）和数据（参数）的内容和方式以及计算机提供的命令处理结果（如报表）的内容和格式等。
例如需要向提供何种命令，带哪些参数，通过命令驱动方式还是菜单驱动方式，使用图形界面还是文本界面等。
}
需求名称
详细要求
[界面友好]
[操作设计尽量参考Windows操作系统的操作习惯]
[软件界面风格清新，给用户一种舒服的感觉]
[输入、显示界面尽量与原始纸质单证、表格一致]
[操作简单]
[操作按钮合理布局，并给以适当提示，简单易学]
[下拉式菜单，最大层次不超过三层。
]
[常用功能除通过菜单选择外，可以用快捷键操作，并且可以显示/隐藏为图标直接点击操作。
]
［快捷健规定：
F1-当前屏幕操作帮助 F2-代码提示F4-新增一行 F7－删除当前行。
］
5.2软硬件环境需求
硬件环境需求：
[一般客户端电脑设备要求：
CPU：
PIII以上；内存：
5126M以上；硬盘：
10G以上；I/O设备：
鼠标、键盘、显示器。
]
[开票客户端电脑设备要求：
…………。
]
[服务器电脑设备要求：
CPU：
586以上；内存：
4GB以上；硬盘：
50GB以上；I/O设备：
鼠标、键盘、显示器。
]
软件环境需求
[一般客户端电脑设备要求：
Windows操作系统，怎么xp及以上，IE5.5及以上版本，ActiveX10.0及以上版本，安全级别设置为中级。
预装Access3.0软件……。
]
[开票客户端电脑设备要求：
…………。
]
[服务器电脑设备要求：
操作系统， 数据库：
中间件应用服务器：
，开发工具运行环境：
。
]
5.3产品质量需求
｛根据对顾客满意的影响程度不同，应对质量属性进行分类管理。
常用的质量特性分类方法是将质量特性划分为关键、重要和次要三类，它们分别是：
关键质量属性：
是指若超过规定的特性值要求，会直接影响产品安全性或产品整机功能丧失的质量特性。
重要质量属性，是指若超过规定的特性值要求，将造成产品部分功能丧失的质量特性。
次要质量属性，是指若超过规定的特性值要求，暂不影响产品功能，但可能会引起产品功能的逐渐丧失。
针对不同的应用、不同的用户需求选择几个关键、重要的质量指标进行描述即可。
详细的质量属性可参见起日CMMI咨询文档.XLS!
质量属性。
CMMI3级对质量需求要求不是很高，可以以定性描述为主。
以下列出软件产品主要质量属性及详细要求的描述如下：
｝
质量属性
详细要求（CMMI3）
正确性
[每个功能操作输入、输出正确，图形及文字正确显示]
健壮性
[功能具有完备性，即能满足一般用户的全部需求]
可靠性
[软件运行稳定，没有数据丢失]
性能
[单笔业务操作响应时间不能超过2秒，数据查询、报表打印等不能超过1分钟，日结汇总、月度汇总不超过5分种]/[响应速度快]
易用性
[经操作培训的非计算机专业人员通过半天培训练习，可以完全本身业务的操作。
]
安全性
[用户需要通过身份验证才能进入系统，其操作行为被记入操作日志。
通过对用户权限的配置，保证数据信息的安全。
]
可扩展性
[本软件采用模块化设计，需要扩展功能时只需编写满足相应功能的模块于本软件接口对接即可，可扩展性较强；]
兼容性
[兼容于Windowsxp以上所有版本，对系统其它应用软件没有任何影响；］
可移植性
[可移植到Linux服务器；]
5.4故障处理要求
程序出现异常不能影响已保存数据
程序出现异常退出后能再次正常进入，并能正常使用其他功能。
程序出现异常退出后错误信息保存到系统日志信息中。
5.5数据转换需求
[需要转换数据将在Excel中进行整理，并通过导入程序导入数据库，并对导入数据进行审核是否正确，不正确数据将进行修改，审核完成数据将导入正式数据库。
]
5.6提交客户产品清单
提交给客户的产品清单包括以下内容：
1.需求分析说明书
2.[软件运行程序]
3.[软件安装手册]
4.[软件使用手册]
升级会员 