软件需求分析案例.docx
- 文档编号:8422404
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:25
- 大小:171.38KB
软件需求分析案例.docx
《软件需求分析案例.docx》由会员分享,可在线阅读,更多相关《软件需求分析案例.docx(25页珍藏版)》请在冰豆网上搜索。
软件需求分析案例
软件需求分析案例
教学管理系统(用例驱动的交互式需求获取)
以一个教学管理系统JXGL的分析与设计作为示例,说明用例驱动技术在软件项目开发中的应用。
高等学校的教学管理内容十分丰富,工作繁多。
作为一个示例,规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。
教学管理系统JXGL的用户是学校的学生、教师和教学管理员。
学生使用JXG系统查询新学
期将开设的课程和授课教师的情况,选择自己要学习的课程,并进行登记注册。
学生还可以使用JXGL系统查询自己的课程成绩。
教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况,以及学生的考试成绩。
教学管理员使用JXGL系统进行教学管理,包括新学期的课程选课注册管理和学生成绩管理。
1.需求描述:
对教学管理系统JXGL要求提供两个方面的服务:
(1)选课管理,负责新学期的课程选课注册工作;
(2)成绩管理,负责学生成绩管理。
在选课管理方面应填写的用户需求描述如下。
(1)录入与生成新学期课程表教学管理员在新学期开始前录入新学期课程,打印将开设的课程目录表,供师生参考选择。
若某课程的实际选课学生少于10人,则停开该课程,把该课程从课程目录表中删除;若某课程的选课学生多于30人,则停止选课。
(2)学生选课注册新学期开始前一周为选课注册时间,在此期间学生可以选课注册,并且允许改变或取消注册申请。
每个学生选课不超过4门课程。
每门课程最多允许30名学生选课注册。
学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。
在选课注册结束后,教学管理员打印学生选课注册名单和开课
通知书,送交有关部门和授课教师
(3)查询
可以查询课程信息、学生选课信息和学生、教师信息。
学生、教师、教学管理员可以查询课程表,获得课程信息。
查询的关键词以是:
课程名,授课教师名,学分。
教师、教学管理员可以查询学生选课情况。
查询的关键词可以是:
学生名、程名,授课教师名,学分。
学生只允许查询自己的选课信息,不允许查询别人选课信息。
学生、教师、教学管理员可以查询学生或教师的信息。
查询的关键词可以是学生名、教师名,性别、班级、职称。
(4)选课注册信息的统计与报表生成。
教学管理员对学生的选课注册信息进行统计(按课程,按学生,按班级),印汇总统计报表。
在成绩管理方面应填写的用户需求描述如下:
(1)成绩录入:
教学管理员录入学生考试成绩。
(2)成绩查询:
教师、教学管理员可以查询学生考试成绩。
查询的关键词可以是:
学生名、课程名、授课教师名、学分名、学生只允许查询自己的考试成绩,不允许查询别人的考试成绩。
(3)成绩统计与报表生成
教学管理员进行成绩统计(按课程、学生、按班级),打印成绩汇总统计报表。
为保存数据,需建立教学管理数据库。
可以采用关系数据库,建立下列数据库表:
学生表、教师表、课程表、选课表、任课表、成绩表。
教学管理系统的直接用户有学生、教师和教学管理员。
教学管理员有权操纵数据库的数据,进行添加、更新、删除等操作。
学生和教师一般只查询信息,只允许对自己有关的数据进行添加,更新、删除等操作。
教学管理系统JXGL的相关系统有财务系统。
JXGL系统需要把学生选课注册信息传送给财务系统,以供财务系统计算学生应交纳的费用,但是不要求财务系统回馈学生应交纳的费用信息。
假定在学校的计算中心有功能强大的工作站机器,在各系、各部门、图书馆、学生宿舍都有台式PC机,学校的全部计算机已经连网。
教学管理系统JXGL将采用客户机/服务器结构建立,JXGL系统的应用服务器和数据库服务器设置在学校计算中心的工作站。
学生、教师和教学管理员可以在各系、各部门、图书馆、学生宿舍的台式PC机上使用JXGL系统。
2.确定系统范围和边界
首先要确定业务需求和系统目标。
教学管理系统JxGL用于新学期课程的选课注册管理和学生的成绩管理。
凡是这两方面的教学管理内容都是JXGL系统的
职责范围,其他的教学管理内容,如安排教学计划、排课、实习、实验、考试等都不属于JXGL系统的职责范围。
至于学校的其他管理工作,如科研、人事、财务、资产等管理不属于JXGL系统的职责范围。
JXGL系统与财务系统存在系统边界,财务系统将从JXGL系统得到学生选课注册信息。
JXGL系统与学校的其他信息管理系统没有直接的联系,但是可以从学校的全局数据库中共享学生、教师、教学计划等必要的数据。
3.定义用户
根据JXGL系统用户需求描述可以确定4个参与者:
学生、老师、教学管理员和财务系统。
对于每一个参与者,应当明确其业务活动的内容、对系统的服务要求。
“学生”参与者使用JXGL系统查询新学期开设的课程信息和教师开课信息,选课并登记注册课程,查询自己的课程成绩信息。
“老师”参与者使用JXGL系统查询新学期开设的课程信息、学生选课信息和学生成绩信息。
“教学管理员”参与者使用JXGL系统管理学期开设的课程的选课注册和学生的考试成绩。
管理工作包括课程与成绩数据的录入、维护、统计、报表打印等,并且负责把学生的选课注册信息发送给财务系统,作为计算学生应付费用的依据。
“教学管理员”要求能够方便地查询课程信息、学生选课信息、学生信息、教师信息和成绩信息。
财务系统”参与者是外部系统参与者,从JXGL系统接受学生的课程注册
信息。
4.UseCase的获取
每一个USeCase都是一个参与者与系统在交互中执行的有关事务序列。
应当
根据用户需求描述,找出全部的USeCase并从参与者的角度给出事件流,当
USeCase执行时系统应提供给参与者的服务。
从JxGL的用户需求描述分析可的有以下用例存在:
(1)查询课程信息:
学生、教师或教学管理员查询课程表,获得课程信息。
(2)选课注册:
学生登录进行选课注册。
(3)管理开设课程:
教学管理员登录系统产生选课信息,按照要求进行分类统计,生成选课注册报表。
(4)管理学生信息:
教学管理员对学生数据进行录入、修改、删除等操作。
(5)管理老师信息:
教学管理员对教师数据进行录入、修改、删除等操作。
(6)管理课程信息:
教学管理员对课程数据进行录入、修改、删除等操作。
(7)查询学生成绩:
学生、教师查询学生成绩。
(8)查询课程成绩:
学生、教师查询课程成绩。
(9)学生成绩管理:
教学管理员对学生考试成绩数据进行录入,修改、删除等操作。
(10)成绩统计:
教学管理员对学生的考试成绩数据进行分类统计,生成成绩报表。
5.需求获取描述
(1)
用户需求描述
录入与生成新学期课程农
用搠宕
宵理課段信息
用例捲述
敕学管理场对谀鶴数据进行录入.修徴、删除曙换柞.
1:
娶actor
執学ff理貝
血置条件
倉师已将緬学期所幵课程数据上拽1
成功后誉峯件
鞍学管理员、学生和教师可以在网络上进杼课程的相关操柑
光败廉固条件
芳生利敬师在网络上无法获知谍程数据
关联用恻
去询课稈倩息、管理开设课程
⑵
用户褂求描述
学生选谍注册
1
HJ例名
赶课注册
出例描述
学先鲨录进打选课注册.
主actor
学主.
前盘条件
適知学生在网上进行选课注册
盛功厉習条件
—F“
拽学管理员、学生利教师可以在网络上进行评和的相艾摊忙
矢收后宣条件
学定利枚祈生网络上无袪扶知课稈数据
关联用例
讦询课稈信息.育理开设课稈
(3)
用户需求描述1
9W
用例名
賁询课稈惜息
用例播谨
学埜、敦师或教学甘理呦丧询课科蔻.获得课程信息f
卞要actor
学生、教师利教学世理员.
前酋条件
教学督理员将陳槿值息上传至岡劉
成功片过条件
学生*敎师或救学許理员准确获得谍稈信息=
失败厉矍条件
系统挺示课程数据厚出现故障
梵联用例
皆理开设课秤*管理课以信息
⑷
用户需求描述
选踝注册悟息的统计与赧表生成
用例名
管理卄设课裡
阳网描述1
校学供理员登录系统产生选课信息,按照娶求逬行分类统计,上嵐选谯
注册报為
主factor
教学鹫遷员
学员己究成了选谡注册
成功萨曽集件
按婆求进杼分类址计.绘虛选谍注册报表.
肚课注册信息宵富■无法生成fit衷
逸i®注册
(5)
用尸需求描述
教学管理员录人学生成绩
坤例名
:
学生成绩管理
用例描谨
教学管理员对学主考试咸绩数据进行求入.修改.删除等嫌彳匚
主要tictor
救学管理员
旳宙条件
学员考试第東并圧阅卷充成,学员成绩需翌以救据斥记录
成功肝置条件
教学管理员、学生和敎师可以在闻络上进行学生成绩的相关按作
火败后置条件
学生利教郝在网络上无袪获取学生咸绩
关戯用例
于:
牛战绮胃理、咙織统计、杳洵聲生成简、忙旬课玮応篩
(6)
用户需般描述
育训成绩
用例卷」
脊询喙庄成绩
1用例描逑
学生、教师貢询学生成绩.
上耍actor
学生、救师
営生成绩以敬据库记录if上传至服等器
虑功启置条件
嵌据筆生电、谯秤名.授谟敕肺喀.学分名苇关樓词讲询考就成绒
先敷后置条11
)»»StoT维护中
茏联用例
学生成绩宵理
(7)
用户需求描述
戚绩统计耳报表生成
感绩统计
用例描述
教嗥管理蔗对学生的看试成绩奴据进行分类统计,生成成绩报住「1
主Jractor
教学裁理员
前JK条杵
学生成绩以数据專记录井上传至服务器
成功后直条件1
教咿管理员戲行成绩统计(按葆祝*学生、按班级).打印成绩汇总统计
报艮
貴炊后置条件
服务器处于维护中
关联出例|
学生应绩管理
6.导出UseCase
案例Two水利厅办公业务资源系统
水利厅办公业务资源系统是一个面向300多用户以及10多个部门日常业务流程的项目,由于系统牵涉的用户面和业务范围较广,系统的各种功能与用户的日常工作息息相关,因此做好系统需求分析显得至关重要。
项目需求调研阶段始终坚持“以用户为中心”,采取了有效、多样的方式与用户沟通,充分重视用户提出的每一项需求,并根据实际情况采用各种技术手段与用户进行沟通以最大限
度获得需求。
(1)系统功能和性能需求分析分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参考价值。
经过研究分析,水利厅原有办公自动化系统存在几个突出的问题:
1技术手段比较落后。
如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明显下降;另一方面系统管理员的维护工作量很大,系统版本更新后需要重新更新各客户端程序;
2系统的跨平台性和移植性差。
旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很大;
3工作流固化用户实际流程与默认流程不符时需手工重新配置流程,导致系统推广应
用难度大;
4可供办公使用的信息资源少。
基于以上分析,可得出新系统的功能和性能方面基本要求如下:
功能主要包括公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库等。
性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。
技术方面要求采用J2EE平台和关系型数据库(ORACLE实现,基于B/S的三层体系结构进行设计。
(2)需求信息来源分析
通过对需求信息的来源进行分析,得出如下需求捕获计划(见表1)
表1需求捕艮计划
11」采趟可侃潯和部蚣的妙能
阳萦址裕求分析报吉JUM册用P
斯系统两新增加的功能和非功
潇索统潜左的用户、技本人处白身
同类系统战功案剖可服抽的的怨和经豔
参观和韦農同类索址.借圧吁的邛
(3)需求分析技术的选用
用户调查。
在直接与用户进行面对面交流前,先对旧系统用户作一个书面调查,收集他们对旧系统的使用体会以及对新系统最关心的功能需求,目的是在面
对面进行用户访谈时提高需求分析人员提问的针对性和引导作用。
《需求调研表》
涉及的主要内容包括:
用户使用频度最高的功能、旧系统设计存在的主要不足、对系统改进的建议等,调查对象为全体用户。
通过收集用户的信息反馈表并进行归纳总结,得出以下几个结论:
用户使用频率最高的模块主要是公文收发处理、内
部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。
用户访谈。
经过用户调查后,通过组织用户进行面对面访谈来达到细化系统需求的目的。
访谈的对象主要是典型业务处室代表,如办公室负责文件收发的秘
书、关键业务部门、技术部门的代表。
进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题,如:
公文收发的流程是怎样的(办公室代表回答)?
在业务处室内部处理的流程是怎样的(业务处室代表回答)?
系统界面的人性化方面有哪些要求(全体代表回答)?
系统管理方面的需求是什么(技术部门代表回答)?
参观考察。
为了吸取兄弟单位同类项目的先进经验,开拓思路,组织用户到一些有成功案例和良好口碑的单位进行参观考察。
通过参观考察,博取众长,将各单位有价值的好的经验和做法吸纳到本系统的建设需求中来。
(4)几种需求分析技术对比
1用户调查覆盖的面较广(涉及到本单位300多用户),不需要占用被访用户太多工作时间,容易被用户接受。
但是由于某些用户对用户调查的重视程度不够,导致所反馈的信息不全面,参考价值有限,只能作为需求分析技术的一种参考和补充手段。
2用户访谈对于本系统需求分析是一种收效较好的技术手段。
但是这种技术的使用对于需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。
在条件允许的情况下,应尽量采
用这种技术。
3参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的
效果案例3:
学院房产管理系统
1.开发背景:
行政学院房地产管理系统是在金融体制改革的形势下,由行政学院信息技术部承担开发的,在成都市范围内进行房产投资和管理的应用系统。
系统的应用范围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来源,以及计算所有投资的回报情况的能力。
该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理,也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。
2.使用用例驱动获取需求:
(1)确定系统的初始范围
第一步是考虑这个系统的大的范围。
通过与项目有关人员(主要是用户)的大量交流沟通,以及组织多次访谈会,首先根据系统的作用,用户的最基本要求确定了系统的初始范围,如图18所示。
图15玉统的初始蒞国
2)确定参与者
确定了三个参与者:
经营经理、房产经理和外部合作伙伴。
1)经营经理:
负责数据录入和数据维护。
经营经理创建报表,以提供有关房产的管理信息,并保证考虑到房产的日常问题。
2)房产经理:
负责管理自己掌握的资金用于房地产投资。
房产经理要确定准备投资的各种类型的房地产项目。
这种参与者主要关注投资所需的资本和投入的资本与所产生的回报的比较。
3)外部合作伙伴:
外部合作伙伴与房产经理起类似的作用,不过是在机构的外部。
外部合作伙伴参与房产,但是在很多方面可以斟酌决定。
外部合作伙伴的主要责任是保证投资产生回报,还需要向房产经理定期提供信息,包括现金流、对帐单和回报信息。
(3)获取用户需求与关键项目的相关人员一起,经过大量的分析讨论,确定了两个基本用例。
用例1管理投资
用例名称
管理投资
描述
跟踪公司所投资傍产的展4M性,房产承租人的信息和和期;
稱与者
•经营经理
•房产经理
•外部介作伙ft
触发条件
厉产、厉产承租人或租期就主变化,
前提
分类表和直它数摒已经进人系统.
幕本常件过程
L当获取一址房产时*
a)录入投资{用产)的详细信息。
b)堀定腐产的资本委托爭坝。
呻将房产划分为一个或多个单元。
2.当找到房产单元的解利人时:
a>呆入朋租人详细信息a
b)螂定承机条款。
O确定旅租人付款时间衣•
d)将这个房产单元与该承租人关联"
3.为房产售出时:
a*记录销售细W
b)与房产的所冇承租人脱离关联,
C)删除对该房产的所冇未来盜木投入。
d)从时间表中删除所冇耒来现金流*
4.当到达租期Eh
a>将房产单元与承和人脱离关系,便代可确崔新的租期.b)删除与该承棚人关联的所有未来现金流無
界常
无
后果
用例2汇总投资
用例低称
汇总投资
描述
把匕址仔储的放据筆理为支持业务运莒和决策旳•纽报&’
参与者
•经营经理
•房产经理
触发条件
•房产经理主要以临时确足的力史川报农以做出各种抉
•经营经理定期使nj报丧支持业务运营。
前提
♦投资和房产部门已经把详细倚息晟入到系统中。
•系纨必烦a那眶依赖u令外部数据的报衣获収来自外部的数据。
里本事件过程
1.系统显示已有报表消单*包[岳
a)込营报农
1耒来11个月内到期的承租合同。
ii-房产便用常况-
iii.磚个区城水承祖的单元氏
b)房产经理报衣
L预期创报率“
ii.排名皿门位的房产。
Hi.每个区域的房产。
d.房产状况“
这里只列表了H前垠重要的报表,而不是穷艮所有报表清单。
2*参与者选择报我环
3.系统提术参与者输入绡化报崔的详细佶息.包括报表H期.
4.系统检索数据,执行汁算导出投有存仿的数据,对申就排丿讥父系统准备提供提交的报我.包括报丧的外观和交m矗式,包
括打印格式利屏幕格式.
昇常
无
后果
系统不会根据报表牛成修改业务数据。
此时,我们除了可能有外部房产经理参与者的远程访问需求之外,还没有提
出紧迫的技术需求,也没有得到业务规则。
通过项目相关人员的讨论,我们得到他们对系统提出的两个基本要求。
1)根据用户的视点来设计本系统。
这是一项基本要求,我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。
项目相关人员要求为其业务提供很强的会计支持,但是愿意将两个系统分开。
帐本簿与房地产管理系统之间没有多少冗余数据,项目相关人
员不愿意增加额外经费补充会计功能,或将两个系统数据集成起来。
2)把系统看作是一种“数据采集与报表生成系统”。
关键是构建采集实现他们所定义的业务规则的数据的系统,既要使数据“安全”(不能丢失或遗忘),又要为不同参与者提供专门化的视图,以便根据这些视图做出业务决策(例如,系统具有比较回报和投资的能力,要能够知道从出租的角度看,哪些房产在历史上没有得到充分的利用,哪些区域的出租率和回报率高)。
(4)获取功能需求
下一步是充分与用户讨论,搜集尽可能多的有关各种参与者如何与系统交互的信息,以及他们需要通过系统获得什么样的信息。
搜集这些信息的结果,我们可以将前面的用例进行进一步的扩展。
为了更好地表示用例,我们把用例图一分为三。
如图19、20、21所示。
图19经过扩踊的报艇生成
图20经过扩展的数据求入
(2)
这里把用例由最初的两个扩展为20个
用例3录入承租人详细信息
川例名称
录入承租人详细佶息
描述
房地产管理系统跟踪谁在承租房产.系统存储每个承租人的一套详细信息,以记帐、跟踪和检査状况4
参与者
经营经理
触发条杵
•发现承租房产的新展租人或潜在承租人,本用例町以由讪祖馬产”用例来启动。
•发现现有煦梱人的补允或丈史信息。
前提
「无
堆本事件过程
K经营经理找到卓祖人区域.
1.经背经理朮入承祖人的标识倍息:
a)个人示和人的姓名和目份证号码白
b)机构承相人的公司名称和税务修记证号口
3,系统检在现冇匹甩项。
4.索统显示□经瞋写了现右信息的数拥录入模板一个人丞租人和机构承租人的模板不同.
<需墓补充插入所需数据顶的淸单〉
5”绊骨经理录入鏗个数曲项。
6*系统根抓数曲;录入规则(H期,刖份iiF等)拎船录入的数抓
7.如果经营经理时所玻入的数据必到淌总:
,则提交数据变更。
8.系统检資所录入数据是否完1!
农
9.如果通过检验,则系统存储所做的数齬变更,该承租人彼标记为有效。
异常
3.如果系统发现重亘项,则时参与者发出警告,并显示现冇隨租人址求。
7.如果参巧者对所做的数拥变也不满氐可以选样肢弃所做变更.如果系统中有以前存储的记录,则恢复以前存储的记录•
8.如果没有输入鉴求必须输入的数据,系统对参与者发出警告,并解释哪些数据必须录入如果该承租人是当前鷹租介同签订人(即拥有尚未到期的承租合同的承租人人并且系统不接收数那变页,则这会导敷该承租人失去冇效状态"
后果
如果数揺是完备的,有效的,系统朋有一个有效的承租Ac
业务规则
V插入7投和表格级的详細检脸规则〉
技术需求
•本功能口崔丄办公生内便川.经营经理爪崔其他地方办公Q•承租人所需的数据集过去已经变更过多次"房产綽理喪求系纯旦冇*卜充或删除有关承和人的珥接或孑IH数掘的入活性••预期一次只有一个人更新承租人数据,系统不需要支持承租人信息的同时更新占
•系统应该存储对承租人伯息变更的所有历归包括进行变更的参与者标识*以及变更日期和时间•
用例4录入投资详细信息
用例5录入房产详细信息
用例6建立单元
用例7出租房产
用例8输入数据
用例名称
输入数据
描述
外部存作伙伴诗理一部分房产。
在典型悄况卜;外部合作伙伴与本单位共同拥有房产——他们拥冇房产的一部分,并负责维护和出租整个房产。
外部合作伙伴根据协议,按期向本单位提交数据和钱款.本用例将外部合作伙佯提供的数据输入到系统存储.吐供生成报表°
参与者
•外部合作伙伴
•经营经理
触发条件
外部汁作伙伴按介同规定.定期提供牧据。
在毎个拯农提交周期.外部合作伙伴都鉴准备数据并提交给本公司,从而触发本用例。
就提
外部合作伙伴和本公司已经签订协议。
基本車件过程
E经营经理收到组来口外部介作伙伴的数將或有关数抵已经生成的通知.
2.经营经理找到数据所对应的房产°
3・经营经理找剑输入外部合作伙伴数据的区城&
4.系统询问外部数据的位賣。
匚经营经理给出外部数拥的位置*
•系统检査数攜对应的房产准确无谋。
7.系统读取房产的以下数据:
a)对应1【期的一系列现金金報;
b)对应日期的一系列资本支付。
&系统将这部分倩息与所给出的房产关联。
9”系统向经营就能影了显示所输入的数据供批准。
a)经背经理检僅这些数据,批准或取消输入数据操作竹
b)紺果数据被批准.系统存储所输入的数据口
异常
忙如果系统不能找到威访河输人数据,则系统警告经营经理.井等特经营经理提供其他数据存放位賈或取消操作。
6.如果数据没有对应所期瑕的房产,则系统警告经营经理,本用例结束。
后果
无
业务规则
无
技术需求
只支持种数粥转换方i龙这样可以降低系统的更杂性,减轻员工培训负担.一个项II相关人员提岀,外部合作伙伴拥有很少的技术和业齐口治能力.并提出电了表捲应该足舍适的数据转换机制
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 分析 案例