ExeERP系统工具需求文档第2学期.docx

ExeERP系统工具需求文档第2学期.docx

《ExeERP系统工具需求文档第2学期.docx》由会员分享，可在线阅读，更多相关《ExeERP系统工具需求文档第2学期.docx（18页珍藏版）》请在冰豆网上搜索。

ExeERP系统工具需求文档第2学期

第1章ExeERP系统工具需求文档

文件修改记录

编号

状态

日期

执笔人

审核人

批准人

修改页码及条款

1

创建文档

2009-7-8

王刚

2

修改文档

2009-7-9

王刚

韩立宸

3

确立文档

2009-07-12

谢冠雄

4

打印文档

目录

第1章ExeERP系统工具需求文档1

1.1引言1

1.1.1目的1

1.1.2背景1

1.1.3参考资料1

1.2任务概述2

1.2.1目标2

1.2.2假定与约束2

1.3系统组织结构2

1.4功能需求3

1.4.1用例驱动需求建模3

1.4.2功能划分5

1.4.3功能描述5

1.5性能需求6

1.5.1时间要求6

1.5.2适应性6

1.6设计约束6

1.7项目风险分析7

1.7.1用户角度的风险7

1.7.2项目角度的风险8

1.8分配任务12

1.9附表12

1.1引言

1.1.1目的

该项目主要目的用于指导湖南科技职业学院学生的第2学期的项目实训。

前期已经针对湖南科技职业学院第3学期任务做过详细调研。

编写此文档可以更好的明确客户需求，同时也为《设计说明书》的编写提供依据。

预期的读者：

1、系统设计人员。

2、湖南科技职业技术学院软件学院老师。

1.1.2背景

项目名称：

ExeERP系统工具

版本：

1.0

任务提出者：

湖南科技职业学院项目案例组老师

任务实施者：

ExeERP实训项目组

任务承担者：

浙江天演维真网络科技有限公司软件事业部

使用对象：

湖南科技职业学院师生

与其它系统的关系：

作为执行企业资源计划系统（ExeERP）的一个子系统，是其系统操作工具。

执行企业资源计划系统（ExeERP）是浙江天演维真网络科技有限公司联合浙江大学计算机学院共同开发，并拥有自主知识产权的优秀管理软件。

系统采用先进的多层体系架构（用户界面层，商业逻辑层，数据库层），是现代网络技术、数据库技术、电子商务技术和各界企业人士宝贵管理经验的完美结晶。

其功能强大，操作简便，是各级企业实现全面信息化管理、简便工作的理想选择。

普遍适用于各类制造型企业，改变了企业传统的条块分割的管理模式，通过信息化手段对各个职能部门（如车间、仓库、销售、财务、采购等）和各个管理环节（如订单的下达与执行、生产计划的实施和控制等）进行全面的智能化管理，给企业管理者提供全方位的决策支持，实现现代企业管理的规范化、系统化、智能化。

1.1.3参考资料

1）《执行企业资源计划系统需求规格说明书.doc》

2）《第二学期案例方案.doc》

3）项目合同

1.2任务概述

1.2.1目标

该软件是应湖南科技职业学院师生要求针对湖南科技职业学院第2学期学生项目实训的演示案例。

该软件提供（ExeERP）系统中配置文件的修改与系统的备份。

是执行企业资源计划系统（ExeERP）的子系统。

1.2.2假定与约束

开发期限为2009-7-9—2009-7-22

1.3系统组织结构

管理员应用ExeERP系统管理工具对系统配置文件进行维护操作（读取、增加、修改），在项目的拷贝、移植过程中为了系统文件的安全，对系统文件进行备份操作。

1.4功能需求

1.4.1用例驱动需求建模

1.4.1.1管理员用例图

1.4.1.1.1绘制用例图

1.4.1.1.2读取配置文件信息

1）用例标识符：

UC_T2_ADMIN_001

2）用例名称：

读取配置文件信息

3）用例描述：

管理员将配置信息的内容读取到应用程序界面

4）角色：

管理员

5）前置条件：

管理员启动应用程序，成功进入管理界面

6）后置条件：

完成此程序的相应操作

7）基本路径：

（1）管理员成功进入管理界面

（2）系统判断配置文件是否存在

（3）读取出相应的系统配置信息，如：

config.properties文件

（4）将读取的信息显示在应用程序界面上

8）扩展点：

2a文件目录不存在

2a1应用程序界面上是空值/初始值。

2b文件不存在

2b1应用程序界面上是空值/初始值。

9）补充说明：

无

1.4.1.1.3维护配置文件信息

1）用例标识符：

UC_T2_ADMIN_002

2）用例名称：

修改配置文件信息

3）用例描述：

管理员可对ERP项目的配置文件进行修改操作

4）角色：

管理员

5）前置条件：

管理员启动应用程序，成功进入管理界面

6）后置条件：

完成此程序的相应操作

7）基本路径：

（1）管理员成功进入管理界面

（2）读取出相应的系统配置信息，如：

config.properties文件

（3）在系统界面上，修改配置参数

（4）修改完成，点‘保存’

（5）系统判断路径和文件是否存在。

（6）文件路径存在，修改文件，提示‘数据已更新’。

8）扩展点：

2a、指定的文件路径不存在

2a1．自动找到指定路径，在指定路径下创建目录和配置文件，并保存文件的配置信息。

2b、在指定的路径下，找不到相应的配置文件

2b1．自动创建配置文件，并保存文件的配置信息。

9）补充说明：

1、修改配置文件格式要准确

2、窗体切换必须小于0.5秒

1.4.1.1.4系统文件备份

1）用例标识符：

UC_T2_ADMIN_003

2）用例名称：

系统文件备份

3）用例描述：

用户可对ERP项目的配置文件进行备份操作

4）角色：

管理员

5）前置条件：

管理员启动应用程序，成功进入管理界面

6）后置条件：

备份ExeERP系统

7）基本路径：

（1）管理员运行ExeERP管理工具系统

（2）管理员按“备份”按键。

（3）系统根据管理员指定的备份路径，将ExeERP系统文件备份

（4）系统完成备份ExeERP系统操作。

（5）系统提示“备份成功”。

8）扩展点：

3a、指定的备份路径不存在

3a1．备份时，系统在制定的备份路径下创建文件，备份ExeERP系统文件

3b、在指定的备份路径下，备份文件已存在

3b1.系统将提示备份文件已存在，是否覆盖。

或新建一文件再备份

9）补充说明

无

1.4.2功能划分

1.4.3功能描述

功能名称

功能标识符

功能详细描述

读取配置文件信息

FUN_T2_ADMIN_001

将配置文件信息读取出来，显示在应用程序界面上

增加配置文件

FUN2_ADMIN_002

可以在配置信息目录下，添加一个的系统配置文件

修改配置文件信息

FUN_T2_ADMIN_003

对系统的配置参数进行修改更新操作

实现事件监听

FUN_T2_ADMIN_004

融入面向对象编程的思想具体实现；以及实现按钮事件监听

系统文件备份

FUN_T2_ADMIN_005

备份ExeERP系统的运行程序到指到目录中。

其中融入了对文件的流操作。

1.5性能需求

1.5.1时间要求

响应时间不超过50毫秒、更新处理时间不超过70毫秒、数据转换时间不超过70毫秒，尽可能的缩短传送时间。

1.5.2适应性

1、本系统用JAVA语言编写。

Java具有“WriteOnce，RunAnywhere”的优点，所以本系统的运行与平台无关，具有很强的可移植性，系统环境的改变对它影响不大。

2、本系统完全采用OO（面向对象）思想进行设计与编程，因此，系统的扩展性与开放性都比较好，与其他系统的接口很方便，即便接口发生改变，修改的工作量也不会很大。

3、本系统运行对机器的性能、配置要求均不高。

1.6设计约束

1、考虑到学生第2学期仅学习了Java基础、面向对象编程、Java图形接口等知识，所以本系统只采用上述技术手段来实现；

2、考虑到本系统的工作量要满足“一名学生3周时间完成”的要求，所以在实际功能上进行了一定的删减；

3、本系统工具是针对浙江天演公司的ExeERP系统开发的，所以只适用于ExeERP系统的配置管理。

1.7项目风险分析

1.7.1用户角度的风险

1.7.1.1客户的任务和目标

编号

风险要素

低风险

中等风险

高风险

等级

1

项目是否符合客户的目标

完全符合客户的目标

一个或几个客户的目标不能直接实现

基本不能达到客户的目标

低

2

对客户原有工作流程的影响

基本保持客户原有的工作流程

某些工作流程会因为本项目而受到小的影响

客户的工作流程和方法将因本项目的实施而产生很大的变化

低

1.7.1.2客户的机构管理

编号

风险要素

低风险

中等风险

高风险

等级

1

客户机构的稳定性

基本不会发生变化

会发生较小的变化

客户的机构或管理方式会发生持续的或迅速的变化

低

2

客户机构中的人员及责任

每一个人都很清楚自己及他人的角色和工作责任

每一个人都清楚自己的角色和工作责任，但并不清楚其他人的责任

客户机构中的大多数人都不清楚自己或他人的工作职责

低

3

客户组织成员的参与程度

项目组可以与客户所有需要交流的部门进行足够的交流

项目组不能确认是否能够与所有需要交流的部门进行足够的沟通

项目组与客户组织中的一个或数个关键部门进行交流，或这些部门之间没有交流，或项目组与某个关键部门的交流将影响项目组与其他部门的交流

中等

1.7.1.3客户/最终用户

编号

风险要素

低风险

中等风险

高风险

等级

1

最终用户在项目中的参与程度

最终用户紧密参与项目开发，并有重要的作用

最终用户在项目中扮演次要的角色，对项目的贡献为中等程度

几乎没有最终用户的参与，最终用户对项目也几乎没有意见和建议

低

2

最终用户的使用经验

用户在类似项目上有丰富的使用经验，对如何达到需求有明确的思路

用户有类似系统的使用经验，并且有关于需求的想法

用户几乎没有任何类似系统的使用经验，也不知道如何达到需求

低

3

最终用户的培训需求

培训需求已被充分考虑，培训工作正在进行或已有合适的计划

培训需求已被充分考虑，但培训工作没有开始并且没有合适的计划

培训需求没有被考虑过

低

4

最终用户在项目涉及的领域中的知识

最终用户对项目涉及的领域有相当的知识和经验

该领域对最终用户相对较新，但已经开始对他们进行适当的培训

用户对该领域几乎没有任何认识，并且没有计划好的培训工作

低

1.7.1.4客户的技术部门

编号

风险要素

低风险

中等风险

高风险

等级

1

客户组织吸引和留住员工的能力

客户能够招聘到并且留住有足够技能的员工，并对技能不足的员工进行适当的培训

客户能够招聘到有限数量的有足够技能的员工，可能需要支付额外的奖金

很少人愿意在客户的组织中工作，客户也因为员工的频繁流失而不愿意对他们进行培训

低

1.7.2项目角度的风险

1.7.2.1项目特征

编号

风险要素

低风险

中等风险

高风险

等级

1

项目复杂度

项目较小，不很复杂，或很容易分解

项目规模中等，复杂度中等，可以被分解

大型项目，高复杂度，难于分解

低

2

硬件限制

几乎没有硬件限制，单一系统平台

有一些硬件限制；少量几个平台

重大的硬件限制，多平台系统

低

3

需求稳定性

对定义好的需求基本不会发生变化

基本需求可能会发生一些变化

没有基本需求，或基本需求变化很快

低

4

客户期望值

客户期望值与项目组相同

双方没有正式讨论过项目的期望值，但看起来是相同的

客户的期望值与项目组不同

低

5

可测试性

项目需求很容易被测试，测试计划正在进行中

项目的某些部分很难被测试，或测试计划刚刚开始制定了一小部分

项目的大部分都难于测试，或项目测试计划尚未开始制定

低

1.7.2.2项目的决定

编号

风险要素

低风险

中等风险

高风险

等级

1

行政因素的影响

所有决定都不是由行政影响而作出的

项目中的某些决定不是因为技术或管理的原因，而是行政上的需要

项目中的大多数决定都是行政上的原因，而没有技术或管理上的因素

低

2

确定项目结束日期

发布日期是基于项目组对项目进展的估计作出的

发布时间的确定部分由于市场的需要或其他方面的因素

发布日期的确定完全是由于市场的需要，或财务目标，或其他类似因素，却没有考虑到项目组对工作时间的估计

低

3

开发技术的选择

技术选择完全符合客户的需求

之所以选择某种新技术，部分是由于新技术本身

项目成了引进新技术的借口，而新的技术对满足用户需求毫无用处

低

1.7.2.3项目的开发过程

编号

风险要素

低风险

中等风险

高风险

等级

1

项目的依赖性

所有的依赖因素都是已知的，并且有可靠的保证

某些依赖条件可能会部分导致延期

影响项目的条件是员工、决策或组件不足

低

2

对评估结果的信任度

任务划分明确，项目组对评估结果高度信任

项目组成员对评估结果的某些部分缺乏信任

任务划分不明，评估涉及的范围太广，或项目组不信任评估结果

低

3

现有系统的文档

现有系统的文档完全，格式通用统一，项目组很容易理解且从中获益

部分系统有文档说明；每一部分文档有自己的编写方法

没有有关现有系统的文档；或现有文档不正确或已过期

低

4

项目文档

文档正确可用，由项目组成员在项目进展过程中编写

缺少部分文档，但已有文档是可用的，可能滞后于项目进展

没有项目文档；没有建立项目内部文档的计划

低

5

开发流程的制订和使用

项目进展流程已经建立，并且是适当的和高效的，项目组成员遵照该流程工作

流程已建立，但效果不好，没有被很好的遵守

没有正式的工作流程

低

1.7.2.4项目开发和部署的环境

编号

风险要素

低风险

中等风险

高风险

等级

1

物理设备

几乎不需要改变

某些已存在，其他需要改变

需要较大的改造

低

2

硬件平台

平台稳定，有足够的能力，不需要改变

平台有一些变化，但在控制之下

平台与软件在开发中

低

1.7.2.5项目（程序）管理

编号

风险要素

低风险

中等风险

高风险

等级

1

管理方法

具有有效的计划和监督的机制和工具

计划和监督机制需要加强

几乎没有计划和监督机制

低

2

管理经验

项目经理和程序经理在类似项目上很有经验

项目经理和程序经理在类似项目上有一些经验，或在其它项目上有管理经验

项目经理和程序经理没有经历过类似项目的管理工作，或在项目管理上是新手

低

3

项目和程序经理的权威

具有管理上的或官方的权威，可以有效的承担领导项目组的任务

基于私人的关系，可以影响组织中的其他成员

既没有官方的地位也没有个人的影响，从而在做出决定和资源调配上没有影响力

低

1.7.2.6项目组

编号

风险要素

低风险

中等风险

高风险

等级

1

项目组成员的可用性

总是就绪，几乎没有什么原因可以导致中断工作

基本可用，有时候会因紧急事件而中断工作

几乎不可用，成员花费大量的时间用于应付紧急事件

低

2

综合技能

综合技能极好

某些技能不是很充分

不具备某些必要的技能

中等

3

类似项目的经验

项目组在类似项目上有大量的经验

在类似项目中有一定经验

几乎没有类似项目的经验

中等

4

开发流程的经验

在这种流程上有大量的经验

在这种流程上有一些经验或在其他流程上有大量的经验

没有正规流程的经验

低

1.7.2.7项目技术

编号

风险要素

低风险

中等风险

高风险

等级

1

技术与项目的符合程度

对客户的问题，项目所采用的技术有可靠的解决方案

项目计划中采用的技术对解决客户的问题在某些方面不是很合适

所选择的技术与解决客户的问题之间有较大的差异

低

2

与工业标准的符合程度

技术路线符合客户的组织体系和技术架构

技术路线对用户是全新的，但是与现存的标准和技术架构没有冲突

技术路线与现有的标准或技术架构有矛盾，或没有成文的标准

低

3

技术成熟性

该技术已经使用了很长时间

技术被项目组充分理解

采用的是可能导致失败的新技术

低

1.7.2.8项目维护

编号

风险要素

低风险

中等风险

高风险

等级

1

设计复杂性

高可维护性

某些方面难于维护

非常难于维护

低

2

维护人员

有足够的合适的有经验的人员

缺少某些方面的专家

非常缺乏受过训练的专家

低

1.8分配任务

序号

任务名

任务描述

起始时间

结束时间

责任人