COSPLAY需求文档.docx
- 文档编号:10912563
- 上传时间:2023-02-23
- 格式:DOCX
- 页数:16
- 大小:94.44KB
COSPLAY需求文档.docx
《COSPLAY需求文档.docx》由会员分享,可在线阅读,更多相关《COSPLAY需求文档.docx(16页珍藏版)》请在冰豆网上搜索。
COSPLAY需求文档
《统一建模语言UML》
需求文档
专业软件工程
年级2班
姓名邹金妍
学号ZKA10270079
指导老师鲁迅
实验室编号
苏州大学计算机科学与技术学院统一印制
二O一三年二月
下表1-1为我们与用户访谈、学习、观察等过程所记录的COSPLAY演出时演员各方面要求。
表1-1演员招聘需求记录表
编号
说明
F01
COSPLAY进行招聘
F02
列出所有通过初试演员名单
F03
进行复试并对初试名单进行筛选
F04
列出所有正式演员名单
F05
通知演员进入指定进行注册登录
F06
演员进入网页注册并填写基本信息获取演习地点、时间
F07
修改已有的注册信息记录
F08
按人、按演员名查询注册信息
F09
列出所有演员注册信息
F10
培训部门根据相关注册信息进行通知演习
F11
确定实来培训者名单
将一些需求功能相近的合并到同一个用例中去,通过这些整理我们得到表1-2中的系统用例。
表1-2系统用例
特征
用例
F01COSPLAY进行招聘
F02列出所有通过初试演员名单
F03进行复试并对初试名单进行筛选
F04列出所有正式演员名单
UC01确定面试后演员名单
F05通知演员进入指定网页进行注册登录
F06演员进入网页注册并填写基本信息获取演习地点、时间
UC02新增注册信息记录
F07修改已有的注册信息记录
UC03修改注册信息
F08按人、按演员名查询注册信息
F09列出所有演员注册信息
UC04查询注册信息
F10培训部门根据相关注册信息进行通知演习
F11确定实来培训者名单
UC05确定实际演员名单
经过合并整理出5个用例,这些用例中,UC03(修改注册信息)必须先通过UC04(查询注册信息)才能启动,所以它们是扩展关系。
完成后的用例图1-1。
图1-1COSPLAY演员招聘管理系统用例图
绘制完用例图后,还需给出用例描述。
以下是各主要用例的用例描述。
用例编号:
UC02
用例名称:
新增注册信息记录
简要说明:
录入新成员姓名,并自动进行存储建档
事件流:
基本事件流:
1)演员登录注册系统后进行注册信息。
2)系统要求注册演员选择要新增的是演员名称还是真实名称。
3)系统确认输入的信息查询未存在重名。
4)系统将所输入的信息存储建档。
扩展事件流:
3a)如果输入的姓名有重名现象,则显示出重名姓名,并要求注册演员重新输入或者取消输入。
3a1)注册演员选择取消输入则结束用例,不做存档工作。
3a2)注册演员选择重新输入后,转到3)。
非功能性要求:
前置条件:
系统中未对该实名制或演员名进行存储
后置条件:
完成演员注册
用例编号:
UC04
用例名称:
查询注册信息
简要说明:
进入演出管理系统指定网页进行查询
事件流:
基本事件流:
1)培训人员向系统发出“查询注册信息”请求。
2)系统要求培训人员选择要查询的注册日期。
3)系统让培训人员输入信息,并进行审核。
4)系统确认输入信息中日期正确。
5)系统将所输入日期成功注册人员加以显示。
扩展事件流:
4a)如果输入日期不正确,则显示不存在该日期,并要求培训人员重新输入或者取消输入。
4a1)服饰管理人员选择取消输入则结束用例,不做显示工作。
4a2)服饰管理人员选择重新输入后,转到4)。
非功能性要求:
前置条件:
系统中已对该演员信息进行储存
后置条件:
完成查询应调出的注册信息并显示
用例编号:
UC05
用例名称:
确定实际演员名单
简要说明:
所有爱好者均可报名,并由负责人对面试者进行筛选
事件流:
基本事件流:
1)演出商对负责人提出招聘演员要求。
2)负责人根据前来面试人员具备的条件进行筛选。
3)选出符合演出商要求的演员。
4)通知演员进入指定网页注册并填写基本信息获取演习地点、时间
5)系统确认输入信息中演员姓名未有重名。
6)系统将所输入的信息存储建档。
7)培训部门根据相关已注册信息确定培训者名单
扩展事件流:
5a)如果输入的姓名有重名现象,则显示出重名姓名,并要求负责人重新输
入或者取消输入。
5a1)负责人选择取消输入则结束用例,不做存档工作。
5a2)负责人选择重新输入后,转到5)。
非功能性要求
前置条件:
演出商进行演员招聘
后置条件:
完成最终演员名单存储
下表1-3为我们与用户访谈、学习、观察等过程所记录的COSPLAY演出时演员各方面要求。
表1-3购买服饰需求记录表
编号
说明
F01
进入供应商系统并进行搜索服饰信息
F02
按动漫服装汇总、动漫饰品汇总、演员配套服饰汇总进行选择性搜索
F03
筛选所需订购服饰信息并生成订单
F04
修改生成订单并进行确认
F05
提交订单并生成购买清单
F06
确认订购服饰无误形成一张订货通知单
F07
根据订货单后可查询订单详情
F08
到货后由指定人员通知负责人进行签收并生成付款清单
F09
核对付款单并确认付款
F10
仓库管理员根据付款清单整理出服饰总账单
将一些需求功能相近的合并到同一个用例中去,通过这些整理我们得到表1-4中的系统用例。
表1-4系统用例
特征
用例
F01进入供应商系统并进行搜索服饰信息
F02按动漫服装汇总、动漫饰品汇总、演员配套服饰汇总进行选择性搜索
F03筛选所需订购服饰信息并生成订单
UC01选定服饰生成订单
F04修改生成订单并进行确认
UC02修改并确认订单
F05提交订单并生成购买清单
F06确认订购服饰无误形成一张订货通知单
UC03生成订货通知单
F07根据订货单后可查询订单详情
UC04查询订单信息
F08到货后由指定人员通知负责人进行签收并生成付款清单
F09核对付款单并确认付款
UC05核对清单并付款
F10仓库管理员根据付款清单整理出服饰总账单
UC06统计服饰总账单
经过合并整理出6个用例,这些用例中,UC02(修改并确认订单)包含UC01(选定服饰生成订单),服饰选定后进行修改确认,UC05(核对清单并付款)必须先通过UC06(统计服饰总账单)才能启动,所以它们是扩展关系。
完成后的用例图1-2。
图1-2COSPLAY购买服饰管理系统用例图
绘制完用例图后,还需给出用例描述。
以下是各主要用例的用例描述。
用例编号:
UC01
用例名称:
选定服饰生成订单
简要说明:
进入供应商系统并进行搜索服饰
事件流:
基本事件流:
1)服饰管理人员向供应商系统发出“搜索服饰”请求。
2)系统要求服饰管理人员选择要搜索的是动漫服装汇总、动漫饰品汇总还是演员配套服饰汇总。
3)服饰管理人员做出选择后,显示系统分类好的服饰信息。
4)服饰管理人员进行指定服饰选择。
扩展事件流:
4a)服饰管理人员可直接点击进行选择
4b)也可直接输入服饰名称进行搜索选择。
非功能性要求
前置条件:
用户进入服饰供应商管理系统
后置条件:
完成需求服饰订单
扩展点:
无
用例编号:
UC02
用例名称:
修改并确认订单
简要说明:
确认订单中所选服饰均需要
事件流:
基本事件流:
1)单击进入已生成订单。
2)将需求服饰购物单与已生成订单进行对照。
3)缺少则点击分类进行添加。
4)一致则确认订单。
扩展事件流:
3a)如果订单中有多余服饰,则进行删除,转到3)。
非功能性要求:
前置条件:
服饰订单已生成
后置条件:
完成并生成确认订单
用例编号:
UC04
用例名称:
查询订单信息
简要说明:
进入供应商系统指定网页进行查询
事件流:
基本事件流:
1)服饰管理人员向系统发出“查询订单信息”请求。
2)系统要求服饰管理人员选择要查询的订单号。
3)系统让服饰管理人员输入信息,并进行审核。
4)系统确认输入信息中订单号正确。
5)系统将所输入的订单详情加以显示、包括时间、送货地点、已到达地址、派送员等。
扩展事件流:
4a)如果输入的订单号未进行发货,则显示不存在该订单,并要求服饰管理人员重新输入或者取消输入。
4a1)服饰管理人员选择取消输入则结束用例,不做显示工作。
4a2)服饰管理人员选择重新输入后,转到4)。
非功能性要求:
前置条件:
系统中已对该订单号进行发货
后置条件:
完成查询应调出的订单详情信息
用例编号:
UC06
用例名称:
统计服饰总账单
简要说明:
根据付款清单进行统计
事件流:
基本事件流:
1)仓库管理员向负责人发出索要“付款清单”请求。
2)负责人将“付款清单”提交给仓库管理员。
3)仓库管理员将一系列“付款清单”进行整理。
4)统计出购入服饰件数和类别,以及配套服饰的套数。
5)将整理出来的数据制作成表格,以便以后查询方便。
非功能性要求:
前置条件:
已从负责人那得到付款清单
后置条件:
整理出数据并完成表格
下表1-5为我们与用户访谈过程所记录的COSPLAY演出演员各方面要求。
表1-5登记购入服饰需求记录表
编号
说明
F01
购入演员服装及饰品
F02
新增服装饰品信息
F03
修改已有的服装饰品信息
F04
按照主角、配角分别对服饰进行分类
F05
录入新服饰时能自动按规则生成服饰号
F06
录入新服饰时如果有重名将自动提示
F07
按照固定演员、佩戴、辅助、等关键字组合查询服饰
F08
列出所有服饰、演员名称
F09
记录演员使用服饰情况
F10
按照演员名、服饰名来查询使用情况
F11
列出所有的服饰使用情况
F12
按特定时间段统计购买金额、服饰套数
F13
所有查询列表统计功能应可以单独对主角、配角名称进行
将一些需求功能相近的合并到同一个用例中去,通过这些整理我们得到表1-6中的系统用例。
表1-6系统用例
特征
用例
F01购入演员服装及饰品
F02新增服装饰品信息
F04按照主角、配角分别对服饰进行分类
F05录入新服饰时能自动按规则生成服饰号
F06录入新服饰时如果有重名将自动提示
UC01新增服饰信息
F03修改已有的服装饰品信息
UC02修改演员服饰信息
F07按照固定演员、佩戴、辅助、等关键字组合查询服饰
F08列出所有服饰、演员名称
F13所有查询列表统计功能应可以单独对主角、配角名称进行
UC03查询服饰信息
F09记录演员使用服饰情况
F10按照演员名、服饰名来查询使用情况
UC04登记服饰使用情况
F10按照演员名、服饰名来查询使用情况
F11列出所有的服饰使用情况
F13所有查询列表统计功能应可以单独对主角、配角名称进行
UC05查询服饰使用情况
F12按特定时间段统计购买金额、服饰套数
F13所有查询列表统计功能应可以单独对主角、配角名称进行
UC06统计金额和套数
经过合并整理出6个用例,这些用例中,UC03(查询服饰信息)包含UC05(查询服饰使用情况),使用情况进行统计后更新查询信息,UC02(修改演员、服饰信息)必须先通过UC03(查询服饰信息)才能启动,所以它们是扩展关系。
完成后的用例图1-3。
图1-3COSPLAY购入服饰管理系统用例图
绘制完用例图后,还需给出用例描述。
以下是各主要用例的用例描述。
用例编号:
UC01
用例名称:
新增服饰信息
简要说明:
录入新购入服饰信息,并自动进行存档
事件流:
基本事件流:
1)仓库管理员向系统发出“新增服饰信息”请求。
2)系统要求仓库管理员选择要新增的服饰是主角类还是配角类。
3)仓库管理员做出选择后,显示相应界面,让仓库管理员输入信息,并自动根据服饰号。
4)仓库管理员输入服饰的相关信息,包括服饰类型、服饰名称、供应厂商、购入价格、购入地点及购入时间等。
5)系统确认输入信息中服饰名未有重名。
6)系统将所输入的信息存储建档。
扩展事件流:
5a)如果输入的姓名有重名现象,则显示出重名姓名,并要求仓库管理员重新输入或者取消输入。
5a1)仓库管理员选择取消输入则结束用例,不做存档工作。
5a2)仓库管理员选择重新输入后,转到5)。
非功能性要求
前置条件:
用户进入购买服饰管理系统
后置条件:
完成新增服饰的存储建档
扩展点:
无
优先级:
最高(满意度5,不满意度5)
用例编号:
UC02
用例名称:
修改演员、服饰信息
简要说明:
将原系统中有的演员服饰信息进行修改补充
事件流:
基本事件流:
1)单击进入系统服饰管理页面。
2)对比原先存货数量对其进行添加或删除功能。
3)并对使用情况较频繁的服饰进行标记。
4)对这些记录进行存储建档。
非功能性要求:
前置条件:
服饰信息已经保存
后置条件:
完成并对修改进行保存
用例编号:
UC03
用例名称:
查询服饰信息
简要说明:
根据主角或配角名称对服饰进行查询
事件流:
基本事件流:
1)负责人向系统发出“查询服饰信息”请求。
2)系统要求注册演员选择要查询的是服装信息还是饰品信息。
3)负责人做出选择后,显示相应界面,让负责人输入信息,并自动根据服饰号。
4)系统确认输入信息中服饰名正确。
5)系统将所输入的服饰信息加以显示。
6)系统显示服饰的相关信息,包括服饰类型、服饰名称、供应厂商、购入价格、购入地点及购入时间等
扩展事件流:
4a)如果输入的服饰名未进行存储,则显示不存在该服饰,并要求负责人重新输入或者取消输入。
4a1)负责人选择取消输入则结束用例,不做显示工作。
4a2)负责人选择重新输入后,转到4)。
非功能性要求:
前置条件:
系统中已对该服饰进行存储
后置条件:
完成查询应调出的服装搭配信息
用例编号:
UC04
用例名称:
登记服饰使用情况
简要说明:
记录演员主角与配角专业服饰使用情况
事件流:
基本事件流:
1)负责人向系统发出“服饰使用情况”请求。
2)系统要求注册演员选择要查询的是服装信息还是饰品信息。
3)负责人做出选择后,显示相应界面,提供整个演出周期服饰的进出情况。
4)负责人对使用频繁的服饰进行检查,确认没有损坏情况。
扩展事件流:
4a)如果有出现损坏现象,则须重新购入该服饰。
非功能性要求:
前置条件:
负责人进入服饰管理系统
后置条件:
记录服饰使用情况并重新购入损坏了的服饰
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- COSPLAY 需求 文档