需求文档模板_范文大全

需求文档模板

【范文精选】需求文档模板

【范文大全】需求文档模板

【专家解析】需求文档模板

【优秀范文】需求文档模板

范文一:信管需求文档模板 投稿:段醟醠

宾馆住房管理系统

需求分析

班 级: 08信管本科

分 组: 5组

编写人员:

许江峰 张程成 郎立超 左志勇

宾馆住房管理系统

签字页

版 次: Ver 1. 0 业务负责人: 项目负责人: 项目负责人: 项目负责人: 项目负责人: 项目负责人: 项目负责人:

执笔人: 杜光辉 日 期: 日 期: 日 期: 日 期: 日 期: 日 期: 日 期:

宾馆住房管理系统

目 录

1. 引言................................................................... 4

1.1文档编写目的....................................................................................................................4 1.2背景..................................................................................................................................4 1.3参考资料...........................................................................................................................4

2. 任务概述 .......................................................... 5

2.1 目标 ................................................................................................................................5 2.2 用户的特点 .....................................................................................................................5

3. 数据描述 ............................................................ 5

3.1 对功能的规定 ..................................................................................................................5

3.1.1 宾馆管理系统关联图 .............................................................................................6 注:前台接待系统即安排和退订房间 ...............................................................................6 3.1.2宾馆管理系统的E-R图 ..........................................................................................6 3.1.3客房预订系统 ........................................................................................................7 3.1.4 前台接待系统和前台收银系统 ...............................................................................9 3.1.5 客房中心管理 ..................................................................................................... 11 3.1.6特定功能模块 ...................................................................................................... 13 3.2 输人输出要求 ................................................................................................................ 16

3.2.1 输入要求 ............................................................................................................ 16 3.2.2 输出要求 ............................................................................................................ 16 3.3 数据管理能力要求 ......................................................................................................... 16 3.4故障处理要求................................................................................................................. 16 3.5 其他专门要求 ................................................................................................................ 16

宾馆住房管理系统

1. 引言

1.1文档编写目的

本文档详细介绍了宾馆管理信息系统的需求说明,为用户和领导描述出一个具体的产品模型,为软件设计、开发及测试人员提供下步工作的依据。本文档的预期读者是酒店管理系统软件开发有关的开发人员。

1.2背景

在我国,宾馆分成五星级、四星级、三星级、二星级和一星级。客房方面的管理也随着酒店的星级不同有所区别,但大体上是相同的。宾馆在正常的运营中需要对客房资源、顾客信息、结算信息进行管理,利用宾馆管理信息系统及时了解各个环节中信息的变更,有利于提高管理效率。信息社会的高科技,商品经济化的高效益,使计算机的应用已普及到经济和社会生活的各个领域。计算机虽然与人类的关系愈来愈密切,还有人由于计算机操作不方便继续用手工劳动。为了适应现代社会人们高度强烈的时间观念,宾馆管理系统软件为管理人员带来了极大的方便。通过操作手册,使用者可以了解本软件的基本工作原理。操作人员只需输入一些简单的汉字、数字,即可达到自己的目标。对于大中型宾馆来说,利用计算机支持高效率完成日常事务,是适应现代要求、推动管理走向科学化、规范化的必要条件;而且宾馆管理又是一项非常烦琐的事情,数量之大,核算极其不便。同时计算机具有手工管理所无法比拟的优点。例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。这些优点能够极大地提高宾馆管理的效率,也是宾馆的科学化、正规化管理,与世界接轨的重要条件。 说明:

① 待开发的软件系统的名称:宾馆住房管理系统; ② 本项目的任务提出者:宾馆管理人员;

③ 本项目的任务开发者:宾馆管理系统软件开发小组; ④ 用户及实现该软件的计算中心或计算机网络:宾馆计算机;

1.3参考资料

宾馆住房管理系统

①②③

1.4开发工具与平台

为了适用系统运行平台的变化性,本系统选择当今流行的Java语言作为系统的开发语言。Java语言具有跨平台的优势,相对于其他语言来说整个系统的可移植性非常高,对于平台的依赖关系非常小,只要可以安装JDK,系统就可以正常运行。 本宾馆住房管理系统确定的软件系统环境: ①需要安装Sun™ 公司发布的JDK1.6 ②操作系统:Window XP

③数据库软件:SQL Server 2000 ④开发软件为:Eclips 硬件系统环境配置:

①CPU :P4或更高处理器 ②内存:256MB ③硬盘:20G及以上

④显示器:VGA或更高分辨率的显示器 ⑤相应的输入输出设备

2. 任务概述

2.1 目标

开发本软件是为了服务宾馆,使得宾馆更好的经营。适用于一些大中型宾馆,主要用于客房管理、住宿管理、财务管理和人事管理。本软件产品是一项独立的软件,不过功能还可以增加,完成后可以升级以增加功能和完善系统。

2.2 用户的特点

使用本软件要求用户熟悉Windows 操作,并且有一定的软件操作基础。预计本软件将会在一些大中型宾馆中得到广泛使用。

3. 数据描述

3.1 对功能的规定

宾馆管理系统适合任何小型、中型以及大型宾馆管理,主要功能包括:客房预订、前台接待、前台服务、人事管理、财务管理等功能。

宾馆住房管理系统

3.1.1 宾馆管理系统关联图

注:前台接待系统即安排和退订房间

3.1.2宾馆管理系统的E-R图

图1.1 宾馆管理系统关联图

宾馆住房管理系统

图2 宾馆管理E-R图

3.1.3客房预订系统

客房预订系统的主要功能有: 散客预定、团体预定、客房预定、预定未到处理、预售查询等功能。

(1)以下是客房预定的数据流图

1:1层DFD图

宾馆住房管理系统

客房预订信息表

个人预订信息表

(2)以下是客房预订说明数据字典

客房预订信息表预订金入账

并核对“客

宾馆住房管理系统

人黑名单”(进行消费而未付帐的客人名单)及“挂帐表”,无误后收取预订押金并记入“预订金入帐表”。进行订房,将预订信息记入“客人预订信息表”,修改“客房预订信息表”的客房状态,给客人预订证明表。预订完成。

3.1.4 前台接待系统和前台收银系统

前台接待系统要实现的主要功能是:散客入住登记、合约入住登记、、补填客单、修改客人信息、调房、设置房态、客人留言等。

前台收银系统的主要功能包括:记帐 (包括客人在酒店各营业场点的消费)、埋单、退房、查帐 (可查总客帐、总消费帐)、转帐等业务。

客人一旦入住酒店,将允许客人先消费(签单),后付帐。

(1)以下是前台接待和前台收银系统的数据流图: 1:1层DFD图

客房信息表 挂账个人表

客房财务收支表 2:2层DFD图

客户信息表

宾馆住房管理系统

(2)以下是前台接待与前台收银系统的数据字典

宾馆住房管理系统

3.1.5 客房中心管理

客房种类管理主要实现的功能是:增加客房种类、删除客房种类、修改客房种类、查询客房种

类等。

客房信息管理主要实现的功能是:添加客房信息、删除客房信息、修改客房信息

综合查询的功能主要体现在:住店客单查询、查询客房状态、客房占用统计、帐务查询等方面。 (1)客房中心3层DFD图 1:1层DFD图

宾馆住房管理系统

3:2层DFD图

(2) 以下是客房中心数据字典

宾馆住房管理系统

3.1.6特定功能模块

人事管理模块主要包括了人员配置和员工详细信息

财务管理模块主要实现收银系统的功能外,还具有纠错、报表输出等功能,能将损失降至最低。并且包括了月底收入汇总、员工工资发放、净盈利情况的管理。 (1)以下是特定功能模块的DFD图 1:1层DFD图

宾馆住房管理系统

客房财务收支

3:第2层DFD图

宾馆住房管理系统

(2)以下是特定功能模块的数据字典

宾馆住房管理系统

3.2 输人输出要求

3.2.1 输入要求

输入数据基本为:旅客姓名、性别、年龄、证件名称、证件号码、工作单位、房间编号、房间

等级、房间价格等。年龄为整型数据,房间价格为浮点型数据,其余均为字符型。输入一般采用界面的形式,如编辑框,下拉框,单选框,复选框等。

3.2.2 输出要求

输出一般采用对话框形式或打印到纸上。输出数据主要有消费的金额及客户的消费历史记录。

3.3 数据管理能力要求

本软件管理的数据大都以数据库的形式存储,主要包括房间信息数据,客户信息数据,其中房间信息数据基本不变,数据库大小基本不变,而客户信息数据随着时间的推移每天都在增加,客户信息数据需要定期进行整理和处理。

3.4故障处理要求

本软件具有错误和异常的处理能力,基本不会有软件故障,保证软件能正常运行,有对数据库备份的功能,这样才使得用户满意。

3.5 其他专门要求

本软件有保密的功能,设立了系统帐号管理功能,用户登录时需要验证用户名及密码,对于三次密码输入错误的使用者则关闭此系统,这样保证了数据的安全。本软件使用也十分方便,以窗口的形式呈现给用户,很容易操作。

范文二:需求文档模板 投稿:朱鮅鮆

XXX项目小组

蓝湖网络科技有限公司

修订表

蓝湖网络科技有限公司

审批记录

蓝湖网络科技有限公司

1 引言

1.1 编写目的

• 阐明开发本软件的目的;

1.2 项目背景

标识待开发软件产品的名称、代码; • 列出本项目的任务提出者、项目负责人、系统分析员、资料员以及与本项目开展工作直接有关的人员和用户; •说明该软件产品与其他有关软件产品的相互关系。

1.3 术语说明

1.4参考资料

2

2.1待开发软件的一般描述

描述待开发软件的背景,所应达到的目标,以及市场前景等。

蓝湖网络科技有限公司

2.2待开发软件的功能

简述待开发软件所具有的主要功能。为了帮助每个读者易于理解,可以使用列表或 图形的方法进行描述。使用图形表示,可以采用: • 顶层数据流图; • 用例UseCase图; • 系统流程图; • 层次方框图。

2.3 用户特征和水平(是哪类人使用)

2.4 运行环境

件或与其共存的应用程序等。

2.5 条件与限制

• •

33.1

列举出所开发的软件能实现的全部功能,可采用文字、图表或数学公式等多种方法 进行描述。

3.2 功能描述

对各个功能进行详细的描述。

蓝湖网络科技有限公司

4外部接口需求

4.1 用户界面

对用户希望该软件所具有的界面特征进行描述。以下是可能要包括的一些特征: • 将要采用的图形用户界面标准或产品系列的风格; • 屏幕布局; • 菜单布局; • 输入输出格式; • 错误信息显示格式;

建议采用RAD开发工具, 比如Visio,构造用户界面。

4.2 硬件接口

硬件接口之间,及所使用的通信协议。

4.3软件接口

并指出这些外部软件或组件的名字和版本号。使用什么数据库连接组件,和什么商 Web浏览器、网络通信协议等。

4.5 故障处理

对可能的软件、硬件故障以及对各项性能而言所产生的后果进行处理。

蓝湖网络科技有限公司

5.性能需求

5.1 数据精确度

输出结果的精度。

在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时,软件的适应能力。

6.其他需求

7.数据描述

包括输入数据和输出数据。 对于数据流图、

蓝湖网络科技有限公司

8、总体方案确认 9、数据库系统设计 10、信息编码设计 11.附录

范文三:需求文档模板 投稿:史礆礇

需求分析 班 级: 学 号:

编写人员:

签字页

版 次: Ver 1. 0

业务负责人: 执笔人: 杜光辉 日 期: 项目负责人:项目负责人:项目负责人:

日 期:日 期:日 期:

目 录

1引言 .................................................................... 6

1.1编写目的 ........................................................................................................................................... 7

1.2适用对象及范围 ............................................................................................................................... 7

1.3需求分析设计依据 ........................................................................................................................... 7

2总体设计 ............................................................ 8

2.1需求概述 ........................................................................................................................................... 8

2.2处理流程 ........................................................................................................................................... 9

2.3软件功能结构 ................................................................................................................................. 11

3功能说明 .......................................................... 13

3.1 工程技术文件管理子系统 ............................................................................................................ 13

3.1.1技术文件的管理 .................................................................................................................. 13

3.1.1.1技术文件的登录与签收 ........................................................................................... 13

a、AD/CAD文件的签收 ............................................................................................. 13

b、SB/SL文件的登录 ................................................................................................. 14

c、SB/SL文件的签收 .................................................................................................. 14

d、TL及其他文件登录 ............................................................................................... 15

e、TL及其他文件签收 ............................................................... 错误!未定义书签。

3.1.1.2技术文件的审核评估(技术文件处理单的完成) ..................... 错误!未定义书签。

3.1.1.2.1 AD/CAD 的审核评估 ................................................... 错误!未定义书签。

a、AD/CAD处理单的建立 ................................................. 错误!未定义书签。

b、AD/CAD处理单的科长审核 ......................................... 错误!未定义书签。

c、AD/CAD处理单的总工审批 ......................................... 错误!未定义书签。

3.1.1.2.2 SB/SL 的审核评估 ........................................................ 错误!未定义书签。

a、SB/SL处理单的建立 ...................................................... 错误!未定义书签。

b、SB/SL技术处理单的科长审核...................................... 错误!未定义书签。

c、SB/SL处理单的总工审批 .............................................. 错误!未定义书签。

3.1.1.2.3 TL/其他文件处理单的审核评估 .................................. 错误!未定义书签。

a、TL/其他技术文件处理单的建立 ................................... 错误!未定义书签。

b、TL/其他文件技术处理单的科长审核 ........................... 错误!未定义书签。

c、TL/其他文件处理单的总工审批 ................................... 错误!未定义书签。

3.1.1.3技术科外发文件的管理 ........................................................... 错误!未定义书签。

3.1.1.3.1 工程指令管理 ............................................................... 错误!未定义书签。

a、工程指令的建立 ............................................................. 错误!未定义书签。

b、工程指令的科长审核 ..................................................... 错误!未定义书签。

c、工程指令的总工审批 ..................................................... 错误!未定义书签。

d、工程指令工作单的建立 ................................................. 错误!未定义书签。

e、工程指令取消通知单的建立 ......................................... 错误!未定义书签。

f、工程指令取消通知单的审核 .......................................... 错误!未定义书签。

g、工程指令取消通知单的批准 ......................................... 错误!未定义书签。

f、工程指令的修正 .............................................................. 错误!未定义书签。

3.1.1.3.2 CAD延时申请单的管理 ............................................ 错误!未定义书签。

a、CAD延时申请单的建立 ................................................ 错误!未定义书签。

c、CAD延时申请的批准 .................................................... 错误!未定义书签。

3.1.1.3.3 技术通告管理 ............................................................. 错误!未定义书签。

a、技术通告的建立 ............................................................. 错误!未定义书签。

b、技术通告的审核 ............................................................. 错误!未定义书签。

c、技术通告的批准 ............................................................. 错误!未定义书签。

d、修正手册通告的完成 ..................................................... 错误!未定义书签。

e、技术通告的报警 ............................................................. 错误!未定义书签。

3.1.1.3.4 互换信息通告管理 ..................................................... 错误!未定义书签。

a、互换信息通告的建立 ..................................................... 错误!未定义书签。

b、互换信息通告的审核 ..................................................... 错误!未定义书签。

c、互换信息通告的批准 ..................................................... 错误!未定义书签。

3.1.1.3.5 飞机线路更改通告管理 ............................................. 错误!未定义书签。

a、线路更改通告的建立 ..................................................... 错误!未定义书签。

b、线路更改通告的审核 ..................................................... 错误!未定义书签。

c、线路更改通告的批准 ..................................................... 错误!未定义书签。

3.1.1.3.6 飞机加改装订货通知单管理 ..................................... 错误!未定义书签。

a、飞机加改装订货通知单的建立 ..................................... 错误!未定义书签。

b、飞机加改装订货通知单的审核 ..................................... 错误!未定义书签。

c、飞机加改装订货通知单的取消 ..................................... 错误!未定义书签。

3.1.1.3.7 订货信息通知单管理 ................................................. 错误!未定义书签。

a、订货信息通知单的建立 ................................................. 错误!未定义书签。

b、订货信息通知单的审核 ................................................. 错误!未定义书签。

c、订货信息通知单的取消 ................................................. 错误!未定义书签。

3.1.1.3.8 外送改装通知单管理 ................................................. 错误!未定义书签。

a、外送改装通知单的建立 ................................................. 错误!未定义书签。

b、外送改装通知单的审核 ................................................. 错误!未定义书签。

3.1.1.3.9 维护经验信息交流单管理 ......................................... 错误!未定义书签。

a、维护经验交流信息单的建立 ......................................... 错误!未定义书签。

3.1.1.3.10 工艺工作单的管理 ................................................... 错误!未定义书签。

a、工艺工作单的建立 ......................................................... 错误!未定义书签。

b、工艺工作单的审核 ......................................................... 错误!未定义书签。

c、工艺工作单的批准 ......................................................... 错误!未定义书签。

3.1.1.3.11 飞机维护工作单的管理 ........................................... 错误!未定义书签。

a、飞机维护工作单的建立 ................................................. 错误!未定义书签。

b、飞机维护工作单的审核 ................................................. 错误!未定义书签。

c、飞机维护工作单的批准 ................................................. 错误!未定义书签。

3.1.1.3.12 维修方案更改申请单的管理 ................................... 错误!未定义书签。

a、维修方案更改申请单的建立 ......................................... 错误!未定义书签。

b、维修方案更改申请单的审核 ......................................... 错误!未定义书签。

c、维修方案更改申请单的批准 ......................................... 错误!未定义书签。

d、维修方案更改信息反馈 ................................................. 错误!未定义书签。

3.1.1.3.13 定检工作单内容更改申请单的管理 ....................... 错误!未定义书签。

a、定检工作单内容更改申请单的建立 ............................. 错误!未定义书签。

b、定检工作单内容更改申请单的审核 ............................. 错误!未定义书签。

c、定检工作单内容更改申请单的信息反馈...................... 错误!未定义书签。

3.1.1.3.14 飞机检查技术标准的管理 ....................................... 错误!未定义书签。

a、飞机检查技术标准的建立 ............................................. 错误!未定义书签。

b、飞机检查技术标准的审核 ............................................. 错误!未定义书签。

c、飞机检查技术标准的批准 ............................................. 错误!未定义书签。

3.1.1.3.15 飞机保留工作的审批 ............................................... 错误!未定义书签。

3.1.1.3.16 索赔单的维护 ........................................................... 错误!未定义书签。

a、索赔单的维护 ................................................................. 错误!未定义书签。

3.1.1.4 技术文件的分类查询及报表生成 .......................................... 错误!未定义书签。 a、适航指令汇总清单 ................................................................. 错误!未定义书签。

b、适航指令完成情况月报 ......................................................... 错误!未定义书签。

c、SB/SL等技术文件收发处理汇总清单 .................................. 错误!未定义书签。

d、技术通告汇总清单 ................................................................. 错误!未定义书签。

e、电传及其他类文件收发处理汇总清单 ................................. 错误!未定义书签。

f、EO汇总清单 ........................................................................... 错误!未定义书签。

g、单机档案飞机适航指令完成情况清单 ................................. 错误!未定义书签。

h、单机档案发动机适航指令完成情况清单 ............................. 错误!未定义书签。

i、单机档案飞机SB/SL完成情况清单 ..................................... 错误!未定义书签。

j、单机档案发动机SB/SL完成情况清单 ................................. 错误!未定义书签。

k、单机档案电传及其他类文件完成情况清单 ......................... 错误!未定义书签。

l、单机档案EO完成情况清单 ................................................... 错误!未定义书签。

m、定货信息通知单汇总清单 .................................................... 错误!未定义书签。

n、外送改装通知单汇总清单 ..................................................... 错误!未定义书签。

o、索赔单清单 ............................................................................. 错误!未定义书签。

3.2 维修方案及工卡管理子系统 ........................................................................ 错误!未定义书签。

3.2.1 维修方案管理 ..................................................................................... 错误!未定义书签。

3.2.1.1 B737-300型飞机维修方案管理 .............................................. 错误!未定义书签。 a、定检工卡清单的维护 ............................................................. 错误!未定义书签。

b、老龄飞机防腐工卡目录清单维护 ......................................... 错误!未定义书签。

c、B737-300结构抽样表的维护 ................................................ 错误!未定义书签。

d、B737-300cosl表的维护 .......................................................... 错误!未定义书签。

e、维修方案的修改 ..................................................................... 错误!未定义书签。

3.2.1.2 B737-700型飞机维修方案管理 .............................................. 错误!未定义书签。 a、定检工卡清单的维护 ............................................................. 错误!未定义书签。

b、B737-700CMR项目清单的维护 ........................................... 错误!未定义书签。

c、B737-700cosl表的维护 .......................................................... 错误!未定义书签。

d、维修方案的修改 ..................................................................... 错误!未定义书签。

3.2.1.3 B767-300型飞机维修方案管理 .............................................. 错误!未定义书签。 a、定检工卡清单的维护 ............................................................. 错误!未定义书签。

b、B767-300CMR项目清单的维护 ........................................... 错误!未定义书签。

c、B767-300cosl表的维护 .......................................................... 错误!未定义书签。

d、维修方案的修改 ..................................................................... 错误!未定义书签。

3.2.1.4 CRJ-200型飞机维修方案管理 ................................................ 错误!未定义书签。 a、定检工卡清单的维护 ............................................................. 错误!未定义书签。

b、结构检查工卡清单的维护 ..................................................... 错误!未定义书签。

c、适航限制项目工卡清单的维护 ............................................. 错误!未定义书签。

d、CRJ-200 CMR项目清单的维护 ............................................ 错误!未定义书签。

e、CRJ-200 cosl表的维护 ........................................................... 错误!未定义书签。

f、维修方案的修改 ...................................................................... 错误!未定义书签。

3.2.2 定检工卡管理 ..................................................................................... 错误!未定义书签。 a、定检工卡的维护 ............................................................................. 错误!未定义书签。 b、工卡所需工具设备维护 ................................................................. 错误!未定义书签。 c、工卡所需航材维护 ......................................................................... 错误!未定义书签。

3.2.3 定检工单管理 ..................................................................................... 错误!未定义书签。 a、定检任务工卡清单的生成 ............................................................. 错误!未定义书签。 b、定检任务所需工具设备清单生成 ................................................. 错误!未定义书签。

c、定检任务所需航材清单生成 ......................................................... 错误!未定义书签。

3.3 技术资料管理 ................................................................................................ 错误!未定义书签。

3.3.1 资料的收发管理 ................................................................................. 错误!未定义书签。

3.3.1.1飞机、发动机资料的登记与维护 ........................................... 错误!未定义书签。 a、飞机、发动机资料的登记 ..................................................... 错误!未定义书签。

b、飞机、发动机资料的版本更新 ............................................. 错误!未定义书签。

c、飞机、发动机资料的收发记录 ............................................. 错误!未定义书签。

3.3.1.2 附件技术资料的维护 ............................................................... 错误!未定义书签。 a、附件技术资料的登记 ............................................................. 错误!未定义书签。

b、附件技术资料的版本更新 ..................................................... 错误!未定义书签。

3.3.1.3培训资料资料登记 ................................................................... 错误!未定义书签。

3.3.1.4外单位发往云航的资料的维护 ............................................... 错误!未定义书签。 a、外单位发往云航的资料的登录 ............................................. 错误!未定义书签。

b、外单位发往云航的资料的版本更新 ..................................... 错误!未定义书签。

3.3.1.5其他资料维护 ........................................................................... 错误!未定义书签。 a、其他资料的登记 ..................................................................... 错误!未定义书签。

b、其他资料的收发记录 ............................................................. 错误!未定义书签。

3.3.2 资料异常情况处理 ............................................................................. 错误!未定义书签。

3.3.3资料查询管理 ...................................................................................... 错误!未定义书签。 a、飞机、发动机资料的查询 ............................................................. 错误!未定义书签。 b、附件资料的查询 ............................................................................. 错误!未定义书签。 c、培训资料的查询 ............................................................................. 错误!未定义书签。 d、外单位发往云航的资料查询 ......................................................... 错误!未定义书签。

3.3.4 资料的申报定购 ................................................................................. 错误!未定义书签。 a、技术资料申报定购清单的建立 ..................................................... 错误!未定义书签。 b、技术资料申报定购清单查询 ......................................................... 错误!未定义书签。

1引言

1.1编写目的

本需求分析设计说明书确定云南航空公司维修基地机务维修综合管理系统工程技术管理子系统的需求说明、模块划分、各模块内的算法以及各模块的内部数据组织(包括数据项与单据、表格内容)。同时也包括相关的业务处理需求说明。1引言

1.2适用对象及范围

本需求分析设计说明书适用于参加本项目的用户方项目组成员、用户方的相关业务人员、所有管理人员、开发人员和维护人员。

1.3需求分析设计依据

《云南航空公司维修基地维修手册》

《云南航空公司机务维修工程管理系统技术开发合同书》

云南航空公司维修基地需求调研材料

中国民用航空管理局《中国民用航空管理规章第145部》

GB8566—88《计算机软件开发规范》

北京航安伟业科技发展公司《需求分析设计规范》

北京航安伟业科技发展公司《机务维修计算机系统软件》

北京航安伟业科技发展公司《云南航空公司机务维修工程管理系统招标文件》

2总体设计

2.1需求概述

工程技术管理模块主要包括工程技术文件管理、维修方案及工卡管理、技术资料管理三部分内容。

工程技术文件管理主要对维修基地接收到的AD/CAD/SB/SL/TL/其他技术文件进行建立、审核评估,并对由其产生的指令、通告以及单据进行建立、审核、存档、查询、打印管理;在此基础上自动生成单机档案;同时对技术文件的整个处理过程的状态进行监控。

工程技术文件管理包括:

1.技术文件的接收;

2.技术文件的审核评估;

3.技术文件生成的指令、通告及单据的管理;

4.技术文件的分类查询与报表;

5.单机档案管理。

维修方案及工卡管理主要针对维修基地的所有机型的维修方案进行数据库管理,提供对维修方案的建立、插入、修改、查询、打印管理;同时针对工卡目录建立(或导入)与之对应的工卡信息(所需航材、工具及工卡内容),并提供对工卡查询、修改和打印管理。

维修方案及工卡管理主要包括:

1.针对机型的维修方案的建立与维护;并为相关部门提供查询及打印功能;

2.提供Cosl表的建立(或导入)、维护、查询核对以及打印功能。同时为对其进行实时控制提供基础信息;

3.提供针对机型的定检工卡及工单的建立(或导入)与打印功能;并建立与工卡对应的相关信息(所需航材、工具、设备清单);

4.提供针对每次定检的工卡目录及工卡的打印功能。

技术资料管理主要是通过计算机对技术资料的收、发、存档进行分类管理。

技术资料管理包括:

1.技术资料的分类登记;

2.技术资料的版本维护;

3.技术资料的分类查询;

4.技术资料申报订购清单管理。

通过计算机系统对工程技术有关信息进行管理,可以提高数据共享,加快信息传递,简化管理控制流程。从而能大大提高工作效率。

版 次: 管理信息系统需求分析设计文档

河北金融学院

第 9 页

2.3软件功能结构

1、工程技术文件管理

2、维修方案及工卡管理:

3

3功能说明

3.1 工程技术文件管理子系统 3.1.1技术文件的管理

3.1.1.1技术文件的登录与签收 a、AD/CAD文件的签收

 功能:主要对由技术科专业工程师对质管科登录的AD/CAD技术文件进行签收。  主要数据项:

生效日期:指AD/CAD的具体生效日期;

规定完成期限:填入具体的数字,单位由计量单位确定。 规定期限的计量单位:可以是年、天、小时。

签收警告期限:指AD/CAD的生效日期后在此期限内必须签收,否则提

示警告。

处理警告期限:指AD/CAD在签收后在此期限内必须处理,否则提示。 执行状态:分为待处理、处理中、处理完毕、执行中、执行完毕。 适用状态:N-不适用,A-适用 2)功能实现:

◆该功能主要对接收到的AD/CAD的基本信息进行维护; ◆AD/CAD的基本信息的增加、删除、修改、查询等功能; ◆ 数据来源:(质控科对接收的适航指令)录入

◆ 数据流向:是适航指令处理的源头和起点。是技术科建立处理单及

EO的数据来源。

◆ 计算模型:当前时间-警告期限≥生效日期 系统警告提示

b、SB/SL文件的录入

 功能:主要由技术科资料室对接收到的SB/SL文件的管理信息进行录入。  主要数据项:

文件类型:SB-通告,SL-信件,OT-其他 发行日期:指SB/SL的发行日期; 签收警告期限:指SB/SL在登记后在此期限内必须签收,否则系统将提示

警告;此期限由领导确定。

处理警告期限:指SB/SL在专业工程师签收后在此期限内必须处理,否则

系统将提示警告;此期限由领导确定。

适用状态:N-不适用,O-适用但作参考,I-按文件要求执行,PI-执

行但未按文件要求。

注:其中签收人及签收日期由技术科专业工程师文件签收时录入。 2)功能实现:

◆该功能主要对接收到的SB/SL的基本信息进行维护; ◆对SB/SL的基本信息的增加、删除、修改、查询等功能; ◆数据来源:(技术科资料室对接收的通告、信函)录入 ◆数据流向:可根据其生成技术通告、技术处理单。

◆计算模型:当前时间-警告期限≥登记日期 系统警告提示

c、SB/SL文件的签收

 功能:主要由技术科专业工程师对资料室已登录的SB/SL文件进行签收。  主要数据项:

同表2 SB/SL文件登录表; 1)功能实现:

◆该功能主要对资料室登录的SB/SL技术文件进行签收;

◆数据来源:(技术科资料室登录的通告、信函)专业工程师签收录入 ◆数据流向:可根据其生成技术通告、技术处理单。

◆计算模型:当前时间-处理警告期限≥签收日期 系统警告提示

d、TL及其他文件登录

 功能:主要由技术科资料室对接收到的TL及其他文件的管理信息进行录入。  主要数据项:

文件类型:TL-电传,OT-其他

发行日期:指TL及其他技术文件的发行日期;

签收警告期限:指TL及其他技术文件在登记后在此期限内必须签收,否

则系统将提示警告,此期限由领导确定。。

处理警告期限:指TL/其他技术文件在专业工程师签收后在此期限内必须

处理,否则系统将提示警告;此期限由领导确定。

处理情况:N-不适用,O-适用但作参考,I-按文件要求执行,PI-执

行但未按文件要求。

2)功能实现:

◆该功能主要对接收到的TL及其他技术文件的基本信息进行维护; ◆对TL及其他技术文件的基本信息的增加、删除、修改、查询等功能; ◆数据来源:(技术科资料室对接收的TL及其他技术文件)录入 ◆数据流向:可根据其生成技术通告、技术处理单。

◆计算模型:当前时间-警告期限≥登记日期 系统警告提示

范文四:需求分析文档模板 投稿:钱玘玙

软件需求模板

修订历史

版本 说明 编制 批准日期

1引言

1.1背景

说明:

a.待开发的软件系统的名称;

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

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

1.2参考资料

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

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

b.属于本项目的其他已发表的文件;

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

1.3假定和约束

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

1.4用户的特点

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

2功能需求

2.1. 系统范围

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

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

2.2系统体系结构(二层架构的系统可剪裁本小节)[可选]

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

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

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

2.3系统总体流程

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

例如:图2.1是计划合同管理系统的总体流程图。

图2.1

2.4需求分析

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

建立需求模型

2.4.1需求调查

2.4.2 需求建模

2.4.2.1 事件表

1. 0层事件表

2. 各分层事件表

2.4.2.2过程建模

1. 0层DFD图

2. XXXXXXX(功能名称)

责任人:

批准人:

功能编号:

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

需求建模:DFD片段

数据字典等

其他功能类似

2.4.2.3数据建模

1. 0层ER图

2. XXXXXXX(功能名称)

ER图

对每一个关系及属性、实体进行定义(名称、标识符、说明、访问频率等)

2.4.2.4用户界面

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

1. 系统界面

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候选方案确定

范围表、自动化表等

6需求跟踪

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

7相关管理问题

项目进度计划变更、项目成本、效益分析、项目工作分解结构细化等

8签批单

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

执行主管:

日期

技术主管:

日期

项目组长:

日期

用户代表:

日期

开发人员代表:

日期

小组成员:

日期

小组成员:

日期

范文五:需求分析文档模板 投稿:夏妶妷

软件需求规格说明书模板

修订历史

版本 说明 编制 批准日期

1引言

1.1背景

1.2参考资料

项目启动表20120227.doc 需求变更申请表.doc 需求变更说明书.doc

1.3假定和约束

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

1.4用户的特点

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

2功能需求

2.1. 系统范围

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

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

2.2系统体系结构(二层架构的系统可剪裁本小节)[可选]

以图+文本结合的方式描述系统的总体架构。 以下应提供系统总体架构图: 以下对系统总体架构进行描述:

2.3系统总体流程

以图+文本结合的方式说明系统的总体流程。 例如:图2.1是计划合同管理系统的总体流程图。

图2.1

2.4需求分析

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

建立需求模型

2.4.1需求调查 2.4.2 需求建模

2.4.2.1 事件表

1. 0层事件表 2. 各分层事件表

2.4.2.2过程建模

1. 0层DFD图

2. XXXXXXX(功能名称) 责任人: 批准人: 功能编号:

功能描述:从用户业务的角度描述功能需求。 需求建模:DFD片段 数据字典等 其他功能类似

2.4.2.3数据建模

1. 0层ER图

2. XXXXXXX(功能名称) ER图

对每一个关系及属性、实体进行定义(名称、标识符、说明、访问频率等)

2.4.2.4用户界面

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

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候选方案确定

范围表、自动化表等

6需求跟踪

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

7相关管理问题

项目进度计划变更、项目成本、效益分析、项目工作分解结构细化等

8签批单

我已阅读上述软件需求规格说明书,我将严格遵守说明书中的条款,并保证全力支持该规格说明书的实施。 执行主管: 日期 技术主管: 日期 项目组长: 日期 用户代表: 日期

开发人员代表: 日期 小组成员: 日期 小组成员: 日期

范文六:PRD需求文档模板 投稿:汪澏澐

产品文档(V1.0 - 20120820)

相册系统需求说明书

文档修订历史

目录

1

文档介绍................................................................................................................... 4 1.1 1.2 2

文档的目的 ................................................................................................. 4 参考文档..................................................................................................... 4

1.3 产品命名规范.............................................................................................. 4

产品介绍................................................................................................................... 5 2.1 2.2 2.3

产品概要说明.............................................................................................. 5 产品用户定位.............................................................................................. 6 产品中的角色.............................................................................................. 6

3

4 5

产品总体业务流程图 ................................................................................................. 7 产品功能结构图 ........................................................................................................ 8 功能需求................................................................................................................... 9 5.1 系统管理..................................................................................................... 9

5.1.1

5.1.2 5.1.3 5.1.4 5.1.5

功能原型.............................................................................................. 9 功能概述.............................................................................................. 9 功能(业务)流程图 ................................................................................. 9 功能点清单 ........................................................................................ 10 功能详细描述..................................................................................... 11

5.1.5.1 角色管理.................................................................................... 11 5.1.5.2 用户管理.................................................................................... 12 5.1.5.3 系统日志.................................................................................... 13 5.1.5.4 密码修改.................................................................................... 13 5.1.5.5 角色查询.................................................................................... 13

5.1.5.6 用户查询.................................................................................... 13 5.1.6 5.1.7 5.1.8 5.1.9 5.2

与其他子模块的接口 .......................................................................... 14 业务数据描述..................................................................................... 14 边界值处理 ........................................................................................ 14 异常处理............................................................................................ 14

渠道管理................................................................................................... 15

5.2.1 功能概述............................................................................................ 15 5.2.2 5.2.3

功能点清单 ........................................................................................ 15 功能详细描述..................................................................................... 15

5.2.3.1 管理申请.................................................................................... 15 5.2.3.2 管理申请.................................................................................... 16 5.2.4 5.3

业务数据描述..................................................................................... 16

订单管理................................................................................................... 16

5.3.1 功能原型............................................................................................ 16 5.3.2 5.3.3

功能概述............................................................................................ 16 功能点清单 ........................................................................................ 17

5.3.4 功能详细描述..................................................................................... 17 5.3.4.1 订单审核.................................................................................... 17 5.3.4.2 订单管理.................................................................................... 19

5.3.4.3 订单查询.................................................................................... 20 5.3.4.4 新增订单.................................................................................... 21

5.3.5 业务数据描述..................................................................................... 21

5.4 资源管理................................................................................................... 21

5.4.1 功能原型............................................................................................ 21 5.4.2 功能概述............................................................................................ 21

5.4.3 5.4.4

功能(业务)流程图 ............................................................................... 22 功能点清单 ........................................................................................ 22

5.4.5 子功能详细描述 ................................................................................. 22 5.4.5.1 产品管理.................................................................................... 22 5.4.5.2 发布管理.................................................................................... 24 5.4.6 5.4.7 5.5

业务数据描述..................................................................................... 24 功能原型............................................................................................ 25

统计管理................................................................................................... 25

5.5.1 功能概述............................................................................................ 25 5.5.2 5.5.3 5.5.4

功能(业务)流程图 ............................................................................... 25 功能点清单 ........................................................................................ 25 功能详细描述..................................................................................... 26

5.5.4.1 工作量统计 ................................................................................ 26 5.5.4.2 广告效果统计............................................................................. 26

6

5.5.5 业务数据描述..................................................................................... 32

非功能性需求.......................................................................................................... 33 6.1界面操作需求............................................................................................... 33 6.2性能需求 ....................................................................................................... 33 6.3安全性需求 ................................................................................................... 33

6.4维护与升级 ....................................................................................................... 33 6.5可靠性和健壮性 ................................................................................................ 33 6.6用户文档需求 .................................................................................................... 33 6.7运行环境 ........................................................................................................... 33

1 文档介绍

1.1

文档的目的

此文档是提供用于软件开发部门和产品设计部门、产品测试部门之间就此产品的需求分析、产品开发、产品设计、测试方案交流的基础;

1.2 参考文档

1.3 产品命名规范

2 产品介绍

2.1

产品概要说明

产品管理系统是公司运营内部使用的对公司线上产品进行管理对订单进行发布的系统平台。可以对订单进行审核及管理,对产品进行管理,对订单效果进行查询。保证整个运营服务系统的正常流转。

结构图如下:

2.2 产品用户定位

此产品面向的主要是两类人员。一类是面向系统运行的系统管理员,另一

类是面向运营人员。两者对软件的操作熟练程度差距很大,所以产品设计和实现时尽量给予简单的界面和完备的帮助,并对重要功能的业务权限要集中、重点控制。

2.3 产品中的角色

3 产品总体业务流程图

4 产品功能结构图

5 功能需求

5.1

系统管理

5.1.1 功能原型

参见原型添加日志分类名称测试是否允许标点符号以及长度限制等

5.1.2 功能概述

对角色、系统用户、系统日志、密码进行管理操作。

5.1.3 功能(业务)流程图

5.1.4 功能点清单

5.1.5 功能详细描述

5.1.5.1 角色管理

 功能点描述:管理员可以在后台定义不同的角色,例如,渠道经理、财务人员。

 使用角色:系统管理员

 输入:查询条件,角色信息

 处理:

1、 查询角色

系统管理人员输入查询信息,进行查询。

查询条件:角色名称。

查询结果:编号、角色名称、角色描述。

2、 新增角色

系统管理人员添加新的角色名称。

添加数据:角色名称、角色描述、角色所属权限。

3、 修改角色

系统管理人员选中要修改的角色名称,并对其进行修改。

修改数据:角色名称、角色描述、角色所属权限。

4、 禁用角色

系统管理员对某一角色实施禁用操作。日志中将依旧保留此角色的操作记录。但当为新建用户分配角色时将无法显示此禁用角色。此角色的现有用户将无法进行操作。

5、 启用角色

系统管理员对某一个禁用角色进行启用操作。建立用户时将可以在下拉选择列表中

看到此角色。

6、 删除角色

系统管理员只能删除没有赋予用户的空角色。

 输出:

1、 查询结果

全选 角色名称 角色描述 状态 操作

2、 操作按钮

查询、新增、修改、禁用、启用、删除

操作链接:查看,修改

5.1.5.2 用户管理

 功能点描述:系统管理员创建用户,并赋予不同用户不同的角色。还可以查

询显示出用户信息,并修改用户信息。如对用户进行禁用操作后,不允许用户登录、启用后恢复登录功能。也可以删除用户信息,删除只能删除没有对应任何操作的空用户信息。

 使用角色:系统管理员。

 输入:查询条件、用户信息、所属角色。状态(禁用、启用)

 处理:

1、 查询用户:输入相关的用户信息,选取角色范围,查询用户。并显示在列表中。 2、 新增用户:新增用户信息,填写用户的基本信息,分配角色。

3、 修改用户信息:修改已有用户的基本信息。 4、 修改用户密码:重新填写用户密码。

5、 禁用用户:对用户进行禁用操作后,用户使用用户名,密码无法再登陆系统。 6、 启用用户:对禁用用户进行操作后,用户恢复登陆功能。

7、 删除用户:删除没有关联任何操作的用户(操作后记录操作信息)。空用户信息。

如果有要删除的用户有关联信息,那么将提示只能禁用用户。

 输出:

1、 查询显示结果

操作按钮:查询、新增、禁用、启用、修改、删除

操作链接:角色查看、修改信息、修改密码 5.1.5.3 系统日志

 功能点描述:系统管理员对操作人员的所有操作信息进行查看

 使用角色:系统管理员

 输入:查询条件

 处理:按条件查询信息,输入选择查询条件,可按用户、IP地址、操作模块、操作类

型、操作时间进行查询,显示在列表中。

操作按钮:查询 5.1.5.4 密码修改

 功能点描述:登陆系统的用户可以使用此功能修改密码。   

5.1.5.5 角色查询

 功能点描述:登陆系统的用户可以使用查询系统中所有角色信息。  使用角色:查询权限的用户  输入:查询信息

 处理:查询出所有符合条件的信息。  输出:

全选 角色名称 角色描述 状态 操作

使用角色:所有用户

输入:新密码、重复密码

处理:所有登陆系统的用户都可以通过此功能修改密码 输出:提示修改成功、提示输入错误

操作链接:查看

5.1.5.6 用户查询

 功能点描述:登陆系统的用户可以使用查询系统中所有的用户信息。    

使用角色:查询权限的用户 输入:查询信息

处理:查询出所有符合条件的信息。 输出:

操作链接:角色查看

5.1.6 与其他子模块的接口

1、 在撤销订单以后需要变更客户资料的状态,这里需要调用呼出模块的接口 2、 在撤销订单以后需要删除相关工作流的任务,这里需要调用工作流的接口

5.1.7 业务数据描述

1、 角色信息(编号、角色名称、角色描述)

角色名称:20个中文字符 角色描述:50个中文字符 角色权限:复选框选择

2、 用户信息(编号、登陆密码、E-mail、部门、所属角色、状态)

用户名: 由字母a~z(不区分大小写)、数字0~9、点、减号或下划线组成。只能以数字或字母开头和结尾 用户名长度为4~18个字符。

登陆密码:5到16个字符。机器生成

E-mail:判断是否含有@的字符串,20位以内。 部门: 20个字符以内。

所属角色:下拉框选择,20个中文字符。 3、 日志信息

操作模块:10个中文字符。

操作类型:15个中文字符。 操作内容:200个中文字符。 操作时间:yy-mm-ddhh:mm:ss 用户名称:4到18个字符 角色名称:20个中文字符。

5.1.8 边界值处理

1、 如果驳回,那么驳回原因必须填写

2、 对于合同组合同审核,如果通过,那么合同编号必须申请,印刷编号必须填写

5.1.9 异常处理

撤销订单信息和撤销工作流任务一起作为原子操作,如果一个失败,两个都要rollback

5.2 渠道管理

5.2.1 原型

参见原型地址。

5.2.2 功能概述

渠道经理登陆系统查看渠道商的申请信息。线下联系渠道商,并达成代理协议。

5.2.3 功能(业务)流程图

5.2.4 功能点清单

5.2.5 功能详细描述

5.2.5.1 管理申请

 功能点描述:渠道经理查询渠道商申请,删除掉无意义的申请信息。  使用角色:渠道经理  输入:查询条件

 处理:

1、 查询申请:渠道经理输入查询条件,查出近期网上提交的渠道代理申请。

2、 删除申请:渠道经理对一些明显无意义的申请进行删除操作。  输出:

1、查询结果

按钮:删除、复审确认、分配审核人

5.2.5.2 管理申请

 功能点描述:渠道经理查看渠道申请,线下联系渠道商并签订合同。  使用角色:渠道经理  输入:查询条件

 处理:

1、删除申请:渠道经理删除无意义的渠道申请信息。  输出:

1、查询结果

全选 区域 公司 电话

传真

联系人

Email

申请时间

操作按钮:删除

5.2.6 业务数据描述

1、 渠道商信息

代理区域:下拉菜单 公司名称:(必填)30位中文字符 联系人:(必填)10个中文字符 联系电话:(必填)20个字符 传真号码:(必填)20个字符

E-mail:(必填):判断是否含有@的字符串,60位。

5.3 订单管理

5.3.1 功能原型

参见原型地址。

5.3.2 功能概述

运营人员新增订单并对提交的订单进行审核及管理。

业务(功能)流程图

5.3.3 功能点清单

5.3.4 功能详细描述

5.3.4.1 订单审核

 功能点描述:后台运营人员下订单并对订单进行内容、排期审核,驳回订单审核人员填写驳回原因。如有部分问题,审核人员可以修改订单内容,并通过审核。  使用角色:运营人员

 输入:查询条件、驳回理由  处理:

1、 查看订单详细内容 2、 驳回并填写驳回理由 3、 通过审核

4、 修改客户意向并通过审核。

 输出:

1、待审核订单列表:

订单号

全选

订单类型

合同号

客户公司名称 联系电话

业务员

创建时间 创建人

操作

操作链接:查看明细 操作按钮:通过、驳回

2、订单明细

订单号: 订单类型: 合同号: 公司名称: Showroom: 联系电话: 业务员:

操作按钮:驳回、通过、修改、删除

5.3.4.2 订单管理

 功能点描述:订单管理员会对所有订单进行管理、可以对某些通过审核的订单进行禁用

启用操作。能对已审核、待审核的订单进行禁用,禁用后订单状态为冻结。启用后订单恢复原来状态。可以查看订单的状态(待审核、已审核、驳回、已完成、已退单)  使用角色:订单管理员

 输入:查询条件为(订单号、合同号、客户公司名、联系电话、业务员)创建人、审核

人、订单状态(下拉)、创建时间(时间选择输入)排序方式(订单号、合同号、客户公司名、联系电话、业务员、创建时间状态审核人创建人)(升序、降序)显示(10、20、40)  处理:

1、查询显示符合条件的订单。

2

、 查看订单明细。

3、 对明细进行退订操作。

4、 对明细进行禁用启用。

5、 对整个订单进行禁用启用。 6、 对整个订单进行退订操作。

 输出:

订单类型

订单号 全选

合同号

客户

业务

公司名称

付费用户

YN00001

北京

2006-12-23

MIC-H-00069 天大010-88887777 mike 待审核 mikemike查看明细

10:08:09

公司

创建审核

创建时间 状态

操作

人 人

联系电话

操作按钮:查询、禁用、启用、退订 操作链接:查看明细

订单明细

订单号: 订单类型:

合同号: 公司名称: Showroom: 联系电话: 业务员:

总产品数: 7 订单产品信息

产品类型

产品编号

全选

固定位广告

HOP001

首页通栏 产品名称

服务开始日服务终止日

状态

期 期

客户意向

2006-12-10 2006-12-17 待发布 详细

搜索排名

会员服务

HOP001

搜索排名第1位

2006-12-10 2006-12-17 发布中

(mp3)

先进型会员服务

2006-12-10 2006-12-17 已完成

详细

HOP001 详细

黄金展位

HOP001 黄金展位(mp4) 2006-12-10 2006-12-17 退订 详细

黄金展位

HOP001

黄金展位(mp3

2006-12-10 2006-12-17 冻结

player)

详细

退订禁用启用

操作按钮:禁用、启用、退订 操作链接:详细

5.3.4.3 订单查询

 功能点描述:相关人员可以有查询订单的权限。并查看订单的详细信息,但无法进行任

何操作。  使用角色:销售人员、CEO

 输入:查询条件为(订单号、合同号、客户公司名、联系电话、业务员)创建人、审核

人、订单状态(下拉)、创建时间(时间选择输入)排序方式(订单号、合同号、客户公司名、联系电话、业务员、创建时间状态审核人创建人)(升序、降序)显示(10、20、40)  处理:

1、 如何查询条件显示符合条件的信息。

2、 点中详细查看每条订单的详细信息。

 输出:

订单类型

订单号 全选

合同号

客户

业务

公司名称

付费用户

YN00001

北京

2006-12-23

MIC-H-00069 天大010-88887777 mike 待审核 查看明细

10:08:09

公司

创建审核

创建时间 状态

操作

人 人

联系电话

操作链接:查看明细

5.3.4.4 新增订单

 功能点描述:运营人员操作此模块按照合同要求给客户下订单  使用角色:下单人员

 输入:合同号,公司名称、业务员、联系电话、Showroom地址,客户意向。

 处理:

1、 输入订单基本信息 2、 查询客户showroom 3、 添加客户意向并提交

5.3.5 业务数据描述

合同号:(必填)20个字符 公司名称:(必填) 100个字符 业务员:20个字符 联系电话:(必填)40个字符 投放关键词:100个字符

图片:小于100K的gif 和jpg图片。 广告文本:200个字符

广告链接:300个中文字符

5.4 资源管理

5.4.1 功能原型

参见原型地址

5.4.2 功能概述

产品负责人员对产品资源进行管理,包括产品价格,折扣,规格。运营人员对发布进行管理。

5.4.3 功能(业务)流程图

订订订订

订订订订

5.4.4 功能点清单

5.4.5 子功能详细描述

5.4.5.1 产品管理

 功能点描述:产品运营人员添加产品编号,产品类型,产品相应的规格信息。生成产品

配置表。前台查询此配置表,得到相应的产品信息。产品运营人员在日常事务中维护此资源配置表。对所有产品信息进行增加、查询、修改、删除、禁用、启用操作。

 使用角色:产品运营人员

 输入:固定位广告、黄金展位、搜索排名、产品推荐、公司推荐等产品的产品信息

 处理:

a) 查询产品:输入查询条件,产品编号、产品名称、选择产品类型、产品状态(所

有、禁用、启用),排序方式,按某一个字段的升序降序,显示条数进行查询。

b) 修改产品信息:选中产品信息。点操作区“修改信息”,将弹出信息表单。可

修改产品类型、产品编号、产品名称、数量、规格、价格、折扣、默认图片、

产品描述。点击保存按钮提示保存成功信息。列表中的产品相应信息将做出相应的变化。

c) 新增产品:点击右下侧“新增”按钮。将弹出新增输入框,填写产品类型、产

品编号、产品名称、数量、规格、价格、折扣、默认图片、产品描述。并点击保存,提示新增成功。产品编号、产品名称不允许为重复。

d) 禁用产品:当某一个产品由于需求需要隐藏一段时间。我们将采用禁用操作。

选中要禁用的信息后点“禁用”按钮。提示此条信息将被禁用。禁用操作后将改变此条产品状态。此条产品信息将无法在前台及下订单模块查询出来,但历史的操作数据将保留。

e) 启用产品:对禁用的产品进行启用操作。恢复此条产品的状态,在下订单模块

将能查询显示出此条信息。

f) 删除产品:只能对没有任何订单操作的产品信息进行删除操作。

 输出:

1、 产品管理

全选 产品编号 产品类型

HO001

固定位

产品名称

数量

规格

价格

折扣

状态

操作

首页通栏 1 770*100 50000.00 100% 启用 修改信息

按钮:查询、新增、禁用、启用、删除 链接:修改信息

5.4.5.2 发布管理

 功能点描述:

对现在发布中以及待发布的所有订单明细进行查询,可以修改发布明细的信息。(图片,

广告标题,广告文本,广告链接,对应产品,对应图片)当每日的自动发布实效时,可以手动重新发布。

 使用角色:

产品运营人员  输入:

广告产品的相关客户意向(广告图片、广告标题、广告文本、广告链接、对应的产品)

 处理:

1. 按条件查询

查询条件:产品类型(下拉)、订单类型(下拉:付费用户、内部推荐)、产品编号、产品名称、状态(下拉:待发布、发布中)、 排序方式:订单类型、产品类型、产品编号、产品名称、订单号、开始日期、终止日期、业务员、公司名称、合同号、状态(升序、降序) 显示:10、20、40

默认:排序按照发布日期,降序,显示10条

2. 手动发布

点击手动发布按钮对所有修改信息重新发布。

 输出:

1、 发布查询结果

订单

订单号 合同号

类型

产品产品编产品业务

公司名称 开始日期 终止日期 状态 操作

类型 号 名称 员

付费北京天锡固定首页发布修改 / 查

HY001 MIC-H-0001 HOS001 2008-09-21 2008-09-21 mike

用户 有限 位 通栏 中 看详细

操作按钮:查询、手动发布 操作链接:修改、查看详细

5.4.6 业务数据描述

1、产品管理

类型名称:20个中文字符 类型描述:100个中文字符

产品编号:8位字符 产品名称:20个中文字符 所在频道:20个中文字符 所在页面:20个中文字符 所在页面地址:300个字符 图片宽度:3位数字 图片高度:3位数字

市场参考价(¥/周):10位数字,保留小数点后2位。

折扣:2位数字

2、 发布管理

广告图片:大小在100k以下的图片。 广告标题:25个字符以内(必填) 广告文本:70个字符(必填) 链接地址:300个字符(必填) 站内地址:300个字符(必填)

5.4.7 功能原型

参见原型地址

5.5 统计管理

5.5.1 功能概述

对审核订单工作量、广告的效果进行全面的统计。

5.5.2 功能(业务)流程图

订订订订

5.5.3 功能点清单

5.5.4 功能详细描述

5.5.4.1 工作量统计

 功能点描述:

对所有订单审核的工作量进行查询统计,按操作人员统计出下订单数量,审核订单数量、驳回数量。  使用角色: 运营人员  输入: 查询条件  处理:

1、 查询工作量

查询条件:操作人员、所属角色(下拉)统计日期

排序方式:操作人员、所属角色、下订单数量、审核数量、驳回数量 显示: 10、20、40

默认按操作数量排序,显示10

条信息 点操作人员可以查看操作人员信息 点角色信息可以查看操作人员角色信息

 输出:

操作按钮:查询

5.5.4.2 广告效果统计

 功能点描述:

可以按订单、按产品、按购买词显示广告的效果统计信息。  使用角色: 产品运营人员  输入: 查询条件  处理:

1. 按订单统计 查询条件

订单号(10个字符)

订单类型(20个中文字符)

公司名称:(100个字符)

联系电话:(20个中文字符) 业务员:20个中文字符

订单类型:下拉选择全部、内部推荐、付费用户

订单状态:下拉选择(全部、已审核、已完成、冻结) 创建时间:时间控件

排序方式

订单号、合同号、订单类型、公司名称、联系电话、业务员、创建时间、订单状态(升序、降序)

默认按创建时间降序 显示

10、20、40 默认显示10条

订单详细项统计综合、地域、时间段、操作系统、浏览器效果时。可选择时间段。时间段选择范围分两种情况,如果订单状态为已审核,此订单明细的时间段为上线日期到昨日。如果订单状态为已完成,此订单明细的时间段为上线日期到下线日期

2. 按产品统计 查询条件

产品类型全部 (KP001)产品搜索关键词广告 产品编号(20个字符) 产品名称(40个字符)

状态:下拉(全部、启用、禁用) 统计时间:时间控件

排序方式

产品编号、产品名称、产品类型、订单数、曝光数、点击数、点击率(‰)、状态(升序、降序)

默认按点击率(‰)降序 显示

10、20、40 默认显示10条

月统计按年选择统计,默认为当年 周统计选择时间段,默认上一周 天统计选择时间段,默认为昨天

3. 购买词统计 查询条件

年份:下拉(2007~2017) 关键词:(100个字符)

级别:下拉(全部、A 、B、C)

排序方式

关键词、订单数、曝光数、点击数、点击率‰(升序、降序) 默认按关键词曝光数升序 显示

10、20、40

默认显示10条

购买词统计详细,按选择年份查看某个词的详细信息,统计出这个词在不同产品中的广告效果。

所有统计图以折线图显示。显示点击率情况。

点击率= 点击数 / 曝光数 点击率单位以‰ 表示

 输出:

1. 按订单统计

订单订单合同号

公司名称 联系电话

类型

业务员

创建时间

订单状

操作

查看订单详

操作按钮:查询、返回上一级 操作链接:查看订单详细

订单详细统计 操作链接:综合、地域、时段、操作系统、浏览器

综合

地域

时段

操作系统

订单(订单号)

产品类型:(类型编号)类型名称

产品编号: 产品名称:

发布日期:yyyy-mm-dd

截止日期:

yyyy-mm-dd

浏览器

订单(订单号)

产品类型:(类型编号)类型名称 产品编号: 产品名称:

发布日期:yyyy-mm-dd 截止日期:yyyy-mm-dd

操作按钮:查询、返回上一级 操作链接:月、周、日

统计图为折线

统计图为折线

统计图为折线

3. 购买词统计

操作按钮:查询、返回上一级 操作链接:详细信息

购买词统计详细

关键词: 订单数: 年份:

5.5.5 业务数据描述

6 非功能性需求

6.1界面操作需求

整体风格保持一致,功能操作使用按钮,操作在同一界面上完成。

运行界面可最大化最小化拖拽改变大小,兼容800X600以及以上各分辨率。

6.2性能需求 6.3安全性需求

高级管理员与普通运营人员以权限划分不同的操作菜单。

6.4维护与升级 6.5可靠性和健壮性 6.6用户文档需求 6.7运行环境

IE5以上

范文七:PRD需求文档模板 投稿:于忚忛

项目管理文档

产品文档(V1.0 - 20110411)

订单管理系统流程需求说明书

文档修订历史

目录

1

文档介绍 ....................................................................................................................... 5 1.1 文档的目的 ..................................................................................................... 5 1.2 参考文档 ......................................................................................................... 5 1.3 产品命名规范.................................................................................................. 5 产品介绍 ....................................................................................................................... 5 2.1 产品概要说明.................................................................................................. 5 2.2 产品用户定位.................................................................................................. 6 2.3 产品中的角色.................................................................................................. 7 产品总体业务流程图 ..................................................................................................... 8 产品功能结构图 ............................................................................................................ 8 功能需求 ..................................................................................................................... 10 5.1 系统管理 ....................................................................................................... 10

5.1.1 功能原型................................................................................................ 10 5.1.2 功能概述................................................................................................ 10 5.1.3 功能(业务)流程图 .................................................................................. 10 5.1.4 功能点清单 ............................................................................................ 11 5.1.5 功能详细描述 ........................................................................................ 11

5.1.5.1 角色管理 ....................................................................................... 11 5.1.5.2 用户管理 ....................................................................................... 12 5.1.5.3 系统日志 ....................................................................................... 13 5.1.5.4 密码修改 ....................................................................................... 14 5.1.5.5 角色查询 ....................................................................................... 14 5.1.5.6 用户查询 ....................................................................................... 14 5.1.6 与其他子模块的接口 ............................................................................. 14 5.1.7 业务数据描述 ........................................................................................ 14 5.1.8 边界值处理 ............................................................................................ 15 5.1.9 异常处理................................................................................................ 15 5.2 渠道管理 ....................................................................................................... 15

5.2.1 功能概述................................................................................................ 15 5.2.2 功能点清单 ............................................................................................ 16 5.2.3 功能详细描述 ........................................................................................ 16

5.2.3.1 管理申请 ....................................................................................... 16 5.2.3.2 管理申请 ....................................................................................... 16 5.2.4 业务数据描述 ........................................................................................ 17 5.3 订单管理 ....................................................................................................... 17

5.3.1 功能原型................................................................................................ 17 5.3.2 功能概述................................................................................................ 17 5.3.3 功能点清单 ............................................................................................ 18 5.3.4 功能详细描述 ........................................................................................ 18

5.3.4.1 订单审核 ....................................................................................... 18 5.3.4.2 订单管理 ....................................................................................... 19 5.3.4.3 订单查询 ....................................................................................... 21

2

3 4 5

6

5.3.4.4 新增订单 ....................................................................................... 22 5.3.5 业务数据描述 ........................................................................................ 22 5.4 资源管理 ....................................................................................................... 22

5.4.1 功能原型................................................................................................ 22 5.4.2 功能概述................................................................................................ 22 5.4.3 功能(业务)流程图 .................................................................................. 22 5.4.4 功能点清单 ............................................................................................ 23 5.4.5 子功能详细描述 ..................................................................................... 23

5.4.5.1 产品管理 ....................................................................................... 23 5.4.5.2 发布管理 ....................................................................................... 24 5.4.6 业务数据描述 ........................................................................................ 25 5.4.7 功能原型................................................................................................ 26 5.5 统计管理 ....................................................................................................... 26

5.5.1 功能概述................................................................................................ 26 5.5.2 功能(业务)流程图 .................................................................................. 26 5.5.3 功能点清单 ............................................................................................ 26 5.5.4 功能详细描述 ........................................................................................ 27

5.5.4.1 工作量统计 ................................................................................... 27 5.5.4.2 广告效果统计 ................................................................................ 27 5.5.5 业务数据描述 ........................................................................................ 33 非功能性需求 .............................................................................................................. 34 6.1界面操作需求 ................................................................................................... 34 6.2性能需求 ........................................................................................................... 34 6.3安全性需求 ....................................................................................................... 34 6.4维护与升级 ............................................................................................................ 34 6.5可靠性和健壮性 .................................................................................................... 34 6.6用户文档需求 ........................................................................................................ 34 6.7运行环境 ............................................................................................................... 34

1 文档介绍

1.1

文档的目的

此文档是提供用于软件开发部门和产品设计部门、产品测试部门之间就此产品的需求分析、产品开发、产品设计、测试方案交流的基础;

1.2 参考文档

1.3 产品命名规范

2 产品介绍

2.1

产品概要说明

产品管理系统是公司运营内部使用的对公司线上产品进行管理对订单进行发布的系统平台。可以对订单进行审核及管理,对产品进行管理,对订单效果进行查询。保证整个运营服务系统的正常流转。 结构图如下:

2.2 产品用户定位

此产品面向的主要是两类人员。一类是面向系统运行的系统管理员,另一

类是面向运营人员。两者对软件的操作熟练程度差距很大,所以产品设计和实现时尽量给予简单的界面和完备的帮助,并对重要功能的业务权限要集中、重点控制。

2.3 产品中的角色

3 产品总体业务流程图

4 产品功能结构图

5 功能需求

5.1

系统管理

5.1.1 功能原型

参见原型添加日志分类名称测试是否允许标点符号以及长度限制等

5.1.2 功能概述

对角色、系统用户、系统日志、密码进行管理操作。

5.1.3 功能(业务)流程图

5.1.4 功能点清单

5.1.5 功能详细描述

5.1.5.1 角色管理

 功能点描述:管理员可以在后台定义不同的角色,例如,渠道经理、财务人员。

 使用角色:系统管理员

 输入:查询条件,角色信息

 处理:

1、 查询角色

系统管理人员输入查询信息,进行查询。 查询条件:角色名称。

查询结果:编号、角色名称、角色描述。

2、 新增角色

系统管理人员添加新的角色名称。

添加数据:角色名称、角色描述、角色所属权限。

3、 修改角色

系统管理人员选中要修改的角色名称,并对其进行修改。

修改数据:角色名称、角色描述、角色所属权限。

4、 禁用角色

系统管理员对某一角色实施禁用操作。日志中将依旧保留此角色的操作记录。但当为新建用户分配角色时将无法显示此禁用角色。此角色的现有用户将无法进行操作。

5、 启用角色

系统管理员对某一个禁用角色进行启用操作。建立用户时将可以在下拉选择列表中看到此角色。

6、 删除角色

系统管理员只能删除没有赋予用户的空角色。

 输出:

1、 查询结果

全选 角色名称 角色描述 状态 操作

2、 操作按钮

查询、新增、修改、禁用、启用、删除

操作链接:查看,修改 5.1.5.2 用户管理

 功能点描述:系统管理员创建用户,并赋予不同用户不同的角色。还可以查

询显示出用户信息,并修改用户信息。如对用户进行禁用操作后,不允许用户登录、启用后恢复登录功能。也可以删除用户信息,删除只能删除没有对应任何操作的空用户信息。

 使用角色:系统管理员。

 输入:查询条件、用户信息、所属角色。状态(禁用、启用)

 处理:

1、 查询用户:输入相关的用户信息,选取角色范围,查询用户。并显示在列表中。 2、 新增用户:新增用户信息,填写用户的基本信息,分配角色。 3、 修改用户信息:修改已有用户的基本信息。 4、 修改用户密码:重新填写用户密码。

5、 禁用用户:对用户进行禁用操作后,用户使用用户名,密码无法再登陆系统。 6、 启用用户:对禁用用户进行操作后,用户恢复登陆功能。

7、 删除用户:删除没有关联任何操作的用户(操作后记录操作信息)。空用户信息。

如果有要删除的用户有关联信息,那么将提示只能禁用用户。

 输出:

1、 查询显示结果

操作按钮:查询、新增、禁用、启用、修改、删除 操作链接:角色查看、修改信息、修改密码 5.1.5.3 系统日志    

功能点描述:系统管理员对操作人员的所有操作信息进行查看

使用角色:系统管理员 输入:查询条件

处理:按条件查询信息,输入选择查询条件,可按用户、IP地址、操作模块、操作类型、操作时间进行查询,显示在列表中。

操作按钮:查询

5.1.5.4 密码修改     

功能点描述:登陆系统的用户可以使用此功能修改密码。 使用角色:所有用户 输入:新密码、重复密码

处理:所有登陆系统的用户都可以通过此功能修改密码 输出:提示修改成功、提示输入错误

5.1.5.5 角色查询     

功能点描述:登陆系统的用户可以使用查询系统中所有角色信息。 使用角色:查询权限的用户 输入:查询信息

处理:查询出所有符合条件的信息。 输出:

全选 角色名称 角色描述 状态 操作

操作链接:查看

5.1.5.6 用户查询     

功能点描述:登陆系统的用户可以使用查询系统中所有的用户信息。 使用角色:查询权限的用户 输入:查询信息

处理:查询出所有符合条件的信息。

操作链接:角色查看

5.1.6 与其他子模块的接口

1、 在撤销订单以后需要变更客户资料的状态,这里需要调用呼出模块的接口 2、 在撤销订单以后需要删除相关工作流的任务,这里需要调用工作流的接口

5.1.7 业务数据描述

1、 角色信息(编号、角色名称、角色描述)

角色名称:20个中文字符

角色描述:50个中文字符 角色权限:复选框选择

2、 用户信息(编号、登陆密码、E-mail、部门、所属角色、状态)

用户名: 由字母a~z(不区分大小写)、数字0~9、点、减号或下划线组成。只能以数

字或字母开头和结尾 用户名长度为4~18个字符。

登陆密码:5到16个字符。机器生成

E-mail:判断是否含有@的字符串,20位以内。 部门: 20个字符以内。

所属角色:下拉框选择,20个中文字符。

3、 日志信息

操作模块:10个中文字符。 操作类型:15个中文字符。 操作内容:200个中文字符。 操作时间:yy-mm-ddhh:mm:ss 用户名称:4到18个字符 角色名称:20个中文字符。

5.1.8 边界值处理

1、 如果驳回,那么驳回原因必须填写

2、 对于合同组合同审核,如果通过,那么合同编号必须申请,印刷编号必须填写

5.1.9 异常处理

撤销订单信息和撤销工作流任务一起作为原子操作,如果一个失败,两个都要rollback

5.2 渠道管理

5.2.1 原型

参见原型地址。

5.2.2 功能概述

渠道经理登陆系统查看渠道商的申请信息。线下联系渠道商,并达成代理协议。

5.2.3 功能(业务)流程图

5.2.4 功能点清单

5.2.5 功能详细描述

5.2.5.1

管理申请    

功能点描述:渠道经理查询渠道商申请,删除掉无意义的申请信息。 使用角色:渠道经理 输入:查询条件 处理:

1、 查询申请:渠道经理输入查询条件,查出近期网上提交的渠道代理申请。 2、 删除申请:渠道经理对一些明显无意义的申请进行删除操作。  输出:

1、查询结果

全选 区域

公司

电话

联系人

传真

Email

申请时间

按钮:删除、复审确认、分配审核人

5.2.5.2 管理申请

 功能点描述:渠道经理查看渠道申请,线下联系渠道商并签订合同。  使用角色:渠道经理

 输入:查询条件  处理:

1、删除申请:渠道经理删除无意义的渠道申请信息。  输出:

1

、查询结果

全选 区域 公司 电话

传真

联系人

Email

申请时间

操作按钮:删除

5.2.6 业务数据描述

1、 渠道商信息

代理区域:下拉菜单 公司名称:(必填)30位中文字符 联系人:(必填)10个中文字符 联系电话:(必填)20个字符 传真号码:(必填)20个字符 E-mail:(必填):判断

是否含有@的字符串,60位。

5.3 订单管理

5.3.1 功能原型

参见原型地址。

5.3.2 功能概述

运营人员新增订单并对提交的订单进行审核及管理。

业务(功能)流程图

5.3.3 功能点清单

5.3.4 功能详细描述

5.3.4.1 订单审核

 功能点描述:后台运营人员下订单并对订单进行内容、排期审核,驳回订单审核人员填

写驳回原因。如有部分问题,审核人员可以修改订单内容,并通过审核。  使用角色:运营人员

 输入:查询条件、驳回理由  处理:

1、 查看订单详细内容 2、 驳回并填写驳回理由 3、 通过审核

4、 修改客户意向并通过审核。

 输出:

1、待审核订单列表:

订单号

合同号

客户公司名称 联系电话

业务员

创建时间 创建人

操作

全选

订单类型

操作链接:查看明细 操作按钮:通过、驳回

2、订单明细

订单号: 订单类型: 合同号: 公司名称: Showroom: 联系电话: 业务员:

操作按钮:驳回、通过、修改、删除

5.3.4.2 订单管理

 功能点描述:订单管理员会对所有订单进行管理、可以对某些通过审核的订单进行禁用

启用操作。能对已审核、待审核的订单进行禁用,禁用后订单状态为冻结。启用后订单恢复原来状态。可以查看订单的状态(待审核、已审核、驳回、已完成、已退单)  使用角色:订单管理员

 输入:查询条件为(订单号、合同号、客户公司名、联系电话、业务员)创建人、审核

人、订单状态(下拉)、创建时间(时间选择输入)排序方式(订单号、合同号、客户公司名、联系电话、业务员、创建时间状态审核人创建人)(升序、降序)显示(10、20、40)  处理:

1、查询显示符合条件的订单。 2、 查看订单明细。

3、 对明细进行退订操作。 4、 对明细进行禁用启用。

5、 对整个订单进行禁用启用。 6、 对整个订单进行退订操作。

 输出:

订单类型

订单号 全选

合同号

客户

业务

公司名称

付费用户

YN00001

北京

2006-12-23

MIC-H-00069 天大010-88887777 mike 待审核 mikemike查看明细

10:08:09

公司

创建审核

创建时间 状态

操作

人 人

联系电话

操作按钮:查询、禁用、启用、退订 操作链接:查看明细 订单明细

订单号: 订单类型: 合同号: 公司名称: Showroom: 联系电话: 业务员: 总产品数: 7 订单产品信息

产品类型

产品编号

全选

产品名称

服务开始日服务终止日

状态

向 客户意

固定位广告

HOP001 首页通栏

搜索排名第1位

2006-12-10 2006-12-17 待发布 详细

搜索排名

会员服务

HOP001

2006-12-10 2006-12-17 发布中

(mp3)

详细

HOP001 HOP001

先进型会员服务 黄金展位(mp4)

2006-12-10 2006-12-17 已完成 2006-12-10 2006-12-17 退订

详细 黄金展位

黄金展位

HOP001

黄金展位(mp3

2006-12-10 2006-12-17 冻结

player)

详细

退订禁用启用

操作按钮:禁用、启用、退订 操作链接:详细

5.3.4.3 订单查询

 功能点描述:相关人员可以有查询订单的权限。并查看订单的详细信息,但无法进行任

何操作。

 使用角色:销售人员、CEO

 输入:查询条件为(订单号、合同号、客户公司名、联系电话、业务员)创建人、审核

人、订单状态(下拉)、创建时间(时间选择输入)排序方式(订单号、合同号、客户公司名、联系电话、业务员、创建时间状态审核人创建人)(升序、降序)显示(10、20、40)  处理:

1、 如何查询条件显示符合条件的信息。 2、 点中详细查看每条订单的详细信息。

 输出:

订单类型

订单号 全选

合同号

客户

业务

公司名称

付费用户

YN00001

北京

2006-12-23

MIC-H-00069 天大010-88887777 mike 待审核 mikemike查看明细

10:08:09

公司

创建审核

创建时间 状态

操作

人 人

联系电话

操作链接:查看明细

5.3.4.4 新增订单    

功能点描述:运营人员操作此模块按照合同要求给客户下订单 使用角色:下单人员

输入:合同号,公司名称、业务员、联系电话、Showroom地址,客户意向。 处理:

1、 输入订单基本信息 2、 查询客户showroom 3、 添加客户意向并提交

5.3.5 业务数据描述

合同号:(必填)20个字符 公司名称:(必填) 100个字符 业务员:20个字符 联系电话:(必填)40个字符 投放关键词:100个字符

图片:小于100K的gif 和jpg图片。 广告文本:200个字符 广告链接:300个中文字符

5.4 资源管理

5.4.1 功能原型

参见原型地址

5.4.2 功能概述

产品负责人员对产品资源进行管理,包括产品价格,折扣,规格。运营人员对发布进行管理。

5.4.3 功能(业务)流程图

订订订订

订订订订

5.4.4 功能点清单

5.4.5 子功能详细描述

5.4.5.1 产品管理

 功能点描述:产品运营人员添加产品编号,产品类型,产品相应的规格信息。生成产品

配置表。前台查询此配置表,得到相应的产品信息。产品运营人员在日常事务中维护此资源配置表。对所有产品信息进行增加、查询、修改、删除、禁用、启用操作。

 使用角色:产品运营人员

 输入:固定位广告、黄金展位、搜索排名、产品推荐、公司推荐等产品的产品信息

 处理:

a) 查询产品:输入查询条件,产品编号、产品名称、选择产品类型、产品状态(所

有、禁用、启用),排序方式,按某一个字段的升序降序,显示条数进行查询。

b) 修改产品信息:选中产品信息。点操作区“修改信息”,将弹出信息表单。可

修改产品类型、产品编号、产品名称、数量、规格、价格、折扣、默认图片、产品描述。点击保存按钮提示保存成功信息。列表中的产品相应信息将做出相应的变化。

c) 新增产品:点击右下侧“新增”按钮。将弹出新增输入框,填写产品类型、产

品编号、产品名称、数量、规格、价格、折扣、默认图片、产品描述。并点击保存,提示新增成功。产品编号、产品名称不允许为重复。

d) 禁用产品:当某一个产品由于需求需要隐藏一段时间。我们将采用禁用操作。

选中要禁用的信息后点“禁用”按钮。提示此条信息将被禁用。禁用操作后将改变此条产品状态。此条产品信息将无法在前台及下订单模块查询出来,但历史的操作数据将保留。

e) 启用产品:对禁用的产品进行启用操作。恢复此条产品的状态,在下订单模块

将能查询显示出此条信息。

f) 删除产品:只能对没有任何订单操作的产品信息进行删除操作。

 输出:

1、 产品管理

全选 产品编号 产品类型

HO001

固定位

产品名称

数量

规格

价格

折扣

状态

操作

首页通栏 1 770*100 50000.00 100% 启用 修改信息

按钮:查询、新增、禁用、启用、删除 链接:修改信息

5.4.5.2 发布管理

 功能点描述:

对现在发布中以及待发布的所有订单明细进行查询,可以修改发布明细的信息。(图片,广告标题,广告文本,广告链接,对应产品,对应图片)当每日的自动发布实效时,可以手动重新发布。

 使用角色:

产品运营人员

 输入:

广告产品的相关客户意向(广告图片、广告标题、广告文本、广告链接、对应的产品)

 处理:

1. 按条件查询

查询条件:产品类型(下拉)、订单类型(下拉:付费用户、内部推荐)、产品编号、产品名称、状态(下拉:待发布、发布中)、 排序方式:订单类型、产品类型、产品编号、产品名称、订单号、开始日期、终止日期、业务员、公司名称、合同号、状态(升序、降序) 显示:10、20、40

默认:排序按照发布日期,降序,显示10条

2. 手动发布

点击手动发布按钮对所有修改信息重新发布。

 输出:

1、 发布查询结果

订单

订单号 合同号

类型

产品产品编产品业务

公司名称 开始日期 终止日期 状态 操作

类型 号 名称 员

付费北京天锡固定首页发布修改 / 查

HY001 MIC-H-0001 HOS001 2008-09-21 2008-09-21 mike

用户 有限 位 通栏 中 看详细

操作按钮:查询、手动发布 操作链接:修改、查看详细

5.4.6 业务数据描述

1、产品管理

类型名称:20个中文字符 类型描述:100个中文字符 产品编号:8位字符

产品名称:20个中文字符 所在频道:20个中文字符

所在页面:20个中文字符 所在页面地址:300个字符 图片宽度:3位数字 图片高度:3位数字 市场参考价(¥/周):10位数字,保留小数点后2位。

折扣:2位数字

2、 发布管理

广告图片:大小在100k以下的图片。 广告标题:25个字符以内(必填) 广告文本:70个字符(必填) 链接地址:300个字符(必填) 站内地址:300个字符(必填)

5.4.7 功能原型

参见原型地址

5.5 统计管理

5.5.1 功能概述

对审核订单工作量、广告的效果进行全面的统计。

5.5.2 功能(业务)流程图

订订订订

5.5.3 功能点清单

5.5.4 功能详细描述

5.5.4.1 工作量统计

 功能点描述:

对所有订单审核的工作量进行查询统计,按操作人员统计出下订单数量,审核订单数量、驳回数量。

 使用角色: 运营人员  输入: 查询条件  处理:

1、 查询工作量

查询条件:操作人员、所属角色(下拉)统计日期

排序方式:操作人员、所属角色、下订单数量、审核数量、驳回数量 显示: 10、20、40

默认按操作数量排序,显示10条信息 点操作人员可以查看操作人员信息 点角色信息可以查看操作人员角色信息

 输出:

操作按钮:查询

5.5.4.2 广告效果统计

 功能点描述:

可以按订单、按产品、按购买词显示广告的效果统计信息。  使用角色: 产品运营人员  输入: 查询条件  处理:

1. 按订单统计 查询条件

订单号(10个字符)

订单类型(20个中文字符) 公司名称:(100个字符) 联系电话:(20个中文字符) 业务员:20个中文字符

订单类型:下拉选择全部、内部推荐、付费用户

订单状态:下拉选择(全部、已审核、已完成、冻结) 创建时间:时间控件

排序方式

订单号、合同号、订单类型、公司名称、联系电话、业务员、创建时间、订单状态(升序、降序)

默认按创建时间降序 显示

10、20、40 默认显示10条

订单详细项统计综合、地域、时间段、操作系统、浏览器效果时。可选择时间段。时间段选择范围分两种情况,如果订单状态为已审核,此订单明细的时间段为上线日期到昨日。如果订单状态为已完成,此订单明细的时间段为上线日期到下线日期

2. 按产品统计 查询条件

产品类型全部 (KP001)产品搜索关键词广告 产品编号(20个字符) 产品名称(40个字符)

状态:下拉(全部、启用、禁用) 统计时间:时间控件

排序方式

产品编号、产品名称、产品类型、订单数、曝光数、点击数、点击率(‰)、状态(升序、降序)

默认按点击率(‰)降序 显示

10、20、40 默认显示10条

月统计按年选择统计,默认为当年 周统计选择时间段,默认上一周 天统计选择时间段,默认为昨天

3. 购买词统计 查询条件

年份:下拉(2007~2017) 关键词:(100个字符)

级别:下拉(全部、A 、B、C) 排序方式

关键词、订单数、曝光数、点击数、点击率‰(升序、降序) 默认按关键词曝光数升序

显示

10、20、40 默认显示10条

购买词统计详细,按选择年份查看某个词的详细信息,统计出这个词在不同产品中的广告效果。

所有统计图以折线图显示。显示点击率情况。 点击率= 点击数 / 曝光数 点击率单位以‰ 表示

 输出:

1. 按订单统计

订单订单合同号

公司名称 联系电话

类型

业务员

创建时间

订单状

操作

查看订单详

操作按钮:查询、返回上一级 操作链接:查看订单详细

订单详细统计 操作按钮:返回上一级别、导出报表

操作链接:综合、地域、时段、操作系统、浏览器

综合

订单(订单号)

产品类型:(类型编号)类型名称 产品编号:

地域

操作系统

订单(订单号)

产品类型:(类型编号)类型名称 产品编号: 产品名称:

发布日期:yyyy-mm-dd

截止日期:

yyyy-mm-dd

浏览器

订单(订单号)

产品类型:(类型编号)类型名称 产品编号: 产品名称:

发布日期:yyyy-mm-dd 截止日期:yyyy-mm-dd

操作按钮:查询、返回上一级 操作链接:月、周、日

统计图为折线

统计图为折线

统计图为折线

操作按钮:查询、返回上一级 操作链接:详细信息

购买词统计详细

关键词: 订单数: 年份:

5.5.5 业务数据描述

6 非功能性需求

6.1界面操作需求

整体风格保持一致,功能操作使用按钮,操作在同一界面上完成。

运行界面可最大化最小化拖拽改变大小,兼容800X600以及以上各分辨率。

6.2性能需求 6.3安全性需求

高级管理员与普通运营人员以权限划分不同的操作菜单。

6.4维护与升级 6.5可靠性和健壮性 6.6用户文档需求 6.7运行环境

IE5以上

范文八:需求分析文档模板 投稿:金裵裶

@二

14

需求分析报告编写说明

14. 1

51 言编 写说明

引 言是 对这份软件 产 品需求分析报告的概览,是为 了 帮助阅读者了解这份文档是如何编 写 的,并且应该如何阅读、理解和解释这份文档 。

14.1 . 1

编写目的

说明这份软件 产 品需求分析报 告是 为哪个软件产品编写的,开发这个软件产品意义、作用

以及最终要达到的意图 . 通过这份软件产品需求分析报 告详尽 说明了眩软件产品的需求规

楠,包括修正和发行版本 号 ,从而对该软件 产 品进行准确的定义 。

如果这份软件产品需求分析报 告只与整 个系统的某 一 部分有关系,那么只定义软件产品

需求分析报告中说明的那个部分或子系统。

14. 1.2

预期读者和阅读建议

列举本软件产 品需求分析报 告 所针对的各种不同的预期读者,如可能包括用户、开发人 员、项目经理、营销人员、测试人员、文档编写人员;并且描述了参考文档中,其余部分的内容

及其组织结构,针对每 一 类读者提出最适合的文档阅读建议。

14.1.3

产品范围

产品范围说明该软件产品及其开发目的的简短描述,包括利益和目标。产品范围必须考

虑软件产品开发与企业目标 ,或 业务策略相联系 。

14.1.4

例如:

参考资料

下面列出有用的 参考资料 .

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

. 属 于本项日 的其他已发 表 的文件;

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

令软件时炼成的一从时叫软附设计

· 业务调研报告相关文件 。

14.2

14.2.1

概述编 写 说明

开发意图

在需求分析报告中,开发意图部分需要说明系统开发的目标、意图、提高管理目标等,这部

分内容可以简略描述,不作为重点内容编写。

14.2.2

约束和假定

列举出对软件产品需求分析报告中,影响需求陈述的假设因素 。 如果这些假设因素不正

确 、不 一致或者被修改,就会使软件产品开发项目受到影响.这些假设的因素可能包括,计划

使用的商业组件,或其他软件中的某个部件;假定产品中某个用户界面将符合 一 个特殊的设

计约定;有关本软件用户的若干假定;有关本软件开发工作的若干假定;有关本软件运行环

境的 一 些问题 。

14.2 . 3

产品描述

概括描述软件体系结构、软件组织结构、每个子系统的主要功能等 。

14.3

X X X 子 系统功能 需 求 详细描述编 写 说明

本节主要以子系统为单位 , 对每个子系统的功能项进行描述,按照本书第 10 章设计结果, 分别说明 子 系统的用例关系以及用例的详细

描述 。

14. 3.1 14.3.2 14.3.3

xxx 子系统功能概述

详细描述所要描述子系统的功能、结构关系等。

xxx 子系统用例图

绘制用例图,并且说明用例之间的关系 。 相关概念请参见第 10 章。

用例描述

按照事件流格式 , 描述用例的事件疏、例外事件流,相关概念请参 见第 9 章 .

14.4 领域类图编 写 说明

14.4.1

xxx 领域类图

在用例图的基础上,结合用例对象设计领域类关系 , 绘制出领域类图。相关概念请参见本 书第 11 章 。 在本节中需要绘制领域类图,井且说明领域类之间的关系 。 考虑到篇幅问题,在

领域类图中可以省略属性部分,属性部分由领域类属性部分来说明。

14.4.2

xxx 领域类属性

领域类属性其实就是对领域类圆的补充说明,在这里我们依据数据字典和数据集为依据

第1 篇软倒开发⑥

以 表 格形式给予描述,相关概念请参加第 8 章部分 。

14.5

14. 5.1

非功能 需求编写说明

物理需求

描述系统运行的必要的硬件需求,要求详细到性能、容量、速度、容错性 等 。 相关概念请参

见第 12 章相关概念 .

14.5.2

实施需求

详尽陈述与系统安全性、完整性问题相关的错求,或与个人隐私问题相 关 的 需求 。 这些问

题将 会影 响到软件产品的使用,和软件产品所创建或者使用的数据的保护 。 定义用户身份认

证,或备授权需求 。 相关概念详见第 12 章相 关 概念 。

14.5 . 3

易用性需求

在本部分内容中,应该详细阐述用户在使用系统方面的相 关铺求,包括 界面、操作流程、文

字 解释、使用场景、帮助文档等方面 。

14. 5 . 4

性能需求

阐述软件产品性能的需求,并且说明提出需求的原理或者依据,以帮助 开发 人员 做出 合 理 的设计选择 。 尽可能详细 地描述性能 需求,如果需要,可以针对每个功能需求或者特征分别陈

述其性能需求 。 相关概念请参见本书第 12 章 。

14.5.5

可靠性需求

可靠性需求是投核保系统的重要内容,在这里应该详细陈述软件可靠性方面的具体需求 。

以及可革性需求方面的具体解决办法 。 相关概念见第 12 章 。

14.5.6

软件项目管理需求

软件项目管理需求在 一 般的软件需求分析中很少用到,但 是 ,规范的软件开 发文挡 ,应 该

将软件项目管理需求 列为需求分析报告的 重要 的内容来说明, 只有 这样才能够保证整个 项目

组街统一 的管理认可和客户认可的管理体系 。

14.6

概念 。

数据字 典编 写 说明

以表格的形式,解释系统中用到的每个数据项和专业术语 。 相 关 概 念请参见第 8 章 相 关

范文九:腾讯需求文档(模板) 投稿:董蛨蛩

XXX

修订记录

目 录

修订记录 .................................................................................................................................................. 1 目 录 ...................................................................................................................................................... 1 1

前言.................................................................................................................................................. 2 1.1 1.2 1.3 2

名词解释 ................................................................................................................................. 2 参考文档 ................................................................................................................................. 2 整体流程/逻辑关系 ................................................................................................................ 2

特性.................................................................................................................................................. 2 2.1

特性 F01 XXXX ....................................................................................................................... 2

2.1.1 2.1.2

特性所包含的功能 ......................................................................................................... 2 功能性需求(Functional Requirements,FR) ........................................................... 2 2.1.2.1 F01.FR01 XXXXX ................................................................................................................... 2 2.1.2.2 F01.FR02 XXXXX ................................................................................................................... 3

特性 F02 XXXX ....................................................................................................................... 3

2.2 3 4 5

性能需求.......................................................................................................................................... 3 国际化需求 ...................................................................................................................................... 4 附录.................................................................................................................................................. 4

1 前言

1.1 名词解释

说明:列出本文档中所用到的专门术语的定义和缩略语的全称和解释。

1.2 参考文档

说明:列出本文档的所有参考文档。

1.3 整体流程/逻辑关系

说明:说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图。

2 特性

2.1 特性 F01 XXXX

说明:陈述该特性的简要说明。F指特性,m为1~n的自然数,Fmm为该特性的编号。 如:1.1特性F03 截图功能优化。

2.1.1 特性所包含的功能

2.1.2 功能性需求(Functional Requirements,FR)

2.1.2.1 F01.FR01 XXXXX

说明:将复杂特性细分为系统需求,陈述该功能的详细说明。 如:1.1.2.1 F01.FR01屏幕截图灰屏机制优化。

2.1.2.2 F01.FR02 XXXXX

2.2 特性 F02 XXXX

内容构架同1.1,同样描述特性2的功能性需求

3 性能需求

对照此表进行检查,在“相关特性”中简单标注符合条件的特性

4 国际化需求

说明: 国际化需求包括以下方面:1、编码问题Unicode 2、区域和文化意识方面:区域,

日期和日历,时间格式,货币格式,大小与转换,排序和字符串比较,数字格式, 3 4

5 附录

涉及到的其他相关文档在此列明。没有则写无。

需求文档命名规范参见《Hummer产品需求规格说明书命名范例》。

范文十:需求文档模板 投稿:叶衼衽

需求文档模板

编者说明:

许多有经验的开发团队在开始需求调查的时候,总会将

1.要求分析人员使用符合客户语言习惯的表达;

2.要求分析人员了解客户系统的业务及目标;

3.要求分析人员组织需求获取期间所介绍的信息,并编写软件需求规格说明.

4.要求开发人员对需求过程中所产生的工作结果进行解释说明;

5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度;

6.要求开发人员 产品的实现及需求都要提供建议,拿出主意.

7.描述产品使其具有易用,好用的特性;

8.可以调整需求,允许重用已有的软件组件;

9.当需要对需求进行变更时,对成本,影响,得失有个真实可信的评估;

10.获得满足客户功能和质量要求的系统,并且这些要求是开发人员同意的.

软件客户需求义务书

1.给分析人员讲解业务及说明业务方面的术语等专业问题;

2.抽出时间清楚地说明需求并不断完善;

3.当说明系统需求时,力求准确详细;

4.需要时要及时对需求做出决策;

5.要尊重开发人员的成本估算和对需求的可行性分析;

6.对单项需求,系统特性或使用实例划分优先级;

7.评审需求文档和原型;

8.一旦知道要对项目需求进行变更,要马上与开发人员联系;

9.在要求需求变更时,应遵造开发组织确定的工作过程来处理;

10.尊重需求工程中开发人员采用的流程(过程).

软件项目视图和范围

编者说明:

项目所涉及的内容与所解决的问题都是有限的,而且项目应该是十分有目的性的,是为了实现某个可度量的目标而做的.因此,在需求分析的前期应该将

1.业务需求

[业务需求说明了提供给客户和产品开发商的新系统的最初利益.不同产品可能会有不同的侧重点.本部分描述了你为什么要从事此项项目的开发,以及它将给开发者和购卖者带来的利益.]

1.1 背景

[在这一部分,总结新产品的理论基础,并提供关于产品开发的历史背景或形势的一般性描述.]

1.2 业务机遇

[描述现存的市场机遇或正在解决的业务问题.描述商品竞争的市场和信息系统将运用的环境.包括对现存产品的一个简要的相对评价和解决方案,并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势.认识到目前只能使用该产品才能解决的一些问题,并描述产品是怎样顺应市场趋势和战略目标的.]

1.3 业务目标

[用一个定量和可测量的合理方法总结产品总结产品所带来的重要商业利润.关于给客户带来的价值在后面阐述,这里仅把重点放在给业务的价值上.这些目标与收入预算或节省开支有关,并影响到投资分析和最终产品的交付日期.]

1.4 客户或市场需求

[描述一些典型客户的需求,包括不满足现在市场上的产品或信息系统的需求.提出客户目前所遇到的问题在新产品中将可能(或不可能)出现的阐述,提供客户怎样使用产品的例子.确定了产品所能运行的软,硬件平台.定义了较高层次的关键接口或性能要求,但避免设计或实现细节.把这些要求写到列表中,可以反过来跟踪调查特殊用户和功能需求.]

1.5 提供给客户的价值

[确定产品给客户带来的价值,并指明产品怎样满足客户的需要.可以用下列言辞表达产品带给客户的价值: 提高生产效率,减少返工;

节省开支;

业务过程的流水线化;

先前人工劳动的自动化;

符合相关标准和规则;

与目前的应用产品相比较,提高了可用性或减少了失效程度.]

1.6 业务风险

[总结开发(或不开发)该产品有关的主要业务风险,例如市场竞争,时间问题,用户的接受能力,实现的问题或对业务可能带来的消极影响.预测风险的严重性,指明你所能采取的减轻风险的措施.]

2.项目视图的解决方案

[文档中的这一部分为系统建立了一个长远的项目视图,它将指明业务目标.这一项目视图为在软件开发生存期中作出决策提供了相关环境背景.这部分不包括详细的功能需求和项目计划信息.]

2.1 项目视图陈述

[编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述.项目视图陈述将考虑权衡有不同需求客户的看法.它可能有点理想化,但必须以现有的或所期待的客户市场企业框架.组织的战略方向和资源局限性为基础.]

[如:

2.2 主要特征

[包括新产品将提供的主要特性和用户性能的列表.强调的是区别于以往产品和竞争产品的特性.可以从用户需求和功能需求中得到这些特性.]

2.3 假设和依赖环境

[在构思项目和编写项目视图和范围文档时,要记录所作出的任何假设.通常一方所持的假设应与另一方不同.如果你把它们都记录下来,并加以评论,就能对项目内部隐含的基本假设达成共识.比如,

3.范围和局限性

[项目范围定义了所提出的解决方案和概念和适用领域,而局限性则指出产品所不包括的某些性能.如果一般客户所提出的需求超出项目的范围时就应当拒绝它,除非这些需求是很有益的.记录这些需求以及拒绝它们的原因,以待查.]

3.1 首次发行的范围

[总结首次发行的产品所具有的性能.描述了产品的质量特性,这些特性使产品可以为不同的客户群提供预期的成果.应当避免将想到的每一个特性都包括到1.0版本产品中去.开发者应把重点放在能提供最大价值,

花花费最合理的开发费用及普及率最高的产品上.]

3.2 随后发行的范围

[如果你想象一个周期性的产品演变过程,就要指明哪一个主要特性的开发将被延期,并期待随后版本发行的日期.]

3.3 局限性和专用性

[明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径.列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能.]

4.业务环境

[这一部分总结了一些项目的业务问题.]

4.1 客户概貌

[客户概述明确了这一产品的不同类型客户的一些本质特点,以及目标市场部门和在这些部门中的不同客户的特征.对于每一种客户类型,概述要包括:

各种客户类型将从产品中获得的主要益处;

它们对产品所持的态度;

感兴趣的关键产品的特性;

哪一类型客户能成功使用;

必须适应任何客户的限制.]

4.2 项目的优先级

[一旦明确建立项目的优先级,风险承担者和项目的参与者就能把精力集中在一系列共同的目标上.达到这一目的的一个途径是考虑软件项目的五个方面:性能,质量,计划,成本和人员.在所给的项目中,其每一方面应与下面三个因素之一相适应.

一个驱动----一个最高级别的目标;

一个约束----项目管理者必须操纵一个对象的限制因素;

一个自由度----项目管理能权衡其它方面,进而在约束限制的范围内完成 目标的一个因素.

未必所有的因素都能成为驱动,或所有的因素都能成为约束因素.在项目开始时记录和分析哪一个因素适用于哪一类型,将有助于使每一个人的努力和期望与普遍认可的优先级相一致.]

5.产品成功的因素

[明确产品的成功是如何定义和测量的,并指明对产品的成功有巨大影响的几个因素.不仅要包括组织直接控制的范围内的事务,还要包括我部素.如果可能,可建立测量的标准,用于评价是否达到业务目标,如:市场股票,销售量及收入,客户满意度,交易处理量和准确度.]

项目构想

编者说明:

这个文档模板与

1.文档简介

[软件需求规格说明书的整个内容还是锁定于整个系统的操作,使用层面之上的功能性需求,只是解决了How的问题,而并未回答Why的问题.这使得系统在开发过程中,开发团队经常陷入知其然,而不知其所以然的困境,造成了不必要的误解与错误.因此,需要一个侧重于对项目的风险承担者,目标用户需要的文档,不仅要了解他们需要的功能,还要找到他们提出这些需求的原因.这就是

[本节的内容主要是提供项目构想文档的目的,范围,定义,参考资料以及对其的摘要性概述.]

1.1 目的

[说明该文档的写作目的.]

1.2 范围

[范围主要用来说明该文档描述的项目内容,以及与其相关的其它东西.]

1.3 定义,首字母缩写词和缩略语

[与其它文档一样,该文档也需要将本文档中所涉及的所有术语,缩略语进行详细的定义.还有一种可简明的做法,就是维护在一个项目词汇表中,这样就可以避免在每个文档中都重复很多内容.]

1.4参考资料

[在这一小节中,应完整地列出该文档引用的所有文档.对于每个引用的文档都应该给出标题,标识号,日期以及来源,为阅读者查找这些文档提供足够详细的信息.]

1.5 概述

[在本小节中,主要是说明项目构想各个部分所包含的主要内容,就像一个文章摘要一样.同时也应该对文档的组织方式进行解释.]

2.定位

2.1 商业机会

[如果该项目是一个产品型项目,那么应该在本小节中描述该产品所针对的商业机会.如果是定制开发项目,那么可以省去本小节.]

2.2 问题说明

[使用表格的形式,将该项目将要解决的问题进行概要性地描述:]

存在的问题

[问题的简要说明]

受影响的人群

[该问题对哪些人群带来了影响]

导致的后果

[该问题带来的不利因素]

希望的解决方案

[列出解决方案所能够解决的问题,以及其相应的优点.]

2.3 产品定位说明

[如果是产品型项目,则该小节将以表格的形式对产品的定位进行明确,如果是定制开发项目,可以省略本小节.]

目标市场

[描述产品目标客户群体]

目标客户需求

[说明客户的需要或者潜在的机会]

产品类别

[说明该产品属于什么领域]

主要优点

[描述让目标客户产生兴趣和购买欲的理由]

主要竞争对手

[列出与该产品有竞争的其它厂商的产品]

主要优势

[针对竞争产品的分析]

[一个具有清晰定位的产品,在开发过程中,团队将更好地理解,更容易开发出满足目标市场的产品,因而该部分内容是十分重要的.]

3.项目相关人员和用户说明

[了解用户,了解所有与该项目相关的人员,是有效地满足他们对系统,产品需求的基础.你应该在本小节中将所有的项目相关人员以及用户收罗在一起,并对他们进行简要的描述,对他们的需求,习惯,角度进行说明.这些内容将有助于开发团队更好的理解用户的需求本质.]

3.1 产品用户分析

[如果是产品型项目,那么你应该本节中对目标客户进行分析.可以在市场调查的基础上,对其市场的规模和增长率进行研究,从而估计其潜在的用户数量.另外,还应结合目标市场的实际情况,分析你的组织是否在该市场上有拓展的优势,如何获得这些优势.如果是定制开发项目,可以省略这一小节.]

3.2 项目相关人员一览表

[使用下面的表格,对项目相关人员进行分析.]

人员类别

代表

作用

[指明项目相关人员的类别]

[列举该类人员的代表]

[说明其对产品,项目开发的影响]

3.3 用户一览表

[使用下面的表格,对项目,产品的用户进行分析.]

用户类型

说明

代表

[指明用户类别]

[简要说明他们在系统中代表的对象和充当的作用]

[列举出代表]

3.4 用户环境

[了解用户在使用环境下使用系统或产品,是十分有意义的事,也是实现产品更好地满足需求,提供更加方便的使用界面的基础.例如:该任务由多少人来完成 是否总在变化 一个任务周期需要多长时间 执行每项活动要用多长时间 是否总在变化 是否有特殊的环境约束:移动,户外,乘机旅行等 目前使用的是哪些系统平台 以后会使用哪些平台 还在使用哪些应用程序 您的应用程序是否需要和这些应用程序集成 他们的计算机硬件系统的环境情况如何 他们都是在什么样的工作环境中使用系统的 ]

3.5 项目相关人员的简要说明

[以下表的形式,将各类项目相关人员的基本情况进行说明,以帮助开发团队更好地了解他们的情况.为每一类人员生成一张表格.]

代表

[列出该类项目相关人员的代表.]

说明

[对该类人员进行简要说明.]

专业技能

[描述本类人员的技能特长,技术背景以及电脑系统操作的熟练程度(可以分成业务用户,专家用户,熟练用户,初级用户等)]

职责

[描述本类人员对系统开发所承担的职责,以及应享有的利益.]

验收标准

[描述验证系统是否满足其职责的标准.]

参与方式

[该类人员是否参与系统开发,如果参与将以什么形式参加.]

项目成果

[说明该类项目相关人员是否参与项目成果的开发,是否有与其相关的项目成果.]

意见/问题

[列出与该类项目成员相关的问题与建议.]

3.6 用户简要说明

[以下表的形式,将与系统相关的各种用户的信息整理出来,以方便开发团队针对性的工作.要注意的是,用户会有不同的类型,有些用户需要的是灵活性,方便快速操作的高级功能,而有些用户则侧重与用户界面的友好性.这些与该用户的基本情况直接相关,了解用户才能够真正地开发出符合用户习惯和水平的系统.为每类用户生成一张表.]

代表

[列出该类用户的代表.]

说明

[对该类用户进行简要说明.]

专业技能

[描述该用户的技能特长,技术背景和对计算机系统操作的熟练程度.]

职责

[列出该用户对所开发的系统负有的关键职责,如记录详细信息,撰写报告,协调工作等.]

验收标准

[描述验证系统符合用户需求的标准.]

参与方式

[说明该类用户是否参与开发,如何参与.]

项目成果

[说明是否有依赖于该类用户的项目成果.]

意见/问题

[列出一些该类用户对系统提出的一个意见与建议,并且收集其认为该系统将遇到的问题.]

3.7 关键的项目相关人员/用户需要

[列出项目相关人员提出的针对对于该解决方案的关键问题.对于列出的每个问题,需澄清:为什么会出现这一问题 目前的解决方案是什么 他们需要什么要的解决方案 或者对新的解决方案有什么样的预期 ]

[还有一个很关键的内容就是,每个需求的优先级,这将对制定迭代计划时提供有效的基础,而优先级的确定,应该采用分级,累积投票等方法从用户,项目相关人员那里获得.应充分考虑项目客户方的要求.如果是产品型项目,则应该从产品经理,市场调查资料里获得.]

[经过整理后,将内容填入下表:]

需求

优先级

要点

目前解决方案

提议的解决方案

3.8 备选方案和竞争

[如果是产品型项目,应在此小节列举出客户除了购买该产品这外的选择,其中包括购买竞争对手的产品,自行设计解决方案甚至是维持现状.对所有潜在的竞争产品做一个列表,并根据客户的实际情况来确认主要优缺点.]

[而如果是定制开发型项目,则应该了解竞争对手提供的解决方案,比在此进行相应的比较.]

4. 产品概述

[本节主要从产品级,系统级的视角,高度概括产品的功能,与其它应用程序的交互以及所需的系统配置等.]

4.1 产品总体效果

[本小节主要将产品话在用户环境,使用环境的角度来介绍.如果是自成一体,则说明用户将如何使用;如果是

与其它的应用系统进行交互的,则在此小节说明如何与这些系统进行交互 它们之间采用什么样的通讯方式和接口.在这里最适合的方式是使用UML的部署图,让用户对系统最终的运行环境有一个较宏观的了解.]

4.2 主要功能

[本小节不是对系统或产品所有功能的罗列,而是将能够体现系统,产品主要优点和特性功能在此列出.在内容组织方面,应该直接与

4.3 假设与依赖关系

[在此小节中,列出所有会影响该文档中所述特性的各种因素.也就是列举出所有可能让该文档发生变化的假设条件.]

4.4 成本与定价

[该小节主要是对该项目的成本进行核算,对给出相应的定价策略.对于定制开发的项目,其成本主要包括开发的人工成本,公司管理成本,项目额外开支,相关软硬件工具投资等方面.而对于产品型项目而言,还包括分销成本,用户手册制作,CD制作等方面的成本.这里的成本核算为最终的合同价格以及产品的销售价值将提供一个基础的依据,因此也是十分重要的.]

4.5 许可与安装

[该小节中主要列出影响开发工作的一些许可和安装相关的问题.例如是否需要加密,如果验证用户合法性,安装界面的要求是什么.这方面对于产品型项目而言显得更加重要,也是对软件知识产权保护的一个重要措施.]

5.产品特性

[在本节中将列出系统或产品的特性,特性是指实现用户价值的系统功能.每一个特性都是一个所需的服务,通常是通过一系列操作实现预期结果.在FDD中,也就是特征.通常一个特征会由一个或多个用例来实现,通常系统的特性应该进行整合打包,以25-99项为合适.]

[本小节的描述应该能够让用户,操作人员,外部系统直接从系统的外边感受到每项特性,这些特性应该包括功能性说明以及一些可用性问题.但是要注意,在这里不要过早地引入设计的内容,这里说明的是What,而不是How.]

[另外,因在所有特性的描述中,确定其优先级.]

6.约束

[记录用户,项目相关人员提供出的一些约束条件,以及与其它系统之间的依赖关系,这是制订解决方案时必须考虑到的问题.]

7.质量要求

[对于整个系统的质量要求,如可靠性,可用性,性能,容错等质量要求,在这此节中详细地定义与描述.]

8.其他产品需求

[一些要求符合的标准,硬件基础要求,软件基础要求,环境要求等.]

8.1 适用的标准

[列出产品必须符合的所有标准.其中可能包括法律和法规(FDA,UCC)标准,通讯标准(TCP/IP,ISDN),平台一致性标准(Windows,Unix 等)以及质量和安全标准(UL,ISO,CMM).]

8.2 系统需求

[确定支持该应用程序所必需的任何系统需求.其中可能包括操作系统,网络环境,系统配置,内存大小,硬盘大小,外围设备和配套软件.]

8.3 性能需求

[本节用于详细说明性能需求.性能问题可能包括在各种负载条件下的用户负载因素,带宽或通信容量,吞吐量,精确度以及可靠性或响应时间.]

8.4 环境需求

[对于基于硬件的系统,环境因素可以包括温度,振荡,湿度,辐射等.对于软件应用系统,环境因素可以包括使

用条件,用户环境,资源可用性,维护问题,错误处理和恢复.]

9. 文档需求

[列举用户所需的与该系统或产品相关的文档.]

9.1 用户手册

[用户手册的制作说明,例如手册篇幅,详细程序,是否需要图,主要关心的点,要不要建立索引,词汇表,采用教程式还是速查手册式.]

9.2 联机帮助

[联机帮助是一种用户界面友好的服务,它可以为用户提供实时的协助.]

9.3 安装指南,配置文件,自述文件

9.4 标签与包装

10. 功能需求属性

[为了在项目开发过程中,对每个功能需求进行跟踪管理,在此对所有的功能进行一个总体的描述.]

[可以生成一张功能需求属性表,每条记录代表一条功能,每个功能包括以下字段:]

1)状态:标识该功能的最新状态.

已提出:已经提出来,但是还没有经过正式的复审而确定的需求;

已批准:已经经过正式的渠道复审而确定,准备实施的需求;

已加入:已经加入到需求管理基线中的特性.

2)利益:根据客户的态度,确定每个需求的重要程序,也是确定系统开发优先级的基础数据.

关键:必不可少的特性,缺少这些特性的系统将无法满足客户的要求,这些特性通常会在最早安排到迭代开发中去;

重要:对于系统来说,该特性是十分重要的,很难以通过其它方式来弥补,如果这些特性没有第一时间实现,将会使得客户满意度大大降低.因此是第二优先实现的特性;

有用:这些是一些有效,但使用频率较低的功能特性.如果没有在第一时间实现,也不会对客户满意度造成很大的影响;

无用:对于系统来说是

3)工作量:根据特性所需的时间和资源进行估算,给出团队开发的工作时间或个人开发的工作时间.也可以估算出代码行数或功能点数,这也将为迭代开发计划的制定提供良好的基础.

4)风险:列出该特性开发的最大风险,可以对这些风险进行级别细分,对于影响较大的风险还应该制定相应的应对措施.

5)稳定性:对该特性需求是否容易变化进行一个预估,以帮助设计人员在设计解决方案时更加有效地避免变化对体系结构的影响,从而节省时间.

6)基线:确定其是否已经纳入基线;

7)职责分配:列出负责实现该特性的团队;

8)原因:列出提出该特性的原因,也可以将与客户交流的记录等资料放在这里,以帮助开发团队更好的理解客户的本意.

需求规格说明书(ISO标准版)

编者说明:

当需求调查,分析工作告一段落时,你就需要将这些需求进行规格化描述,整理成文,即软件需求规格说明书,也就是SRS.这是在软件项目过程中最有价值的一个文档.ISO所提供的标准虽然已经时间久远,但还是颇具参考价值的.

1.引言

1.1编写的目的

[说明编写这份需求说明书的目的,指出预期的读者.]

1.2背景

a. 待开发的系统的名称;

b. 本项目的任务提出者,开发者,用户;

c. 该系统同其他系统或其他机构的基本的相互来往关系.

1.3定义

[列出本文件中用到的专门术语的定义和外文首字母组词的原词组.]

1.4参考资料

[列出用得着的参考资料.]

2.任务概述

2.1目标

[叙述该系统开发的意图,应用目标,作用范围以及其他应向读者说明的有关该系统开发的背景材料.解释被开发系统与其他有关系统之间的关系.]

2.2用户的特点

[列出本系统的最终用户的特点,充分说明操作人员,维护人员的教育水平和技术专长,以及本系统的预期使用频度.]

2.3假定和约束

[列出进行本系统开发工作的假定和约束.]

3.需求规定

3.1对功能的规定

[用列表的方式,逐项定量和定性地叙述对系统所提出的功能要求,说明输入什么量,经怎么样的处理,得到什么输出,说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标.]

3.2 对性能的规定

3.2.1精度

[说明对该系统的输入,输出数据精度的要求,可能包括传输过程中的精度.]

3.2.2时间特性要求

[说明对于该系统的时间特性要求.]

3.2.3灵活性

[说明对该系统的灵活性的要求,即当需求发生某些变化时,该系统对这些变化的适应能力.]

3.3输入输出要求

[解释各输入输出数据类型,并逐项说明其媒体,格式,数值范围,精度等.对系统的数据输出及必须标明的控制输出量进行解释并举例.]

3.4数据管理能力要求(针对软件系统)

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

3.5故障处理要求

[列出可能的软件,硬件故障以及对各项性能而言所产生的后果和对故障处理的要求.]

3.6其他专门要求

[如用户单位对安全保密的要求,对使用方便的要求,对可维护性,可补充性,易读性,可靠性,运行环境可转换性的特殊要求等.]

4.运行环境规定

4.1设备

[列出运行该软件所需要的硬设备.说明其中的新型设备及其专门功能,包括:

a. 处理器型号及内存容量

b. 外存容量,联机或脱机,媒体及其存储格式,设备的型号及数量

c. 输入及输出设备的型号和数量,联机或脱机;

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

e. 功能键及其他专用硬件]

4.2支持软件

[列出支持软件,包括要用到的操作系统,编译程序,测试支持软件等.]

4.3接口

[说明该系统同其他系统之间的接口,数据通信协议等.]

4.4控制

[说明控制该系统的运行的方法和控制信号,并说明这些控制信号的来源.]

需求规格说明书(Volere版)

编者说明:

Atlantic System Guild(www.atlsysguild.com)公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术,是一个十分实用,完善的SRS模板.其所提供的Volere需求记录卡也十分实用,强烈推荐.

注:从Atlantic System Guild公司网站www.atlsysguild.com上获得,并稍做修改

1.产品的目标

1.1 该项目工作的用户问题或背景

[对引发开发任务的工作和情况的描述.同时也应描述用户希望用将要交付的软件来完成的工作.]

[该节内容为该项目提供了合法的理由,你应该考虑用户的问题是否严重,是否应该解决和为什么应该解决.]

1.2 产品的目标

[用一句话或很少的几句话来说明

[项目如果没有一个表述清晰,易于理解的目标,就会迷失在产品开发的沙漠中.产品必须带来某种优势.典型的优势是产品会增加组织在市场上的价值,减少运作成本,或提供更好的客户服务.这个优势应该是可度量的,这样才能够让您确定交付的产品是否达到目标.]

2.客户,顾客和其它风险承担者

2.1 客户是为开发付费的人,并将成为所交付产品的拥有者

[这一项必须给出客户的姓名,三个以内是合理的.]

[客户最终将接受该产品,因此必须对交付的产品满意.如果你无法找到一个客户的姓名,那么也许你就不应该构建该产品.]

2.2 顾客是将花钱购买该产品的人

[也给出姓名和相关的信息]

2.3 其它风险承担者

[其他的一些人或组织的名称,他们或者受到产品的影响,或影响产品.]

经理或项目负责人;

业务领域专家;

技术人员;

系统开发者;

市场人员;

产品经理;

测试和质量保证人员;

审查员,诸如安全审查员或审计人员;

律师;

10)易用性专家;

11)你所处行业的专业人员.

3.产品的用户

3.1 产品的用户

[产品的潜在用户或操作员的列表.针对每种类型的用户,提供以下信息:]

用户分类

用户工作的任务;

主要相关的经验;

技术经验;

其他用户特征:包括身体,智力,工作态度,对技术的态度,教育程度,语言技能,年龄,性别等.

[用户是为了完成工作而与产品交互的人,你了解用户,就越可能提交适合用户工作方式的产品.]

3.2 对用户设的优先级

[在每类用户后面附上一个优先级,这区别了用户的重要性和优先地位:]

关键用户:对产品的后续成功至关重要;

次要用户:他们使用产品,但对产品的长期成功并无影响;

不重要的用户:不常用,未授权和没有技能的用户.

[如果认为某些用户对产品或组织更重要,那么应该写明,因为它会影响你设计产品的方式.]

4.需求限制条件

4.1 解决方案限制条件

[此处明确了限制条件,它们规定了解决问题必须采取的方式.您可以认为它们是指令式的解决方案.仔细描述该解决方案,以及测试是否符合的度量标准.如果可能,您应该解释使用该解决方案的原因.]

[换一句话说,就是要求软件解决方案满足哪些限制条件!]

4.2 实现环境

[此处描述产品将被实施的技术环境和物理环境.]

[该环境也将成为设计解决方案时的限制条件之一.]

4.3 伙伴应用

[此处描述那些不属于产品的一部分,但产品却又必须与其协作的应用程序.]

4.4 COTS

[此处描述实现产品需求所必须使用的COTS(商业组件).]

4.5 预期的工作场地环境

[此处描述用户工作和使用该产品的工作场地.此处应该描述任何可能对产品设计产生影响的工作场地特征.]

4.6 开发者构建该产品需要多少时间

[任何已知的最后期限,或商业机会的时限,应在此处说明.]

4.7 该产品的财务预算是多少

[该产品的预算,以金钱的形式或可得资源的形式说明.]

5.命名标准和定义

[定义项目中使用到的所有术语,包括同义词.这里的内容就是一个字典,包括在需求规格说明书中使用的所有名称的含义.这个字典应该使用你的组织或行业使用的标准名称.这些名称也应该反映出在工作领域中当前使用的术语.该字典包括项目中用到的所有名称.请仔细地选择名称,以避免传达不同的,不期望的含义.为每个名字写下简明扼要的定义,这些定义必须经过相应的风险承担者同意.]

6.相关事实

[可能对产品产生影响的外部因素,但不是命令式的需求限制条件.]

7.假定

[列出开发者所做的假设.]

[将所有的假设列在此的目的是让每一个项目成员都意识到这个假设.]

8.产品的范围

8.1 工作的上下文范围

[上下文范围图用来表示将要开发的系统,产品与其它系统之间的关系,以确定系统边界.]

8.2 工作切分

[一个事件清单,确定系统要响应的所有业务事件.清单包括:]

事件名称

输入和输出

8.3 产品边界

[你可以使用用例图(use-case)来确定了用户与产品之间的边界.]

9.功能性需求与数据需求

9.1 功能性需求

[对产品必须执行的动作的描述.]

[每个功能性需求必须有一个验收标准.]

9.2 数据需求

[与产品/系统有密切关系的主题域相关的业务对象,实体,类的说明书.]

[进行问题域建模,生成相应的类图.]

10.观感需求

[一些与产品的用户界面相关的需求描述.]

11.易用性需求

11.1 易于使用

[描述如何构建符合最终用户期望的产品.]

11.2 学习的容易程序

[学习使用该产品应该多容易的说明.通常是有学习时间来衡量.]

12.性能要求

12.1 速度需求

[明确完成特定任务需要的时间,这常常指响应时间.]

12.2 安全性的需求

[对可能造成人身伤害,财产损失和环境破坏所考虑到的风险进行量化描述.]

12.3 精度需求

[对产品产生的结果期望的精度进行量化描述.]

12.4 可靠性和可用性需求

[本节量化产品所需的可靠性.这常常表述为允许的两次失败之间无故障运行时间,或允许的总失败率.] 12.5 容量需求

[本节明确处理的吞吐量和产品存储数据的容量.]

13.操作需求

13.1 预期的物理环境

[本节明确产品将操作的物理环境,以及这种环境引起的任何特殊需求.]

13.2 预期的技术环境

[硬件和其它组成新产品操作环境的设备的规范.]

13.3 伙伴应用程序

[对产品必须与之交互的其它应用程序的描述.]

14.可维护性和可移植性需求

14.1 维护该产品需要多容易

[对产品作特定修改所需时间的量化描述.]

14.2 是否存在一些特殊情况适用于该产品的维护

[关于预期的产品发布周期和发布将采取的形式的规定.]

14.3 可移植性需求

[对产品必须支持的其他平台或环境的描述.]

15.安全性需求

15.1 该产品是保密的吗

[关于该被授权使用该产品,以及在什么样的情况下授权等方面的描述.]

15.2 文件完整性需求

[关于需要的数据库和其他文件完整性方面的说明.]

15.3 审计需求

[关于需要的审计检查方面的说明.]

16.文件和政策需求

[本节包括针对社会和政策的因素的规格说明,这些因素会影响产品的可接受性.如果你开发的产品是针对外国市场的,可能要特别注意这些需求.]

[问一下是否产品的目标是你所不熟悉的文化环境,是否其它国家的人或其他类型的组织的人会使用该产品.人们是否有与你的文化不同的习惯,节日,迷信,文化上的社会行为规范.]

17.法律需求

17.1 该产品是否受到某些法律的管制

[明确该产品的法律需求的描述.]

17.2 是否有一些必须符合的标准

[明确适用的标准和参考的详细标准的描述.]

18.Opend问题

[对未确定但可能对产品产生重要影响的因素的问题描述.按照需求分析的术语还说,就是TBD(To Be Define)的问题.]

19.COTS解决方案

19.1 是否有一些制造好的产品可以购买

[应该调查现存产品清单,这些产品可以作为潜在的解决方案.]

19.2 该产品是否可使用制造好的组件

[描述可能用于该产品的候选组件,包括采购的和公司自己的产品.列出来源.]

19.3 是否有一些我们可以复制的东西

[其他相似产品的清单.]

20.新问题

20.1 新产品会在当前环境中带来什么问题

[关于新产品将怎样影响当前的实现环境的描述.]

20.2 新的开发是否将影响某些已实施的系统

[关于新产品将怎样与现存系统协同工作的描述.]

20.3 是否我们现有的用户会受到新开发的敌对性影响

[关于现有用户可能产生的敌对性反应的细节.]

20.4 预期的实现环境会存在什么限制新产品的因素

[关于新的自动化技术,新的组织结构方式的任何潜在问题的描述.]

20.5 是否新产品会带来其他问题

[确定我们可能不能处理的情况.]

21.任务

21.1 为提交该产品已经做了哪些事

[用来开发产品的生命周期和方法的细节.画一个高层的过程图展示各项任务和它们之间的接口,这可能是

沟通这方面信息的最好办法.]

21.2 开发阶段

[关于每个开发阶段和操作环境中的组件的规格说明.]

22.移交

22.1 我们要让已有数据和过程配合新产品,有什么特殊要求

[一个移交活动的列表,一个实现的时间表.]

22.2 为了新产品,哪些数据必须修改/转换

[数据转换任务清单,同时确定新产品需要转换的数据.]

23. 风险

23.1 当你开发该产品时,要面对什么风险

23.2 你制定了怎样的偶然紧急情况计划

24.费用

[需求的其他费用是你必须投入到产品构建中去的钱或工作量.当需求规格说明书完成时,你可以使用一种估算方法来评估费用,然后以构建所需的资金或时间的形式表述出来.]

25.用户文档

[用户文档的清单,这些文档将作为产品的一部分交付.]

26.后续版本的需求

[这里记录下一些希望今后版本中实现的需求.]

Volere需求记录卡

编者说明:

正如前面所述,Atlantic System Guild还提供了一个配套的Volere需求记录卡,这个记录卡十分实用.建议大家在需求调查,分析过程中,将需求记录在一系列的Volere需求记录卡上,这个卡让你能够很好的理清需求之间的关系,需求提出的背景,用户对需求的期望,有了这些素材,整理SRS时将变得更加简单.

注:顾客满意度是指完成该项功能顾客满意的程度,而顾客不满意度则是指未实现该功能顾客不满意的程度. 软件需求规格说明书

编者说明:

如果在需求分析时采用了用例(Use case)技术,那么该需求规格说明书将更加符合你的需要.当然,你也可以结合Volere需求规格说明书对该模板进行必要的修改.

1. 文档概述

[该部分主要是对软件需求规格说明书文档进行基本的描述,包括该文档的目的,范围,术语定义,参考资料以及概要.]

[软件需求规格说明书用来系统,完整地记录系统的软件需求.该软件需求说明书的基础是用例分析技术.因此该文档中应包括用例模型,补充规约等内容.]

1.1目的

[在此小节中,主要对软件需求规格说明书的目的做一概要性说明,通常软件需求规格说明书应详细地说明应用程序,子系统的外部行为,还要说明非功能性需求,设计约束,以及其它的相关因素.]

1.2范围

[系统是有范围的,而不是无限扩展的,对于无限扩展的需求是无法进行描述的.因此,在本小节应该对该说明书所涉及的项目范围进行清晰的界定.指定该规格说明书适用的软件应用程序,特性或者其它子系统分组,其相关的用例模型.当然在此也需要列出会受到该文档影响的其它文档.]

1.3 定义,首字母缩写词和缩略语

[与其它文档一样,该文档也需要将本文档中所涉及的所有术语,缩略语进行详细的定义.还有一种可简明的做法,就是维护在一个项目词汇表中,这样就可以避免在每个文档中都重复很多内容.]

1.4参考资料

[在这一小节中,应完整地列出该文档引用的所有文档.对于每个引用的文档都应该给出标题,标识号,日期以及来源,为阅读者查找这些文档提供足够详细的信息.]

1.5 概述

[在本小节中,主要是说明软件需求规格说明书各个部分所包含的主要内容,就像一个文章摘要一样.同时也应该对文档的组织方式进行解释.]

2. 整体说明

[在本节中,将对整个软件需求进行总体性的描述,以期让读者对整个软件系统的需求有一个框架性的认识.也就是说,该节中主要包括影响产品及其需求的一般因素,而不列举 具体的需求.主要包括产品总体效果,产品功能,用户特征,约束,假设与依赖关系,需求子集等方面的内容.]

2.1用例模型

[在本小节中,将列出该软件需求的用例模型,该模型处于系统级,对系统的特性进行宏观的描述.在此应该列出所有的用例和Actor的名称列表,并且对其做出简要的说明,以及在图中的各种关系.]

2.2 假设与依赖关系

[在软件系统的开发过程中,存在许多假设和依赖关系.在本小节中应列举出所有的重要的技术可行性假设,子系统或构件可用性假设,以及一些可行性的假设.]

3. 具体需求

[如果说第二章节是框架,那么本节就是血肉.在本节中,应该详细列出所有的软件需求,其详细程序应使设计人员能够充分理解并且进行设计的要求,同时也应该给予测试人员足够的信息,以帮助他们来验证系统是否满足了这些需求.整个需求的组织可以采用用例描述进行.]

3.1用例描述

[如果你使用用例建模技术,那么你已经通过用例定义了系统的大部分功能性需求和一些非功能性需求.因此,在软件需求规格说明书只需将这些具体的用例描述,整理在一起,全部放在该小节之中.当然也可以将用例描述做为附件,在此列出引用,只是这样做并不利于阅读.建议在组织形式上采用以

3.2补充需求

[由于用例毕竟主要针对功能性需求,因此还会有一些其它的补充需求遗漏,因此在本小节中就是将这些东西补充出来.这些补充需求大部分集中在非功能需求之上,包括以下几个方面的内容:]

易用性:例如指出普通用户和高级用户要高效地执行某个特定操作所需的培训时间;指出典型任务的可评测任务次数;或者指出需要满足的可用性标准(如IBM的CUA标准,Microsoft的GUI标准.

可靠性:包括系统可用性(可用时间百分比,使用小时数,维护访问权,降纸模式操作等);平均故障间隔时间(MTBF,通常表示为小时数,但也可表示为天数,月数或年数);平均修复时间(MTTR,系统在发生故障后可以暂停运行的时间);精确度(指出系统输出要求具备的精密度,分辨率和精确度);最高错误或缺陷率(通常表示为bugs/KLOC,即每千行代码的错误数目或 bugs/function-point,即每个功能点的错误数目);错误或缺陷率(按照小错误,大错误和严重错误来分类:需求中必须对

性能:包括对事务的响应时间(平均,最长);吞吐量(例如每秒处理的事务数);容量(例如系统可以容纳的客户或事务数);降级模式(当系统以某种形式降级时可接受的运行模式);资源利用情况:内存,磁盘,通信等. 其它:包括用户界面要求,联机帮助系统要求,法律许可,外购构件,以及操作系统,开发工具,数据库系统等设计约束.

4.支持信息

[支持信息用于使软件需求规格说明书更易于使用.它包括:目录,索引,附录等.]

计算机软件需求说明编制指南

编者说明:

软件需求规格说明是十分重要的文档,因此为开发团队提供一份详细的编制指南是十分有意义和必要的.本

文档就是一个编制指南的例子,你可以根据该指南,结合自己的实际情况进行修改.

1.引言

1.1 目的和作用

本指南为软件需求实践提供了一个规范化的方法.本指南不提倡把软件需求说明(Software

Requirements Specifications,以下简称SRS)划分成等级,避免把它定义成更小的需求子集.

本指南适用对象:

1)软件客户(Customers),以便精确地描述他们想获得什么样的产品.

2)软件开发者(Suppliers),以便准确地理解客户需要什么样的产品.

对于任一要实现下列目标的单位和(或)个人:

1)要提出开发规范化的SRS提纲;

2)定义自己需要的具体的格式和内容;

3)产生附加的局部使用条款,如SRS质量检查清单或者SRS作者手册等.

SRS将完成下列目标:

在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础.对要实现的软件功能做全面描述,帮助客户判断所规定的软件是否符合他们的要求,或者怎样修改这种软件才能适合他们的要求;

提高开发效率.编制SRS的过程将使客户在设计开始之前周密地思考全部需求,从而减少事后重新设计,重新编码和重新测试的返工活动.在SRS中对各种需求仔细地进行复查,还可以在开发早期发现若干遗漏,错误的理解和不一致性,以便及时加以纠正;

为成本计价和编制计划进度提供基础.SRS提供的对被开发软件产品的描述,是计算机软件产品成本核算的基础,并且可以为各方的要价和付费提供依据.SRS对软件的清晰描述,有助于估计所必须的资源,并用作编制进度的依据;

为确认和验证提供一个基准.任何组织将更有效地编制他们的确认和验证计划.作为开发合同的一部

分,SRS还可以提供一个可以度量和遵循的基准(然而,反之则不成立,即任一有关软件的合同都不能作为SRS.因为这种文件几乎不包括详尽的需求说明,并且通常不完全的);

便于移植.有了SRS就便于移值软件产品,以适应新的用户或新的机种.客户也易于移植其软件到其他部门,而开发者同样也易于把软件移植到新的客户;

作为不断提高的基础.由于SRS所讨论的是软件产品,而不是开发这个产品的设计.因此SRS是软件产品继续提高的基础.虽然SRS也可能要改变,但是原来的SRS还是软件产品改进的可靠基础.

1.2 范围

本指南适用于编写软件需求规格说明,它描述了一个SRS所必须的内容和质量,并且在第6章中提供了SRS大纲.

2.引用标准

GB 8566 计算机软件开发规范

GB 8567 计算机软件产品开发文件编制指南

GB/T 11457 软件工程术语

3.定义

GB/T 11457所列术语和下列定义适用于本指南.

合同(contract):是由客户和开发者共同签署的具有法律约束力的文件.其中包括产品的技术,组织,成本和进度计划要求等内容.

客户(customer):指个人或单位,他们为产品开发提供资金,通常(但有时也不必)还提出各种需求.文件中的客户和开发者也可能是同一个组织的成员.

语言(language):是具有语法和语义的通信工具,包括一组表达式,惯例和传递信息的有关规则.

分割(partitioning):把一个整体分成若干部分.

开发者(supplier):指为客户生产某种软件产品的个人或集团.在本指南中,客户和开发者可能是同一个组织

的成员.

用户(user):指运行系统或者直接与系统发生交互作用的个人或集团.用户和客户通常不是同一些人.

4.编写SRS的背景信息

4.1 SRS的基本要求

SRS是对要完成一定功能,性能的软件产品,程序或一组程序的说明.对SRS的描述有两项基本要求:

1)必须描述一定的功能,性能;

2)必须用确定的方法叙述这些功能,性能.

4.2 SRS的环境

必须认识到SRS在整个软件开发规范(见GB 8566)所规定的有关阶段都起作用.正因为如此,SRS的起草者必须特别注意不要超出这种作用的范围.这意味着要满足下列要求:

SRS必须正确地定义所有的软件需求;

除设计上的特殊限制之外,SRS中一般不描述任何设计,验证或项目管理细节.

4.3 SRS的特点

4.3.1 无歧义性

当且仅当它对每一个需求只有一种解释时,SRS者是无歧义的.

要求最终产品的每一个特性用某一术语描述;

若某一术语在某一特殊的行文中使用时具有多种歧义,那么对该术语的每种含义作出解释并指出其适用场合.

需求通常是用自然语言编写的,使用自然语言的SRS起草者必须特别注意消除其需求的歧义性.提倡使用形式化需求说明语言.

4.3.2 完整性

如果一个SRS能满足下列要求,则该SRS就是完整的:

包括全部有意义的要求,无论是关系到功能的,性能的,设计约束的,还是关系到属性或外部接口方面的需求; 对所有可能出现的输入数据的响应予以定义,要对合法和非合法的输入值的响应做出规定;

要符合SRS要求.如果个别章节不适用,则在SRS中要保留章节号;

填写SRS中的全部插图,表,图示标记和参照,并且定义全部术语和度量单位.

4.3.2.1 关于使用

任何一个使用

若万一遇到使用

对产生

描述必须干什么事,以删除这个

包含有

标识与此特定文件有关的版本号或叙述其专门的发布号;

拒绝任何仍标识为

4.3.3 可验证性

当且仅当SRS中描述的每一个需求都是可以验证的,该SRS才是可以验证的;当且仅当在某一性能价格比可取的有限处理过程,人或机器能通过该过程检查软件产品能否满足需求时,才称这个需求是可以验证的.

4.3.4 一致性

当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的.

4.3.5 可修改性

如果一个SRS的结构和风格在需求有必要改变时是易于实现的,完整性的,一致的,那么这个SRS就是可以修改的.可修改性要求SRS具备以下条件:

具有一个有条不紊的易于使用的内容组织,具有目录表,索引和明确的交叉引用表;

没有冗余.即同一需求不能在SRS中出现多次.

冗余本身不是错误,但是容易发生错误.冗余可增加SRS的可读性,但是在一个冗余文件被更新时容易出现问题.例如:假设一个明确的需求在两个地方详细列出,后来发现这个需求需要改变,若只修改一个地方,于是SRS就变得不一致了.

不管冗余是否必须,SRS一定要包含一个详细的交叉引用表,以便SRS具备可修改性.

4.3.6 可追踪性

如果每一个需求的源流是清晰的,在进一步产生和改变文件编制时,可以方便地引证每一个需求,则该SRS就是可追踪的.建议采用如下两种类型的追踪:

向后追踪(即向已开发过的前一阶段追踪).根据先前文件或本文件前面的每一个需求进行追踪.

向前追踪(即是向由SRS派生的所有文件追踪).根据SRS中具有唯一的名字和参照号的每一个需求进行追踪.

当SRS中的一个需求表达另一个需求的一种指派或者是派生的,向前,向后的追踪都要提供.例如: 从总的用户响应时间需求中分配给数据库操作响应时间;

识别带有一定功能和用户接口的需求的报告格式;

支持法律或行政上需要的某个软件产品(例如,计算税收).在这种情况下,要指出软件所支持的确切的法律或行政文件.

当软件产品进入运行和维护阶段时,SRS的向前可追踪性显得特别重要.当编码和设计文件作修改时,重要的是要查清这些修改所影响的全部需求.

4.3.7 运行和维护阶段的可使用性

SRS必须满足运行和维护阶段的需要,包括软件最终替换.

维护常常是由与原来开发无联系的人来进行的.局部的改变(修正)可以借助于好的代码注释来实现.对于较大范围的改变.设计和需求文件是必不可少的,这里隐含了两个作用:

如4.3.5 条指出,SRS必须是可修改的;

SRS中必须包括一个记录,它记录那些应用于各个成分的所有具体条文.例如:它们的危急性(如故障可能危及完全或导致大量财政方面和社会方面的损失);它们仅与暂时的需要相关(如支持一种可立即恢复原状的显示);它们的来源(如某功能是由已存在的软件产品的全部拷贝复制而成).

要求在SRS中清楚地写明功能的来源和目的,因为对功能的来源和引入该功能的目的不清楚的话,通常不可能很好地完成软件的维护.

4.4 SRS的编制者

软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的.这种协议要使用SRS的形式,应该由双方联合起草.这是因为:

客户通常对软件设计和开发过程了解较少,而不能写出可用的SRS;

开发者通常对于客户的问题和意图了解较少,从而不可能写出一个令人满意的系统需求.

4.5 SRS的改进

软件产品的开发过程中,在项目的开始阶段不可能详细说明某些细节,在开发过程中可能发现SRS的缺陷,缺点和错误之类的问题,所以可能要对SRS进行改进.

在SRS的改进中,应注意如下事项:

尽管可以预见校正版本的开发以后不可避免,而对需求还必须尽可能完全,清楚地描述.

一旦最初识别出项目的变化,应引入一个正式的改变规程来标识,控制,追踪和报告项目的改变.批准了的需求改变,用如下的方法编入SRS之中:

提供各种改变后的正确的,完全的审查记录;

允许对SRS当前的和被替代部分的审查.

4.6 SRS的编制工具

编制SRS最显而易见的方法是用自然语言来描述.尽管自然语言是丰富多彩的,但不易精确,用形式化的方法较好.

4.6.1 形式化说明方法

在SRS中是否使用形式化方法要依据下列因素:

1) 程序规模和复杂性;

2) 客户合同中是否要求使用;

3) SRS是否是一个合同工具或仅仅是一个内部文件;

4) SRS文件是否成为设计文件的根据;

5) 具有支持这种方法的计算机设备.

4.6.2 生产工具

软件产品生产中有多种生产工具.比如,计算机的字处理器就是非常有用的生产辅助工具.一个SRS通常有若干作者.可能经历若干版本,并且要进行多次重新组织内容.故生产工具是必要的.

4.6.3 表达工具

在SRS中有许多词汇,特别是许多名词和动词,专门涉及到系统的实体和许多活动,所以表达SRS需要若干工具.比如:

1) 可以验证实体或活动,无论在SRS中什么地方都是同一名字.

2) 可以标识一个特殊的实体或动作在规格说明中的描述位置.

此外,可以使用若干种形式化方法,以便允许自动处理SRS内容,只要作某些限制就可以做到:

用一些表格或图示法来显示需求.

用详细分层体系自动检查SRS的需求,这里每一个分层自身是完全的,但是也可以扩展为下一层,或是上一层的一个组成成分.

自动检查SRS具有在4.3条描述的部分或全部特点.

5 软件需求

SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述.

5.1 表达软件需求的方法

软件需求可以用若干种方法来表达:

1)通过输入,输出说明;

2)使用代表性的例子;

3)用规范化的模型.

5.1.1 输入,输出说明

用输入输出序列来描述一个软件产品所要求的特性是很有效的.

5.1.1.1 途径

根据被描述的软件的性质,至少有三种不同的途径:

有些软件产品(如报表系统)要求着重说明输出.一般情况下,致力于输出的系统主要是在数据文卷上操作.用户的输入通常是致力于提供控制信息和启动数据文卷的处理;

有些软件产品需要着重说明输入,输出特性.关注输入,输出的系统主要是在当前的输入上操作,要求生成与输入相匹配的输出(类似于数据转换例行程序或一个数学函数包);

还有一些系统(如过程控制系统)要求记忆它们的状态.可以根据本次输入和上一次输入进行应答.也就是说,它的行为如同一个有限状态机.在此种情况下,既要关注输入/输出对,又要关注这些输入/输出对的次序.

5.1.1.2 困难

多数软件产品可能接收无限的序列作为输入,于是,为了通过输入输出序列完整地说明产品的特性,就要求SRS包括一个无限长的输入和所需的输出充列.然而,用这样的途径不可能完整地描述软件所要求的一切特性.

5.1.2 典型例子

一种选择是用典型例子来说明要求的特性.例如,假设一个系统中当接收

典型的例子,用它描述系统特性.

0101

010101010101

01

010101

这些对话仅提供了要求的输入和输出之间的关系,但是不能完全描述系统的特性.

5.1.3 模型

另一种表达需求的方法是模型的方式,这是表达复杂需求的精确和有效方法. 至少可以提出三种可供使用的通用模型:数学型,功能型,计时型.应注意区别各种模型的应用场合,参考5.1.3.5.

5.1.3.1 数学模型

数学模型是使用数学关系描述软件特性的模型.数学模型对某些特殊应用领域是特别有用的.例如,导航,线性规划,计量经济,信号处理和气象分析等.

用数学模型能够对5.1.2中所讨论的典型例子描述如下:

(01)*.

这里,

5.1.3.2 功能模型

功能模型是提供从略语以输出映象的模型.象有限状态机或Petri网,这些功能模型可以有助于标识和定义软件的各种特点,或者可以表示系统所要进行的操作.

对前面用数学模型描述的例子.可用图1所示的有限状态机形式的功能模型来描述.图中进入的箭头表示启动状态.双线的方框表示接收状态.在各线记号x/y的含义是:x代表接受的输入,而y是产生的输出.

5.1.3.3 计时模型

计时模型是一种增加了时间限制的模型.这种模型对于表达软件特性的形式和细节特别有用.尤其是实时系统或考虑人为因素的系统.

计时模型可以把下列限制加到图1的模型中去:

1)激活因素0将在进入S1状态30S之内出现;

2)响应1将在进入S2状态2S之内出现.

5.1.3.4 其他模型

除了上面提及的模型外.对一些特殊的应用还有一些特别有用的模型.例如,编译程序的说明可以使用属性文法,工资单系统可以使用表格.要注意的是,对SRS使用形式需求语言,通常含有使用特殊模型的意思.

5.1.3.5 警告

无论使用哪一类型的模型,都要在SRS中或在SRS涉及到的一个文件中对它严格定义.这个定义应该规定:

1)模型中的参数所要求的范围;

2)使用时的限定值;

3)结果的精确度;

4)负载的能力;

5)要求的执行时间;

6)缺省或失败时的响应.

必须注意,在需求的定义域内要保持一个模型定义.每当一个SRS使用一个模型时:

1)它意味着此模型提供一个十分有效和精确的方法说明需求;

2)并不意味着软件产品的实现必须基于这个模型.

一个模型用于解释文件所写的需求是有效的,但是对于实际软件的实现可能并不是最适宜的.

5.2 软件需求的注释

有关软件产品的所有需求,并不是同等重要的.某些需求可能是基本的,例如是对于生命攸关的应用.而另一些可能并不那么重要.

SRS中每一个需求必须进行注释,以便区别其重要的程度.

有这种方法注释需求,可以:

帮助客户对每个需求给予更周密的考虑,通常可以在需求中澄清隐藏的假设;

帮助开发者做出正确的设计决定,并对软件产品不同部分作出相应的努力.

5.2.1 稳定性

注释需求的一种方法是使用稳定性量纲.当一个需求在软件预期的生存期间内描述不改变的话,可以认为该需求是稳定的,否则可以认为是易变的.

5.2.2 必要性等级

注释的另一种方法是把需求分成必须保证级,期望级和任选级.

必须保证是指软件必须和这些需求相一致,否则该软件不可能被接受;

期望是指这些需求将提高软件产品的功能,但如果缺省的话也是可接受;

任选是给开发者一个机会,可以提供某些超出SRS规定的目标.

5.2.3 注意事项

在注释需求之前,必须彻底理解这种注释的实质性含义.

5.3 在表达需求时遇到的共同弊病

SRS的基本点是它必须说明由软件获得的结果,而不是获得这些结果的手段.编写需求的人必须描述的基本问题是:

功能――所设计的软件要做什么;

性能――是指软件功能在执行过程中的速度,可使用性,响应时间,各种软件功能的恢复时间,吞吐能力,精度,频率等等;

强加于实现的设计限制――在效果,实现的语言,数据库完整性,资源限制,操作环境等等方面所要求的标准; 属性――可移植性,正确性,可维护性及安全性等方面的考虑因素;

外部接口――与人,硬件,其他软件和其他硬件的相互关系.

编写需求的人应当避免把设计或项目需求写入SRS之中,应当对说明需求设计约束与规划设计两者有清晰的区别.

5.3.1 在SRS中嵌入了设计

在SRS中嵌入设计说明,会过多地约束软件设计,并且人为地把具有潜在危险的需求放入SRS中.

SRS必须描述在干什么数据上,为谁完成什么功能,在什么地方,产生什么结果.SRS应把注意力集中在要完成的服务目标上.通常不指定如下的设计项目:

把软件划分成若干模块;

给每一个模块分配功能;

描述模块间的信息流程或者控制流程;

选择数据结构.

把设计完全同SRS隔离开来始终是不现实的.安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求.例如:

在一些分散的模块中保持某些功能;

允许在程序的某些区域之间进行有限的通讯;

计算临界值的检查和.

通常应考虑到,若要为软件选择高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:

不顾本指南的警告,在SRS中描述了设计.这意味着,或者将一个潜在不适当的设计作为一个需求进行描述(因为,若要得到好的设计,所花费的时间是不够的),或者在需求阶段花费了过多的时间(因为在SRS完成之前整个设计分析都要完成);

采用本指南中5.1.3条中的建议,用模型设计描述需求,这种模型设计只用于辅助描述需求,而不使之成为实

际的设计.

5.3.2 在SRS中嵌入了一些项目要求

SRS应当是描写一个软件产品,而不是描述生产软件产品的过程.

项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解(因此不应当包括在SRS中)例如: 成本;

交货进度;

报表处理;

软件开发方法;

质量保证;

确认和验证的标准;

验收过程.

项目需求在另外文件中描述.在SRS中提供的只是关于软件产品本身的需求.

6 SRS大纲

本章着重讨论SRS的每一个基本部分,可以作为一个SRS的大纲.表1给出该大纲目录,表2至表5给出大纲中第3章的具体需求内容.各开发者和客户应当根据所描述的实际情况,按本指南有关规定编写自己的SRS.

6.1 前言(SRS第1章)

本章提供整个SRS综述.

6.1.1 目的(SRS的1.1条)

在这一条包括下列内容:

1)描述实际SRS的目的;

2)说明SRS所预期的读者.

6.1.2 范围(SRS的1.2条)

通常应考虑到,若要为软件选择高层次的设计,就可能需要大量的资源(可能占整个产品开发成本的10%-20%以上).有两种选择:

用一个名字标识被生产的软件产品.比如:×××数据库系统,报表生

站点地图