游戏点卡项目需求分析

游戏点卡项目需求分析
游戏点卡项目需求分析

版本历史

第一部分概述

1.项目名称及背景

项目名称

游戏点卡在线销售系统

开发背景

网络购物已经随着Ineternet的飞速发展而得到越来越多应用。传统的面对面的现金交易已经远远不能满足人们的现代化生活需要,尤其是卡片类商品,人们往往要为了简单的卡

号和密码跑一趟商店。这些都给人们的生活带来了很大的不便。

为了更好的适应现代社会人们的购物需要,为了提高交易效率,节省人们的宝贵时间,我们开发了这套稳定可靠、操作方便、安全有效的游戏点卡在线销售系统,它主要包括:用

户管理、卡片管理、公告管理、汇款审核、综合信息管理、会员购物等几大模块。

2.文档说明

该需求文档在实际开发过程中,迎合用户不断完善需求的过程中总结而来,请仔细阅读。

第二部分任务说明

1.功能概述

该系统要求实现管理员后台管理和会员购买卡片功能。

会员操作包括:会员注册、修改个人信息、汇款、投诉、购买物品、查看个人汇款信息和购物信息等;

管理员后台管理包括:修改个人资料、新会员和会员汇款审核、用户管理、角色管理、卡片类别管理、游戏卡管理、汇款审核、公告管理、销售统计、投诉浏览。

第三部分需求分析

1.实现功能

系统用例图

管理员和会员业务逻辑如下图所示:

管理员功能清单

功能编号功能名称文中标题编号备注

01 个人管理

0101 修改资料

0102 审核操作

02 系统管理

0201 用户管理

0202 角色管理

0203 卡片类型管理

0204 游戏卡管理

0205 汇款审核

0206 公告管理

03 综合信息

0301 销售统计

0302 浏览投诉

会员功能清单

功能编号功能名称文中标题编号备注

01 个人管理

0101 修改资料

02 会员操作

0201 商品列表

0202 投诉建议

0203 汇款通知

03 综合信息

0301 存款记录

0302 购物记录

0303 联系我们

2.用例说明

[用例1]

用例图

描述

该模块主要包括:修改个人资料和审核操作。

修改个人资料与会员注册所需资料完全一致,主要有:登录号、密码、真实姓名、性别、密码问题、密码答案、Email、地址、电话、身份证。

审核操作:主要是对新注册的会员和会员的汇款信息进行审核,可以把新会员设置成为正式会员,根据会员汇款的数额,对会员的个人帐户充值。

参与者

//*参与者,参与用例的对象*//

[用例2]

用例图

描述

用户管理:(1)选择不同类型用户。

(2)把选中的用户设置为“普通会员”,“vip会员”,“管理员”。

(3)删除选中用户。

参与者

//*参与者,参与用例的对象*//

[用例3]

用例图

描述

角色管理:主要包括添加角色、修改角色、删除角色、分配角色功能、浏览所有角色功能、设置会员优惠价。添加角色:包括角色名称、角色描述。

分配角色功能:列出所有功能菜单,菜单分为两级,只列出子菜单,把选中的菜单id及菜单的父菜单id添加到指定的角色下,可以随时修改角色对应的功能菜单。

浏览所有角色功能:按角色分别列出这些角色对应的权限菜单。

设置会员优惠价:设置不同角色的优惠比例。

参与者

//*参与者,参与用例的对象*//

[用例4]

用例图

描述

卡片类型管理:包括显示卡片类型、添加卡片类型、删除卡片类型。

添加卡片类型:包括卡片名称、卡片代表图片(把所有用到的图片都放到工程下的images/card文件夹里,路径默认为:~/images/card/xxxx.gif),卡片价格(初始化几个价格)3个字段信息。

用ListBox列出所有卡片信息,以“卡片名称—价格”表示。

参与者

//*参与者,参与用例的对象*//

[用例5]

用例图

描述

游戏卡片管理:主要包括显示卡片信息、添加卡片、修改卡片、删除卡片。

添加卡片:包括选择卡片类型(绑定已有卡片类型),卡号,密码,卡片备注等字段信息。

用GridView显示所有卡片信息。

参与者

//*参与者,参与用例的对象*//

[用例6

用例图

描述

汇款审核主要包括:显示汇款信息、通过审核、撤回审核和删除汇款记录几个功能。

显示汇款信息。

显示汇款信息:绑定不同的汇款类型,根据选择的汇款类型自动绑定该汇款类型对应的汇款信息。

审核操作:“通过审核”将把选中的会员汇款金额追加到该用户的帐户下,“撤回审核”将不追加金额,让系统以消息的形式通知该会员汇款失败信息,并提醒重新填写邮寄信息。

删除汇款记录:把选定的汇款记录删除。

参与者

//*参与者,参与用例的对象*//

[用例7]

用例图

描述

公告管理主要包括:显示公告信息、添加公告、修改公告、发布公告、删除公告。

添加公告:主要包括公告标题和公告内容两个字段信息。

发布公告前可以修改公告,当发布公告后不可以修改公告。

参与者

//*参与者,参与用例的对象*//

[用例8]

用例图

描述

销售统计:显示销售统计信息,主要包括商品名称、单价、总量、售出量、剩余量。

参与者

//*参与者,参与用例的对象*//

[用例9]

描述

浏览投诉:显示信息,主要包括投诉人和投诉内容。

参与者

//*参与者,参与用例的对象*//

[用例10]

用例图

描述

商品列表主要包括:显示所有商品、按商品名称模糊查询、放入购物车、我的购物车几个部分。

显示所有商品:显示所有商品,具体内容如下图所示:

图:所有商品列表

“我的购物车”和“放入购物车”共用同一个弹出窗口,当选择新的商品点“放入购物车”后,打开的购物车自动刷新。

购物车页面:如下图所示:

图:我的购物车

选好的商品和推荐商品部分显示,

选好的商品中,购买数量默认为1,当超过库存量结算时就报告库存不足错误。

推荐的商品:根据会员选好的商品提供相关的商品推荐,

(1)循环“您选好的商品”,根据会员已经选择的每一个商品,查找选择了该商品的所有其他会员;

(2)查找这些会员所购买过的商品中,尚有库存的,并且被购买次数最多的2种商品,如果商品不在“您选好的商品”列表中,并且不在“相关推荐表”中,则添加到推荐的相关信

息表中。

参与者

//*参与者,参与用例的对象*//

[用例11]

用例图

描述

投诉建议:默认投诉用户为登录用户,填写投诉或建议内容提交即可。

参与者

//*参与者,参与用例的对象*//

[用例12]

用例图

描述

汇款通知:默认汇款用户为登录用户,填写汇款银行,汇款金额,汇款时间,附言,提交即可。

参与者

//*参与者,参与用例的对象*//

[用例12]

用例图

描述

汇款记录:显示该会员所有汇款历史记录,包括汇款人、汇款金额、汇款时间、附言。购物记录:包括商品名称、面值、卡号、密码、购物日期。

以上两个都用GridView显示信息,要求相同的项要进行单元格合并,如上图所示。

参与者

//*参与者,参与用例的对象*//

[用例13]

用例图

描述

联系我们:静态页面,如上图所示。

参与者

//*参与者,参与用例的对象*//

3.用例关系

可以查看业务关系图。

第四部分数据库设计

1.逻辑设计

数据库关系图:

2.表设计

//*所有的表的详细设计信息汇总,如:*//

4.1 数据库:GameCardSale所有表信息

功能说明

UserI

存放用户基本信息-----

nfo

User

可扩展性,设置用户是否被屏蔽的状态----

State

RoleI

存放角色基本信息

nfo

SysF

存放菜单功能基本信息

un

Role

存放所有角色权限

Right

Card

卡片类型信息表

Type

Card 具体卡片表

Card

可扩展,卡片是否被售出的状态

State

Shop ping Cart 购物车功能,存放用户已经选择的卡片信息------

Temp

Relat

iveCa

rd

根据用户选择的卡片,给出相关的选择

Shop

Histo

ry

用户购物历史记录-----

Post

Histo

ry

用户汇款历史记录-----

Appr

oveSt

ate

可扩展,用户汇款被审核状态----

PostF

ailedI

nfo

存放汇款失败时,系统发送的信息----

News 存放系统公告信息

Advi

ce

存放会员的投诉建议信息-----

4.2 表UserInfo存放用户基本信息

表名

列名数据类型(精度范围)空/非空约束条件其他说明

UserId Varchar(50) 非空用户唯一标识

UserName Varchar(50) 非空真实姓名

PassWord Varchar(50) 非空密码

UserRole int 非空用户角色

Gender int 非空性别

PassQuestion Varchar(50) 非空密码提示问题

PassAnswer Varchar(50) 非空密码提示答案

Email Varchar(50) 非空

TelNo bigint 非空电话号码

Address Varchar(50) 联系地址

IDCardNo bigint 身份证号

Money float 用户余额

UserState

int 非空表UserState中

UserStateId的外键

用户状态

4.3 表UserState可扩展性,设置用户是否被屏蔽的状态

表名

列名数据类型(精度范围)空/非空约束条件其他说明

UserStateId Varchar(50) 非空1:正常状态;0:被屏蔽

UserStateName Varchar(50) 非空

4.4 表RoleInfo

表名

列名数据类型(精度范围)空/非空约束条件其他说明

RoleId int 非空角色id

RoleName Varchar(50) 非空角色名称

RoleDesc Varchar(50) 角色描述

DisCount int 会员折扣

4.5 表SysFun

表名

列名数据类型(精度范围)空/非空约束条件其他说明

NodeId int 非空菜单节点id

DisplayName Varchar(50) 非空菜单名称

NodeURL Varchar(50) 菜单连接地址

DisplayOrder int 非空菜单显示顺序

ParentNodeId int 非空父节点id

4.6 表RoleRight

表名

列名数据类型(精度范围)空/非空约束条件其他说明

RoleRightId int 非空角色权限id

RoleId int 非空表RoleInfo中RoleId的外键角色id

NodeId int 非空表SysFun中NodeId的外键菜单节点id

4.7 表CardType

表名

列名数据类型(精度范围)空/非空约束条件其他说明

CardTypeId int 非空卡片类型id

CardTypeName Varchar(50) 非空卡片类型名称

CardPrice int 非空卡片价格

CardImage Varchar(50) 对应图片地址

4.8 表Card

表名

列名数据类型(精度范围)空/非空约束条件其他说明

CardId int 非空卡片id

CardTypeId int 非空表CardType中CardTypeId的外键卡片类型id

CardNo bigint 非空卡片序号

CardPassword int 非空卡片密码

CardDesc Varchar(50) 卡片描述

CardTime datetime 非空添加卡片时间

CardState int 非空表CardState中CardStateId的外键卡片售出状态

4.9 表CardState

表名

列名数据类型(精度范围)空/非空约束条件其他说明

CardStateId int

非空卡片状态id

1:售出;0:未售出

CardStateName Varchar(50) 非空卡片状态名称

4.10 表ShoppingCart购物车功能,存放用户已经选择的卡片信息

表名

列名数据类型(精度范围)空/非空约束条件其他说明

ShoppingCartItemId int 非空购物车项id

UserId Varchar(50) 非空表UserInfo中userid的外键用户id

CardTypeId int

非空表CardType中CardTypeId

的外键卡片类型id

Num int 非空购买数量

4.11 表TempRelativeCard

表名

列名数据类型(精度范围)空/非空约束条件其他说明

TempRelativeCardId Varchar(50) 非空相关卡片标识id

UserId int 非空表UserInfo中userid的外键用户id

CardTypeId int

非空表CardType中CardTypeId

的外键卡片类型id

4.12 表ShopHistory

表名

列名数据类型(精度范围)空/非空约束条件其他说明

ShopHistoryId int 非空购物历史记录id

UserId Varchar(50) 非空表UserInfo中userid的外键用户id

CardId int 非空表Card中CardId的外键卡片id

ShopTime datetime 非空购买时间

4.13 表PostHistory

名列名数据类型(精度范

围)

空/非

空约束条件其他说明

PostHistoryId int

非空汇款历史记录id

UserId Varchar(50) 非空表UserInfo中userid的外键用户id Bank Varchar(50) 非空汇款银行Money int 非空汇款金额PostTime datetime 非空汇款时间PostDesc Varchar(50) 备注

ApproveState int

非空表ApproveState中ApproveStateId的

外键审核状态

4.14 表ApproveState

表名数据类型(精度范围)空/非空约束条件其他说明

列名

ApproveStateId int 非空种子,自增1 审核状态id

ApproveStateName Varchar(50) 非空审核状态名称名称4.15 表PostFailedInfo

名列名数据类型(精度

范围)空/非空约束条件其他说明

PostFailedInfoId int 非空汇款失败信息id UserId Varchar(50) 非空表UserInfo中userid的外键用户id

PostHistoryId int

非空表PostHistory中PostHistoryId的外

键汇款历史记录id

ReadState int

非空消息阅读状态0:未读;1:已读

4.16 表News

表名

列名数据类型(精度范围)空/非空约束条件其他说明

NewsId int 非空公告id

Title Varchar(50) 非空公告标题

Content Varchar(500) 公告内容

NewsTime datetime 非空发布公告时间

NewsState int

非空消息发布状态1:已发布;0:未发布

4.17 表Advice

表名

列名数据类型(精度范围)空/非空约束条件其他说明

AdviceId int 非空投诉建议id

UserId Varchar(50) 非空表UserInfo中userid的外键用户id

Content Varchar(2000) 非空投诉或建议内容…

第五部分界面设计

1.登陆界面设计

说明:所有页面设计要求使用div布局完成。

验证码,自动生成

查看商品

网站公告点这里注册找回密码

图1.1用户登陆首页

用户登陆首页要求:只有当用户名、密码和验证码都正确时才能通过验证。“网站公告”部分为由下到上的滚动字幕,“查看所有商品”部分为从右到左的滚动字幕。点“注册会员”时,弹出添加新会员窗口,如图1.2所示。点“忘记密码?”,弹出找回密码页面,如图1.4所示。点“查看所有商品”,弹出商品展示页面,如图1.7所示。点网站公告信息,弹出该公告的详细信息页面,如图1.9所示。

会员注册页面:(如图1.2所示)

图1.2 用户注册页面

会员注册页面要求:用户登陆名只能为数字和字母以及“_”“-”,不得使用其它字符。并且用户登陆名不能少于4位,密码不能少于6位,最多不超过10位,email和电话都要进行有效性验证,除了地址和身份证号外,其他信息不能为空。提交后若注册成功则提示,如图1.3所示。

图1.3 注册成功提示信息

找回密码页面:(如图1.4所示)

图1.4 找回密码页面

找回密码页面要求:首先只显示用户登陆名填写部分,如图1.4所示。验证该用户是否存在,不存在则报错,若存在则显示找回密码问题和答案框部分,如图1.5所示。

图1.5用户存在后显示用户和密码框界面

如果问题和答案都填写正确,则显示输入新密码部分,如图1.6所示。

图1.6 问题和答案完全正确提交后的新密码界面

输入新密码后提交,则显示:“恭喜您,重新设置密码成功,请牢记”,确定后,找回密码页自动关闭。

商品展示页面:(如图1.7所示)

图1.7商品展示页面

商品展示页面功能要求:展示所有商品,如图1.7所示,要求实现翻页和模糊查询功能,点“放入购物车”后报告“请登录后购买!!”,如图1.8所示。

图1.8放入购物车时提示

公告详细信息浏览页面:(如图1.9所示)

图1.9公告详细信息页面

公告详细信息页面功能要求:显示公告标题和内容,点“关闭”按钮可以关闭窗体。

2.后台管理主界面设计

个人基本信息

内容页部分

功能菜单部分

图2.1 后台管理主界面

主界面功能要求:

要求使用母版页设计主界面,如图2.2所示,展示用户功能菜单,内容首页展示待审核的新用户和用户汇款,如图2.1所示。管理员菜单包括:个人管理、系统管理、综合信息3个父级模块,个人管理包括:修改资料、审核操作2个菜单,系统管理包括:用户管理、角色管理、分类管理、游戏卡管理、汇款审核、公告管理6

个菜单项,综合信息包括:销售统计、浏览投诉2个菜单项。

图2.2 后台管理主页面设计

3.后台管理用例界面实现

//*用例界面实现是对需求的进一步明确和以可视化的方式呈现,作为编码和实现依据*//

用例1

个人修改资料界面:(如图2.3所示)

图2.3修改个人资料界面

修改个人资料页面功能要求:显示用户基本信息如图2.3所示,修改资料时的限制如注册时相同。

用例2

审核操作界面:(如图2.4所示)

图2.4审核操作界面

审核操作页面功能要求:分别显示待审核的用户和汇款信息,如图2.4所示,都有“查看详细”功能。点“通过审核”实现通过审核功能,如果汇款出现错误,点“撤回汇款”则以系统消息的形式通知用户。

用例3

用户管理界面:(如图2.5所示)

图2.5 用户管理界面

用户管理页面功能要求:展示用户基本信息,点“查看详细”可以查看更详细的信息,如图2.4所示,选中用户后,点页面上的四个操作按钮,即可以实现把用户设置为普通会员、vip会员、管理员和删除选中用户功能。另外添加全选功能,选择不同的用户角色,相应的用户信息。

用例4

角色管理页面:(如图2.6所示)

图2.6 角色管理界面

角色管理页面功能要求:展示角色基本信息,如图2.5 所示,要求实现添加角色、修改角色、删除角色、分配角色权限、浏览角色功能和设置会员优惠价功能。

添加角色页面:(如图2.7所示)

图2.7 添加角色界面

添加角色页面功能要求:为模式对话框,角色名称不能为空,提交后自动关闭并刷新角色管理页面。

修改角色页面:(如图2.8 所示)

图2.8 修改角色界面

功能要求同添加页面。

分配角色权限页面:(如图2.9所示)

图2.9 分配角色权限

分配角色权限页面功能要求:列出所有子菜单权限名称,不要求列出父菜单名称,要求选中子菜单时,自动把父菜单分配给该角色,把选中的权限分配给对应的角色,点“提交”提示“权限已生效”,确定后关闭该模式对话框。

角色功能浏览页面:(如图2.10所示)

图2.10 角色功能浏览界面

角色功能浏览界面功能要求:按角色展示它们被分配的权限,如图2.9所示。

设置会员优惠价页面:(如图2.11所示)

图2.11 设置会员优惠价页面

设置会员优惠价页面功能要求:会员类型又roleinfo表动态绑定,然后选择你要设置的会员类型,填写优惠价比(1~100之间的整数)后,点“提交”则更新选定会员类型的优惠价比例,如图2.12所示。

图2.12 设置会员优惠价比

能成功执行删除操作。

用例5

卡片类别管理界面:(如图2.13所示)

图2.13 卡片类别管理界面

卡片类别管理页面功能要求:卡片类别可以同名,用卡片类别和价格结合起来作为唯一标志,用ListBox列

出所有卡片类别+价格。商品价格部分可以自己定义,但菜单项要合理。图片路径部分要求只保存图片的相对路径,并且输入框部分为只读,可以把所有的图片都放在项目中的“images”文件夹里,保存数据库时,路径保存为:“~/images/....gif”。点“添加新类型后”卡片类别列表自动刷新,显示刚才添加的卡片类别,另外点“删除选中类型”按钮,删除该行记录,并自动刷新卡片

用例6

卡片管理界面:(如图2.14所示)

图2.14 卡片管理界面

卡片管理页面功能要求:显示卡片基本信息,按卡片类别名称和价格排序,相同的部分尽量合并单元格,如图2.14所示。实现添加、修改和删除功能。

添加卡片页面功能要求:为卡片管理页面弹出的模式对话框,如图2.15所示,要求所属类型部分为自动绑定的所有卡片类型+价格,默认编号是从数据库获取的当前默认种子最大值,卡号和密码部分要有有效性验证,比如卡号只能为10~20位整数,密码为3~10位数字。点“提交”后保存卡片信息,并自动关闭模式对话框。

图2.15 添加卡片界面

修改卡片页面功能要求:初始时分别绑定卡片管理中选中的卡片信息,卡片类型也要自动绑定为该卡片对应的类型,修改卡片的内容,“提交”更新卡片信息,关闭模式对话框,自动刷新卡片管理页面。

图2.16 修改卡片界面

用例7

汇款审核界面:(如图2.17所示)

图2.17 汇款审核界面

汇款审核页面功能要求:显示汇款基本信息,添加查看详细信息和全选功能,“汇款信息选择”下拉菜单项如图2.18所示,点“通过审核”追加用户余额,点“撤回汇款”通知用户汇款失败,当改变“汇款信息选择”中的类型时,显示相关信息。

图2.18 汇款审核菜单展开界面

用例8

公告管理界面:(如图2.19所示)

图2.19 公告管理界面

公告管理页面功能要求:显示公告基本信息,有添加、修改、删除和发布功能,要求发布后,不能修改,但可以删除。

添加新消息页面功能要求:公告管理页面弹出的模式对话框,如图2.20所示。填写消息标题和内容,提交后关闭该对话框,自动刷新公告管理页面,消息标题不能为空。

图2.20 添加新消息界面

修改消息页面功能要求:初始时显示该消息的基本信息,其他要求同添加新消息页面。

用例9

商品统计界面:(如图2.21所示)

图2.21 商品统计界面

商品统计页面功能要求:显示商品销售情况信息。

用例10

浏览投诉界面:(如图2.22所示)

图2.22 浏览投诉界面

浏览投诉页面功能要求:显示投诉建议基本信息。

4.前台操作主界面设计

个人基本信息

内容页部分

功能菜单部分

图4.1 前台操作主界面

前台操作主界面功能要求:

要求使用母版页设计主界面,如图4.1所示,展示用户功能菜单,内容首页展示所有可购商品信息,如图4.1所示。会员菜单包括:个人管理、会员操作、综合信息3个父级模块,个人管理包括:修改资料1个菜单,会员操作包括:商品列表、投诉建议、汇款通知3个菜单项,综合信息包括:存款记录、购物记录和联系我们3个菜单项。

5.前台操作用例界面实现

//*用例界面实现是对需求的进一步明确和以可视化的方式呈现,作为编码和实现依据*//

用例1

修改个人资料页面功能要求与后台管理中的相同。

用例2

商品列表界面:(如图4.2所示)

图4.2 商品列表界面

商品列表页面功能要求:显示可购商品基本信息,展示方式如图4.2所示。可以按照商品名称模糊搜索,点“放入购物车”后,打开新的窗口,里面显示该会员已经选择的卡片信息,当选择另外的商品点“放入购物车”后,只刷新原来的窗口不打开新窗口,点“我的购物车”共用刚才打开的窗口。如图4.3所示。

图4.3 我的购物车界面

我的购物车页面功能要求:t显示选好的商品信息,根据已经选择好的商品,在上边用DataList列出推荐的商品,如图4.3所示。选择好的商品部分“您的成交价”即是该会员的身份所对应的优惠价比*卡片面值而得到,当更改购买数量时,金额总计自动刷新,当购买数量超过库存量,结算时报告库存不足的提示。推荐商品来源------首先查找购买了该会员已经选择的某一件商品的所有会员,然后从这些会员购买的商品中,挑选出被购买次数最多的2种商品,如果这些商品不在购物车中则把它们显示出来。依照上边的方法,遍历该会员选择好的所有的商品。

另外:当推荐的商品,点“购买”时,将自动更新已经选择的商品和推荐的商品数据,如图4.4所示。

图4.4 推荐的商品点“购买”后的界面

用例3

投诉建议界面:(如图4.5所示)

图4.5 投诉建议界面

投诉建议页面功能要求?:客户文本框部分默认为用户登陆时的id,内容有非空验证。

用例4

汇款通知界面:(如图4.6所示)

图4.6 汇款通知界面

汇款通知页面功能要求:客户默认为登陆id,银行默认为工商银行,汇款金额只能为数字类型,除了附言外,其他输入框都要求非空。

用例5

存款记录界面:(如图4.7所示)

图4.7 汇款记录界面

汇款记录页面功能要求:显示汇款基本信息,相同的项要进行合并,如图4.7所示。

用例6

购物记录界面:(如图4.8所示)

图4.8 商品列表界面

购物记录页面功能要求:显示购物历史记录,如图4.8所示。

用例7

联系我们界面:(如图4.9所示)

图4.9 联系我们界面

联系我们页面功能要求:静态页面,注意div布局。

附1.4 答辩用的幻灯片的目录结构

第一页是标题部分。

第二页是本幻灯片的主要内容和目录。

第三页是小组成员列表。

第四页是项目概述。

第五页是实施技术、框架及硬软件环境。

以下是功能模块技术实现的说明。

提示进行现场演示。

提示进行文档展示。

开发经验和总结。

提示可以进行答辩提问。

感谢。

详细的内容可以参看教员提供的电子文档。

附1.5 项目进度安排表模板

[系统名称]开发进度表

文档名称项目名称

开发单位项目组长

任务名称计划日期实际日期负责人进度偏差的原因序

1

2

3

4

5

6 …

7

8

说明:

进度表用于进度汇报,并且为进度控制提供依据。

以上的进度,是项目里程碑和关键路径上主要控制点的进度情况汇报,也可以根据项目计划中工作分解结构的工作包进行更加细致的控制。

专门用于编码过程中的进度汇报,可以按照功能、模块、子系统的完成情况来进行汇报,进度控制的力度因不同的情况和要求而有差异。

若关键路径发生更改,需要在进度报告中说明。

可用灰色的进度表示项目的里程碑。

软件需求分析的详细流程

第一阶段:总体把握,了解概况 接手一个项目,不要着急去了解需求,这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门,最好能指定本次项目的接口人。 该阶段的主要工作方法:客户访谈 输出成果:业务流程报告/调查报告(对客户方的组织业务概况和企业现状的一些总结) 第二阶段:详细了解业务,梳理业务流程 通过第一阶段的调研,了解客户业务概况的前提下,经过充分的业务调研准备,开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构,尽可能多的与相关基层人员进行诱导式的访谈,与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作,发现问题,提出改进的意见和建议。 该阶段的主要工作方法:访谈、业务分析、原型设计演示 输出成果:调研分析报告、原型反馈报告、业务流程报告 第三阶段:需求细化和确认 这一阶段是在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段,这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统,来提出反馈意见,并对已经可接受的报告、文档签字确认。 实现手段:拜访(回顾、确认),提交业务流程报告、数据项表;原型演示系统 输出成果:需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归入需求分析报告中,提交用户方、监理方进行确认和存档)

XX系统用户需求调研报告

用户需求说明书

目录 0.文档介绍 (1) 0.1发布与修改历史 (1) 0.2文档目的与范围 (1) 0.3读者对象 (2) 0.4参考文档 (2) 0.5术语与缩写解释 (2) 1系统简述 (3) 1.1系统目的 (3) 1.1.1管理目标: (3) 1.1.2使用目标: (3) 1.2系统范围 (3) 1.2.1客户组织结构图 (3) 1.2.2客户人员结构图 (3) 1.2.3系统业务关系图 (3) 1.2.4系统面向的用户群 (4) 1.3产品应当遵循的标准或规范 (4) 1.4定义、首字母缩写词和缩略语 (4) 2用户当前操作模式 (5) 2.1用户需要解决的问题 (5) 3功能性需求 (6) 3.1功能结构图 (6) 3.2功能1 (6) 3.2.1子功能点1 (6) 3.2.2...... . (7) 3.2.3与其它功能模板间的接口 (7) 3.3...... . (7) 4产品的非功能性需求 (8) 4.1对系统环境的要求 (8) 4.2对易用性的要求 (8) 4.3软硬件环境需求 (8) 4.3.1对系统软件的技术要求 (8) 4.3.2对系统硬件的技术要求 (8) 4.4用户对安全性的要求 (8) 4.5对可维护性的要求 (8) 4.6对培训的要求 (8) 5附录A:用户需求调查记录 (10) 5.1A.1需求标题1 (10) 5.2A.N 需求标题N (10)

0.文档介绍 0.1发布与修改历史 参与者及其贡献 0.2文档目的与范围 提示:文档介绍是对本文涉及内容和目的的高度概括。本节内容是读者接触到的本文的第一段正式的文字,我们必须用不超过500字的文字描述简明扼要的告诉他们如下几个重要信息: 0.2.1、本文的目标 0.2.2、本文的主要内容的概括;

项目需求分析报告

项目需求分析报告 导读:本文项目需求分析报告,仅供参考,如果觉得很不错,欢迎点评和分享。 项目需求分析报告(一) 一、项目名称 今日事 二、设计背景 随着社会的发展,我们的生活节奏逐渐加快,与此同时,网络的大量普及,导致大量的信息不断的冲击着我们。在这种生活节奏下,我们难免会出现一不小心忘掉一些重要的事情,这是让我们产生这个想法的一个方面。 另一方面,现如今的学生总是计划很多,却很少付诸行动,这不仅与个人的坚持与否有关,同样是因为步入大学时代后,大家心中充满了迷茫所致,往往计划赶不上变化,因此,我们决定开发这样一款软件,来改变这种情况。 三、项目风险 该软件开发项目的风险承担者有: 任务提出者:需要承担的风险是产品是否能达到用户的需求,该产品是否能带来收益。 软件开发者:需要承担的风险是产品是否能满足需求报告说明书里的各种功能需求等。

产品使用者:需要承担的风险是产品是否能满足自己所需。 四、功能需求 日历功能,可以查询日期 制定计划功能,分为长期,中期,短期三个层次,短期即为今日事,中期为1周或1月,长期为数月或1年,这些可以由用户自己设置。 完成计划功能,可以通过勾选来标注哪些是已经完成的,哪些是还为完成的。 成就系统,通过统计各期所完成计划数量给予用户相应称号,同时可以与其他用户进行竞争。 提醒功能,手机解屏时提醒用户今日需要做的事,而在每天结束时,汇报今日完成进度。 五、运行环境 移动端android平台 六、性能要求 为保证软件能够长期,安全,稳定,高效的运行,应满足以下性能要求: 时间特性:系统响应时间应在人的感觉和视觉范围内(适应性:在操作方式,运行环境,软件接口或开发计划发生变化时,应具有适应能力。 项目需求分析报告(二) 一、引言

需求分析文档

Word的山大王的额度为恶臭反对法vervg1额外俄方vervg2 需求分析 引言 目的 说明编写这份报告的目的,指出预期的读者。 背景 指出待开发的软件系统的名称;行业情况;本项目的任务提出者、开发者、用户;该软件系统同其他系统或其他机构的基本的相互来往关系。 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准,以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 术语 列出本报告中用到的专门术语的定义。 任务概述 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中的其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 系统(或用户)的特点 如果是产品开发,应列出本软件的特点,与老版本软件(如果有的话)的不同之处,与市场上同类软件(如果有的话)的比较。说明本软件预期使用频度; 如果是针对合同开发,则应列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件预期使用频度。这些是软件设计工作的重要约束。 假定和约束 列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。 需求规定 软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求,说明输入什么量、经怎样的处理、得到什

最新客户需求分析报告

客户需求分析报告 客户名称 申请部门 部门审核 填报人 申请日期年月日 珠海网佳科技有限公司

客户需求分析报告填写说明 1.填写《客户需求分析报告》前,需进行认真、严谨地市场调研工作,本报告是市场调研 工作结果输出的载体,亦是公司产品立项决策的重要依据; 2.建议在市场调研前,先熟悉本报告要求内容,以便开展针对性的调研工作; 3.在填写过程中对本报告内容有任何疑问,请向项目管理工程师咨询,我们将随时为您提 供服务。

目录 1客户的需求............................................................................. 错误!未定义书签。2产品功能、性能分析............................................................. 错误!未定义书签。3应用范围和作用..................................................................... 错误!未定义书签。4产品开发的时间要求............................................................. 错误!未定义书签。5产品费用说明......................................................................... 错误!未定义书签。6将来可能提出的要求............................................................. 错误!未定义书签。7综合风险评估 ........................................................................ 错误!未定义书签。8其它......................................................................................... 错误!未定义书签。9附表. (1)

如何做好游戏开发项目基本需求分析(doc0)()

如何做好游戏开发项目基本需求分析 一款游戏项目的确立是建立在各种各样的需求上面的,这种需求往往来自于玩家的实际需求或者是出于公司自身发展和实力的情况,其中玩家的实际需求也就是说市场需求最为重要。面对对游戏拥有不同知识和理解层面的玩家,项目的负责人(或者游戏制作人)对玩家需求的理解程度,在很大程度上决定了此类游戏开发项目的成败。因此如何更好地的了解、分析、明确玩家需求,并且能够准确、清晰以文档的形式表达给参与项目开发的每个成员,保证开发过程按照满足玩家需求为目的正确项目开发方向进行,是每个游戏开发项目管理者需要面对的问题。就这个问题,本文想提出自己的一些看法和建议,希望各位读者批评指正: 需求分析的原则 需求分析中的缺陷将给项目成功带来极大,这里的“成功”是指推出的游戏能以合理的定价、及时地在功能、质量上完全满足大部分玩家的期望。 不适当的需求过程所引起的一些风险: 1. 无足够玩家参与 游戏制作经常不明白为什么收集需求和确保需求质量需花费那么多功夫,开发人员可能也不重视玩家的参与。 究其原因: 一是因为开发人员感觉与玩家合作不如编写代码有意思 二是因为开发人员觉得已经明白玩家的需求了。

在某些情况下,与实际玩同类型游戏产品的玩家直接接触很困难,而玩家有时候也不太明白自己的真正需求。但还是应让具有代表性的玩家在项目早期直接参与到开发队伍中,并一同经历整个开发过程。 国外一些游戏开发人员在实践过程中,也有些感觉,在实施一个新的游戏项目时,若无足够的玩家参与,系统人员获得的需求是片面的,不完整的,这样游戏在需求设计之初就埋下风险。 2. 玩家需求的不断增加 在开发中若不断地补充需求,项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致(网络游戏开发的复杂性已经比传统游戏提高很多),这使得问题更难解决。实际上,问题根源在于玩家需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小,必须一开始就对项目定位、范围、目标、约束限制和成功给予明确说明。有助于投资者或者风险承担者明白决策的合理性,即为何进行某些变更,相应消耗的时间、或特性上的折中。 游戏开发中不断延续的变更会使其整体结构日渐紊乱,补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则,如果你尽早地区别这些可能带来变更的特性,你就能开发一个更为健壮的结构,并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码,同时也有利于减少因变更导致程序质量的下降,和对游戏稳定性的影响。 3. 模棱两可的需求 模棱两可是游戏功能说明中最为可怕的问题。它的一层含义是指诸多玩家对需求说明产生了不同的理解;另一层含义是指单个玩家能用不止一个方式来解释某个功能和需求说明。

需求分析文档

需求分析文档 1引言 1.1编写目的 该课题的终极目标是开发一个实用,操作便捷的桌面闹钟应用程序,达到在日常生活工作中可以合理利用时间从而大大地提高人们的工作效率。 1.2背景 我国现在在各个方面发展迅猛,民众的生活质量得到极大的提高。与此同时,根据时代的要求,人们的生活节奏也随之加快。人们都要求自己在很短的时间尽量做到最多的事。所以开发一款能让人们能将其所有的事有序地组织起来,同时又能提醒在什么时间该做什么事的软件是很有必要的。虽然目前这样软件很多功能虽强大,但是用起来都很复杂,有些功能并不实用,操作也太麻烦。该课题的终极目标是开发一个实用,操作便捷的桌面闹钟应用程序,达到在日常生活工作中可以合理利用时间从而大大地提高人们的工作效率。 说明: 项目名称:桌面闹钟应用程序 项目提出单位:西安电子科技大学计算机学院031114班 1.3定义 与已有的桌面闹钟应用程序的繁杂、操作麻烦等特点相比,该桌面闹钟应用程序的简单易操作等特点使得其用起来更方便。 二.项目概述

2.1目标 为满足现代生活的要求,本应用程序将闹钟建立在基于安卓系统的基础上,从而得出一个实用,操作便捷的桌面闹钟应用程序,达到在日常生活工作中可以合理利用时间从而大大地提高人们的工作效率。 2.2产品功能 A) 添加一个闹铃; B) 删除一个闹铃; C) 设置闹铃名称及闹铃方式,铃声、震动、铃声+震动等; D) 编辑闹铃,修改时间、闹铃方式等; 2.3产品系统流图 2.4用户的特点 本应用程序的可以是任何人,要求是能够进行基本的手机操作。 2.5假定和约束 由于知识有限和时间约束,本系统部分功能尚需完善。

系统需求分析报告-范例1

高校学生学籍管理信息系统 系统需求规格说明书 (系统需求分析报告)

目录 1-------------------------------------------------------------------概述1.1----------------------------------------------------------------背景1.2-------------------------------------------------------------系统目标1.2.1------------------------------------------------------应完成的任务1.2.2------------------------------------------------------不完成的任务1.3------------------------------------------------------------业务模式1.4-------------------------------------------------------------业务状况2---------------------------------------------------------------用户需求2.1-------------------------------------------------------------业务需求2.1.1---------------------------------------------------------使用范围2.1.2----------------------------------------------------------功能要求2.1.3----------------------------------------------------------权限管理2.2-------------------------------------------------------------性能需求3---------------------------------------------------------------业务流程3.1-----------------------------------------------------与其他系统的关系3.2----------------------------------------------------------业务流程图4---------------------------------------------------------------业务逻辑4.1-------------------------------------------------------------业务分解4.2------------------------------------------------------------业务描述5---------------------------------------------------------------数据分析5.1------------------------------------------------------------数据单据5.2------------------------------------------------------------数据分析5.2.1---------------------------------------------------------数据分类5.2.2---------------------------------------------------------数据描述6-------------------------------------------------------------------附件

详细的需求分析文档规范

需求规格文档 1 导言 1.1 目的 [说明编写这份项目需求规格的目的,指出预期的读者] 1.2 背景 说明: a)待开发的产品的名称 b)本项目的任务提出者、开发者、用户及实现该产品的单位 c)该系统同其他系统的相互往来关系 1.3 编写说明 [缩写] [缩写说明] 列出本文件中用到的外文首字母组词的原词组 1.4 术语定义 [术语] [术语定义] 列出本文件中用到的专门术语的定义

1.5 参考资料 [编号]《参考资料》[版本号] 列出相关的参考资料 1.6 版本更新信息 具体版本更新记录如表所列。 表版本更新记录 2 任务概述 2.1 系统定义 本节描述内容包括: ●项目来源及背景; ●项目要达到的目标,如市场目标、技术目标等; ●系统整体结构,如系统框、系统提供的主要功能,涉及的借口等; ●各组成部分结构,如果所定义的产品是一个更大的系统的一个组成部分,则应说 明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明 该系统和本产品其他各部分的联系和接口。 2.2 应用环境 本节应根据用户的要求对系统的运行环境进行定义,描述内容包括: ●设备环境; ●系统运行硬件环境; ●系统运行软基纳环境; ●系统运行网络环境; ●用户操作模式; ●当前应用环境。 2.3 假设和约束 列出进行本产品开发工作的假定和约束,例如经费限制、开发期限等。列出本产品的最终用户特点,充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。

3 需求规定 3.1 对功能的规定 本节依据合同中定义的系统组成部分分别描述其功能,描述应包括: ●功能编号; ●所属产品编号; ●优先级; ●功能定义; ●功能描述。 3.2 对性能的规定 本节描述用户对系统的性能需求,可能的系统性能需求有: ●系统响应时间需求; ●系统开放型需求; ●系统可靠性需求; ●系统可移植性和可扩展性需求; ●系统安全性需求; ●现有资源利用需求。 3.2.1 精度 说明对该产品的输入、输出数据精度的要求,可能包括传输过程中的精度。 3.2.2 时间特性要求 说明对于该产品的时间特性要求,如对: A)响应时间; B)更新处理时间; C)数据的转换和传送时间; D)计算时间等的要求。 3.2.3 灵活性 说明对该产品的灵活性的要求,即当需求发生某些变化时,该产品对这些变化的适应性能力,如: a)操作方式上的变化; b)运行环境的变化; c)同其他系统的借口的变化; d)精度和有效时限的变化;

需求分析方法主要步骤

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面,需求包括系统要做什么,相对于原系统目标系统需要进行哪些修改,目标用户有哪些,以及不同用户需要通过系统完成何种操作等。 在性能方面,需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面,需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求,以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面,需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求,识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题,要满足哪些限制条件,这个过程就是对需求的获取。开发人员通过调查研究,要理解当前系统的工作模型和用户对新系统的设想与要求。 此外,在需求的获取时,还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如,多长时间需要对系统做一次备份,系统对运行的操作系统平台有何要求,发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求,开发人员应该采取科学的需求获取方法。在实践中,获取需求的方法有很多种,比如,问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析,开发人员便可以得到一些有用的信息。采用这种方法时,调查问卷的设计很重要。一般在设计调查问卷时,要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制,自由灵活,能够激发用户的思维,使他们能尽可能地阐述自己的真实想法。但是,对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的,用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理,但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈,进而了解到用户的意见,是最直接的需求获取方法。为了使访谈有效,在进行访谈之前,开发人员要首先确定访谈的目的,进而准备一个问题列表,预先准备好希望通过访谈解决的问题。在访谈的过程中,开发人员要注意态度诚恳,并保持虚心求教的姿态,同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样,开发人员要根据用户的身份特点,进行提问,给予启发。当然,进行详细的记录也是访谈过程中必不可少的工作。访谈完成后,开发人员要对访谈的收获进行总结,澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。

软件需求分析报告书实例

需求分析说明书 1. 引言 (3) 1.1 编写目的 (3) 1.2 项目风险 (3) 1.3 预期读者和阅读建议 (5) 1.4 产品范围 (5) 1.5 参考文献 (5) 2. 系统总体概述 (6) 2.1 目标 (6) 2.2 用户类和特性 (7) 2.3 运行环境 (7) 2.3.1 硬件环境 (7) 2.3.2 软件环境 (7) 2.4 设计和实现上的限制 (7) 2.5 假设和约束(依赖) (8) 2.5.1 产品的SEO排名 (8) 2.5.3系统的安全 (8) 3. 外部接口需求 (8) 3.1 用户界面 (8) 3.2 硬件接口 (8) 3.3 软件接口 (8) 3.4 通讯接口 (9) 4. 系统特性 (9) 4.1 说明和优先级 (9) 4.2 激励/响应序列 (9) 4.3 功能需求 (9) 4.4 功能详述 (12) 4.4.1以使用软件的汽车用户为例: (12) 5. 其它非功能需求 (13) 5.1 性能需求 (13) 5.2 安全措施需求 (13) 5.3 安全性需求 (14) 5.4 操作需求 (14) 5.5 软件质量属性 (14) 5.6 业务规则 (14) 5.7 用户文档 (14) 6. 词汇表 (14) 6.1 SSH (14)

6.2 JAVA (14) 6.3 MYSQL (15) 7. 待定问题列表 (15)

1. 引言 1.1 编写目的 本需求分析说明书对本项目第一阶段的内容进行分析,对需求细节和实现方式进行了较为详细的阐述。本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用,并作为产品验收确认的依据。 需求分析是在可行性研究的基础上,将用户对系统的描述,通过开发人员的分析概括,抽象为完整的需求定义,再形成一系列文档的过程。可行性研究旨在评估目标系统是否值得去开发,问题是否能够解决,而需求分析旨在回答"系统做什么"的问题,确保将来开发出来的软件产品能够真正满足用户的需要。 构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样,在出错之后会如此严重地影响随后实现的系统,并且在以后修补竟会如此的困难。 需求分析是一个非常重要的过程,它完成的好坏直接影响后续软件开发的质量。一般情况下,用户并不熟悉计算机的相关知识,而软件开发人员对相关的业务领域也不甚了解,用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以,开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。 有效的需求分析通常都具有一定的难度,一方面是因为交流存在障碍,另一方面是因为用户通常对需求的陈述不完备、不准确和不全面,并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求,还需要挖掘隐藏的需求。此外,把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。 在进行需求分析的过程中,首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性,需求往往很难做到一步到位。需求分析不仅仅是属于软件开发生命周期早期的一项工作,而且还应该贯穿于整个生命周期中,它应该随着项目的深入而不断地变化。 此外,为了方便后续的评审和测试等工作,需求的描述应该尽量做到:具体、详细、可以测量和可以实现,并且基于时间。 1.2 项目风险 政策风险分析: 随着社会的进步与人们生活水平的提高大幅度增加,尤其在我国汽车进入家庭的条件下,需要更多的适合现代汽车技术要求和社会经济承受能力的汽车维修检测设备,为了让四轮定位仪市场变得规范、有序,中国汽车保修设备行业协会与全国汽车维修标准化技术委员会于2004年,制定了四轮定位仪的行业标准(标准号JT/T505-2004),国家交通部2004年国标GB/T16739.1-.2-2004《汽车维修业开业条件》规定:一、二类汽车维修企业必须配备

实践项目需求文档

软件需求规格说明书 (仅供参考) 编制李捷日期2008/04/22 审核日期2008/04/24 审核日期 批准日期

第一章引言 1 编写目的 本需求规格说明书是为了开发企业信息平台系统而编写,主要面向系统分析员、程序员、测试员、实施员和最终用户。 本说明书是整个软件开发的依据,它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。同时本说明书还是《用户手册》和《测试计划》的编写依据。 2 项目背景 信息社会的高科技,商品经济化的高效益,使计算机的应用已普及到经济和社会生活的各个领域。计算机虽然与人类的关系愈来愈密切,还有人由于计算机操作不方便继续用手工劳动。为了适应现代社会人们高度强烈的时间观念,学生信息管理系统软件为教学办公室带来了极大的方便。该软件是以汉语编程语言为实现语言,其功能在系统内部有源代码直接完成。通过操作手册,使用者可以了解本软件的基本工作原理。操作人员只需输入一些简单的汉字、数字,即可达到自己的目标。 第二章任务概述 本需求的编写目的在于研究学生信息管理系统软件的开发途径和应用方法。 本需求的预期读者是与学生信息管理系统软件开发有联系的决策人,开发组成人员,扶助开发者,支持本项目的领导和公司人员,软件验证者。

系统关系图 第三章需求规定 1 对功能的规定 从系统的主要功能大致可以分为五大部分,即用户管理、课程管理、选课管理、班级管理、成绩管理几大部分。 2 对子模块的规定 1.用户管理 (1)管理员:对信息享有最大的权利,可以对信息进行修改,删除,增加等操作。(2)教师:可以查看所有学生的信息列表,不可进行修改,删除,增加等操作。

(需求分析+概要设计+详细设计)文档简单范例

软件开发文档 项目名: “通讯录” 版本: α测试版 作者: ccba 编写时间:2001-8-20 文档内容: 1 需求规格说明书 2 概要设计说明书 3 详细设计说明书 文档号IM00101 需求规格说明书 1、引言: 1.1 编写目的 本文档的编写是为了确定待开发软件的功能、性能、数据、界面的需求。 1.2 项目背景 “通讯录”软件是为了提供一种功能完备,易于操作、界面美观的优秀软件。该软件由蔡文亮单独开发完成。 1.3 定义 需求规格说明书采用参考资料②标准 1.4 参考资料 ①薛华成《管理信息系统(第三版)》清华大学出版社1999.5 ②郑人杰、殷人昆、陶永雷《实用软件工程(第二版)》清华大学出版社1997.4 ③周之英《现代软件工程(基本方法篇)》科学出版社 2000.1 2、功能需求 该软件由四个主功能模块和一个扩展功能模块构成,各功能模块中规定的均为软件的基本功能,在开发过程中,开发人员可根据实际情况在满足基本功能需求的前提下增加新功能,但必须详细编写相关文档。 2.1录入、修改功能模块 该功能块主要用于数据库的数据录入和修改,考虑到通讯录的实际需要,可以放松对数据库完整性结束的控制,但从减少数据库的角度来考

虑,不容许有完全相同的纪录出现(考虑的合并,相同的纪录项)。 2.2查询功能块 本功能模块是最重要的功能块,对通讯录的操作最主要部分就是查询操作。 本功能块要求有如下功能: 1)按数据库各个属性查询 2)按数据库各个属性之间的逻辑组合查询 如:查询名称为“鸭子”且年龄为20岁的详细情况 (SQL语句表示)SELECT * FROM MESSAGER WHERE NICKNAME=“鸭子” AND AGE=20 3)按某一属性的数值范围查询及其逻辑组 如:查询年龄在20至35岁间的详细情况 (SQL语句表示)SELECT * FROM MESSAGER WHERE AGE BETWEEN 20 AND 35 4)模糊查询 同时我们要求查询结果可以按用户要求的格式来显示,如:用户能调整显示属性的个数和组合。 2.3系统安全块 通讯录的信息是个人隐私,故在软件中加入必要的安全措施。主要有以下三点: 1)登录帐号和密码的管理 2)帐户权限的控制 3)对部分登录帐号隐藏部分内容 2.4系统设置块 本部分内容主要是对软件使用时一些设置使其更利于软件的使用:主要包括以下四个方面: 1)系统界面背景和色彩设置(模仿WINNAP) 2)闹铃功能开关,即实现朋友生日提醒功能 3)记录内容项(即数据库修改通讯录上的内容项) 4)历史记录,用户可以选择是否记录下何人何时使用过该软件 2.5扩展功能块 1)网络功能:通过OLE/COM接口的调用,实现E-mail软件调用。2)帮助文档的制作(On-line help)

用户需求分析报告

window命令大全 需求分析报告 引言 ¨编写目的(阐明编写需求分析报告的目的) ¨项目背景(应包括:a.项目的委托单位、开发单位和主管部门; b.该软件系统与其他系统的关系。) ¨名词解释(列出文档中所用到的专门术语的定义和缩写词的原文。) ¨参考资料(列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:a.立项报告;b.项目开发计划;c.文档所引用 的资料、标准和规范。) 任务概述 ¨目标 叙述该项软件开发的意图、应用目标、作用范围以及该软件的背景资料。 解释被开发软件与其他有关软件之间的关系。如果本软件是一个独立的软 件,而且全部内容自含,则说明这一点。如果定义的产品是一个更大系统 的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关 系。 ¨假定与约束 列出本软件开发工作的假定与约束,例如经费限制、开发期限等等。 数据描述

数据分为静态数据和动态数据。所谓静态数据,指在运行过程中主要作为参考的数据,它们在很长一段时间内不会变化,一般也不会随着运行而改变,所谓动态数据,包括所有在运行中要发生变化的数据,以及在运行中要输入、输出的数据。 ¨静态数据(系统运行前已有的数据) 列出所有作为控制或参考用的静态数据,并给出名称。 ¨动态数据(系统运行过程中需要的输入数据以及系统运行过程中产生的输出数据) 列出所有动态数据,并给出名称。 功能需求 ¨流程图 画出系统的整体流程图。 ¨功能划分 对于流程图中的各个功能用树状结构自顶向下进行细化。并对最底层的功 能进行编码,给出功能标识符。 ¨功能描述 对最底层的功能所要完成的功能进行详细描述,填入下表中: ¨ 用一张矩阵图说明功能描述中的各个功能与数据描述中的静态数据、动态 数据之间的对应关系,例如:

软件需求分析方法

欢迎阅读 软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整?性,促 使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准;

3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面:软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 (5)??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件,如果出现待定的部分,必须进行待定部分内容说明,落实负责人员、落实实施日期。 2)功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化: (1)??? 功能描述必须清晰地描述出怎样输入到怎样输出,并且输入、输出描述应对应有数据流描述、控制流描述图,这些描述必须与其它地方描述一致;

(2)??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言,描述前必须说明该步骤(或子功能)的执行是顺序,选择, 重复,还是并发,然后说明步骤逻辑。整个描述必须单入单出。 (3)??? 描述时,每一个功能名称和参照编号必须唯一,且不要将多个功能混在一起进行描述,这样便于功能的追踪和修改。 (4)??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计,它给出软件运行的的外部功能描述,以及为了实现这一外部功能必须做哪些事情(采 2.2、 2.3、 (2)??? 处理容限、精度、采样参数的分辨率,误差处理等; (3)??? 可靠性的MTBF要求,可维护性、安全性要求等。(对可能的不正常的输入给以正常响应是可靠性的重要内容,这属于功能性需求。) 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况:某些用户需求适宜采用反向形式说明,如数据安全性要求属于这类形式。第二种情况:对一些可靠性和安全性要求较高的软件,有些必须描述软件不能做些什么。如控制点火时序,我们必须交代清楚在那些情况下不能点火,否则会造成故障。

需求分析报告怎么写

软件需求分析报告模板精选 (主要参考红色部分。写作时,主要用用例图和类图做为辅助说明) 1 1. 引言 引言是对这份软件产品需求分析报告的概览,是为了帮助阅读者了解这份文档是如何编写的,并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的,开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格,包括修正和(或)发行版本号,从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系,那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.1 1.2 项目风险 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括: ●任务提出者; ●软件开发者; ●产品使用者。 1.2 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话),或者各种排版约定。排版约定应该包括: ●正文风格; ●提示方式; ●重要符号; 也应该说明高层次需求是否可以被其所有细化的需求所继承,或者每个需求陈述是否都有其自己的优先级。 1.3 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者,例如,可能包括: ●用户; ●开发人员; ●项目经理;

●营销人员; ●测试人员; ●文档编写入员。 并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。 1.4 1.5 产品范围 说明该软件产品及其开发目的的简短描述,包括利益和目标。把软件产品开发与企业目标,或者业务策略相联系。 描述产品范围时需注意,可以参考项目视图和范围文档,但是不能将其内容复制到这里。 1.5 1.6 参考文献 列举编写软件产品需求分析报告时所用到的参考文献及资料,可能包括: ●本项目的合同书; ●上级机关有关本项目的批文; ●本项目已经批准的计划任务书; ●用户界面风格指导; ●开发本项目时所要用到的标淮; ●系统规格需求说明; ●使用实例文档; ●属于本项目的其它己发表文件; ●本软件产品需求分析报告中所引用的文件、资料; ●相关软件产品需求分析报告; 为了方便读者查阅,所有参考资料应该按一定顺序排列。如果可能,每份资料都应该给出: ●标题名称; ●作者或者合同签约者; ●文件编号或者版本号; ●发表日期或者签约日期; ●出版单位或者资料来源。 2 2. 综合描述 这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。

项目需求分析和调研实践过程

某集团船代项目需求分析和调研实践过程 此文档主要在于项目管理设置项目相关文档,有兴趣人员可以参考一下,对于项目管理和未来有此方向者有一定的参考价值。 流程再造方法论 -流程影射,系统评估,定义考核,再造建议 前言 本文档主要根据某集团船代项目需求分析和调研实践过程整理而得,描述从项目启动,调研到设计过程的大致过程叙述,重点在于咨询过程中涉及的需求分析和调研方法论,其他相关项目前期规划和调研可参考此方法论。如有不妥之处敬请指正,也希望能不断完善,谢谢!正文: 软件需求的定义: 根据IEEE软件工程标准词汇(1997年)中定义的需求为: 用户解决问题或达到目标所需的条件和能力; 系统或系统部件要求满足合同,标准,规范或其他正式规定文档所需具有的条件和能力; 一种反映上述条件和能力的文档说明。 本项目简介 因某某集团船代业务发展需要,加上目前的系统存在很大问题,也不能涵盖目前的所有业务需求,需进行调研和需求分析是否需要上一套

新的船代系统,新系统需要整合目前的业务结构和业务流程,同时满足业务的需求和未来发展。 适合读者 此文档适合信息系统项目咨询规划和分析的相关项目人员作为项目前期方法论参考之用。 目录 1.项目启动 2.项目调研 3.项目规划与考核指标 4.撰写SOR 项目启动 1.与成员企业与相关部门沟通 召开项目总启动会议,介绍项目组相关人员以及此项目的主要目的和要求,企业简单本项目涉及的业务流程和相关业务部门和目前主要组织结构。例如船代项目我们在这一个环节我们了解到了整个船代所涉及的主要业务可以分为: 集装箱进出口业务 散杂货进出口业务 箱管

订舱 根据业务的分工部门的分工也不同。以后的调研思路我们也可以按照这样两种业务流程主线去咨询调研相应的部门与人员。 2.安排项目相关人员 根据业务主线(集装箱进出口,散杂货进出口)整理调研思路,要求企业根据提供的业务主线流程,和部门结合分工安排,组织各部门主要相关人员积极配合项目未来的调研。 3.出初期调研时间和相关人员安排表 根据前期的准备工作,出具具体调研时间和人员安排表,时间项目组掌控制(需要和业务部门协调),人员安排需要业务部门提供详细人员名单资料。以便项目成员和企业相关部门人员提前做好调研准备(安排相关人员和准备一些相关资料)。 根据时间人员安排表,做好前期调研准备。 注:在调研具体调研前,我们因该知道所有物流在运作过程中碰到的四个主要问题为: 出错率 时效 成本 结算 在具体的调研过程中,我们始终要以此作为主导的思路问问题,才能找出目前的问题所在。也就是未来规划后的系统的价值所在。

有关软件需求分析的步骤以及所需

有关软件需求分析的步骤以及所需文档一、需求分析的几个方面 ○ 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段,包括以下几个方面: 1、确定软件所期望的用户类;获取每个用户的需求 2、了解实际用户任务和目标以及这些任务所支持的业务需求 3、分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量 属性、建议解决方法和附加信息 4、将系统级的需求分为几个子系统,并将需求中的一部分分配给软件组件 5、了解相关质量属性的重要性 6、讨论得出实施优先级 7、将所收集的用户需求编写成需求规格说明和模型 8、评审需求规格说明,确保与用户达成共识 二、需求分析的任务与过程 ○ 需求分析的任务是借助于当前系统的物理模型(待开发系统的系统元素)导出目标系统的逻辑模型(只描述系统要完成的功能和要处理的数据),解决目标系统“做什么”的问题。

所要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节,定义软件的其他有效性需求,通过逐步细化对软件的要求描述软件要处理的数据,并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。 必须全面理解用户的各项要求,但不能全盘接受,只能接受合理的要求;对其中模糊的要求要进一步澄清,然后决定是否采纳;对于无法实现的要求要向用户作充分的解释。 最后将软件的需求准确地表达出来,形成软件需求说明书SRS。 实现步骤: (1)获得当前系统的物理模型 首先分析、理解当前系统是如何运行的,了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程,并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”,其主要任务是对用户的组织机构或企业进行评估理解他们的需要及未来系统要解决的问题,然后建立一个业务USECASE模型和业务对象模型。当然如果系统相对简单,也没必要大动干戈区进行业务建模,只要做一些简单的业务分析即可。 (2)抽象出当前系统的逻辑模型 在理解当前系统“怎样做”的基础上,取出非本质因素,抽取出“做什么”的本质。

相关文档
最新文档