软件需求分析案例word文档良心出品.docx

上传人:b****6 文档编号:13850410 上传时间:2023-06-18 格式:DOCX 页数:29 大小:217.60KB
下载 相关 举报
软件需求分析案例word文档良心出品.docx_第1页
第1页 / 共29页
软件需求分析案例word文档良心出品.docx_第2页
第2页 / 共29页
软件需求分析案例word文档良心出品.docx_第3页
第3页 / 共29页
软件需求分析案例word文档良心出品.docx_第4页
第4页 / 共29页
软件需求分析案例word文档良心出品.docx_第5页
第5页 / 共29页
软件需求分析案例word文档良心出品.docx_第6页
第6页 / 共29页
软件需求分析案例word文档良心出品.docx_第7页
第7页 / 共29页
软件需求分析案例word文档良心出品.docx_第8页
第8页 / 共29页
软件需求分析案例word文档良心出品.docx_第9页
第9页 / 共29页
软件需求分析案例word文档良心出品.docx_第10页
第10页 / 共29页
软件需求分析案例word文档良心出品.docx_第11页
第11页 / 共29页
软件需求分析案例word文档良心出品.docx_第12页
第12页 / 共29页
软件需求分析案例word文档良心出品.docx_第13页
第13页 / 共29页
软件需求分析案例word文档良心出品.docx_第14页
第14页 / 共29页
软件需求分析案例word文档良心出品.docx_第15页
第15页 / 共29页
软件需求分析案例word文档良心出品.docx_第16页
第16页 / 共29页
软件需求分析案例word文档良心出品.docx_第17页
第17页 / 共29页
软件需求分析案例word文档良心出品.docx_第18页
第18页 / 共29页
软件需求分析案例word文档良心出品.docx_第19页
第19页 / 共29页
软件需求分析案例word文档良心出品.docx_第20页
第20页 / 共29页
亲,该文档总共29页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

软件需求分析案例word文档良心出品.docx

《软件需求分析案例word文档良心出品.docx》由会员分享,可在线阅读,更多相关《软件需求分析案例word文档良心出品.docx(29页珍藏版)》请在冰点文库上搜索。

软件需求分析案例word文档良心出品.docx

软件需求分析案例word文档良心出品

 

案例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系统的应用服务器和数据库服务器设置在学校计算中心的工作站。

学生、教师和教学管理员可以在各系、各部门、使用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)

用严需求描述

诫入与4咸新学期课稈丧

用例名

管理课程信息

用例描述

教学管理员对课胃数据进疔朮入.修改.删除第操作•

上耍actor

ft学社理员

前a条件

老师已将新学期所开课数据上报

锻功后S条件

教学®理员、学生利教师可以在网络上进行课程的相关操作

失败石置条件

学生和教师在网络上无法获知®程数据

关联用例

玄询课畀倍息*骨理开设课棵

 

用户需求描述

学生选课注册

用例名

选课注册

W例描述

学宅^^录进荷选课注册.

上翌ftctor

学生

前S条件

通知学生在网匕进行选课注册

成功肩胃条件

«子箭理员、学生利ft师可W在网络上进疔课程的相关操作

失败眉置条件

主和教师在网绪上无法获知课程数据

关联用例

杳询课秤信息、管理开设课程

用户需求描述

杵询

出例名

斤询w程信恵

IU例描述

■7^生、»帅或8学廿理a資询课程表,茯得课丹信息.

 

卞耍actor

学生、»締和教学e理员

前S条fi

教学管理员将课程信息上幘至网络

成功麻a策杵

学生,教师或教学管理员准确获得课再信息・

失败后a条件

系统提示课程数据库di现故障

关联用例

營理开设课稈.管理谍ft信息

 

(4)

用户需求描述

选课注册時息的统计与报表主成

用例名

管理开设慄程

用例描述

教学管理员ffi录杀统产生选课信息,按照要求进行分类统计.生成选课注册根表*

卞factor

教学管理员

®置鐫件

学员匕完成了选课注册

成功后S条件

按耍求进行分类统计•生成选课注册擢表.

失败侨s盖件

选课注册信息有溟’无法4成报表

黄联用例

选课注册

 

用户需求描述

S学管理a录入学生成绩

用例名

学生成绩&理

用例轴述

教学管理员对学生考试成绩数据进行求入,修改、删除筹操作。

主要actor

教子管理员

前逬条ft

学员考试结束并且阅卷丸成,学员成绩需要叹数据痒记录

成功拆国条杵

«学管理S、学生和ft师町以在网络上进行学生成绩的梱关操作

矢败厉宙条件

AJM:

•和教师在网络上无法获XX学生成绩

灾联用例

学生成绒理,成绩统计,査洶学生成绩、俺洵课理成绩

(6)

用户需求担述

贪询成绩

出例名

青询学i成绩

 

用例描述

学乜教师斎询学住成绩-

主要actor

孑生、教師

ms条件

学生成绩以数攜库记录井上传至服养S

成功质置条f[

嵌据学生名、课耗名、投课»师名.学分名等关«词S询考试成绩

失败显宜条仲

ffi务器赴丁维护中

关联川例

学生城绩肓理

(7)

 

用户需求描述

成绩统计与报表生应

出例名

锻绩喷计

用例描述

救学管理员对学生《耆试雀绩数抵进行分类统计’生锻成绩报我.

主Sac1or

教学»理员

前S条ft

学i成绩以数据廉记录并上传至服务器

咸功斥jg条件

教学管理员进存成绩统计(按课程.学生,按班级人打印成绩汇总统计

报我・

火賊麻置条仲

服务器处于维护中

英联由例

学生成绩管理

6.导出UseCase

 

資询课稈成绩

 

案例Two:

广东省水利厅办公业务资源系统

广东省水利厅办公业务资源系统是一个面向300多用户以及10多个部门日常业务流程

的项目,由于系统牵涉的用户面和业务范围较广,系统的各种功能与用户的日常工作息息相关

因此做好系统需求分析显得至关重要。

项目需求调研阶段,始终坚持“以用户为中心”,采取

了有效、多样的方式与用户沟通,充分重视用户提出的每一项需求,并根据实际情况采用各种

技术手段与用户进行沟通以最大限度获得需求。

(1)系统功能和性能需求分析

分析总结旧系统功能和性能方面存在的问题和缺陷对于获取新系统的需求具有很大参考价值。

经过研究分析,水利厅原有办公自动化系统存在几个突出的问题:

技术手段比较落后。

如采用C/S的模式一方面随着用户量增加导致服务器负载过高,服务器性能明

显下降;另一方面系统管理员的维护工作量很大,系统版本更新后需要重新更新

各客户端程序;

2系统的跨平台性和移植性差。

旧系统是基于NET平台开发,未来想移植到LINUX或者UNIX操作系统上困难很大;

3

导致系统推广应用难度大

工作流固化用户实际流程与默认流程不符时需手工重新配置流程

4可供办公使用的信息资源少。

基于以上分析,可得出新系统的功能和性能方面基本要求如下

功能主要包括公文处理子系统、内部电子邮件、机关事务管理子系统、业务资源库

等。

性能及约束条件方面要求主要包括跨平台性、易维护性、稳定性、响应速度等。

技术方面要求采用J2EE平台和关系型数据库(ORACLE实现,基于B/S的三层体系结构进行设计。

(2)需求信息来源分析通过对需求信息的来源进行分析,得出如下需求捕获计划(见表1)。

表1需求捕菠计划

迪时到們斋求倚息

快取紺求的nj能途禅

IH奈统N保齢和讎承的功能

IH築统需求分析报告.1H条统用户

新系统应新增加的功能和IE功

新系统潜在的用门.技术人员I'l耶

的跨验

同类^^统成功案例可吸納的融

辱观和曲案同类眾统”僅鉴好的经验

(3)需求分析技术的选用

用户调查。

在直接与用户进行面对面交流前,先对旧系统用户作一个书面调查,收集他们

对旧系统的使用体会以及对新系统最关心的功能需求,目的是在面对面进行用户访谈时提高

需求分析人员提问的针对性和引导作用。

《需求调研表》涉及的主要内容包括:

用户使用频度

最高的功能、旧系统设计存在的主要不足、对系统改进的建议等,调查对象为全体用户。

过收集用户的信息反馈表并进行归纳总结,得出以下几个结论:

用户使用频率最高的模块主要

是公文收发处理、内部电子邮件、公告发布;旧系统最大的不足主要集中在系统界面不够友

好、系统响应速度越来越慢、流程设计不灵活、系统可供办公参考的资料较少等几个方面。

用户访谈。

经过用户调查后,通过组织用户进行面对面访谈来达到细化系统需求的目的。

访谈的对象主要是典型业务处室代表,如办公室负责文件收发的秘书、关键业务部门、技术

部门的代表。

进行访谈前要根据用户调查的结果设计一些有针对性和引导作用的问题,如:

文收发的流程是怎样的(办公室代表回答)?

在业务处室内部处理的流程是怎样的(业务处室代

表回答)?

系统界面的人性化方面有哪些要求(全体代表回答)?

系统管理方面的需求是什么(技术部门代表回答)?

参观考察。

为了吸取兄弟单位同类项目的先进经验,开拓思路,组织用户到

一些有成功案例和良好口碑的单位进行参观考察。

通过参观考察,博取众长,将各单位有价值

的好的经验和做法吸纳到本系统的建设需求中来。

(4)几种需求分析技术对比

1用户调查覆盖的面较广(涉及到本单位300多用户),不需要占用被访用户太多工作时

间,容易被用户接受。

但是由于某些用户对用户调查的重视程度不够,导致所反馈的信息不全

面,参考价值有限,只能作为需求分析技术的一种参考和补充手段。

2

但是这种技术的使用对于

用户访谈对于本系统需求分析是一种收效较好的技术手段。

需求分析人员来说有较高要求,如谈话技巧、领域的知识面等;另一方面寻找一个各关键被访对象均有空的时间较难。

在条件允许的情况下,应尽量采用这种技术。

3参观考察对系统需求获取可以起到画龙点睛、开阔用户思路、取长补短的效果。

案例3:

学院房产管理系统

1.开发背景:

由行政学院信息技术部承担

行政学院房地产管理系统是在金融体制改革的形势下,

开发的,在成都市范围内进行房产投资和管理的应用系统。

系统的应用范围包括跟踪资本的分配和划拨、所产生的资产现金流和这些现金流的

来源,以及计算所有投资的回报情况的能力。

该系统不仅使这些资产可以像管理固定收入有价证券组合一样被管理,也为学校领导层提供了监控资金流量与流向并及时做出相应决策的现代化手段。

2.使用用例驱动获取需求:

(1)确定系统的初始范围第一步是考虑这个系统的大的范围。

通过与项目有关人员(主要是用户)的大量交流沟通,以及组织多次访谈会,首先根据系统的作用,用户的最基本要求确定了系统的初始范围,如图

网JS系轨的胡“音也W

确定参与者

确定了三个参与者:

经营经理、房产经理和外部合作伙伴。

1)经营经理:

负责数据录入和数据维护。

经营经理创建报表,以提供有关房产的管理信息,并保证考虑到房产的日常问题。

2)房产经理:

负责管理自己掌握的资金用于房地产投资。

房产经理要确定准备投资的各种类型的房地产项目。

这种参与者主要关注投资所需的资本和投入的资本与所产生的回报的比较。

3)外部合作伙伴:

外部合作伙伴与房产经理起类似的作用,不过是在机构的外部。

外部合作伙伴参与房产,但是在很多方面可以斟酌决定。

外部合作伙伴的主要责任是保证投资产生回报,还需要向房产经理定期提供信息,包括现金流、对帐单和回报信息。

(3)获取用户需求

与关键项目的相关人员一起,经过大量的分析讨论,确定了两个基本用例。

用例1管理投资

川例名称

描述

触发条件

匸件过程

并常

2.

理投资

駅踪公Id所投條房产的雀木屈性,房产用ffl人的信息和利恥•经营经理

•房产经理

•外部合作伙伴

.房产、房产承租人或租期发生变化。

分类衣和乩它数据已经进入系统.

1.X煤取一处房产时:

G录入投资(房产)的详细信息.

b)确定房产的资本委托事项,

C)将房产划分为一个或多个单元a当找到房产单兀的承租人时=录入丿氏租人详细佰息.确宦爪用条恥确定用租人付款时间将这个房产雜元打该欣ffl人关联.

a)

b)

c)

d)

3.

a)

b)

c)

d)

芳房产售出时:

记录销售细亿yw产的所仃朋和人脱离关联.

删除对该W产的所竹未來资木投入O从时间农中删除所冇未來现金流.

4.

当到达和期时:

a)将房产单元与承租人脱离关系*使其nJ确定新的租期=

b)删除与该承租人关联的所附耒來现金流。

用例2汇总投资

用例轻称

参与者

触发条件

询提

汇总投资

把U经“储的S(据幣a为支持业务运卄和决策的=组报衣。

•经说经理

•房产经理

•房产经理卞妥以临时确定的方式使用报表以做出各种决策.•经营经理定期使川报表支持业务运营.

•投资和房产部门匕经把详细信息录入到系统中。

•系统吃・须为那些依赖lL仃外部数据的报表获取來自外部的数据.

1-系统显示L1仃报衣沾叭.但括,

a)运营报衣

未來11个月内到期的飛租介同.

II.

房产便用怡况.

工系统准%提供提交的报表,包括报表的外观和交付格式,包括打印格式和屏幕格成.

系统不会根抓报衣生成修改业务数据.

还没有提出紧迫的技

此时,我们除了可能有外部房产经理参与者的远程访问需求之外,术需求,也没有得到业务规则。

通过项目相关人员的讨论,我们得到他们对系统提出的两个基本要求。

1)根据用户的视点来设计本系统。

这是一项基本要求,我们已经考虑了源自可以支撑本系统的会计系统的复杂业务需求。

项目相关人员要求为其业务提供很强的会计支持,但是愿意将两个系统分开。

帐本簿与房地产管理系统之间没有多少冗余数据,项目相关人员不愿意增加额外经费补充会计功

能,或将两个系统数据集成起来。

2)把系统看作是一种“数据采集与报表生成系统”。

(不能

关键是构建采集实现他们所定义的业务规则的数据的系统,既要使数据“安全”

丢失或遗忘),又要为不同参与者提供专门化的视图,以便根据这些视图做出业务决策(例如,系统具有比较回报和投资的能力,要能够知道从出租的角度看,哪些房产在历史上没有得到充分的利用,哪些区域的出租率和回报率高)

(4)获取功能需求

下一步是充分与用户讨论,搜集尽可能多的有关各种参与者如何与系统交互的信息,以及他们需要通过系统获得什么样的信息。

搜集这些信息的结果,我们可以将前面的用例进行进一步的扩展。

19、20、21所示。

为了更好地表示用例,我们把用例图一分为三。

如图

 

 

 

这里把用例由最初的两个扩展为20个。

用例3录入承租人详细信息

用例转称

录入承和人详细信息

描述

W地产骨理系统跟踪谁血用租W产*系统心储毎个承租人舲一套详细信息,以记帐、跟踪和检杳状况.

细¥经理

触发条件

•发现承租房产的新承租人或潜在承租人.本用例可以由“出租房产"川例來罔动.

•发现现仃出租人的补矩或变归占息。

師提

施木靠件过根

b经郴统理找到朋和人区域。

2.经营经理录入承租人的标识信息:

a)个人承和人的姓轻和片份证号码.

b)机构/凭和人的公川■^称和税务登记证兮.

3.系统检杳现有匹配项.

4.条统显示U经片⑴r现仃信息的数那隶入模板.个人爪相人和机构承租人时模板不同。

<需要补充W入所備数据项的沾单>

5.经营经理录入毎个数與C项。

6.系统根据数据录入规则(丨1期、身份证尊)检验录入的数据.

7.如果经背经理対所呆入的数据感到淌臥则捉交数撫变更.

8.系统检查所录入数据是否完犒。

9.如果通过检輪*则系统"储所做的数据变飪■该用租人彼标订为有效。

汗常

乳如果系统K现枣复项,则对参号者K出警苦■幷显示现冇欣和人记杀<■

7,to果参与者对所做的数据斐史不满意.可以选择放弃所做变也,如果系统屮冇以储的込,比,则恢y以储的込,比.

8.如果没有输入耍求胚须输入的数《«,系统对参与者发出警告,并解释哪些数据必须录入.如果该承科人a"1liv承租汁同签订人(即拥右W未到期的承和合同的用机人人片且系统不搂收数折变更.则这会导致该承租人失去有效状态.

如果数据是宜备的,有效的.系统拥仃一个仃效酌永租人.

业务规则

V插入字段和衷格级的详细检验规则>

技术需求

•本功能只在k办公富内便用’统营经理不在托他地方办公.•腹和人所需的数据集过占已经变更过多次.房产经理耍求系统;;有补充或删除有关承租人的克接或导出数拥的灵活性a

•帧册一次只有一个人也新承和人数抑:

”系统不需婆支持用押人信息的同时史新.

•系统庾该“储对承租人伫息变更的所冇W史.包括进行变更的参与者标识,以及变更II期和时间O

用例4录入投资详细信息

用例用例用例用例

5录入房产详细信息

6建立单元

7出租房产

8输入数据

用例杯称

输入数据

描述

外部令作伙伴管理一部分房产.在典型情况卜.外部令作伙件打本单位共同拥宵房产——他们拥有房产的一部分.并负责维护和出和整个房产-外部介作伙邙根据协议.按期向本甲位提交数flUn钱款.本用例将外部合作伙伴提供的数到系统存储,以供生成报衣。

•外部含作伙伴

•经蓿经理

触发条件

外部合作伙伴按合同规定,定期提供数据,在每个报表提交周期,外部介作伙伴都耍准备数据片捉交给本公小从而触发本川例。

询提

外部合作伙伴和本公司已经签订协议.

基本件过e

1.经营经理收到一组來门外部介作伙伴的数据,或仃关数据已经牛.成的通知.

2.经营经理找到数据所对应的房产.

3*经营经理找到输入外部合作伙伴数据购区域。

4,系统询間外部数抓的位世。

予.经营经理给出外部数的位置.

6.系统检查数据对应的房产准确无误.

7.系统iMi产的以卞坡据:

A)对应R期的一系列现金金额;

b)对应H期的一系列资本支忖。

8.系统将这部分倍息1俩给出的用产天联•

9.系统向经蓿就能r显示所输入的数据供批准。

a)经营经理检查这些数据.批准或取消输入数《^操作.

b)如果数据被批准.系统储所输入的数据.

片常

5,如来系统不能找到或访问输入数昭则系统警告纬营纯理.井等待经营经理提供其他数据存放位置或取消操作.

6.如果数据没右对应所期與的W产.则系统警告经营经理.本川例结來.

后果

业务规则

技术苗求

只支持一种数据转换方法.这样町以降低系统的父杂性.《轻员【.培训负孤一个项訂相关人员提出,外部合件伙伴拥冇很少的技术和业务自治能力,并提出电『表格应该是合适的数据转换机制.

用例用例用例用例用例用例用例

9建立现金流时间表

10交易记录

11处置房产

12建立资本时间表

13报告排名前5位的房产

14报告每个区域统计区的房产

15报告预期回报率

用例名称

报苦预期冋报率

描述

木报衣给出W产的陨期内部凹报率.如果可以W到交易数抑:

.则使用实际现金流,杏则便用现金流时间表。

内部冋报率按房产的傕个妤命期讣離

参与者

房产经理

触发条件

“创建报表”用例

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2