案例one：教学管理系统（用例驱动的交互式需求获取）
以一个教学管理系统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. Use Case的获取
每一个USeCase都是一个参与者与系统在交互中执行的有关事务序列。应当根据用户需求描述，找出全部的USeCase，并从参与者的角度给出事件流，当USeCase执行时系统应提供给参与者的服务。
从JxGL的用户需求描述分析可的有以下用例存在:
(1)查询课程信息:学生、教师或教学管理员查询课程表，获得课程信息。
(2)选课注册:学生登录进行选课注册。
(3)管理开设课程:教学管理员登录系统产生选课信息，按照要求进行分类统计，生成选课注册报表。
(4)管理学生信息:教学管理员对学生数据进行录入、修改、删除等操作。
(5)管理老师信息:教学管理员对教师数据进行录入、修改、删除等操作。
(6)管理课程信息:教学管理员对课程数据进行录入、修改、删除等操作。
(7)查询学生成绩:学生、教师查询学生成绩。
(8)查询课程成绩:学生、教师查询课程成绩。
(9)学生成绩管理:教学管理员对学生考试成绩数据进行录入，修改、删除等操作。
(10)成绩统计:教学管理员对学生的考试成绩数据进行分类统计，生成成绩报表。
5.需求获取描述
（1）
（2）
（3）
（4）
（5）
（6）
（7）
6.导出
UseCase
案例Two：广东省水利厅办公业务资源系统
广东省水利厅办公业务资源系统是一个面向300多用户以及10多个部门日常业务流程的项目,由于系统牵涉的用户面和业务范围较广,系统的各种功能与用户的日常工作息息相关,因此做好系统需求分析显得至关重要。项目需求调研阶段,始终坚持“以用户为中心”,采取了有效、多样的方式与用户沟通,充分重视用户提出的每一项需求,并根据实际情况采用各种技术手段与用户进行沟通以最大限度获得需求。
(1)系统功能和性能需求分析
分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参考价值。经过研究分析,水利厅原有办公自动化系统存在几个突出的问题:
① 技术手段比较落后。
如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明
显下降;另一方面系统管理员的维护工作量很大,系统版本更新后需要重新更新
各客户端程序;
②系统的跨平台性和移植性差。
旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很大； ③工作流固化
用户实际流程与默认流程不符时需手工重新配置流程,导致系统推广应用难度大;
④可供办公使用的信息资源少。
基于以上分析,可得出新系统的功能和性能方面基本要求如下:
功能主要包括公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库等。
性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。 技术方面要求采用J2EE平台和关系型数据库(ORACLE)实现,基于B/S的三层体系结构进行设计。
(2)需求信息来源分析
通过对需求信息的来源进行分析,得出如下需求捕获计划(见表1)。
(3)需求分析技术的选用
用户调查。在直接与用户进行面对面交流前,先对旧系统用户作一个书面调查,收集他们对旧系统的使用体会以及对新系统最关心的功能需求,目的是在面对面进行用户访谈时提高需求分析人员提问的针对性和引导作用。《需求调研表》涉及的主要内容包括:用户使用频度最高的功能、旧系统设计存在的主要不足、对系统改进的建议等,调查对象为全体用户。通过收集用户的信息反馈表并进行归纳总结,得出以下几个结论:用户使用频率最高的模块主要是公文收发处理、内部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。
用户访谈。经过用户调查后,通过组织用户进行面对面访谈来达到细化系统需求的目的。访谈的对象主要是典型业务处室代表,如办公室负责文件收发的秘书、关键业务部门、技术部门的代表。进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题,如:公文收发的流程是怎样的(办公室代表回答)?在业务处室内部处理的流程是怎样的(业务处室代表回答)?系统界面的人性化方面有哪些要求(全体代表回答)?系统管理方面的需求是什么(技术部门代表回答)?参观考察。为了吸取兄弟单位同类项目的先进经验,开拓思路,组织用户到一些有成功案例和良好口碑的单位进行参观考察。通过参观考察,博取众长,将各单位有价值的好的经验和做法吸纳到本系统的建设需求中来。
(4)几种需求分析技术对比
①用户调查覆盖的面较广(涉及到本单位300多用户),不需要占用被访用户太多工作时间,容易被用户接受。但是由于某些用户对用户调查的重视程度不够,导致所反馈的信息不全面,参考价值有限,只能作为需求分析技术的一种参考和补充手段。
②用户访谈对于本系统需求分析是一种收效较好的技术手段。但是这种技术的使用对于
需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。在条件允许的情况下,应尽量采用这种技术。
③参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。 案例3：学院房产管理系统
1. 开发背景：
行政学院房地产管理系统是在金融体制改革的形势下，由行政学院信息技术部承担开发的，在成都市范围内进行房产投资和管理的应用系统。
系统的应用范围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来源，以及计算所有投资的回报情况的能力。该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理，也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。
2. 使用用例驱动获取需求：
（1） 确定系统的初始范围
第一步是考虑这个系统的大的范围。通过与项目有关人员（主要是用户）的大
量交流沟通，以及组织多次访谈会，首先根据系统的作用，用户的最基本要求
确定了系统的初始范围，如图18所示。
（2） 确定参与者
确定了三个参与者：经营经理、房产经理和外部合作伙伴。
1）经营经理：负责数据录入和数据维护。经营经理创建报表，以提供有关房产
的管理信息，并保证考虑到房产的日常问题。
2）房产经理：负责管理自己掌握的资金用于房地产投资。房产经理要确定准备
投资的各种类型的房地产项目。这种参与者主要关注投资所需的资本和投入的
资本与所产生的回报的比较。
3）外部合作伙伴：外部合作伙伴与房产经理起类似的作用，不过是在机构的外
部。外部合作伙伴参与房产，但是在很多方面可以斟酌决定。外部合作伙伴的
主要责任是保证投资产生回报，还需要向房产经理定期提供信息，包括现金流、对帐单和回报信息。
（3） 获取用户需求
与关键项目的相关人员一起，经过大量的分析讨论，确定了两个基本用例。
用例1管理投资
用例2汇总投资
此时，我们除了可能有外部房产经理参与者的远程访问需求之外，还没有提出紧迫的技
术需求，也没有得到业务规则。
通过项目相关人员的讨论，我们得到他们对系统提出的两个基本要求。
1） 根据用户的视点来设计本系统。
这是一项基本要求，我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。项目相关人员要求为其业务提供很强的会计支持，但是愿意将两个系统分开。帐本簿与房地产管理系统之间没有多少冗余数据，项目相关人员不愿意增加额外经费补充会计功能，或将两个系统数据集成起来。
2） 把系统看作是一种“数据采集与报表生成系统”。
关键是构建采集实现他们所定义的业务规则的数据的系统，既要使数据“安全”（不能
丢失或遗忘），又要为不同参与者提供专门化的视图，以便根据这些视图做出业务决策（例如，系统具有比较回报和投资的能力，要能够知道从出租的角度看，哪些房产在历史上没有得到充分的利用，哪些区域的出租率和回报率高）。
（4） 获取功能需求
下一步是充分与用户讨论，搜集尽可能多的有关各种参与者如何与系统交互的信息，以及他们需要通过系统获得什么样的信息。搜集这些信息的结果，我们可以将前面的用例进行进一步的扩展。
为了更好地表示用例，我们把用例图一分为三。如图19、20、21所示。
这里把用例由最初的两个扩展为20个。
用例3录入承租人详细信息
用例4录入投资详细信息
用例5录入房产详细信息
用例6建立单元
用例7出租房产
用例8输入数据
用例9建立现金流时间表
用例10交易记录
用例11处置房产
用例12建立资本时间表
用例13报告排名前5位的房产
用例14报告每个区域统计区的房产
用例15报告预期回报率
用例16报告房产状况
用例17报告房产使用情况
用例18报告每个区域统计区没有出租的房产
用例19报告将要到期的承租合同
用例20输入指数信息
用例21设置区域统计区
用例22设置用户
（5） 细化需求及用例求精
在完成填写用例模板最初工作之后，我们记录了需要解决的问题。我们把这个系统看作是数据采集和报表生成两个部分的观点基本没有改变。同时，我们发现报表生成的一个重要部分，即回报，可以通过更仔细地研究报表来提高收益。简单来说，回报数据要描述投资的执行情况。
房产经理通过回报计算，判定投资执行情况，并预测投资变更（例如：提高出租租金）会怎样影响投资的收益。内部回报率是完成这种任务的标准业务计算方法。我们把内部回报率定义为使所有现金流的净帐面值等于0的利率。过去，经营经理采用电子表格计算内部回报率。这是一种很浪费时间并且容易出错的过程，因为内部回报率的计算要使用投资周期内的所有现金流数据。为了出租一座大楼，要计算获得该房产所使用的最初资本和所有预期的出租租金。为此，在系统中增加计算功能是很有意义的。我们决定针对这种计算补充一个小用例，并计划将其“挂”在涉及这些数据的报表生成需求用例上。
用例23计算内部回报率
有了这个计算内部回报率用例的初稿，就可以考虑怎样将其融入到我们对需求的理解中了。这个时候我们避免确定系统如何按公式计算，只是非常概略地定义了公式，只告诉将使用这套需求的业务分析人员和程序员，为了理解这个公式，他们还需要做一些研究，进行细化，由其他人开发的算法最终都会完成这种计算。
下面考虑用例中隐含的需求，即每次使用时都要重新计算回报数据。
增强后的报表生成见图22。
与项目相关人员一起评审了当前的需求集之后，进一步深入研究了其中一些需求，例如针对区域统计区的技术需求，发现这种定期更新的以逗号作为分隔的数据存储格式的数据库可以订购。由于已有的回报指数要使用区域统计区，因此经理保证区域统计区数据的同步更新非常重要。于是提出自动输入区域统计区数据的新要求。进一步的讨论又发现，房产现有的区域统计区数据预期不会变更，因此不必考虑针对这种问题的自动化处理。
用例24输入区域统计区数据
到目前为止，需求已经达到了非常接近能够实现的程度。
案例one：教学管理系统（用例驱动的交互式需求获取）
以一个教学管理系统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. Use Case的获取
每一个USeCase都是一个参与者与系统在交互中执行的有关事务序列。应当根据用户需求描述，找出全部的USeCase，并从参与者的角度给出事件流，当USeCase执行时系统应提供给参与者的服务。
从JxGL的用户需求描述分析可的有以下用例存在:
(1)查询课程信息:学生、教师或教学管理员查询课程表，获得课程信息。
(2)选课注册:学生登录进行选课注册。
(3)管理开设课程:教学管理员登录系统产生选课信息，按照要求进行分类统计，生成选课注册报表。
(4)管理学生信息:教学管理员对学生数据进行录入、修改、删除等操作。
(5)管理老师信息:教学管理员对教师数据进行录入、修改、删除等操作。
(6)管理课程信息:教学管理员对课程数据进行录入、修改、删除等操作。
(7)查询学生成绩:学生、教师查询学生成绩。
(8)查询课程成绩:学生、教师查询课程成绩。
(9)学生成绩管理:教学管理员对学生考试成绩数据进行录入，修改、删除等操作。
(10)成绩统计:教学管理员对学生的考试成绩数据进行分类统计，生成成绩报表。
5.需求获取描述
（1）
（2）
（3）
（4）
（5）
（6）
（7）
6.导出
UseCase
案例Two：广东省水利厅办公业务资源系统
广东省水利厅办公业务资源系统是一个面向300多用户以及10多个部门日常业务流程的项目,由于系统牵涉的用户面和业务范围较广,系统的各种功能与用户的日常工作息息相关,因此做好系统需求分析显得至关重要。项目需求调研阶段,始终坚持“以用户为中心”,采取了有效、多样的方式与用户沟通,充分重视用户提出的每一项需求,并根据实际情况采用各种技术手段与用户进行沟通以最大限度获得需求。
(1)系统功能和性能需求分析
分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参考价值。经过研究分析,水利厅原有办公自动化系统存在几个突出的问题:
① 技术手段比较落后。
如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明
显下降;另一方面系统管理员的维护工作量很大,系统版本更新后需要重新更新
各客户端程序;
②系统的跨平台性和移植性差。
旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很大； ③工作流固化
用户实际流程与默认流程不符时需手工重新配置流程,导致系统推广应用难度大;
④可供办公使用的信息资源少。
基于以上分析,可得出新系统的功能和性能方面基本要求如下:
功能主要包括公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库等。
性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。 技术方面要求采用J2EE平台和关系型数据库(ORACLE)实现,基于B/S的三层体系结构进行设计。
(2)需求信息来源分析
通过对需求信息的来源进行分析,得出如下需求捕获计划(见表1)。
(3)需求分析技术的选用
用户调查。在直接与用户进行面对面交流前,先对旧系统用户作一个书面调查,收集他们对旧系统的使用体会以及对新系统最关心的功能需求,目的是在面对面进行用户访谈时提高需求分析人员提问的针对性和引导作用。《需求调研表》涉及的主要内容包括:用户使用频度最高的功能、旧系统设计存在的主要不足、对系统改进的建议等,调查对象为全体用户。通过收集用户的信息反馈表并进行归纳总结,得出以下几个结论:用户使用频率最高的模块主要是公文收发处理、内部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。
用户访谈。经过用户调查后,通过组织用户进行面对面访谈来达到细化系统需求的目的。访谈的对象主要是典型业务处室代表,如办公室负责文件收发的秘书、关键业务部门、技术部门的代表。进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题,如:公文收发的流程是怎样的(办公室代表回答)?在业务处室内部处理的流程是怎样的(业务处室代表回答)?系统界面的人性化方面有哪些要求(全体代表回答)?系统管理方面的需求是什么(技术部门代表回答)?参观考察。为了吸取兄弟单位同类项目的先进经验,开拓思路,组织用户到一些有成功案例和良好口碑的单位进行参观考察。通过参观考察,博取众长,将各单位有价值的好的经验和做法吸纳到本系统的建设需求中来。
(4)几种需求分析技术对比
①用户调查覆盖的面较广(涉及到本单位300多用户),不需要占用被访用户太多工作时间,容易被用户接受。但是由于某些用户对用户调查的重视程度不够,导致所反馈的信息不全面,参考价值有限,只能作为需求分析技术的一种参考和补充手段。
②用户访谈对于本系统需求分析是一种收效较好的技术手段。但是这种技术的使用对于
需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。在条件允许的情况下,应尽量采用这种技术。
③参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。 案例3：学院房产管理系统
1. 开发背景：
行政学院房地产管理系统是在金融体制改革的形势下，由行政学院信息技术部承担开发的，在成都市范围内进行房产投资和管理的应用系统。
系统的应用范围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来源，以及计算所有投资的回报情况的能力。该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理，也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。
2. 使用用例驱动获取需求：
（1） 确定系统的初始范围
第一步是考虑这个系统的大的范围。通过与项目有关人员（主要是用户）的大
量交流沟通，以及组织多次访谈会，首先根据系统的作用，用户的最基本要求
确定了系统的初始范围，如图18所示。
（2） 确定参与者
确定了三个参与者：经营经理、房产经理和外部合作伙伴。
1）经营经理：负责数据录入和数据维护。经营经理创建报表，以提供有关房产
的管理信息，并保证考虑到房产的日常问题。
2）房产经理：负责管理自己掌握的资金用于房地产投资。房产经理要确定准备
投资的各种类型的房地产项目。这种参与者主要关注投资所需的资本和投入的
资本与所产生的回报的比较。
3）外部合作伙伴：外部合作伙伴与房产经理起类似的作用，不过是在机构的外
部。外部合作伙伴参与房产，但是在很多方面可以斟酌决定。外部合作伙伴的
主要责任是保证投资产生回报，还需要向房产经理定期提供信息，包括现金流、对帐单和回报信息。
（3） 获取用户需求
与关键项目的相关人员一起，经过大量的分析讨论，确定了两个基本用例。
用例1管理投资
用例2汇总投资
此时，我们除了可能有外部房产经理参与者的远程访问需求之外，还没有提出紧迫的技
术需求，也没有得到业务规则。
通过项目相关人员的讨论，我们得到他们对系统提出的两个基本要求。
1） 根据用户的视点来设计本系统。
这是一项基本要求，我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。项目相关人员要求为其业务提供很强的会计支持，但是愿意将两个系统分开。帐本簿与房地产管理系统之间没有多少冗余数据，项目相关人员不愿意增加额外经费补充会计功能，或将两个系统数据集成起来。
2） 把系统看作是一种“数据采集与报表生成系统”。
关键是构建采集实现他们所定义的业务规则的数据的系统，既要使数据“安全”（不能
丢失或遗忘），又要为不同参与者提供专门化的视图，以便根据这些视图做出业务决策（例如，系统具有比较回报和投资的能力，要能够知道从出租的角度看，哪些房产在历史上没有得到充分的利用，哪些区域的出租率和回报率高）。
（4） 获取功能需求
下一步是充分与用户讨论，搜集尽可能多的有关各种参与者如何与系统交互的信息，以及他们需要通过系统获得什么样的信息。搜集这些信息的结果，我们可以将前面的用例进行进一步的扩展。
为了更好地表示用例，我们把用例图一分为三。如图19、20、21所示。
这里把用例由最初的两个扩展为20个。
用例3录入承租人详细信息
用例4录入投资详细信息
用例5录入房产详细信息
用例6建立单元
用例7出租房产
用例8输入数据
用例9建立现金流时间表
用例10交易记录
用例11处置房产
用例12建立资本时间表
用例13报告排名前5位的房产
用例14报告每个区域统计区的房产
用例15报告预期回报率
用例16报告房产状况
用例17报告房产使用情况
用例18报告每个区域统计区没有出租的房产
用例19报告将要到期的承租合同
用例20输入指数信息
用例21设置区域统计区
用例22设置用户
（5） 细化需求及用例求精
在完成填写用例模板最初工作之后，我们记录了需要解决的问题。我们把这个系统看作是数据采集和报表生成两个部分的观点基本没有改变。同时，我们发现报表生成的一个重要部分，即回报，可以通过更仔细地研究报表来提高收益。简单来说，回报数据要描述投资的执行情况。
房产经理通过回报计算，判定投资执行情况，并预测投资变更（例如：提高出租租金）会怎样影响投资的收益。内部回报率是完成这种任务的标准业务计算方法。我们把内部回报率定义为使所有现金流的净帐面值等于0的利率。过去，经营经理采用电子表格计算内部回报率。这是一种很浪费时间并且容易出错的过程，因为内部回报率的计算要使用投资周期内的所有现金流数据。为了出租一座大楼，要计算获得该房产所使用的最初资本和所有预期的出租租金。为此，在系统中增加计算功能是很有意义的。我们决定针对这种计算补充一个小用例，并计划将其“挂”在涉及这些数据的报表生成需求用例上。
用例23计算内部回报率
有了这个计算内部回报率用例的初稿，就可以考虑怎样将其融入到我们对需求的理解中了。这个时候我们避免确定系统如何按公式计算，只是非常概略地定义了公式，只告诉将使用这套需求的业务分析人员和程序员，为了理解这个公式，他们还需要做一些研究，进行细化，由其他人开发的算法最终都会完成这种计算。
下面考虑用例中隐含的需求，即每次使用时都要重新计算回报数据。
增强后的报表生成见图22。
与项目相关人员一起评审了当前的需求集之后，进一步深入研究了其中一些需求，例如针对区域统计区的技术需求，发现这种定期更新的以逗号作为分隔的数据存储格式的数据库可以订购。由于已有的回报指数要使用区域统计区，因此经理保证区域统计区数据的同步更新非常重要。于是提出自动输入区域统计区数据的新要求。进一步的讨论又发现，房产现有的区域统计区数据预期不会变更，因此不必考虑针对这种问题的自动化处理。
用例24输入区域统计区数据
到目前为止，需求已经达到了非常接近能够实现的程度。