两网站需求分析模板

目 录

1. 引言 1

1.1. 背景 1

1.2. 参考资料 1

1.3. 假定和约束 1

1.4. 用户的特点 1

2. 功能需求 1

2.1. 系统范围 1

2.2. 系统体系结构（二层架构的系统可剪裁本小节） 1

2.3. 系统总体流程 2

2.4. 需求分析 2

2.4.1. XXXXXXX(功能需求名称) 2

2.4.1.1. 功能描述 2

2.4.1.2. 业务建模 2

2.4.1.3. 用例描述 3

2.4.1.4. 用户界面 5

2.4.2. XXXXXXX(功能需求名称) 5

3. 非功能需求 5

3.1. 性能要求 5

3.1.1. 精度 5

3.1.2. 时间特性要求 6

3.1.3. 输人输出要求 6

3.2. 数据管理能力要求 6

3.3. 安全保密性要求 6

3.4. 灵活性要求 6

3.5. 其他专门要求 6

4. 运行环境规定 6

4.1. 设备 6

4.2. 支持软件 7

4.3. 接口 7

4.4. 控制 7

5. 需求跟踪 7

6. 签批单 7

1. 引言

1.1. 背景

说明：

a．待开发的软件系统的名称；

b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

C．该软件系统同其他系统或其他机构的基本的相互来往关系。

1.2. 参考资料

列出本说明书中引用和参考的资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他已发表的文件；

c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

1.3. 假定和约束[可选]

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。

1.4. 用户的特点[可选]

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。

2. 功能需求

2.1. 系统范围

明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。

如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选]

以图+文本结合的方式描述系统的总体架构。

以下应提供系统总体架构图：

以下对系统总体架构进行描述：

2.3. 系统总体流程

以图+文本结合的方式说明系统的总体流程。

图一是计划合同管理系统的总体流程图。

图一

2.4. 需求分析

需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？

· 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系

· 描述用例：角色与系统如何交互的规格说明。

2.4.1. XXXXXXX(功能需求名称)

2.4.1.1. 功能描述

功能编号：

功能需求：从用户业务的角度描述功能需求。

2.4.1.2. 业务建模

从可视化的角度--用例图--描述功能需求

图二是综合计划管理系统合同编辑业务的功能需求用例图。

图二

2.4.1.3. 用例描述

以文本的方式描述每一个用例中角色与系统相互交互的规格说明。

1、 XXXXXX(用例名称)

描述对象 描述内容

标识符 用例的唯一标识符

说明 对用例的概要说明

参与者 与该用例相关的参与者列表，以及参与者的特点

频度 参与者访问此用例的频率

状态 通常分为：进行中、等待审查、通过审查或未通过审查

前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足 后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足 被扩展的用例 此用例所扩展的用例（如果存在）

被包含的用例 此用例所包含的用例（如果存在）

基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式

可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径

修改历史记录 修改人 ： 修改日期：修改原因：

问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表

以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述：

描述对象 描述内容

标识符 IPMS0101

说明 增加一条合同记录

参与者 合同编辑人员--熟悉合同管理业务

频度

状态 通过审查

前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价)

后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例

被扩展的用例 无

被包含的用例 无

基本操作流程 请参见图三的合同增加流程

可选操作流程 当用户确认合同增加时发现异常时，系统提示合同增加无效的提示 修改历史记录 修改人 ： 修改日期：修改原因：

问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计

图三 合同增加活动流程

2、XXXXX(用例名称)

……

2.4.1.4. 用户界面

概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。

2.4.2. XXXXXXX(功能需求名称)

……

3. 非功能需求

3.1. 性能要求

3.1.1. 精度[可选]

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

3.1.2. 时间特性要求

说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。

3.1.3. 输人输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.2. 数据管理能力要求[可选]

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。

3.3. 安全保密性要求

用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。

3.4. 灵活性要求[可选]

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：

a．操作方式上的变化；

b．运行环境的变化；

c．同其他软件的接口的变化；

d．精度和有效时限的变化；

e．计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.5. 其他专门要求[可选]

如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。

4. 运行环境规定

4.1. 设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a．处理器型号及内存容量；

b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c．输入及输出设备的型号和数量，联机或脱机；

d．数据通信设备的型号和数量；

e．功能键及其他专用硬件

4.2. 支持软件

列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。

4.3. 接口[可选]

说明该软件同其他软件之间的接口、数据通信协议等。

4.4. 控制[可选]

说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

5. 需求跟踪

需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。

6. 签批单

我已阅读上述软件需求规格说明书，我将严格遵守说明书中的条款，并保证全力支持该规格说明书的实施。

执行主管:

日期

技术主管:

日期

项目组长:

日期

用户代表:

日期

开发人员代表:

日期

小组成员:

日期

小组成员:

第二篇：软件需求分析模板

选修课选课系统

需求说明书

目录

选修课选课系统的需求分析

1 前言

选修课选课系统的需求分析说明书。本选课系统需要满足来自三方面的需求，这三个方面分别是学生、教师和管理员。

目的本项目所开发的学生选课系统完成学校对学生的选课信息的统计与管理，减少数据漏掉的情况，同时也节约人力、物力和财力。告别以往的人工统计。

1．1 目的

在这一条包括下列内容：

a. 编写本文档的目的在于详细、准确和全面的定义本选课系统的功能和和用户需求，用以指导系统顺利地进行开发，并保证后续地开发能够保质保量的完成。本文档所描述的需求信息将作为该项目最终验收的标准和依据。

b. 本文档所描述的需求信息将作为该项目最终验收的标准和依据。

1．2 范围

a. 用一个名字标识被生产的软件产品。比如：×××数据库系统，报表生成程序等等； b. 说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么；

c. 描述所说明的软件的应用。应当：

(1) 尽可能精确地描述所有相关的利闪、目的、以及最终目标。

(2) 如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相

一致（例如，系统的需求规格说明）。

1．3 定义、缩写词、略语

B/S ： 即浏览器/服务器结构，基于浏览器的使用。

用户： 用户分学生、老师和系统管理员，角色不同，所使用的功能不同。 网站： Internet 上提供Web服务的计算机。该计算机的IP绑定了域名，在浏览器输入域名就可以访问该计算机的web资源

1．4 参考资料

本条应包括：

a. 在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关批文、合同等；

b. 列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。每一个文件、文献要有标题，索引号或文件号，发布或发表日期以及出版单位；

c. 详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其他文件提供。

i

2 项目概述

本项目所开发的学生选课系统完成学校对学生的选课信息的统计与管理，减少数据漏掉的情况，同时也节约人力、物力和财力。告别以往的人工统计。

本项目开发的软件采用 B/S结构，方便学生、老师、管理员使用，学生可以再线查看可选课程信息、再线选课、信息修改、成绩查看，老师可以自己的课程人数、课程信息（包括开课时间、地点、开课方式），管理员可以对整个系统进行管理（包括系统管理、用户管理、课程管理）.。

2．1 产品描述

由于本系统的数据还算不上大型的。所以数据库服务器与web服务器共用同一台计算机。系统中的用户信息、系统信息和课程信息都放在数据库中。

系统用例图下图所示

2.1.1 由于本系统的数据还算不上大型的。所以数据库服务器与web服务器共用同一

台计算机。系统中的用户信息、系统信息和课程信息都放在数据库中。

(1) 选课 ： 学生可以执行选课的操作。

Step 1：成功登陆

Step 2：查看所有可选课程

Step 3：进行选课操作

(2) 查询 ：不管用户处于什么角色都可以使用查询

Step 1：用户登陆

Step 2：学生、老师和管理员分别使用的查询不一定全是相同的。

Step 3：查看相应信息

(3) 管理：系统管理员可以使用管理操作

2．2 产品功能

表2.2.1 系统功能模块

2．3 用户特点 本项目所开发的系统用户有三类，学生、老师和系统管理员。

当学校公布可以选课了，学生就应该急时登陆选课系统进行选课。对学生来说，只要有一个能上网的就行可以在浏览器登陆了。系统中有哪些可选的课程由管理员添加，课程重要的信息之一就是该课程的老师。当加入老师时。应该跟老师的信息相关联。当老师登陆时，可以查看自己所教的课程的报名情况等信息。

2．4 一般约束

此系统必须满足以后限制：

（1） 系统中所有账户能够供用户随时使用，能够随时使用相应功能。

（2） 同一时刻，所有账户不能在多个地方登陆。

（3） 学生选课数目不能超过学校限制。

（4） 不能选已经超过规定人数的的课程，不能选已经开课的课程。

（5） 没有达到规定人数的课程不能开课。

（6） 该系统必须确保所有数据安全，以免损失。所有用户都要登陆才能访问，

每个用户只能使用所属角色的权限，必要时限定访问次数。

（7） 界面友好，操作简单。

（8） 软件系统开放性好，结构灵活，可扩充，方便维护。

（9） 安全可靠。

。

2．5 假设和依据

（1） 假设学生不在学校，照样可以选课。只要有联网的电脑且有浏览器就行 。

（2） 假设用户忘记密码，系统设置找回密码的方法，也可与管理员联系。

用例图

iii

3.1功能需求描述

3.1.1系统类图如下图

iv

所有的类：

学生类：包括学生的信息和学生可以执行的操作。

老师类：包括老师的信息和老师可以执行的操作。

管理员：包括管理员的信息和管理员可以执行的操作。

课程类：包括每个课程的信息和可以被执行的操作。

3.2类的详细说明

学生类：

属性：

ID：这是系统数据库中自己分配的一个号码，是唯一的，且会自动往上加的一个序列号，是数据库的关键字，以保证数据的完整性。

学号：用来存学生的学号，每个学生都有学号且唯一。

姓名：存学生的姓名。

v

性别：用来标识用户的性别。

年龄：储存用户的年龄。

入学年份：储存学生进入学校的时间。

毕业院校：记录学生上一次毕业的学校。

密码：学生登陆时所使用的密码。

方法：

登陆与注销：最基本的功能，进入时必须登陆，长时间不使用系统会自己注销用户。

修改资料：对学生自己的可以修改的信息可以进行修改。不能修改的就不能一更改。

查看课程：查看所有被选课程和个体课程的详细信息。

选课： 如果课程可以被选。就可以调用这个方法进行选课。

查看成绩： 如果学生选了某门课并且已经考试，可以查看成绩。 取消选课：如果对选的课不满意，在规定的时间内可以取消。

老师类

属性：

ID：同学生

老师工号：每个老师唯一的证件号码。

姓名：教师姓名。

性别：性别

年龄：年龄

职称：教师的职称号。

密码：登陆使用的密码。

方法

登陆/注销：最基本的方法或者功能。

修改资料：修改可以修改的自己的信息。

查看程信息：查看自己带的课或者其它课程的信息，两种情况的结果不一样。 成绩登记：当完成课程后，对学自己所带的课的学生添加成绩。

管理员

vi

属性：

ID：同学生。

用户名：登陆所用的用户名。

密码：登陆使用的。

方法：

管理用户：对学生和教师进行管理。

管理课程：对所有课程进行管理，例如添加删除课程等。

管理选课：对选课的情况进行管理。

管理成绩：对成绩进行管理，例如设置成绩录入时间的限制等。

要了解详细的方法的功能，请见系统设计说明书，第四章。

3.3 其它需求描述

3.3.1 性能要求

（1）对服务器的要求，至少能够容纳1000人同时访问。

（2）对客户端，在现在使用的电脑中，联网了就行。要求不高。

（3）地本系统，使用功能时，在网速好的情况下，系统响应时间为10秒以内，

3.3.2 设计约束

数据库： SQL

服务器操作系统：windows2003

开发语言：JAVA

服务器硬件：配置稍好就行

开发方式：个人开发。

3.3.3 进度要求

如果5到8人，在20天内应该要完成整个开发并测试。

如果5人以下，在30内应该完成整个工作并测试。

3.3.4 交付要求

该项目完成后，需向用户提交以下信息：

⑴软件需求规格说明书，电子版和纸质版。

⑵软件设计规格说明书，电子版和纸质版。

(3)可运行的软件系统。

vii

(4)部分或者全部java源码。

3.4 用户界面

界面对于用户来说至关重要，既是用户对软件评介的根据，也是用户最终使用的。所以界面设计得怎么样，对整个系统的成功与否有着密切的联系。

当然，也许界面设计得好不会让其性能更好，但是设计得不好却只会让它更差。 界面设计原则：

一致性

操作步骤少

随时提示用户系统正在进行哪些操作

要有撤销操作

减少用户记忆的东西

viii