软件工程系统需求分析说明书模板精.doc

需求分析说明书
团队名称:
组员1学号:
组员1姓名:
组员2学号:
组员2姓名:
组员3学号:
组员3姓名:
组员4学号:
组员4姓名:
日期:
1 引言
1.1 编写目的
本文详细描述任务管理系统的需求,表述的需求信息要求明确、无二义性。开发方与软件使用者充分沟通需求,最终形成此文档。此文档是后续软件开发的依据。
1.2 背景
任务管理系统是一个南京工程学院与康尼电气新技术有限公司产学研合作项目,项目由康尼机电新技术有限公司提出,由南京工程学院承担开发任务。
1.3 定义和缩略语
本文使用了表 1.1所显示的面向用户的术语、定义,包括通用词语在本文档中的专用解释。

表 1.2所列为本文用到的缩略语。

1.4 参考资料
(列出所查阅的图书及网站
1.5 用户
任务信息管理系统的目前用户为康尼公司电气事业部,电气事业部使用成功后可能会在康尼公司推广。
某餐厅餐饮管理系统的目前的用户为某餐厅。
2 任务概述
2.1目标
康尼公司电气事业部目前的任务主要有2类:常规工作任务和临时性工作任务。
针对临时任务布置信息很多时候是处于一种开放状态,缺少任务信息的修正、回馈、和统计分析。而日常职责规定的常规工作,虽然可以通过标准化的文件固化下来并形成《常规工作计划表》作为一种制度来执行,也需要主管在百忙之中花很多时间去检查完成情况
TIMS系统要求工作管理信息能够规范录入,任务信息流向可以选择,任务信息依据轻重排序,可以设定信息提醒,任务完成情况可以评估、任务完成情况依据选择项进行统计输出、工作量进行评估。
2.2 系统的特点
TIMS项目的需求主要由康尼公司电气事业部提出,因此本文档是与康尼公司电气事业部交互后形成的需求定义,系统的功能和使用特点优先满足康尼公司电气事业部的需求,若系统后续由于在康尼公司全面推广而引入的新需求,则不在本文档考虑范围之内。
2.3 假定和约束
本文档经双方确认后,开发方依据本文档进行下阶段工作。若中途需求发生变更则康尼公司需及时告知开发方,若因康尼公司原因引入的需求变更造成开发
方工作量的大幅增加,具体解决方案双方另行协商。若需求变更引入的工作量不大,开发方应尽量配合。
4. 需求规定
4.1 组织架构
康尼公司电气事业部的组织架构如图4-1。

图4-1 电气事业部组织架构
TIMS系统面向整个电气事业部使用,图4-1给出了电气事业部的详细组织。
4.2 权限需求
系统的用户是康尼公司的员工,员工在现实逻辑中分属不同的部门并具有相应的工作权限。系统权限分配时与员工的组织架构并无对应关系。TIMS系统的权限需求有2层含义。
1.针对系统功能设置用户的操作权限。
2.针对用户可以设置查看哪些任务的权限。例如可以设置某用户查看生产部的所有任务信息;设置用户A可以查看用户B及用户C的任务信息。
系统的用户是某餐厅的员工,员工在现实逻辑中分属不同的部门并具有相应的工作权限。系统权限的分配时与员工的组织架构并无对应关系。餐饮管理系统的权限需求如下:
1.针对系统功能设置用户的操作权限。
2.针对用户可以设置查看哪些任务的权限。
4.3 任务处理流程需求
4.3.1 系统用例图
(这部分如果是用结构化设计的方法,那就不要画用例图,改成画数据流图。
TIMS主要对任务信息进行管理,实现任务信息的标准化管理。TIMS系统关于任务处理的用例图如图4-2。

图4-2 系统用例图1

图4-3 系统用例图2
(如果是结构化程序设计方法,请在此添加一节内容介绍所建立的数据字典
4.3.2 任务处理流程
针对
TIMS 系统中任务可能的流程进行分析。为方便理解,对应图4-4进行表述。

图4-4 人员组织架构示例图
流程设计思想:
TIMS 系统采用信息闭环的思想,即任务由任务发布者发布出去,任务最终也在任务发布者处结束,图4-5简单的表示了这一思想,同时也概括了任务在TIMS 系统中的处理流程。

任务发布者任务接收者
任务承担者
图4-5 TIMS 系统任务处理流程图
任务下达采用逐级的层次方式,任务的反馈采用逐级向上的方式。 例如下达任务给制造组的Z3时,任务发布者X 应该将任务发布给制造组的主管Z0,由主管Z0在自己的主管范围内分配该任务,而最终的任务接收者是Z3。若Z3提交完成情况和延期申请,则先提交至Z0,Z0根据实际情况决定是否提交以及如何提交给X 。X 最终决定是否同意延期以及对任务完成情况进行评价。
4.4 详细功能需求 4.4.1 功能解释
本餐饮管理系统下有系统管理7个子功能: 1、财务管理; 2、系统账户管理; 3、前台管理; 4、后勤管理; 5、员工管理;
4.4.1.1 财务管理
财务管理下分为收入、出纳、工资和利润。记录本餐厅的收入信息、支出信息。发放工资以及计算餐厅的利润。
4.4.1.2 系统账户管理
系统账户管理下分账户管理和数据管理,由系统管理员身份的用户可以登录,他负责添加用户,用户分三类:一类为系统管理员,可以添加或删除各类用户;可以修改用户的密码;可以添加机删除新的菜品到菜谱,还可添加大堂座位信息。另一类为服务员,服务员可以为顾客安排座位。可以点菜,结账,接受预定和外卖,及所有日常的营业活动。最后一类是经理,经理具有服务员所具有的所有权限,此外,经理还可以查看及修改服务员的所有基本信息,即有最高的权限。系统管理员可一进行数据库的备份与恢复,即日常数据管理。
4.4.1.3 前台管理
前台管理下分浏览资源,登记菜单,点菜,结账预定服务和外卖服务,可浏览当前饭桌的就餐情况,还有那些空闲的座位可以就餐,定下座位后,可以自动点菜;客人就餐后可按全额结账,也可以按一定的折扣结账。
预订服务:预订服务下分预定订单和酒宴服务,可添加或删除订单,添加的订单记录订单编号、订单类型、预定日期和预定的座位号等。酒宴服务为预定模块,可在以后在扩充。
外卖服务:外卖服务下分为外卖订单和送货服务。负责登记外卖信息,包括订单号,送货地点,送货时间,货物清单机送货人信息。
4.4.1.4 员工管理
员工管理:可添加或删除员工,登记员工信息,包括编号、姓名、性别、年龄、婚否、住址、所属部门、薪金、聘用日期等。
4.4.1.5 后勤管理
后勤管理下分信息分析和物资管理。信息分析是指记录每日所卖的菜品,定期对此信息作分析。得出不同时期阶段的畅销产品。物资管理原材料的购买和座椅,餐具,电器等设备的购买和维护。
4.4.2 数据描述
1、静态数据及数据字典
(1用户登录表

(2员工信息表

在权限设置中可以设置用户查看其他用户的任务信息(包括发布的任务、接收的任务、知晓的任务。
1可以查询到有权限查看的用户的所有发布的任务信息。
2可以查询到有权限查看的用户的所有接收的任务信息。
3可以查询到有权限查看的用户的所有知晓的任务信息。
4.4.1.11 任务统计
此功能模块一般只有少数管理者可以使用,此模块用来完成所有任务信息的查询和统计。
具体功能需求如下:
1根据查询条件对所有任务信息进行查询,例如根据时间、任务发布者等条
件,也可以根据任务所属项目来查询该项目产生的所有任务信息。
2可按时间段、人员、部门进行任务完成率、完成情况统计,并输出图形。
具体汇总表格待定。
3对于未正常完成的任务信息,可以对原因(未完成的原因由任务接收者在
提交任务结束(延期结束时选择进行汇总,用户通过汇总表格对原因进行分析。
4可将查询结果导出至Excel表格。导出的格式待定。
4.4.1.12 任务统计发布
此功能模块一般只有少数管理者可以使用。此功能用来完成常规统计,并定期发布统计结果。统计汇总Excel表格在4.4.1.9中生成。
具体功能需求如下:
1发布统计结果。以Excel表格附件的形式发布。
4.2.1.13 任务统计查看
1. 功能说明
所有用户通过此功能查看任务统计发布。
4.4.2 系统管理
4.4.2.1 部门管理
维护部门信息。
需求说明书 因为系统有向整个康尼公司推广的可能，因此部门信息表与康尼现有 OA 系 统的部门信息表结构一致，这样便于数据的移植和系统整合。 4.4.2.2 员工管理 维护员工信息。 因为系统有向整个康尼公司推广的可能，因此员工信息表与康尼现有 OA 系 统的部门信息表结构一致，这样便于数据的移植和系统整合。 4.4.2.3 用户管理 维护系统的用户。 4.4.2.4 权限管理 设置系统权限 具体功能需求如下： n n 设置用户具有哪些模块的使用权限。 设置用户可以查看哪些用户的任务信息。 5. 运行环境规定 5.1 设备 n 客户端 u u u u n 内存：512M 以上。 CPU：主频 1.6G 以上。 操作系统：Windows Xp。 浏览器：Internet Explorer 6.0 以上。 服务器端 u 内存：2G 以上。 10
需求说明书 u u u CPU：主频 2G 以上。 操作系统：Windows Server 2003。 硬盘：120G 以上。 5.2 n n 支撑软件 后台数据库采用 MySql。 Web 服务器采用 Tomcat。 6 开发技术约定 n n n 系统采用 B/S 架构，即 Browser/Server 架构。 开发语言采用 Jsp、Java 语言。 系统功能页面的分辨率为 1024 x 768。 11