需求获取案例.docx
《需求获取案例.docx》由会员分享，可在线阅读，更多相关《需求获取案例.docx（25页珍藏版）》请在冰豆网上搜索。
需求获取案例
案例1:
广东省水利厅办公业务资源系统
广东省水利厅办公业务资源系统是一个面向300多用户以及10多个部门口常业务流程的项目，由于系统牵涉的用户面和业务范闱较广，系统的各种功能与用户的口常工作息息相关,因此做好系统需求分析显得至关重要。
项目需求调研阶段，始终坚持“以用户为中心”，采取了有效、多样的方式与用户沟通，充分重视用户提出的每一项需求，并根据实际情况采用各种技术手段与用户进行沟通以最大限度获得需求。
（1）系统功能和性能需求分析
分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很人参考价值。
经过研究分析，水利厅原有办公自动化系统存在几个突出的问题：
1技术手段比较落后。
如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明显下降;另一方面系统管理员的维护工作屋很人，系统版本更新后需要重新更新各客户端程序；
2系统的跨平台性和移植性差。
旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很人：
3工作流固化
用户实际流程与默认流程不符时需手工重新配置流程,导致系统推广应用难度人；
4可供办公使用的信息资源少。
基于以上分析，可得出新系统的功能和性能方面基本要求如下：
功能主要包扌舌公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库等。
性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。
技术方面要求采用J2EE平台和关系型数据库（ORACLE）实现，基于B/S的三层体系结构进行设计。
（2）需求信息来源分析
通过对需求信息的来源进行分析，得出如下需求捕获计划（见表l）o
耒1需求捕获计划
想得到的需求信息
获取需求的可能途径
旧系统可保留和继承的功能
旧系统需求分析报告•旧系统用户
新系统应新增加的功能和非功能需求
新系统潜在的用户、技术人员自身
的经验
同类系统成功案例可吸纳的做法和经验
参观和考察同类系统，借鉴好的经
验
（3）需求分析技术的选用
用户调查。
在直接与用户进行面对面交流前，先对旧系统用户作一个书面调查，收集他们对旧系统的使用体会以及对新系统最关心的功能需求，目的是在面对面进行用户访谈时提高需求分析人员提问的针对性和引导作用。
《需求调研表》涉及的主要内容包扌心用户使用频度最高的功能、旧系统设计存在的主要不足、对系统改进的建议等，调查对彖为全体用户。
通过收集用户的信息反馈表并进行归纳总结，得出以下几个结论:
用户使用频率最高的模块主要是公文收发处理、内部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。
用户访谈。
经过用户调查后，通过组织用户进行面对面访谈来达到细化系统需求的目的。
访谈的对象主要是典型业务处室代表，如办公室负责文件收发的秘书、关键业务部门、技术部门的代表。
进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题，如:
公文收发的流程是怎样的（办公室代表回答）?
在业务处室内部处理的流程是怎样的（业务处室代表回答）?
系统界面的人性化方面有哪些要求（全体代表回答）?
系统管理方面的需求是什么（技术部门代表回答）?
参观考察。
为了吸取兄弟单位同类项目的先进经验，开拓思路，组织用户到一些有成功案例和良好11碑的单位进行参观考察。
通过参观考察，博取众长，将各单位有价值的好的经验和做法吸纳到本系统的建设需求中来。
（4）几种需求分析技术对比
1用户调查覆盖的面较广（涉及到本单位300多用户），不需要占用被访用户太多工作时间，容易被用户接受。
但是由于某些用户对用户调查的重视程度不够，导致所反馈的信息不全面，参考价值有限,只能作为需求分析技术的一种参考和补充手段。
2用户访谈对于本系统需求分析是一种收效较好的技术手段。
但是这种技术的使用对于需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。
在条件允许的情况下，应尽量采用这种技术。
3参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。
案例2：
教学管理系统（用例驱动的交互式需求获取）
以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。
高等学校的教学管理内容十分丰富，工作繁多。
作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。
教学管理系统JXGL的用户是学校的学生、教师和教学管理员。
学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。
学生还可以使用JXGL系统查询自己的课程成绩。
教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。
教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。
1•需求描述：
对教学管理系统JXGL要求提供两个方面的服务：
（1）选课管理，负责新学期的课程选课注册工作；
（2）成绩管理，负责学生成绩管理。
在选课管理方面应填写的用户需求描述如下。
（1）录入与生成新学期课程表
教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参考选择。
若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目录表中删除;若某课程的选课学生多于30人，则停止选课。
（2）学生选课注册
新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请。
每个学生选课不超过4门课程。
每门课程最多允许30名学生选课注册。
学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。
在选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门和授课教师。
⑶查询
可以查询课程信息、学生选课信息和学生、教师信息。
学生、教师、教学管理员可以查询课程表，获得课程信息。
查询的关键词以是:
课程名，授课教师名，学分。
教师、教学管理员可以查询学生选课情况。
查询的关键词可以是:
学生名、程名，授课教师名，学分。
学生只允许查询自己的选课信息，不允许查询别人选课信息。
学生、教师、教学管理员可以查询学生或教师的信息。
查询的关键词可以是学生名、教师名，性别、班级、职称。
（4）选课注册信息的统计与报表生成。
教学管理员对学生的选课注册信息进行统计（按课程，按学生，按班级），印汇总统计报表。
在成绩管理方面应填写的用户需求描述如下：
⑴成绩录入：
教学管理员录入学生考试成绩。
（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）
用户需求描述
录入与生成新学期课稈表
用例名
管理谍程信息
用例描述
教学管理另对课程数据进行录入、修改、删除等操作。
上耍actor
教学管理员
at置条件
老师已将新学期所开课程数据上报
成功后置条件
教学管理员、学生和教师可以在网络上进行课程的相关操作
失败后逝条件
学生和教师在网络上无法获知谍程数据
关联用例
查询课程信息、管理开设课稈
（2）
用户需求描述
学生选课注册
川例名
选课注册
用例描述
孑生登录进彳亍选课注册'
主要actor
学生
前貰条件
逋知学生在网上进行选课注册
成功后實条件
教学管理员、学生和教师可以在网络上进行课程的相关操作
失败后虽条件
学生利教师在网络上无法获知课程数据
1关联用例
査询课程信息、管理开设课程
（3）
用户需求描述
査询
用例名
!
靑询课程信息
用例描述
学生.救师或教学智理员責询课理表，获得课程信息。
主婆actor
学生、教师和教学管理员
前垃条件
教学管理员将课程信息上传至网络
成功后进条件
学生、教师或教学骨理员准确获得课程信息&
先败后置条件
系统捉示课程数据库出现故障
关联用例
管理开设课程、管理课程信息
用户需求描述
选课注册信息的统计与报表生成
用例名
管理开设课程
用例描述
教学管理员矍录系统产生选课信总，按照要求进行分类统计，生成选课
注册报表.
主耍actor
菽学管理员
前置条件
学员己完成了选课注册
成功后置条件
按要求进行分类统计，生成选课注册报表。
失败拆连条件
选课注册信息有谋，无法生成报表
关联用例
选课注册
（5）
用户需求描述
教学管理员录入学生成绩
用例名
学生成绩管理
用例描述
教学管理员对響生考试成绩数据进行录入，修改、.删除等操作。
主要actor
教学管理员
前置条件
学员考试结束并且阅卷完成，学员成绩需翌以数据库记录
成功厉愷条件
教学管理员、学生和教师可以在网络上进行学生成绩的相关操作
失败后遇条件
学生和教师在网络上无法获取学生成绩
1关联用例
学生成绩管理、成绩统计、査洵学生成绩、査询课程成绩
（6）
用户需求描述
賁询成绩
用例名
査询学生成绩
用例描述
学生、教师査询学生成绩。
主要actor
学生、教师
前置条件
学生成绩以数据库记录并上传至服务器
成功后置条件
依站学生名、课程名、授课教师名、学分名筹关键诃查询考试成绩
失败后置条件
服务器处丁-维护中
关联川例
学生成绩管理
（7）
1用户需求描述
成绩统计与报表生成
用例名
成绩统计
用例描述
教学管理员对学生的考试成绩数据进行分类统计，生成成绩报表。
1主jSactor
教学1T理员
前置条件,
学生成绩以数据阵记录并上传至服务器
成功后置条件
教学管理员逬行成绩统计（按课程、学生、按班级》，打卬成绩汇总统计
火败后世条件
服务器处于维护中
1关联用例■
学生成绩管理[
6•导出UseCase
案例3：
学院房产管理系统
1.开发背景：
行政学院房地产管理系统是在金融体制改革的形势卞，由行政学院信息技术部承担开发的，在成都市范围内进行房产投资和管理的应用系统。
系统的应用范I制包扌舌跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来源，以及计算所有投资的回报情况的能力。
该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理，也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。
2.使用用例驱动获取需求：
（1）确定系统的初始范围
第一步是考虑这个系统的大的范围。
通过与项目有关人员（主要是用户）的大量交流沟通，以及组织多次访谈会，首先根据系统的作用，用户的最基本要求确定了系统的初始范围，如图18所示。
图is系统的初始范围
（2）确定参与者
确定了三个参与者：
经营经理、房产经理和外部合作伙伴。
1）经营经理：
负责数据录入和数据维护。
经营经理创建报表，以提供有关房产的管理信息，并保证考虑到房产的口常问题。
2）房产经理：
负责管理自己掌握的资金用于房地产投资。
房产经理要确定准备投资的各种类型的房地产项目。
这种参与者主要关注投资所需的资本和投入的资本与所产生的回报的比较。
3）外部合作伙伴：
外部合作伙伴与房产经理起类似的作用，不过是在机构的外部。
外部合作伙伴参与房产，但是在很多方面可以斟酌决定。
外部合作伙伴的主要责任是保证投资产生回报，还需要向房产经理定期提供信息，包扌舌现金流、对帐单和回报信息。
（3）获取用户需求
与关键项目的相关人员一起，经过大量的分析讨论，确定了两个基本用例。
用例1管理投资
用例名称
管理投资
描述
跟踪公司所投资房产的基本属性，房产承租人的信息和租期。
参与者
•经营经理
•房产经理
•外部合作伙伴
触发条件
房产、房产承租人或租期发生变化。
询提
分类表和其它数据已经进入系统。
基本事件过程
1.当获取一处房产时：
a）录入投资（房产）的详细信息。
b）确定房产的资本委托事项。
c）将房产划分为一个或多个单元。
2.为找到房产单元的承租人时：
a）录入承租人详细信息。
b）确定承租条款。
c）确定承租人付款时间表。
（1）将这个房产单元与该承租人关联。
3.当房产售出时：
a）记录销售细节。
b）与房产的所有承租人脱离关联。
c）删除对该房产的所有未来资本投入。
（1）从时间表中删除所有未来现金流。
4.当到达租期时：
a）将房产单元与承租人脱离关系，使其可确定新的租期。
b）删除与该承租人关联的所有未来现金流。
异常
无
后果
无
用例2汇总投资
用例名称
汇总投资
描述
把已经存储的数据整理为支持业务运营和决策的一组报表。
参与者
•经营经理
•房产经理
触发条件
•房产经理主要以临时确定的方式使用报表以做出各种决策。
•经营经理定期使用报表支持业务运营。
前提
•投资和房产部门已经把详细信息录入到系统中。
•系统必须为那些依赖已有外部数据的报表获取来自外部的数据。
基本事件过程
1•系统显示已有报表清单，包括；
a）运营报表
i.未来n个月内到期的承租合同。
ii.房产使用情况。
iii.每个区域未承租的单元。
b）房产经理报表
i.预期回报率。
ii.排名前5位的房产。
iii.每个区域的房产。
iv.房产状况。
这里只列表了L1就最重要的报表，而不是穷尽所有报表清单。
2.参与者选样报表。
3.系统提示参与者输入细化报表的详细信息，包括报表日期。
4.系统检索数据，执彳亍计算导出没有存储的数据，对申请排序。
5.系统准备提供提交的报我，包括报表的外观和交付格式，包括打印格式和屏幕格式。
异常
无
后果
系统不会根据报表生成修改业务数据。
此时，我们除了可能有外部房产经理参与者的远程访问需求之外，还没有提出紧迫的技
术需求，也没有得到业务规则。
通过项目相关人员的讨论，我们得到他们对系统提出的两个基本要求。
1）根据用户的视点来设计本系统。
这是一项基本要求，我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。
项目相关人员要求为其业务提供很强的会计支持，但是愿意将两个系统分开。
帐本簿与房地产管理系统之间没有多少冗余数据，项目相关人员不愿意增加额外经费补充会计功能，或将两个系统数据集成起来。
2）把系统看作是一种“数据采集与报表生成系统”。
关键是构建采集实现他们所定义的业务规则的数据的系统，既要使数据“安全”（不能丢失或遗忘），又要为不同参与者提供专门化的视图，以便根据这些视图做出业务决策（例如，系统具有比较回报和投资的能力，要能够知道从出租的角度看，哪些房产在历史上没有得到充分的利用，哪些区域的出租率和回报率高）。
（4）获取功能需求
卞一步是充分与用户讨论，搜集尽可能多的有关各种参与者如何与系统交互的信息，以及他们需要通过系统获得什么样的信息。
搜集这些信息的结果，我们可以将前面的用例进行进一步的扩展。
为了更好地表示用例，我们把用例图一分为三。
如图19、20、21所示。
图19经过扩展的报表生成
图20经过扩展的数据录入
（2）
这里把用例由最初的两个扩展为20个。
用例3录入承租人详细信息
用例名称
录入承租人详细信息
描述
房地产管理系统跟踪谁在承租房产〉系统存储每个承租人的一套详细信息，以记帐、跟踪和检查状况。
参与者
经营经理
触发条件
•发现承租房产的新承租人或潜在承租人。
本用例可以由“出租房产”用例来启动。
•发现现有承租人的补充或变更信息。
前提
无
基本事件过程
1.经营经理找到承租人区域。
2.经营经理录入承租人的标识信息：
a）个人承租人的姓名和身份证号码。
b）机构承租人的公司名称和税务登记证号。
3•系统检查现有匹配项。
4•系统显示已经填写了现有倍息的数据录入模板。
个人承租人和机构承租人的模板不同。
v需要补充插入所需数据项的清单〉
5・经营经理录入每个数据项。
6•系统根据数据录入规则（日期.身份证等）检验录入的数据。
7.如果经营经理对所录入的数据感到满意，则提交数据变更。
8•系统检查所录入数据是否完整。
9.如果通过检验，则系统存储所做的数据变更，该承租人被标记为有效。
异常
3.如果系统发现重复项，则对参与者发出警告，并显示现有承租人记录。
7・如果参与者对所做的数据变更不满意，可以选择放弃所做变更。
如果系统中有以询存储的记录，则恢复以询存储的记录。
8.如果没有输入要求必须输入的数据「系统対参与者发出警告，并解释哪些数据必须录入。
如果该承租人是X询承租合同签订人（即拥有尚未到期的承租合同的承租人）,并且系统不接收数据变更，则这会导致该承租人失去有效状态。
后果
如果数据是完备的、有效的，系统拥有一个有效的承租人。
业务规则
v插入字段和表格级的详细检验规则〉
技术需求
•本功能只在主办公室内使用，经营经理不在其他地方办公。
•承租人所需的数据集过去已经变更过多次。
房产经理要求系统具有补充或删除有关承租人的直接或导出数据的灵活性。
•预期一次只有一个人更新承租人数据，系统不需要支持承租人信息的同时更新。
•系统应该存储对欣租人信息变更的所有历史，包括进行变史的参与者标识，以及变更日期和时间。
用例4录入投资详细信息
用例5录入房产详细信息
用例6建立单元
用例7出租房产
用例8输入数据
用例名称
输入数据
描述
外部合作伙伴管理一部分房产。
在典型悄况下，外部合作伙伴与本单位共同拥有房产——他们拥有房产的一部分，并负责维护和出租整个房产。
外部合作伙伴根据协议，按期向本单位提交数据和钱款。
本用例将外部合作伙伴提供的数据输入到系统存储，以供生成报表。
参与者
•外部合作伙伴
•经营经理
触发条件
外部合作伙伴按合同规定，定期提供数抑;。
在每个报表提交周期，外部合作伙伴都要准备数据并提交给本公司，从而触发本用例。
前提
外部合作伙伴和本公司已经签订协议。
基本事件过程
1.经营经理收到一组来自外部合作伙伴的数据，或有关数据已经生成的通知。
2.经营经理找到数据所对应的房产。
3.经营经理找到输入外部合作伙伴数据的区域。
4•系统询问外部数据的位置。
5・经营经理给出外部数据的位置。
6•系统检查数据对应的房产准确无误。
7•系统读取房产的以下数据：
a）対应日期的一系列现金金额；
b）对应日期的一系列资本支付。
8•系统将这部分信息与所给出的房产关联。
9•系统向经营就能够了显示所输入的数据供批准°
a）经营经理检查这些数据，批准或取消输入数据操作。
b）如果数据被批准，系统存储所输入的数据。
异常
5・如果系统不能找到或访问输入数据，则系统警告经营经理，并等待经营经理提供其他数据存放位置或取消操作。
6.如果数据没有对应所期望的房产，则系统警告经营经理，本用例结束。
后果
无
业务规则
无
技术需求
只支持一种数据转换方法。
这样可以降低系统的复杂性，减轻员工培训负担。
一个项U相关人员提出，外部合作伙伴拥有很少的技术和业务自治能力，并提出电子表格应该是合适的数据转换机制。
用例9建立现金流时间表
用例10交易记录
用例11处置房产
用例12建立资本时间表
用例13报告排名前5位的房产
用例14报告每个区域统计区的房产
升级会员 