软件需求分析报告(案例)

案例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 系统。 首先要确定业务需求和系统目标。教学管理系统 JxGL 用于新学期课程的选课注册管理 和学生的成绩管理。但凡这两方面的教学管理容都是JXGL系统的职责围，其他的教学管理 容，如安排教学计划、排课、实习、实验、考试等都不属于JXGL系统的职责围。至于学校 的其他管理工作，如科研、人事、财务、资产等管理不属于JXGL系统的职责围。 JXGL系统与财务系统存在系统边界，财务系统将从JXGL系统得到学生选课注册信息。 JXGL 系统与学校的其他信息管理系统没有直接的联系，但是可以从学校的全局数据库中共 享学生、教师、教学计划等必要的数据。 根据JXGL系统用户需求描述可以确定4个参与者:学生、教师、教学管理员和财务系统。 对于每一个参与者，应当明确其业务活动的容、对系统的服务要求。 “学生〞参与者使用 JXGL 系统查询新学期开设的课程信息和教师开课信息，选课并登 记注册课程，查询自己的课程成绩信息。 “教师〞参与者使用 JXGL 系统查询新学期开设的课程信息、学生选课信息和学生成绩 信息。 “教学管理员〃参与者使用JXGL系统管理学期开设的课程的选课注册和学生的考试成 绩。管理工作包括课程与成绩数据的录入、维护、统计、报表打印等，并且负责把学生的选 课注册信息发送给财务系统，作为计算学生应付费用的依据。 “教学管理员〃要求能够方便地查询课程信息、学生选课信息、学生信息、教师信息和 成绩信息。 “财务系统〃参与者是外部系统参与者，从JXGL系统承受学生的课程注册信息。 4. Use Case的获取 每一个USeCase都是一个参与者与系统在交互中执行的有关事务序列。应当根据用户需 求描述，找出全部的USeCase，并从参与者的角度给出事件流，当USeCase执行时系统应提 供应参与者的服务。 从JxGL的用户需求描述分析可的有以下用例存在： (1) 查询课程信息:学生、教师或教学管理员查询课程表，获得课程信息。 (2 )选课注册:学生登录进展选课注册。 (3) 管理开设课程:教学管理员登录系统产生选课信息，按照要求进展分类统计，生成选 课注册报表。 (4) 管理学生信息:教学管理员对学生数据进展录入、修改、删除等操作。 (5) 管理教师信息:教学管理员对教师数据进展录入、修改、删除等操作。 (6) 管理课程信息:教学管理员对课程数据进展录入、修改、删除等操作。 (7) 查询学生成绩:学生、教师查询学生成绩。 (8) 查询课程成绩:学生、教师查询课程成绩。 (9) 学生成绩管理:教学管理员对学生考试成绩数据进展录入，修改、删除等操作。 (10) 成绩统计:教学管理员对学生的考试成绩数据进展分类统计，生成成绩报表。 川尸需求描述 录入肖牛咸新学期课理应 用例名 管理课程信息 期側描述 我学曾理员对课程数据琲打入、修谀、JW除尊撫柞。 主Eictor 數学営理员 前置条也 老师己悔新学期所幵湮程数咼上报 1 成功方置条件 核学管理员、学生和教师可以在网络上进行课程的相关操柞 学生和她在网路上无崔我知课程数蒲 黄联用侧 杳询课捏信息.簪理开设课產 用尸需求描述 沅生选课注册 一 II 4例名 选滦注册 用例描第 学主登录进钎选谍注册" ! 卞娈mwt 学生 逋知学生在网上进行选礫注册 成功肩覽茶件 数学醤理员、悦土和救师可以在网绍上进行训程的相关操件 天收厉遇条件 学左和教师在网络上无袪號知谍程数据 英联用例 査询课程信息，營理开设课程 用户需我描述4 査询 用恻名 杳询课程惜息 用例描述 学叩，教帅我戟学订理员責询课瑕蔻・获得谏程信息* 1 1 卞3c actor 学上、敕师和教学胃理员 1 前连条怦 教学管理员将课程信息土传至网堵 .廢功肩过築托 姿二 换或按密理员准确获魁课程1青啟 失败后3S条杵 系统提示課程叛据库曲现故障 关联用例 背理开设课程、皆理课程信息 用户需求描述 1选课注册信息的统计与报表生成 ' : |用例名 管理开设课程 -1 刑例描述 教学營理员豎录系统产生选课信息，按照要求进行分类统计，生感选课1 注册报表. | 卞翌 actor 1 教学裁理员 学员C完成了逸滦注册 成功后置条件 按要讖进和:分类统计寸生成选煉注册掘表" 规后置条件 罐课注删信息有瓯 无法生成損議 1左联恤 逸课注册 1 用户需求描述 LB 1 ■ "J ■ 1* ~~1 教学骨理员录入学生戒绩 川例樓 学生成绩管理 川例捕述 教学骨理员对学生考试成绩数据进行渤入.條改、删除尊操柞。 主要actur 教甞管理员 询边条件 学员考试结束并口阅卷宪成r学员成绩縮耍以墩据库记录 成功后置峯件 教学管理员、学生和教师可以餌绪上进行学生成绩敢相关携世 冀败厉置条件 学主村教师代网络上无法荻取学生咸绩 关既用例 学牛成绩營理、成绩统计、査询学主成坝、蒼询课程咸航 用例描述■ 学多、教师責询学主施绩. | ］主要actor 学生、菽师 施負条件.. 堂生成绩以数据库记理并上僅至題彗 康功后置条件 依藐学生笔、课程名、段课教那名、学分咯等关擁词查询苦试成绩 先敗后置条件 服务黔处丁维护中 |关联口例 学生戍绩营理 _ 一 I ||用例乞 阳广需求描述 齊'阉成绩 査询学生成绩 学生 选课注册 财务聚统 阳户需求描述 成绩统计打报表生成 用例容 感绩轨计 用例描塗. 教学管理员对学生的垮试成绩数据进疔分类统计+生成成绩报哀- 1 主要actor 教学管理员 前置条杵 学1:成绩以数据庫記录井上传至服务器 1 成功后査条件1 教学暂理员进彳亍成绩统计（按课程、学主、按班级｝,打叩成绩兀总统计1 报我。 1 贵败后置条件 . 服务器址丁维护中 关IO例 1 ■ I. ■ ■专 孑生虑绩管理 案例Two：省水利厅办公业务资源系统 省水利厅办公业务资源系统是一个面向300多用户以与10多个部门日常业务流程的项 目，由于系统牵涉的用户面和业务围较广，系统的各种功能与用户的日常工作息息相关，因此 做好系统需求分析显得至关重要。项目需求调研阶段始终坚持“以用户为中心〃，采取了有 效、多样的方式与用户沟通，充分重视用户提出的每一项需求，并根据实际情况采用各种技术 手段与用户进展沟通以最大限度获得需求。 ⑴系统功能和性能需求分析 分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参 考价值。经过研究分析，水利厅原有办公自动化系统存在几个突出的问题： 技术手段比拟落后。 如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明 显下降;另一方面系统管理员的维护工作量很大，系统版本更新后需要重新更新 各客户端程序； ② 系统的跨平台性和移植性差。 旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很大； ③ 工作流固化 用户实际流程与默认流程不符时需手工重新配置流程导致系统推广应用难度大； ④ 可供办公使用的信息资源少。 基于以上分析，可得出新系统的功能和性能方面根本要求如下： 功能主要包括公文处理子系统、部电子、机关事务管理子系统、业务资源库等。 性能与约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。 技术方面要求采用J2EE平台和关系型数据库（ORACLE）实现，基于B/S的三层体系结 构进展设计。 （2）需求信息来源分析 通过对需求信息的来源进展分析，得出如下需求捕获计划（见表1）。 表1需求捕获计划 崽得到购蛊求信息 荘取蛊求的1叮能逮径 旧系统川保留和绻承的」 旧命统叩朮分折报吿J日系统用户 新系统应満川加泊心储和1 = 新系统潜住的用户■技术人员自身 司类系统应功秦例订吸纳心做 怯和经验 参观和石察司类系统一佶鉴好忙经 （3） 需求分析技术的选用 用户调查。在直接与用户进展面对面交流前，先对旧系统用户作一个书面调查，收集他们 对旧系统的使用体会以与对新系统最关心的功能需求，目的是在面对面进展用户访谈时提高 需求分析人员提问的针对性和引导作用。《需求调研表》涉与的主要容包括用户使用频度最 高的功能、旧系统设计存在的主要不足、对系统改良的建议等,调查对象为全体用户。通过 收集用户的信息反应表并进展归纳总结，得出以下几个结论:用户使用频率最高的模块主要是 公文收发处理、部电子、公告发布;旧系统最大的不足主要集中在系统界面不够友好、系统 响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。 用户访谈。经过用户调查后，通过组织用户进展面对面访谈来达到细化系统需求的目的。 访谈的对象主要是典型业务处室代表，如办公室负责文件收发的秘书、关键业务部门、技术 部门的代表。进展访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题如:公 文收发的流程是怎样的（办公室代表回答）?在业务处室部处理的流程是怎样的（业务处室代表 回答）?系统界面的人性化方面有哪些要求（全体代表回答）?系统管理方面的需什么（技术部门 代表回答）?参观考察。为了吸取兄弟单位同类项目的先进经验，开拓思路，组织用户到一些有 成功案例和良好口碑的单位进展参观考察。通过参观考察博取众长，将各单位有价值的好的 经验和做法吸纳到本系统的建设需求中来。 （4） 几种需求分析技术比照 ① 用户调查覆盖的面较广（涉与到本单位300多用户），不需要占用被访用户太多工作时 间，容易被用户承受。但是由于某些用户对用户调查的重视程度不够，导致所反应的信息不全 面，参考价值有限,只能作为需求分析技术的一种参考和补充手段。 ② 用户访谈对于本系统需求分析是一种收效较好的技术手段。但是这种技术的使用对于 需求分析人员来说有较高要求，如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访 对象均有空的时间较难。在条件允许的情况下，应尽量采用这种技术。 ③ 参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。 案例3：学院房产管理系统 1. 开发背景： 行政学院房地产管理系统是在金融体制改革的形势下，由行政学院信息技术部承当 开发的，在市围进展房产投资和管理的应用系统。 系统的应用围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的来 源，以与计算所有投资的回报情况的能力。该系统不仅使这些资产可以像管理固定收入 有价证券组合一样被管理，也为学校领导层提供了监控资金流量与流向并与时做出相应 决策的现代化手段。 2. 使用用例驱动获取需求： (1) 确定系统的初始围 第一步是考虑这个系统的大的围。通过与项目有关人员〔主要是用户〕的大量 交流沟通，以与组织屡次访谈会，首先根据系统的作用，用户的最根本要求确 定了系统的初始围，如图18所示。 图18系锐的初始范围 (2) 确定参与者 确定了三个参与者：经营经理、房产经理和外部合作伙伴。 1〕经营经理：负责数据录入和数据维护。经营经理创建报表，以提供有关房产 的管理信息，并保证考虑到房产的日常问题。 2〕房产经理：负责管理自己掌握的资金用于房地产投资。房产经理要确定准备 投资的各种类型的房地产项目。这种参与者主要关注投资所需的资本和投入的 资本与所产生的回报的比拟。 3〕外部合作伙伴：外部合作伙伴与房产经理起类似的作用，不过是在机构的外 部。外部合作伙伴参与房产，但是在很多方面可以斟酌决定。外部合作伙伴的 主要责任是保证投资产生回报，还需要向房产经理定期提供信息，包括现金流、 对帐单和回报信息。 (3) 获取用户需求 与关键项目的相关人员一起，经过大量的分析讨论，确定了两个根本用例。 用例1管理投资 川例名称 管理投资 描述 跟踪公诃所扭资朋产的基本属性，房产承租人的信息和租期。 参与者 •经营经理 •房产经理 •外部合件伙伴 触发条件 房产、叼产承和人或租期发生变化。 前提 分类表和实它数据已经进入系统= 基本事件过稈 1. 3荻取…处房产时: 畀 录入投资「房产》1-勺诽细信息。 b） 确疋房产的资本委托事项。 c） 将房产划分为一个或多个单元。 2. 省找到房产单元的承和人时: 3）录入承租人订:细信息c b） 确定承租条款第 c） 确定承租人付款时间表。 d） 将这个房产单元耳该承和人关联。 3. 当房产售出时: a） 记录销售细仏 b） 与房产的所有承租人脱离关联. C）删除对该房产的所有未来资本投入。 d）从时间表中删除所冇未来现金沆° 4. 当到达租期时: a） 将房产单元与承租人脱离关系，使其可确定新的fiSJJ， b） 删除与该承粗人关联的所有未来现金流， 异常 h i果 无 用例2汇总投资 用例名称 汇总投资 描述 扌巴已经存储的数据整理为殳持业务运营fl 1决策的-纽报表* 参与者 •经营经理 •房产经理 触发条件 • 房产经理主哄以临吋确定的方式使用报农以做出务种决策。 •经营经理定期使用报表支持业务运营。 前捉 •投密和房产部门已经把详细信息录入到系统中。 • 系统必须为那些依赖已有外部数据的报表获収来自外部的 数据。 棊本事件过程 1. 系统显示已有报表清单，包括： 3）运营表 i. 未来n个月内到刚的承租合同。 ii. 房产使用情况。 iii. 每个区域未承租的单元。 b）房产经理报表 i. 于贝剔回报率。 ii. 排名前5位的房产。 iii. 每个区域的房产. iv. 房产状况。 这里只列表了目前垠重要的报表，而不是穷尽所有报表清单。 2. 参与者选择报表。 3. 系统提示参与者输入细化报表的详细信息，包括报表日期。 4. 系统检索数拯，执行计算导岀没有存储的数据，对申请排序° 5. 系统准备提供提交的报表，包括报表的外观和交付格式，包 括打印格式和屏幕格式。 异常 X 后果 系流不会根据报表上成1®改业务数据。 此时，我们除了可能有外部房产经理参与者的远程访问需求之外，还没有提出紧迫的技 术需求，也没有得到业务规如此。 通过项目相关人员的讨论，我们得到他们对系统提出的两个根本要求。 1） 根据用户的视点来设计本系统。 这是一项根本要求，我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。 项目相关人员要求为其业务提供很强的会计支持，但是愿意将两个系统分开。帐本簿与 房地产管理系统之间没有多少冗余数据，项目相关人员不愿意增加额外经费补充会计功 能,或将两个系统数据集成起来。 2） 把系统看作是一种“数据采集与报表生成系统〃。 关键是构建采集实现他们所定义的业务规如此的数据的系统，既要使数据“安全〃〔不 能丢失或遗忘〕又要为不同参与者提供专门化的视图，以便根据这些视图做出业务决 策〔例如，系统具有比拟回报和投资的能力，要能够知道从出租的角度看，哪些房产在 历史上没有得到充分的利用，哪些区域的出租率和回报率高〕 （4） 获取功能需求 下一步是充分与用户讨论，搜集尽可能多的有关各种参与者如何与系统交互的信息，以 与他们需要通过系统获得什么样的信息。搜集这些信息的结果，我们可以将前面的用例 进展进一步的扩展。 为了更好地表示用例，我们把用例图一分为三。如图19、20、21所示。 这里把用例由最初的两个扩展为20个。 用例3录入承租人详细信息 川例名称 录入承租人详细信息 描述 房地产管理系统跟踪谁在承租房产,系统存储⑪个承租人的- 套详细倍息,以记帐、跑踪和检査状况* 参与者 经营经理 触发条件 •发现承租房产的新承租人或潜在承租人。本用例可以由”出 租房产”用例来启动。 •发规规有承租人的补充或变更倍息。 前提 无 基本事件过程 K经营经理找到承租人区域。 2.经营经理录入承租人的标识倍息: a） 个人承和人的姓名和身份证号码p b） 机构.承班人世公丸杯称和税务登记订号© 3”乐统捡查现冇从配顶. 4. 系统显下已经填写J'现有信息的数据录入模板。个人承租人 和机构承租人的模板不同. ＜需要补充插入斯需数据项的清单＞ 5. 经营经理录入每个数据项。 6”系统根据数据录入规则（k［期、身份E：等［检骑录入的数据。 7+如果经营经理对所录入的数据感到满意，则提交数据变更。 &系统检查肿处入数■推是否匸整© 9”如果通过检曲 则系统存储所做的数据变更，该承和人彼标 记为有效。 异常 3.如果系统发现重复项，则对参与者发出警告•井显示现有承 租人记录。 7.如果参与者对所做的数据变更不满意，可以选拝竝笄所做变 更。血果系统中有以前存储的记录,则恢复以前存储的记录。 &如果没有输入要求必须输入的数据，系统对参与者发出警甘， 并解释哪些数据必须录入。如果该承粗人是当前承粗合同签订 人（即抑有尚未到期的承租合同的泳相人），幷且系统不接收数 拥变更，则辽公导致该承和人先去有效状态「 h i果 如果数据是完备的、有效的*系统拥有一个有效的承租人。 业务规则 ＜»入字段和*格级的详细检验规则、 技术需求 • 木功能只在左办公室内使用.经营经理不在其他地方办公。 •承租人所需的数据集过去已经变更过名欢•房产经理要求蔡 统具有补充或删除有关承和人的苴接或导川数据的灵活性。 •预期一次只有一个人更新承租人数据,系统不需要支持承租 人信息的同时更新。 •系统应该存储对承租人信息变更的所有肪史,包括进行变更 的参与者标识,以及变更H期和时间° 用例4录入投资详细信息 用例5录入房产详细信息 用例6建立单元 用例7出租房产 用例8输入数据 川例名称 输入数据 描述 外部合作伙伴管理一部分房产。在典型情况下*外部合作伙样 与本单位共同拥有房产——他们拥有房产的一部分，井負责维 护和出租整个房产"外部合作伙伴根据协议，按期向本单位提 交数据和钱款。本用例将外部合作伙伴提供的数据输入到系统 仆储，以供上成报長， 参与者 •外部合作伙伴 •经莒经理 触发条件 外部合作伙伴按合同规定，定期提供数据。在毎个报表提交周 期,外部合作伙伴都要准备数据并提交给本公叭从而触发本 川例‘ li惯 外部存作伙伴和本公N'J匚缗签订协乩 基本事件过程 1. 经营经理收到一组来自外部合作伙伴的数据，或有关数据已 经生成的1SSIU 2. 经营经理找到数据所对应的房产. 3 .经营经理找到输入外部合作伙伴数据的区域* 4”系统训河外部数振的位置© 5. 经营经理给出外部数据的位置。 6. 系统检查数据对应的房产准确无i也 7. 系统读取房产的以下数据： 3）对应H期並啄列现金金额： b）对明丨期11勺-系列资本支■付： 8”系轨将这部分信息与所给出的房产关联。 9.系统向经营就能够了显示所输入的数据供批准。 3）经营经理检查这些数据，批准或取消输入数据操作。 b）如果敎据被批艇 系统仔储所饰入的数据。 异常 5.如果系统不能找到或访问输入数据，则系统警告经营经理， 井等i畑?经理提供其他数据存放位置或収消操作。 6”如果数据没有对应所期望的房产.则系统警告经营经理,本 川例结束。 h i果 无 业务规则 无 技术需求 只支持一科数据转换方法。这样可以降低系统的复杂性・减轻 员工培训负担。一个项目相关人员提出，外部合作伙伴拥有很 少的技术和业务自治能力,井提出电子表格应该是合适的数据 转换机制。 用例9建立现金流时间表 用例10交易记录 用例11处置房产 用例12建立资本时间表 用例13报告排名前5位的房产 用例14报告每个区域统计区的房产 用例15报告预期回报率 用例名称 报告预期回报率 描述 本报表给岀房产的预期内部回报率。如果可以得到交易数据， 则使用实际现金流，否则使用现金流时间表。内部回报率按房 产的整个寿侖期计算。 参与者 .房产经理 触发条件 “创建报表”用例 前握 尢 基木事件过程 1. 系统提示用户输入报表的亶指定打日期. 2. 系统提示房产蚪理从列表中选择房产。 3. 系统计算内部回报率和以下数据”并准备报表: a） 房产名称。 b） 房产的川始bl期。 c） 内卅冋报率。 （1）资本支山总和： e） 和仝总和匸 f） 逐H记录的交易数拡 H常 h i果 生成“指定”期的报表。 业窑规则 技术需求 用例16报告房产状况 用例17报告房产使用情况 用例18报告每个区域统计区没有出租的房产 用例19报告将要到期的承租合同 用例20输入指数信息 用例21设置区域统计区 用例22设置用户 （5） 细化需求与用例求精 在完成填写用例模板最初工作之后，我们记录了需要解决的问题。我们把这个系统看作 是数据采集和报表生成两个局部的观点根本没有改变。同时，我们发现报表生成的一个重要 局部，即回报，可以通过更仔细地研究报表来提高收益。简单来说，回报数据要描述投资的 执行情况。 房产经理通过回报计算，判定投资执行情况，并预测投资变更〔例如：提高出租租金〕 会怎样影响投资的收益。部回报率是完成这种任务的标准业务计算方法。我们把部回报率定 义为使所有现金流的净帐面值等于0的利率。过去，经营经理采用电子表格计算部回报率。 这是一种很浪费时间并且容易出错的过程，因为部回报率的计算要使用投资周期的所有现金 流数据。为了出租一座大楼，要计算获得该房产所使用的最初资本和所有预期的出租租金。 为此，在系统中增加计算功能是很有意义的。我们决定针对这种计算补充一个小用例，并计 划将其“挂〃在涉与这些数据的报表生成需求用例上。 用例23计算部回报率 用例轩称 计算内部回报率 描述 内部回报率是一种基于定期发生的现金流的标准业务计算，可 以用来描述投资冋报率（嗚人 这种计算要被多个抠表使用" 参与者 JR表工成用例 触发条件 准备生成有关内部回报率的报表。 前提 要完成本计算,必须具有一组现金诡,至少包含一个负的现金 棊本事件过程 k系统检査是否有所需数据。 a） 序列中的第…个现金流必须是负值’ b） 现金流必须是一个定期序列（即每片“周、年或类似时间 周期取一亍值人 ©）痢存yUI嗷振的苴他-竖他lih这些限血良有Y專序员仮 计人员对公式进行分析以避免出现“被0除错误胖比,才能U 1 纳岀来。 2.系统按公式计算，并返回计算结果。 2.如来系统不能完成计算，则返回冷Error役 后果 系统拒绝现金流\返回一个错误或返回内部回报率* 业务规则 从本公司到外部的现金流是负值，从外部到本公司的现金流， 例如租金支付，足正：值。 技术需求 报表生成所需时间不能超过1分钟* 有了这个计算部回报率用例的初稿，就可以考虑怎样将其融入到我们对需求的理解中 了。这个时候我们防止确定系统如何按公式计算，只是非常概略地定义了公式，只告诉将使 用这套需求的业务分析人员和程序员，为了理解这个公式，他们还需要做一些研究，进展细 化，由其他人开发的算法最终都会完成这种计算。 下面考虑用例中隐含的需求，即每次使用时都要重新计算回报数据。 增强后的报表生成见图22。 闻22增强鞋的报衣牛.成 与项目相关人员一起评审了当前的需求集之后，进一步深入研究了其中一些需求，例如 针对区域统计区的技术需求，发现这种定期更新的以逗号作为分隔的数据存储格式的数据库 可以订购。由于已有的回报指数要使用区域统计区，因此经理保证区域统计区数据的同步更 新非常重要。于是提出自动输入区域统计区数据的新要求。进一步的讨论又发现，房产现有 的区域统计区数据预期不会变更，因此不必考虑针对这种问题的自动化处理。 用例24输入区域统计区数据 用例名称 输入区域统计区数据 描述 区域统计区数据定义成都的地理区域,类似」j}&都的区县划分 那样的概念。区域统计区对根据馬产位置预测房地产投资的收 益非常重要.本系统跟踪每处房产的区域统计区数据*需要使 这些数据与成都巾邮政局公布的数据保持h d步更新= 釦湘 经营经理 触发条件 收集到新的数拐集。 | 前提 无 基本事件过程 1+经营经理装入包含C刖文件的介质。 2. 经营经理找到維护成域，从系统提供的列表中选择曲装裁区 域统计X数据S 3. 系轨提示轻营经理给姑csv文件的位置和名称。 4”系统朮取该文件，井对文件内衿进行检验。 5.系铳创遂现有区域统计境数据集的一个备份， &系统把数据从csv文件拷贝到系统的数据存储凶。 7.系统检査系统屮房严所使用的所有区域统计区数据都描向有 效的区城统计区。 异常 7,如呆呆处房产的区域统讣区数据没有在新的数据集中，则系 统瞥告参与者，并标识受廳响的房产和区域统计区。经营经理 要研究这个问题，如果有必要，曲受彥响的房产输入新的轻域 统计区数据. A |果 •系统包含已经更新过的区域统计区数据。 •系统中所有已有的房产都指向有效的区域统计区数据。 业务规则 技术需求 到目前为止，需求已经达到了非常接近能够实现的程度。