技术文件
文件名称：任务管理系统需求说明书项目名称：任务管理系统
共页
(包括封面)
作者：
1 引言
1.1 编写目的
本文详细描述任务管理系统的需求，表述的需求信息要求明确、无二义性。开发方与软件使用者充分沟通需求，最终形成此文档。此文档是后续软件开发的依据。
1.2 背景
任务管理系统是一个XX与XX电气新技术有限公司产学研合作项目，项目由XX 机电新技术有限公司提出，由XX承担开发任务。
1.3 定义和缩略语
本文使用了表 1.1所显示的面向用户的术语、定义，包括通用词语在本文档中的专用解释。
表 1.2所列为本文用到的缩略语。
1.4 参考资料
本文使用了表 1.2所列为本文用到的参考资料。
1.5 用户
任务信息管理系统的目前用户为XX公司电气事业部，电气事业部使用成功后可能会在XX公司推广。
2 任务概述
2.1目标
XX公司电气事业部目前的任务主要有2类：常规工作任务和临时性工作任务。
针对临时任务布置信息很多时候是处于一种开放状态，缺少任务信息的修正、回馈、和统计分析。而日常职责规定的常规工作，虽然可以通过标准化的文件固化下来并形成《常规工作计划表》作为一种制度来执行，也需要主管在百忙之中花很多时间去检查完成情况。
TIMS系统要求工作管理信息能够规范录入，任务信息流向可以选择，任务信息依据轻重排序，可以设定信息提醒，任务完成情况可以评估、任务完成情况依据选择项进行统计输出、工作量进行评估。
2.2 系统的特点
TIMS项目的需求主要由XX公司电气事业部提出，因此本文档是与XX公司电气事业部交互后形成的需求定义，系统的功能和使用特点优先满足XX公司电气事业部的需求，若系统后续由于在XX公司全面推广而引入的新需求，则不在本文档考虑范围之内。
2.3 假定和约束
本文档经双方确认后，开发方依据本文档进行下阶段工作。若中途需求发生
变更则XX公司需及时告知开发方，若因XX公司原因引入的需求变更造成开发方工作量的大幅增加，具体解决方案双方另行协商。若需求变更引入的工作量不大，开发方应尽量配合。
4. 需求规定
4.1 组织架构
XX公司电气事业部的组织架构如图4-1。
图4-1 电气事业部组织架构
TIMS系统面向整个电气事业部使用，图4-1给出了电气事业部的详细组织。
4.2 权限需求
系统的用户是XX公司的员工，员工在现实逻辑中分属不同的部门并具有相应的工作权限。系统权限分配时与员工的组织架构并无对应关系。TIMS系统的权限需求有2层含义。
1.针对系统功能设置用户的操作权限。
2.针对用户可以设置查看哪些任务的权限。例如可以设置某用户查看生产部的所有任务信息；设置用户A可以查看用户B及用户C的任务信息。
4.3 任务处理流程需求
4.3.1 系统用例图
TIMS主要对任务信息进行管理，实现任务信息的标准化管理。TIMS系统关于任务处理的用例图如图4-2。
图4-2 系统用例图１
图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 最终决定是否同意延期以及对任务完成情况进行评价。
具体任务处理规则说明如下： 1.关于任务发布者
1）默认的情况下，任务只能由组织的主管发布，且不能越级发布。例如生产部主管S0只能给G0、J0、Z0发布任务。假若最终任务T 由Z1承担，那么是S0向Z0下达任务，Z0再将任务T 分配给Z1。 2）系统可以设定用户可向哪些人员发布任务。 例如：
可以设定计划组的J1向Z0、G0发布任务； 可以设定S0向K0、L0发布任务。
3)可以设定用户直接向具体人员发布任务。 例如：
可以设定J1直接向D2发布任务。正常的发布顺序应该是J1->Z0->D0->D2。系统自动记录任务相关人员Z0、D0，任务延期、提交完成情况由任务承担者D2直接提交给任务发布者J1，但自动设定Z0、D0同意延期和提交完成情况。 2.关于任务的分配和分解
1）若任务的接收者是组织的主管，则可以将任务分配给其组织的直接下属。例如制造组的主管Z0可以将任务分配给Z1、Z2、Z3，当然也可以分配给自己，但不能将任务分配给D1，需要将任务先分配给D0，由D0再在自己的组织进行同样方式的分配。（说明：图4-3中制造组主管Z0直接下属是Z0、Z1、Z2、Z3、D0）。
2）任务接收者接收到任务T后，可以将任务分解为若干子任务T1…Tn，然后发布给本组织的员工。
3.关于发布任务
1）任务接收者可以有多个，必须设定一个主任务接收者。任务主接收者体现在任务的实际协调上。
2）任务接收者可以是组织的主管，也可以不是。如果是组织的主管则可以分配任务和分解任务。
3) 任务的第一接收人是指最初接收到任务的员工。例如X发布任务给Z0，
Z0再分配任务给Z3。那么Z0为任务第一接收人，Z3为任务的承担者。
4）任务第一接收人在接收到任务后必须决定是否接收任务。只有在接收了任务后，才能进行后面的分配任务和分解任务操作。若不同意接收任务则拒绝任务。
5）任务的第一接收人有多个的情况，例如S0给Z0和J0发布任务T。
(1)主管Z0和主管J0必须作出是否接收任务的判定。
若Z0拒绝了任务T，则S0处理Z0的拒绝信息，可以打回或者接受Z0的拒绝。若S0因为Z0的拒绝而修改了任务信息，则需要通知
J0，如果J0之前已经接收了任务，则可以针对修改后的任务信息再次
进行拒绝或者接收操作。
(2)只有Z0和J0都接收了任务，则任务T的状态为进行状态。
(3)只有任务状态为进行状态Z0和J0才能分配任务。
4.关于任务反馈
1）任务是逐级下达，任务反馈则是逐级汇报。
2）以X发布任务给Z0，Z0又将任务分配给Z1、Z2为例。
(1)Z1可以向所有任务相关人员（Z0、X、Z1、Z2）发送信息。
(2)Z1、Z2若要申请延期，则只能向任务分配者Z0申请。
(3)Z0收到Z1或者Z2的延期申请后，处理此延期申请。Z0根据整个任务的
进度情况，来人为判断Z1或者Z2的延期是否对整个任务造成延期，若对整个任务不造成延期，不需要向X提出延期申请；若对整个任务造成延期，可以向任务发布者X提交延期申请。任务发布者X最终决定任务是否延期。
(4) Z1、Z2向对应的任务分配者提交完成情况，Z1、Z2的工作由Z0评价，
Z0最终汇总Z1、Z2的任务完成情况，向X提交完成情况。X根据任务第一接收人提交的完成情况进行评价，同时对整个项目进行评价。
５.关于任务完成情况及评价
1)由任务发布者决定任务的完成状态。
(1)如果所有第一接收人在任务期限内都确认完成了任务，任务发布者给出
每个任务接收的评价后，设定任务为完成。
(2)如果第一接收人没有申请延期，但确认完成任务时间晚于任务期限，则
系统自动设定为非正常延期完成。
(3)若任务在期限内没有完成，或者说任务已经不可能完成，任务发布者可
以设定任务为未完成。
(4)若有第一接收人申请了延期，且延期理由合理，任务发布者同意延期，
并修改任务期限。应设定任务为正常延期完成。
(5)若有第一接收人申请了延期，但延期理由不合理，任务发布者不同意延
期。应设定任务为非正常延期完成。
4.3.2.1 任务发布流程
1.任务第一接收人只有一个
图4-6任务发布流程1
流程说明：
1) X发布任务给制造组的主管Z0，同时将任务抄送S0，由于任务是初始发送给Z0，Z0必须决定是否接收才能进行后续操作。
2) Z0接收任务后，可以将任务分配给自己，也可以分配给制造组内用户，如图4-3所示，Z0将任务分配给D0和Z2，而D0是工段1的主管，他仍然可以将分配到自己的任务继续向下属分配，D0将任务分配给了D1。
3) D1的延期申请、完成情况均直接提交给其任务分配者D0，由D0对其完成情况进行评价。D0若认可了D1的延期申请，则由D0向Z0提交延期申请，若Z0同意了D0的延期申请，则向Ｘ提交延期申请，最终可否延期由X决定，X若同意延期则更改任务完成期限。
4)由D1向D0提交完成情况，D0对D1的完成情况进行评价；由D0向Z0提交完成情况，Z0对D0的完成情况进行评价；由Z0向X提交完成情况，由X对Z0的完成情况进行评价。
5)每个任务第一接收者都要提交自己的完成情况，任务发布者评判每个任务接收者的完成情况，最后给出整个任务的完成情况评价。
2.任务第一接收人有多个
图4-7 任务发布流程2
流程说明：
1) X 发布任务给Z0、J0，知晓者为S0。
2) Z0、J0为任务第一接收人，所以要判定是否接收此任务。只要Z0或者J0接收了任务，就可以进行后续的任务分配或者分解。
3)如果Z0接收了任务，而J0拒绝了任务，X 可以修改任务接收人员。 4) Z0、J0
都提交完成情况后，X 才能认定任务结束。
5) X 对Z0、J0的完成情况进行评价，同时对任务整体完成情况进行评价。 6) 其他流程同任务第一接收者只有一个的情况。 3.任务分解
图4-8 任务分解流程
流程说明：
1) X发布任务T给Z0、J0，知晓者为S0。
2) Z0接收任务T后，Z0即为任务T的最终承担人。任务T的流程同任务第一接收人只有一个的情况。
3) Z0将任务T作为父任务，创建了T1、T2两个子任务，T1、T2的发布者即为Z0。任务T1、T2的流程同任务第一接收人只有一个的情况。
4) T、T1、T2三个任务的处理流程是独立的，但是有父子关系，通过任务T 可以跟踪到任务T1、T2。
5) Z0在T1、T2完成后，提交自己承担的任务T的完成情况给X。
4.3.2.2 任务申诉流程
若任务接收者认为评价不合理，可以提出申诉，申诉信息由专门的申诉处理人来处理，不需要逐级反映。申诉处理人调查实际情况，提出申诉处理意见，选择审核人向其提交处理意见，审核人对处理意见给出审核意见，若同意处理人的处理意见则处理人可以更改相关信息。
申诉流程如下图。
任务申诉人申诉处理人申诉处理审核人
图4-9 任务审核流程
4.4 详细功能需求
4.4.1 任务管理
任务管理是TIMS系统的核心模块，也是用户使用最频繁的模块。
4.4.1.1 任务发布
1. 功能说明
用户在此功能模块中发布任务信息。具体功能需求如下。
1)可以直接在页面上录入任务信息。
2)录入任务信息后并保存，进行发布操作后，任务才会发布出去。
3)发布后的任务信息不能更改，若需更改已发布的任务信息到任务处理模块
进行操作。
4)在下发任务时，可以设定此任务是由哪个任务引入的，即可以设定父任务。
比如某主管从生产部长那接收了一个任务，主管针对此任务分解若干个子任务再下发给工段长。这样便于跟踪任务的进展，如某一个大的任务，产生了多少子任务。
5)设定反馈期限，例如一个需要执行1个月的任务，可以设定4个时间点，
任务接收者需要分别在4个时间节点前向任务发布者反馈任务执行情况。
6)任务接收者可以有多个，但必须设定一个主承担人，只有主承担人才能进
行任务确认完成操作。
7)发布者可以向能够发布的人员发布任务，具体要求参见本文档4.3.2。
8)任务发布时向接收者和知晓者发送提醒消息。
9)若用户在接收到一个任务T后，需要分解成若干子任务，那么需要至此模
块发布子任务，并且设定子任务的父任务为T。
关于常规工作计划
1)常规工作计划分为周工作计划、月工作计划。
2)常规工作计划由可以由Excel导入。Excel表格的格式如下。
周计划样表说明。表4-1和4-2格式一样，只是在示例数据上有区别。
表4-1 周常规计划表1
表4-2 周常规计划表2
(1)接收人可以有多个，反馈期限可以有多个，若有多个用中文顿号分割。
(2)生产部主管S0可以在任务发布模块导入表4-1，向耿亮等下发周常规工
作计划，对于接收到任务的主管，例如耿亮，同样在任务发布模块可以用表4-2导入自己的周常规工作计划，然后下发给本组织的人员。
(3)通过Excel导入周工作计划后，显示导入的任务列表，需用户在确认无
误后发布。
(4)月工作计划同周工作计划。
关于制程管理
制程管理的处理方式同常规工作计划。
2. 数据输入
4.4.1.2 待我接收的任务
1. 功能说明
用户在此功能模块中查看分配给自己的任务。具体功能需求如下。
1)此模块仅显示分配给自己但未接收的任务信息。
2)可以针对自己的情况自行设置任务优先级。
3)若对任务有疑义，可以填写接收者意见后拒绝接收任务。同时向任务发布
者发送拒绝接收任务提醒消息。
4)若对任务无疑义，可以填写接收者意见后接收任务。同时向任务发布者发
送同意接收提醒消息。
5)若用户是组织的主管，在接收任务后可以分配给本组织的直接下属。在分
配任务时，可以指定每个任务接收者的反馈期限。
2. 数据输入
4.4.1.3 我发布的任务
1. 功能说明
用户在此功能对自己发布的任务进行处理。
具体功能需求如下。
1)可以查看自己发布且未结束的任务。若要查询已结束的任务到任务查询模
块。
2)查看自己已发布的任务信息、任务是否被接收、任务是否被拒绝。
3)修改任务信息，因为任务属于已发布任务，所以若修改任务信息则需通过
提醒消息通知任务接收者和知晓者。
4)针对被拒绝的任务可以进行如下操作：
(1)针对任务接收者的决绝接收理由发送回复。
(2)若需修改任务信息，则进行修改后重新发布。同时向任务接收者和知
晓者发送任务被修改提醒消息。
5)针对正在进行的任务（即任务接收者接收了任务）可以进行如下操作：
(1)向任务接收者发送信息，例如督促提醒信息。
(2)通过查看任务接收者的反馈信息了解任务的进展情况。
6)针对任务接收者已完成的任务，给予任务完成情况评价。
7)处理逾期情况，详细见本文档4.2.3。
8)通过图表的方式查看任务进展情况。
2. 数据输入
任务相关信息。
4.4.1.4 我接收的任务
1. 功能说明
用户在此功能对自己接收的任务进行处理。
具体功能需求如下。
1)可以查看任务信息，即自己接收的且未完成的任务。
2)可以针对自己的情况自行设置任务优先级。
3)填写反馈给任务发布者。
4)设定具体任务的提醒期限。
5)若任务已完成，进行任务已完成操作。
6)向任务分配者(发布者)申请任务延期，逐级申请。
7)显示任务的分配信息。
2. 数据输入
任务相关信息。
4.4.1.5 任务提醒
1. 功能说明
此功能用来显示用户相关的任务提醒信息，包括作为发布者或者接收者的相关任务提醒信息。例如针对发布的任务，可以查看到任务接收者同意接收的提醒消息、申请延期的提醒消息等。
用户通过此功能可以全面了解与自己相关的任务动态。
具体功能需求如下。
1)能够方便的查看任务相关的提醒信息，包括：任务发布信息、任务拒绝信
息、任务接收信息、任务修改信息、任务延期信息、任务完成信息、任务申诉提醒信息。
2)通过提醒信息可以链接到相关任务信息。
2. 数据输入
任务相关信息。
4.4.1.6 我的任务申诉
1. 功能说明
任务接收者若对已结束（设定为延期结束、正常完成）的任务信息有疑义，例如认为对任务完成情况评价较低、或者认为任务非正常延期非自己责任，则任务接收者可以提出申诉。
2. 数据输入
4.4.1.7 任务申诉处理
1. 功能说明
由专人来处理，处理所有的申诉。
对申诉所涉及的信息进行实际调查后，向特定的审核人提交调查意见。
2. 数据输入
申诉信息、任务信息。
4.4.1.8 申诉处理审核
1. 功能说明
具有此功能权限的用户，可以审核提交给自己的任务申诉处理意见，若同意，则对应的申诉处理人可以更改任务相关信息，否则不能更改。
2. 数据输入
申诉信息、任务信息。
4.4.1.9 任务延期处理
1. 功能说明
任务的结束状态有3种：正常完成、未完成、延期。延期分为非正常延期、正常延期。
以任务发布者为X，第一接收人J0、Z0，最终任务承担者为Z1、J1为例说明。
1)延期申请逐级向上申请。
2)Z1提交申请给Z0，Z0可以决定是否同意Z1延期。若不同意则拒绝Z1的延期申请；若同意，则新建延期申请至X。
3)对任务发布者而言，处理的应该是来自J0、Z0的延期申请。若不同意则拒绝；若同意则修改任务完成期限。
4)对任务正在进行中，任务第一接收者认为时间来不及了，申请延期，任务发布者可以同意延期申请，并修改任务完成期限。
5)由任务发布者决定延期如何处理，但可能在任务发布者和接收者之间存在争议，这时交由专人在任务申诉处理模块中操作。
2. 数据输入
申诉信息、任务信息。
4.4.1.7 操作授权
1. 功能说明
增加完成代理人，例如出差时可以授权给他人完成自己的操作，但代理人的操作记录在系统日志中。授权人可以查看代理人在自己授权期间进行的操作。
2. 数据输入
申诉信息、任务信息。
4.4.1.10 任务查询
1. 功能说明
通过此功能可以查询任务信息。
具体功能需求如下。
1)可以查询自己发布的所有任务信息。
2)可以查询自己接收的所有任务信息。
3)可以查询自己是知晓者的所有任务信息。
下列查询与权限设置相关。
在权限设置中可以设置用户查看其他用户的任务信息（包括发布的任务、接收的任务、知晓的任务）。
1)可以查询到有权限查看的用户的所有发布的任务信息。
2)可以查询到有权限查看的用户的所有接收的任务信息。
3)可以查询到有权限查看的用户的所有知晓的任务信息。
2. 数据输入
任务相关信息。
4.4.1.11 任务统计
1. 功能说明
此功能模块一般只有少数管理者可以使用，此模块用来完成所有任务信息的查询和统计。
具体功能需求如下：
1)根据查询条件对所有任务信息进行查询，例如根据时间、任务发布者等条
件，也可以根据任务所属项目来查询该项目产生的所有任务信息。
2)可按时间段、人员、部门进行任务完成率、完成情况统计，并输出图形。
具体汇总表格待定。
3)对于未正常完成的任务信息，可以对原因（未完成的原因由任务接收者在
提交任务结束（延期结束）时选择）进行汇总，用户通过汇总表格对原因进行分析。
4)可将查询结果导出至Excel表格。导出的格式待定。
2. 数据输入
任务相关信息。
4.4.1.12 任务统计发布
1. 功能说明
此功能模块一般只有少数管理者可以使用。此功能用来完成常规统计，并定期发布统计结果。统计汇总Excel表格在4.4.1.9中生成。
具体功能需求如下：
1)发布统计结果。以Excel表格附件的形式发布。
2. 数据输入
任务相关信息。
信息系统需求说明书信息系统专业
目录 一、引言 1.1编写说明 (3) 1.2编写目的 (3) 1.3系统目标 (3) 1.4参考文献 (3) 1.5业务流程 (4) 二、用户需求 2.1业务需求 (4) 2.2性能需求 (4) 三、业务流程 3.1数据流程图 (5) 3.2UC矩阵 (7) 四、系统分析 4.1用例图及用例分析 (8) 4.2类图 (16) 4.3 E-R图 (17) 4.4事件流程图 (18) 五、功能 5.1包图 (22) 5.2系统功能 (24) 5.3系统功能的模块 (24) 六、数据调查及分析 6.1数据字典 (26) 6.2数据项描述 (32) 七、系统运用技术分析 7.1主要技术 (33) 7.2开发模式 (33) 7.3项目完成主要步骤 (33) 八、系统重要代码 8.1登陆部分 (34) 8.2卖票部分 (36) 九、风险说明 9.1信息系统面临的主要风险 (40) 9.2风险的处理策略 (41) 十、遗留问题 (42) 十一、总结 (42)
§1引言 随着人们生活水平的不断提升，看电影已经成为越来越多人业余时间消遣和放松的一种必要方式和渠道，人们对电影院的要求也随之不断提高，因此，电影院为了提高自身的竞争力而开发电影信息系统管理软件，在以后的运营中为用户提供更加优质的服务。 §1.1编写说明 项目开发的提出者为在校的学生，开发者为刘储文、赵越、徐燕、杨晓亮、刘玉，已明确用户有：各大电影院。 用户特点：各大电影院的工作人员、管理人员和影院顾客。 §1.2编写目的 此文档定义了该电影院管理系统的规格和功能说明。 该文档的使用者主要为系统的管理人员，使用人员和维护人员。 部分文档中提到的功能在实际操作中因技术限制未能全部实现。 目的是使该程序的使用人员，运行人员和管理人员对该系统的功能有一个统一的认知,方便人员的使用和维护。 §1.3 系统目标 软件开发的意图为便于电影院的管理，方便查看有关电影及放映的情况。如电影院队职工、顾客、电影信息的查找、删除、修改和添加。 §1.4参考文献 （1）杨选辉《信息系统分析与设计》清华大学出版社 （2）王少锋《面向对象技术UML教程》清华大学出版社 （4）萨师煊《数据库系统概论》高等教育出版社 §1.5业务过程
《软件需求说明书》 1引言 1.1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独
立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。| 2.2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束 2.3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3需求规定 3.1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3.2对性能的规定 3.2.1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2时间特性要求 说明对于该软件的时间特性要求，如对： a．响应时间； b．更新处理时间； c．数据的转换和传送时间； d．解题时间；等的要求。 3.2.3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化； b．运行环境的变化； c．同其他软件的接口的变化；
软件开发方向 “成绩管理系统”软件需求规约 安博教育集团 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (6) 2.3 运行环境 (7) 2.4 假设与依赖 (7) 3 系统特性 (8) 3.1 系统角色 (8) 3.2 学生管理 (8) 3.2.1 增加学生信息 (8) 3.2.2 修改学生信息 (9) 3.2.3 删除学生信息 (9) 3.2.4 导入学生信息 (9) 3.3 教师管理 (9) 3.3.1 增加教师信息 (9) 3.3.2 修改教师信息 (9) 3.3.3 删除教师信息 (9)
3.3.4 导入教师信息 (9) 3.4 课程管理 (10) 3.4.1 增加课程基本信息 (10) 3.4.2 修改课程基本信息 (10) 3.4.3 删除课程基本信息 (10) 3.4.4 维护课程学生信息 (10) 3.5 成绩查询 (11) 3.5.1 学生查询成绩 (11) 3.5.2 教师查询成绩 (11) 3.6 成绩分析与统计 (11) 3.6.1 考试成绩表 (11) 3.6.2 班级各科平均成绩表 (11) 3.6.3 年级成绩排名表 (11) 3.7 系统维护 (12) 3.7.1 数据字典维护 (12) 4 非功能性需求 (12) 4.1 性能需求 (12) 4.2 安全性需求 (12) 4.3 可用性需求 (13) 4.4 用户文档 (13) 4.5 其它需求 (13) 5 外部接口需求 (14) 5.1 用户接口 (14) 5.2 硬件接口 (14)
需求规格说明书
目录 第一章综述 (1) 1.1编制目的 (1) 1.2适用范围 (1) 1.3参考依据 (1) 1.4编制约束 (1) 1.4.1图元约束 (1) 1.4.2编码约束 (2) 1.4.3格式约束 (3) 1.5内容结构（可选） (4) 1.6导读说明 (4) 第二章项目概述 (5) 2.1项目背景 (5) 2.2项目范围 (5) 2.3项目目标 (5) 2.4现状描述 (5) 第三章需求总体分析 (6) 3.1功能体系设计 (6) 3.1.1功能结构 (6) 3.1.2功能分布 (7) 3.2整体业务流程（可选） (8) 3.3业务标准体系 (9) 第四章功能性需求 (10) 4.1功能综述 (10) 4.2需求清单 (10) 4.3需求优先级（可选） (10) 4.4功能编码?功能项 (11) 4.4.1功能综述 (11) 4.4.2业务流程 (11) 4.4.3关系分析 (13) 4.4.4详细功能需求 (13) 第五章非功能性需求 (17) 5.1软件质量属性需求 (17) 5.1.1运行期 (17) 5.1.2非运行期 (20) 5.2约束性需求 (21) 5.2.1基础架构 (21) 5.2.2标准规范 (21) 5.2.3集成要求 (21) 5.2.4其他约束 (21) 第六章集成需求 (22)
6.1技术要求 (22) 6.2数据集成 (22) 6.3应用集成 (22) 6.4流程集成 (23) 第七章尚需解决的问题 (24) 7.1问题总表 (25) 7.2问题处理 (25) 附录I 业务对象 (26)
第一章综述 若采用分册编制方式组织，则本章与第二章、第三章单独成册，其它分册可略去本章、第二章和第三章内容。 1.1编制目的 用简洁的语言描述编写这个文档的目的。 1.2适用范围 本文档适用的范围。 1.3参考依据 列举编写软件需求规格说明时所参考的资料或其它资源。这可能包括且不限于：用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。对于非易获得性或项目所专属的参考资料，应当以附件形式提供。 1.4编制约束 1.4.1图元约束 （1）流程图图元约束：
教学管理信息系统需求规格说明书
1.引言 1.1编写目的 1.2项目背景 1.3定义 1.4参考资料 2.任务概述 2.1目标 2.1.1理念目标 2.1.2功能目标 2.2运行环境 2.3条件与限制 2.3.1技术限制 2.3.2使用限制 3.数据描述 3.1静态数据 3.2动态数据 3.3数据库介绍 3.4数据字典 3.4.1数据流词条描述 3.4.2数据文件词条描述 3.4.3加工逻辑词条描述 3.4.4源点及汇点词条描述 4.功能需求 4.1功能划分 4.2功能描述 5.性能需求 5.1数据精确度 5.2时间特性 5.3适应性 6.运行需求 6.1硬件接口 6.2软件接口 6.3故障处理 7.其它需求
1.引言 1.1编写目的 本软件需求规格说明书是系统分析人员与用户进行了大量的交流后写成的，比较全面的描述了用户的各种需求。该文档确定了待开发软件的功能、性能、数据、界面等要求，并确定了系统的逻辑结构。为今后的开发人员进行系统开发提供了依据，也为项目经理、设计人员、营销人员、用户、测试文档的编写人员提供了参考。 1.2项目背景 项目名称：教学管理信息系统 项目任务提出者：齐鲁工业大学 项目开发者：张云、张丽梅、邓蓓蓓、陈瑞红、林慧萍、郑惠 项目用户：齐鲁工业大学所有管理人员和学生 随着学校教育水平的不断提高，学校规模不断扩大，传统的C/S结构的信息管理软件已经远远不能够满足学校的需求，已经成为学校进一步发展的瓶颈。经总结，这类信息系统存在如下的缺陷：①软件维护的费用高。②信息查询不方便。③不利与远程管理。④软件的可操作性不高。 为了眤补这些缺陷，消除影响进一步发展的瓶颈，降低学校的信息软件维护成本，进一步方便学生使用，方便教职工管理，我们项目组决定在这次软件开发过程中，开发基于B/S架构的教学管理信息系统。 1.3 定义 JavaWeb：是用Java技术来解决相关Web互联网邻域的技术总和 MySQL：MySQL是一个小型关系型数据库管理系统 MVC：模型，视图和控制。目的是实现Web系统的职能分工。 主键：数据库表中的关键域，值互不相同。 外部主键：数据库表中与其他表主键关联的域。 1.4 参考资料 1.张海藩.软件工程导论.北京：清华出版社，2008.2 2.王珊.数据库系统原理教程.北京：高等教育出版社，2006.5 3.刘利民.《软件工程综合设计》指导书.XX工业大学，2009.3 2.任务概述 2.1 目标 用户对系统的具体要求，摸清相关业务的具体流程，收集相关的信息、表格和文本，并对这些信息进行分析处理，制定面向现实世界的系统模型，如绘制业务流程图和E??—R图，制作数据字典等，为系统设计做好前期准备工作。 2.1.1理念目标 进一步提高学校的信息化管理水平，方便学生对个人基本信息及成绩的查询，方便教职工的管理，降低学校信息管理软件的维护成本。 2.12功能目标
XXX项目 软件需求规格说明书 XXXX 20 年月日
文档信息 修订历史 文档编制、审核与批准
目录 1引言 (1) 1.1 目的 (1) 1.2范围 (1) 1.3定义、简写和缩略语 (1) 1.4引用文件 (1) 1.5综述 (2) 2总体描述 (2) 2.1产品描述 (2) 2.1.1系统接口 (2) 2.1.2用户界面 (2) 2.1.3硬件接口 (3) 2.1.4软件接口 (3) 2.1.5通信接口 (3) 2.1.6内存约束 (3) 2.1.7操作 (3) 2.1.8现场适应性需求 (4) 2.2产品功能 (4) 2.3用户特点 (4) 2.4约束 (4) 2.5假设和依赖关系 (5) 2.6需求分配 (5) 3具体需求 (5) 3.1外部接口 (5) 3.2功能 (6) 3.3性能需求 (7) 3.4数据库逻辑需求 (8) 3.5设计约束 (8) 3.5.1标准依从性 (8) 3.6软件系统属性 (8) 3.6.1可靠性 (9) 3.6.2可用性 (9) 3.6.3安全保密性 (9) 3.6.4可维护性 (9) 3.6.5可移植性 (9) 3.7具体需求的组织 (9) 3.7.1系统模式 (10) 3.7.2用户类型 (11) 3.7.3对象 (11) 3.7.4特征 (11) 3.7.5激励 (11) 3.7.6响应 (11) 3.7.7功能层次 (11)
3.8附加说明 (12) 4附录 (12)
1引言 本部分应当提供整个SRS的概述 1.1 目的 本条宜： a)描述SRS的目的； b)说明SRS的预期读者。 1.2范围 本条宜： a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等）； b)必要时，说明软件产品将做或不做什么； c)描述规定的软件的应用，包括相关的收益、目标和目的； d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。 1.3定义、简写和缩略语 本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。 1.4引用文件 本条宜：
软件需求分析规格说明书格式 2008年03月28日11:08:00 chenguang79阅读数：1993 1.引言 1.1编写的目的 /*说明编写本说明书的目的 1.2背景说明 /*给出待开发系统的全名及项目提出者，开发者，及用户。同时说明该软件系统将做什么和不做什么。 1.3术语定义 1.4参考资料 /*列出本文档所引用的全部资料以及资料的来源。 2. 任务概述 2.1功能概述 /*简要叙述本系统预计实现的主要功能及功能之间的相互关系，最好用图表明。 2.2约束条件 /* 简要说明对系统设计产生影响的限制备件，如管理模式，硬件限制，技术或工具的制约等。 3. 数据流图与数据字典 3.1 数据流图 3.1.1 数据流图图形 /*将需求分析构造的数据流图按层次逐层画出。 3.1.2加工说明 /*对数据流图中的每一个加工，按编号，加工名，输入流，输出流及加工过程逐一说明。 3.2 数据字典 /*本节对数据流图中使用的数据项，数据结构，文件的内容及组织结构逐项说明. 3.2.1 数据项说明 3.2.2数据结构说明 3.2.3文件说明 4 系统接口 4.1 用户接口 /*说明人机交互界面的用户需求，如屏幕格式，报表，菜单的格式与内容及功能键定义。 4.2 硬件接口 /* 说明本软件系统与硬件设备的接口信息的内容，格式以及运行软件的硬件设
备特征。 4.3 软件接口 /*说明本软件系统与其它支持软件之间的接口规格，支持软件应明确其版本号。 5. 性能需求 5.1 精度要求 /* 说明输入/输出数据以及传输数据的精度要求。 5.2时间特征 /* 定量说明系统应达到的响应时间，更新处理时间，数据传输转换时间，计算时间的特征值 5.3灵活性 /* 说明本软件在需求发生变化时(操作方式，精度要求，时间特征等)的适应能力。 6 软件属性 6.1 可使用性 /* 规定系统的某些特殊需求，如检查点设置，恢复方法和重启动方法，以确保软件可使用。 6.2 系统安全性 /* 规定系统为保证运行安全，信息安全面而采用的技术措施，如密码，防病毒，防黑客等。 6.3 可维护性 /* 规定系统为提高系统的可维护性将采取的措施。 6.4 可移植性 /* 规定程序以及挡方面军的兼容性，扩充性的约束。 7 其它需求 7.1 数据库需求 /*对数据库的静态结构，动态组织，访问信息的方式，使用频率以及数据的存储等方面提出需求。 7.2 系统操作要求 /*列出系统所要求的正确或特殊的操作方式，如用户的操作方式和系统的后援和恢复操作。 7.3 故障及其处理 /* 尽量烈列出能够预测的系统故障(包括软硬件及其它系统)，并指出故障可能造成的影响及故障排除的方法。 8 附录
需求分析说明书 1. 引言 (3) 1.1 编写目的 (3) 1.2 项目风险 (3) 1.3 预期读者和阅读建议 (5) 1.4 产品范围 (5) 1.5 参考文献 (5) 2. 系统总体概述 (6) 2.1 目标 (6) 2.2 用户类和特性 (7) 2.3 运行环境 (7) 2.3.1 硬件环境 (7) 2.3.2 软件环境 (7) 2.4 设计和实现上的限制 (7) 2.5 假设和约束(依赖) (8) 2.5.1 产品的SEO排名 (8) 2.5.3系统的安全 (8) 3. 外部接口需求 (8) 3.1 用户界面 (8) 3.2 硬件接口 (8) 3.3 软件接口 (8) 3.4 通讯接口 (9) 4. 系统特性 (9) 4.1 说明和优先级 (9) 4.2 激励／响应序列 (9) 4.3 功能需求 (9) 4.4 功能详述 (12) 4.4.1以使用软件的汽车用户为例： (12) 5. 其它非功能需求 (13) 5.1 性能需求 (13) 5.2 安全措施需求 (13) 5.3 安全性需求 (14) 5.4 操作需求 (14) 5.5 软件质量属性 (14) 5.6 业务规则 (14) 5.7 用户文档 (14) 6. 词汇表 (14) 6.1 SSH (14)
6.2 JAVA (14) 6.3 MYSQL (15) 7. 待定问题列表 (15)
1. 引言 1.1 编写目的 本需求分析说明书对本项目第一阶段的内容进行分析，对需求细节和实现方式进行了较为详细的阐述。本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用，并作为产品验收确认的依据。 需求分析是在可行性研究的基础上，将用户对系统的描述，通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。可行性研究旨在评估目标系统是否值得去开发，问题是否能够解决，而需求分析旨在回答"系统做什么"的问题，确保将来开发出来的软件产品能够真正满足用户的需要。 构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。 需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以，开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。 有效的需求分析通常都具有一定的难度，一方面是因为交流存在障碍，另一方面是因为用户通常对需求的陈述不完备、不准确和不全面，并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。此外，把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。 在进行需求分析的过程中，首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性，需求往往很难做到一步到位。需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。 此外，为了方便后续的评审和测试等工作，需求的描述应该尽量做到：具体、详细、可以测量和可以实现，并且基于时间。 1.2 项目风险 政策风险分析： 随着社会的进步与人们生活水平的提高大幅度增加，尤其在我国汽车进入家庭的条件下，需要更多的适合现代汽车技术要求和社会经济承受能力的汽车维修检测设备，为了让四轮定位仪市场变得规范、有序，中国汽车保修设备行业协会与全国汽车维修标准化技术委员会于2004年，制定了四轮定位仪的行业标准（标准号JT/T505-2004），国家交通部2004年国标GB/T16739.1-.2-2004《汽车维修业开业条件》规定：一、二类汽车维修企业必须配备
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
出行服务网站 产品需求规格说明书 部门： 时间:
目录 1引言................................................ 错误!未定义书签。 编写目的....................................... 错误!未定义书签。 项目背景....................................... 错误!未定义书签。 术语定义及编写说明............................. 错误!未定义书签。 版本更新信息................................... 错误!未定义书签。2产品定义............................................ 错误!未定义书签。 应用目标....................................... 错误!未定义书签。 产品业务流程........................................ 错误!未定义书签。 接口描述............................................ 错误!未定义书签。3应用环境............................................ 错误!未定义书签。 设备环境....................................... 错误!未定义书签。 系统运行的硬件环境............................. 错误!未定义书签。 系统运行的软件环境............................. 错误!未定义书签。 系统运行的网络环境............................. 错误!未定义书签。 用户操作模式................................... 错误!未定义书签。4功能规格............................................ 错误!未定义书签。 前台功能....................................... 错误!未定义书签。MISP网站系统前台主要功能如下图所示：................... 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。 Function ................................ 错误!未定义书签。
专 组号：小组成员： 完成时间：
目录 1.系统概述 (3) 1.1. 系统功能简介 (3) 1.2 系统用户角色 (3) 2.理由 (3) 3.项目范围 (3) 4.系统假设 (3) 5.系统定义 (4) 6.用户场景 (5) 7.用户用例 (5) 7.1 用户用例步骤 (5) 7.2系统需求 (9) 7.2.1 功能需求 (9) 7.2.2 非功能需求 (12) 8.文档历史 (14)
1.系统概述 1.1. 系统功能简介 教务处工作人员根据设置的用户名和密码，登录到学生信息管理系统，并对学生提交的信息修改进行审核,,系统优先级高; 档案管理员添加、查看、删除、修改学生的基本信息, 系统优先级高; 老师查看自己所管班级的学生的信息, 系统优先级高; 学生修改、查看自己的某些信息, 系统优先级高; 1.2 系统用户角色 2.理由 由于现在的学校规模在逐渐的扩大，设置的专业类别、分支机构及老师、学生人数越来越多，对于过去的学生信息管理系统，不能满足当前学生信息管理的服务性能要求。本报告对于开发新的<<学生信息管理系统>>面临的问题及解决方案进行初步的设计与合理的安排，对用户需求进行了全面细致的分析，更清晰的理解学生信息管理系统业务需求，深入描述软件的功能和性能与界面，确定该软件设计的限制和定义软件的其他有效性需求，对开发计划进行了总体的规划确定开发的需求与面临困难的可行性分析。 3.项目范围 学生信息管理系统是典型的信息管理系统，其开发主要包括后台数据库的建立、维护以及前端应用程序的开发两个方面。对于前者要求建立起数据一致性和完整性强、数据安全性好的数据库。而对于后者则要求应用程序具有功能完备，易使用等特点。学生信息管理系统对全校学生实行统一的管理，可以方便的进行增添、查询、修改、删除学生信息的工作。为了使本系统成功达到用户的要求，需要在2012.12.28之前完成本系统的开发测试，并写提交相关的技术文档。通过与用户的沟通，及时获得用户的最新需求以便于本系统的完善。 4.系统假设 本项目的开发时间为2012.9.9—2012.12.28 开发人员人数：3人 技术文档写作人员人数3人
WORD文档可编辑 X X X X X X单位 X X X X X X X项目 软件需求规格说明书 金碧信息科技
目录 第一章引言 (5) 1编写目的 (5) 2软件需求分析理论 (5) 3软件需求分析目标 (5) 4参考文献 (6) 第二章需求概述 (7) 1.项目背景 (7) 2.需求概述 (7) 3.条件与限制(可选) (8) 4.移动办公系统结构 (8) 5.移动办公网络拓扑图 (9) 第三章系统功能需求 (10) 1.移动办公系统升级改造需求 (10) 界面显示要求 (11) 待办公文列表 (11) 待办公文列表排序 (11) 公文详细信息界面元素 (11) 网站信息审批 (12) 会议申请 (12) 意见录入 (12) 移动邮件 (12) 会议管理 (13) 通知通告 (13) 通讯录管理 (14) 2.车辆管理模块升级改造需求 (14) 系统功能架构 (14) 网络拓扑结构 (15)
3.电子公文预览需求 (15) 电子公文交换网络 (16) 电子公文交换流程 (18) 4.政务信息管理系统平台功能需求 (19) 第四章软硬件或其他外部系统接口需求 (21) 1.用户界面 (21) 2.硬件需求 (22) 3.网络需求 (22) 4.接口需求 (22) 5.通信需求 (23) 6.运行环境 (23) 第五章其他非功能需求 (24) 1.性能需求 (24) 2.安全设施需求 (25) 3.安全性需求 (25) 4.扩展性需求 (26) 5.可移植性需求 (26)
第一章引言 1编写目的 为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。 2软件需求分析理论 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 3软件需求分析目标 软件需求分析的主要实现目标： 1)对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一 致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件 需求； 2)了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一 个基准； 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员
软件开发方向“成绩管理系统”软件需求规约 二零零八年十月
修订历史记录
目录 1 引言 (5) 1.1 目的 (5) 1.2 文档格式 (5) 1.3 预期的读者和阅读建议 (5) 1.4 范围 (6) 1.5 术语 (6) 1.6 参考文献 (6) 2 系统概述 (6) 2.1 概述 (6) 2.2 功能 (7) 2.3 运行环境 (8) 2.4 假设与依赖 (8) 3 系统特性 (9) 3.1 系统角色 (9) 3.2 学生管理 (10) 3.2.1 增加学生信息 (10) 3.2.2 修改学生信息 (10) 3.2.3 删除学生信息 (10) 3.2.4 导入学生信息 (10) 3.3 教师管理 (11) 3.3.1 增加教师信息 (11) 3.3.2 修改教师信息 (11) 3.3.3 删除教师信息 (11) 3.3.4 导入教师信息 (11) 3.4 课程管理 (12) 3.4.1 增加课程基本信息 (12) 3.4.2 修改课程基本信息 (12) 3.4.3 删除课程基本信息 (12) 3.4.4 维护课程学生信息 (12) 3.5 成绩查询 (13) 3.5.1 学生查询成绩 (13) 3.5.2 教师查询成绩 (13) 3.6 成绩分析与统计 (13) 3.6.1 考试成绩表 (13) 3.6.2 班级各科平均成绩表 (13) 3.6.3 年级成绩排名表 (14) 3.7 系统维护 (14) 3.7.1 数据字典维护 (14) 4 非功能性需求 (14) 4.1 性能需求 (14) 4.2 安全性需求 (14) 4.3 可用性需求 (15)
农贸市场信息管理系统
农贸市场信息管理系统 需求规格说明书
1 / 17
农贸市场信息管理系统
文件状态： [ ] 草稿 [√] 正式发布 [ ] 正在修改
系统名称： 当前版本： 作 者： 完成日期：
农贸市场信息管理系统
王金鑫 季猛 袁梦 李美林 2016 年 6 月 22 日
目录
1 文档介绍 ................................................................. 3 1.1 文档目的 ............................................................. 3 1.2 文档范围 ............................................................. 4 1.3 读者对象 ............................................................. 4 1.4 参考文档 ............................................................. 4 1.5 术语与缩写解释 ....................................................... 5
2 / 17
农贸市场信息管理系统
2 产品介绍 ................................................................. 5 3 产品面向的用户群体 ....................................................... 6 4 产品应当遵循的标准或规范 ................................................. 6 5 产品范围 ................................................................. 6 6 产品中的角色 ............................................................. 6 7 产品的功能性需求 ......................................................... 7
7.1 功能性需求分类....................................................... 7 7.2 用例图............................................................... 8 7.3 用例描述............................................................ 11 8 产品的非功能性需求 ...................................................... 12 8.1 用户界面需求...................................................... 13 8.2 产品质量需求........................................................ 14 9 开发及运行环境 .......................................................... 15 9.1 开发环境............................................................ 15 9.2 运行环境............................................................ 16 10 开发团队及分工 ......................................................... 16
1 文档介绍 1.1文档目的
3 / 17
软件需求说明书 （转载自国家计算机标准和文件模板） 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 1.引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2 背景 说明： a.待开发的软件系统的名称； b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； c.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a.本项目的经核准的计划任务书或合同、上级机关的批文； b.属于本项目的其他已发表的文件； c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2. 任务概述 2.1 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说
明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束。 2.3 假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3. 需求规定 3.1 对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3.2 对性能的规定 3.2.1 精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2 时间特性要求 说明对于该软件的时间特性要求，如对： a.响应时间； b.更新处理时间； c.数据的转换和传送时间； d.解题时间；等的要求。 3.2.3 灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a.操作方式上的变化； b.运行环境的变化；
软件需求分析说明书集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
学生信息管理系统 需求分析说明书 1.引言 编写目的 确定学生信息管理系统功能的有效性需求；以供本系统的开发人员参考。 项目背景 开发软件名称：学生信息管理系统。 用户：教学办公室 项目和其他软件：系统的关系。 本项目采用客户机/服务器原理，客户端程序是建立在window NT系统上以 Java为开发软件的应用程序，服务器端采用Linux为操作系统的工作站，是采用Oracle 的为开发软件的数据库服务程序。 定义 学号：学校给学生的编号，用来区分各个学生的信息的中介。 课程名：学校开设课程的名字 Java+SQL：编写该系统的面向对象的开发语言和数据库语言。
参考资料 ⑴《Oracle从入门到精通》 ⑵《JAVA程序设计项目教程》 ⑶《数据库原理及应用》 ⑷《软件工程案例教程》 2．任务概述 目标 ⑴开发意图：由于学校的不断招生，现有的系统空间小，运行速度缓慢，操作过于复 杂，有的操作还不能执行，所以要开发本系统。 ⑵应用目标：学生信息管理系统将解决现有系统的空间不足，运行缓慢，操作复杂，操 作无效等问题。 运行环境 本系统采用C/S体系结构 操作系统：Microsoft Windows xp 支持环境：IIS 数据库：Oracle 软件设备：eclipse 内存：512 M以上 硬盘空间：40G以上 CPU: 233MHZ以上
内存：256M以上 硬盘空间：以上 假定与约束 使用本系统的用户群集中在 22-35 岁的年轻人，用来做学生信息的存储，对计算机的操作一般比较熟练。根据他们对本程序的认可、方便操作的程度，结合他们日常工作的频繁程度，系统每天操作完成一个功能点应该在 2- 10 次之间。用户对界面的友好性，有非常高的要求。本系统的规模比较小，并且将提供操作手册进行操作项的详细说明 （1）、Client/Server结构总体设计方案对它的约束：本系统做为Client/Server 结构的一个应用系统，不可避免的要受到Client/Server结构的约束。在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。同时，由于信息的共享，机票预订系统还受到其它系统的信息约束。 （2）、人力、时间的约束：本系统开发过程中也要考虑到人力、资金和时间的约束。 （3）、技术发展规律的约束：计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。例如图象和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。 3．需求规定 对功能的规定 系统流程图：系统流程图是用户操作此系统的流程和各个用户能够操作的功能，如A-1就是一个系统流程图；用户有系统管理员，教师和学生，每个用户要进入此系统都要登录。每个用户有不同的功能，系统管理员有查询，增加，修改，删除，修改密码，设置权限等功能；教师有查询，修改密码和输入学生成绩的功能；学生只有查询和修改密码的功能。 A-1系统流程图 用例图：用例图是用来表示用户能使用的功能和权限。如图A-2表示系统管理员可以运用的功能，像修改密码，管理学生信息、成绩信息、课程信息、班级信息并且设置权