任务管理平台需求规格说明书_v1.2.6

任务管理平台需求规格说明书_v1.2.6
任务管理平台需求规格说明书_v1.2.6

任务管理系统系统需求规格说明书

软件/系统需求规格说明书(SRS)

版本

拟制日期

审核日期

批准日期

声明

本文件所有权和解释权归智翔集团所有,未经智翔集团书面许可,不得复制或向第三方公开。修订历史记录

(A-

目录

1.引言 (5)

1.1.编写目的 (5)

1.2.系统涵盖范围 (5)

1.3.缩略词 (5)

1.4.假设和限制 (5)

1.5.文档组织结构 (5)

1.6.参考资料 (5)

2.系统概貌 (5)

2.1.系统概述 (5)

2.2.体系结构 (6)

2.3.系统边界和A CTORS (6)

2.4.系统功能 (6)

2.5.用户特性 (7)

2.6.一般限制 (7)

2.7.出错处理 (7)

2.8.假设和依赖条件 (7)

3.功能性需求 (7)

3.1.W EB端平台 (7)

3.1.1.系统管理 (8)

3.1.2.导师功能模块 (9)

3.1.3.学员功能模块 (10)

3.2.客户端接口 (11)

3.2.1.注册接口 (11)

4.非功能性需求 (11)

4.1.易用性 (11)

4.2.可靠性 (11)

4.3.性能 (11)

4.4.可维护性 (11)

4.5.客户端系统更新 (11)

5.安全性 (12)

5.1.设计角度 (12)

5.1.1.应用权限控制 (12)

5.2.传输角度 (12)

5.2.1.与客户端通讯的接口部分 (12)

5.3.业务接入认证角度 (12)

5.4.手机本地安全角度 (13)

5.5.业务监控角度 (13)

5.6.负载均衡角度 (13)

5.7.数据库管理角度 (13)

5.8.黑客角度 (13)

6.机型适配要求 (13)

7.系统体验要求 (13)

8.项目交付清单 (13)

1.引言

1.1.编写目的

本文档主要对『任务管理』系统的架构、流程、功能、性能等进行详细说明,提供给产品开发和UI设计人员参照使用。

本文档属于比较详细的业务需求,对具体功能在手机上的体验并没有进行特别详细的描述。

本文档的阅读对象为客户、项目经理、产品经理、研发需求人员、研发开发人员、测试人员和验收人员。

1.2.系统涵盖范围

本文档只涉及架构、流程以及各功能特性的描述,不涉及具体的实现技术、算法、逻辑等。

具体覆盖移动办公平台产品的平台侧、客户端侧软件需求。

1.3.缩略词

1.4.假设和限制

需求文档中的任何变更都将被新版的SRS跟踪。SRS应有版本历史。用户可以通过SRS的早期版本查找需求的早期版本。

为验证需求,一个需求应有一个或一个以上用例。

1.5.文档组织结构

本文档通过系统概貌、功能性需求、外部接口、非功能性需求描述整个系统的需求。

1.6.参考资料

2.系统概貌

2.1.系统概述

任务管理系统是一个教学任务管理平台,通过该平台可以实现系统管理员管理平台信息,导师可以通过平台针对学员分组、新建任务、分配任务、查看任务完成情况等,学员可根据平台查询任务,提交任务,查看任务评分等。

2.2.体系结构

任务管理平台由服务器端软件、客户端软件(未来实现)组成,各个模块的说明如下:

1、客户端软件是移动版本的使用界面,通过用户的操作来实现系统业务功能的展示与处理。

2、服务器端软件主要分为两部分。

a)第一部分:web端操作管理界面。用户可以使用电脑,完成目前系统的所有功能。

b)第二部分:客户端接口(未来实现)。通过客户端接口,使得客户端软件可以与服务器进行交

互。

2.3.系统边界和Actors

系统用户角色主要按照业务需求进行划分,本文主要的系统用户有:

平台管理员:具有平台的所有功能,对平台基本数据进行维护。

导师:导师可对自己的学生分组,创建不同类型的任务,分配任务给相应的学生分组、查看学生任务的完成情况、给不同任务进行评价打分。

学员:注册账号、老师、查看自己的任务,领取公共任务,提交任务,查看任务评价等

客户端用户(本次版本暂不实现):客户端用户分为任务发布者与学员,功能同web端。

2.4.系统功能

该系统主要实现以下业务目标:

2.5.用户特性

任务管理系统的维护人员、任务发布人员(即导师)、学员。

2.6.一般限制

终端侧的文件处理能力(比如播放媒体,打开office、打开压缩文件等)依赖于终端本身的能力。2.7.出错处理

所有的系统错误都应当记录到系统日志文件中。

2.8.假设和依赖条件

平台侧依赖于Windows操作系统和mysql数据库软件

终端侧的文件处理能力(比如播放媒体,打开office、打开压缩文件等)依赖于终端本身的能力。

3.功能性需求

整个系统由平台侧管理系统、平台侧接口、移动客户端组成。

3.1.Web端平台

要求:平台中所有删除功能都需要提出提示信息,需要操作人员选择是否确认删除。特殊数据则应使用软删除,不能直接删除(添加删除标识,而不是直接在数据库中delete)

1、Web平台使用说明

欲使用平台,需首先建立一个账号,账号分为三类,第一类为系统维护人员,需要以管理员身份在系统中维护。第二类,导师,用户可在web端或者客户端注册账号,注册为导师,导师注册后,需要经过系统管理人员进行审核,审核通过后才可进行导师的相关操作。第三类,学员,用户可在web或者客户端进行账号注册为学员。注册成功后,则可进行学员的相应操作。

2、所有系统用户,可以在web端或者客户端进行自身信息的修改。

3、客户端软件发布:在软件上传之前,需先配置该软件对应的适配组(适配组是因为操作系统或屏幕分辨

率或尺寸的不同人为分配的适配标识,一个适配组通常对应一个操作系统的多款手机终端,见适配组管理),上传软件时只用选择软件的大版本、小版本对应的操作系统和适配组即发布成功(见软件发布)4、客户端软件发布成功后,需要配置该软件可用的相关办公插件,配置后用户在企业应用里面才可以看到

东西

3.1.1.系统管理

系统管理即后台系统管理,指对后台本身的用户进行管理

3.1.1.1.用户管理

即对后台里面的用户进行管理,可以新增、编辑和删除用户,充值用户密码,并可以对用户赋予或删除对应的角色。

新增修改时效果如下图(不需要完全一样,信息科在一页显示、分组信息、角色信息可不要):

用户表的信息包含:用户姓名、账号(不能重复)、邮箱、电话、性别(0女1男)、年龄、状态(0正常、1禁用、2删除)、备注、创建人、创建时间、最后修改人、最后修改时间。

【要求】

平台中用户密码必须加密、用户账号作为用户登录的用户名,在平台中必须唯一。

密码管理

提供给每个后台用户使用,用户可以通过该功能修改自己的后台密码。

3.1.1.2.课程管理

系统维护人员,根据权限,可对系统中的课程进修维护操作,如:查询,新增,删除、修改课程信息。课程信息为关键性数据,在删除课程信息时,必须使用软删除,不能直接删除数据库中的数据。

3.1.2.导师功能模块

3.1.2.1.注册

用户可通过平台提前的web端,注册是导师:导师注册后,需要系统维护人员审核,审核成功后才能够进行相应的操作。

3.1.2.2.学员管理

导师可查看关注自己的学员信息,以及发起拜师请求的学员信息。并可通过或者拒绝学员的拜师请求,拒绝时需填写拒绝理由。

3.1.2.3.班级管理

导师可通过平台管理自己的班级情况,管理班级分为新增,修改,解散班级。

A 新增班级:导师可新增班级,新增班级时需填写班级名称、班级标识、开班时间、班级人数、最少开班人数、是否允许学生申请加入等信息。

B 班级新增后,如到达开班时间未达到最少人数,则系统自动解散班级。

C 修改班级信息,同新增班级信息。

D 解散班级,导师可根据情况,主动解散班级。

E 如果班级为允许学生申请加入,则不是自己的学生也可以申请加入,申请加入后,导师可在班级信息中看到申请加入班级的学生信息。同意申请后,学生加入此班级,并且成为该导师的学生。

F 拒绝学生加入班级:如果学生信息不满足加入班级的条件,则导师可拒绝学生加入班级,拒绝时必须填写拒绝原因。

数据库表字段: id,班级标识(唯一)、班级名称、开班时间、班级最大人数、班级最少人数、教师ID、是否接受申请、状态(0等待开班、1已开班、2已结束、3已删除)、创建人、创建时间、修改人、最后修改时间,备注。

3.1.2.

4.班级分组管理

当班级开课以后,在班级列表,点击管理分组,进入班级分组管理界面。导师可以查询分组、创建分组、修改分组。并可维护每个分组中的学生(同一个学生在同一个班级只能在一个分组中)。

3.1.2.5.基础任务维护

导师可在任务管理界面新增、修改、查询、删除任务信息(删除基础任务信息使用软删除)。

新增基础任务信息包含:基础任务名称、任务类型(在线考试或者其他)、任务说明,任务附件。

3.1.2.6.任务发布

在已发布任务界面,导师可以查看自己已经发布的任务信息,完成情况(发布给多少人,一完成多少人、等信息)。并可以创建发布任务。

点击创建发布任务,进入创建任务界面。填写任务名称,选择基础任务包,选择任务开始时间,选择任务结束时间,选择执行任务的分组(多选),填写备注信息。

3.1.2.7.已提交任务

在发布任务中,点击任务详情,可以查看当前任务的完成情况,针对已提交的任务,导师可查看提交任务的完成情况,并对任务进行打分。

3.1.3.学员功能模块

3.1.3.1.学员注册

用户可以通过平台,注册成为学员,注册学员时,需填写姓名,登录账号,登录密码、性别,年龄、婚姻状况、民族、生日、联系电话、工作年限、邮件地址、联系地址、学校名称、起止时间、专业、学历、学习方向。兴趣爱好、个人技能、工作经历。

3.1.3.2.查询导师

学员注册成功后,可通过登录页面登录平台。学员可在导师介绍界面,查看自己感兴趣的导师,查看导师的学生,查看导师所开的班级等信息。点击我的导师还可以查询自己所拜的导师。

3.1.3.3.拜师

学员针对自己所敢兴趣的导师,可点击拜师操作,进行拜师,拜师时需要给导师进行200字以内的留言。

3.1.3.

4.我的任务

学员可在我的任务中查看导师所分配给自己的任务以及自己所领取的公共任务。我的任务可根据不同的任务状态查询,如,为开始,一开始,已完成,已打回,已结束。

3.1.3.5.查看任务详情

点击任务名称,可查询任务的详情,并可在任务后进行留言。

3.1.3.6.领取公共任务

学员可根据自己的情况,去竞技场领取公共的任务,完全成为,提示自己的等级。

3.1.3.7.提交任务

对于已完成的任务,学员可以提交任务到导师出。提交任务时,可以进行留言,添加附件操作。

3.2.客户端接口

3.2.1.注册接口

4.非功能性需求

4.1.易用性

终端侧遵循相应手机平台的用户操作习惯,平台侧遵循windows的用户操作习惯

4.2.可靠性

平台侧应该能够在不需要重新启动整个系统服务的情况下,自动重新建立与数据库的链接。

平台侧应该能够自动监测服务是否中止,并尝试重新启动;

平台侧应该提供数据库系统备份和恢复功能;

4.3.性能

整个系统要求支持负载均衡和双机热备应用,具体的性能指标要求如下:

●支持2000人在线、400并发,后续可扩展支持更多在线用户和并发数量

●非3G网络和WiFi情况下登录时间少于4秒,获取列表时间少于5秒,信息查看、邮件查看时间少

于5秒,流程查看少于5秒,附件快照方式第一页时间小于12秒(不超过2M的附件),翻页时间小于6秒。

●系统提供7×24小时的连续运行,平均年故障时间:<1天,平均故障修复时间:<1小时

4.4.可维护性

平台侧应该提供日志功能,用于故障处理;

4.5.客户端系统更新

更新原则:更新频度合理,应用变化、权限变化时不需更新客户端。

更新控制:在管理端能控制升级内容及控制是否强制升级。

更新提醒:能提醒用户,用户根据提醒信息可方便升级。

更新监控:能识别已更新用户和未更新用户

5.安全性

通过以下八个角度来保证安全

5.1. 设计角度

5.1.1. 应用权限控制

对用户进行分组,按用户组发布企业应用。在企业应用列表,如用户对某应用无权限,则对应的应用显示无权限,用户无法对此进行下载和安装。

5.2. 传输角度

5.2.1. 与客户端通讯的接口部分

5.2.1.1. Header消息机制

在header消息里面添加一个特殊的参数和参数值,每个接口请求时都要带上,服务器端先对header消息进行校对,成功的才进入业务流程。

5.2.1.2. 登录验证码机制

用户登录之前需先获取验证码,然后根据用户名、密码和验证码进行登录。

5.2.1.3. 会话认证机制

客户端登录成功后,在服务器端生成会话ID,登录接口之后的所有接口都要带上会话ID进行访问。

服务器端对会话ID进行认证,认证成功后才能进入具体业务。

会话ID有效时间为:用户无任何操作之后30分钟

5.2.1.4. 传输加密机制

用户登录成功后,发送业务请求,将用户名、会话ID和相关业务数据提交给服务器端。

服务器端首先验证会话ID,如会话ID正确则根据消息体中的消息指令获得相关消息,并通过会话ID加密返回给客户端。

客户端对数据进行解密并展示。

5.2.1.5. Wap网站和后台部分

外网通过HTTP进行访问

5.3. 业务接入认证角度

1、对用户名进行接入认证,将用户名存储在接入认证表中,登录时进行认证

3、业务接口部分对用户权限进行认证,没有权限则返回统一的错误日志

5.4. 手机本地安全角度

5.5. 业务监控角度

5.6. 负载均衡角度

采用Windows 2008的负载均衡

5.7. 数据库管理角度

5.8. 黑客角度

6.机型适配要求

以下表格为本次项目具体要适配的机型列表:

7.系统体验要求

考虑到移动终端的交互体验和传统PC的体验完全不同,因此对于移动办公平台的交互体验设计有如下的需求:

●UI设计美观,与操作系统相关,符合用户使用习惯

●不同终端主要操作习惯统一,不同终端布局统一,主要的操作项均统一放在明显位置

●不同操作系统操作特性需保持,主要操作尽量不依赖操作系统特性,操作系统主要特征仍需支持,

如苹果系列的滑动

●对于终端应用程序的安装,基本要求是用户能方便、快捷安装程序,具体要求可以通过发送短信获

得下载链接的方式、访问WAP页面的方式、APPstore直接下载等方式获取安装程序包

●特别的,客户端需要支持智能安装功能,即在使用WAP页面或APPstore方式时,系统可根据操作系

统和分辨率等参数,自动选择最适合的安装程序,或用户只需知道手机所属操作系统即可进行安

装。

8.项目交付清单

整个项目完成之后,交付的软件及资料清单如下所示:

需求规格说明书规范

需求规格说明书规范 1.引言 1.1 编写目的 ? 阐明开发本软件的目的 ? 说明编写本软件说明书的目的 ? 指明软件需求说明书所预期的读者 1.2 项目背景 ? 标识待开发软件产品的名称、代码 ? 列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户。 ? 说明该软件产品与其他有关软件产品的相互关系。 1.3 术语说明 列出本文档中所用到的专门术语的定义和英文缩写词的原文。 1.4 参考资料 列举编写软件需求规格说明时参考的资料,包含项目经核准的计划任务书、合同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档,以及相关产品的软件需求规格说明。 在这里应该给出详细的信息,包括标题、作者、版本号、发表日期、出版单位或资金来源。 2.项目概述 1.1 待开发软件的一般描述 描述待开发软件的背景,所应达到的目标,以及市场前景等。 1.2 待开发软件的功能 简述待开发软件所具有的主要功能。为了帮助每个读者理解,可以使用列表或图形的方法进行描述。使用图形表示,可以采用: ? 顶层数据流图; ? UseCase图; ? 系统流程图; ? 层次方框图。 1.3 用户特征 描述最终用户应具有的受教育水平,工作经验及技术专长。 1.4 运行环境 描述软件的运行环境,包括硬件平台、硬件要求、操作系统和版本,以及其他的软件或其共存的应用程序等。 1.5 条件与限制 给出影响开发人员在设计软件时的约束条款,例如: ? 必须使用或避免使用特定的技术、工具、编程语言和数据库; ? 硬件限制; ? 所要求的开发规范或标准。 3.功能需求

软件需求规格说明书-模板

[在此处键入]****系统 软件需求规格说明书Versio n 1.0

精品资料

修订历史记录

目录 1 引言 (5) 1.1 目的与范围 (5) 1.2 预期的读者 (5) 1.3 系统的范围 (5) 1.4 参考资料 (5) 1.5 术语、缩写词 (6) 2 当前系统 (6) 2.1 当前系统概述 (6) 2.2 当前系统存在的问题................................... 错误!未定义书签。 3 建议的系统 .............................................................. 错误!未定义书签。 3.1 建议系统概述......................................... 错误!未定义书签。 3.2 功能性需求概述....................................... 错误!未定义书签。 3.3 非功能性需求......................................... 错误!未定义书签。 3.3.1 用户界面与人员因素............................ 错误!未定义书签。 3.3.2 硬件考虑..................................... 错误!未定义书签。 3.3.3 性能特征..................................... 错误!未定义书签。 3.3.4 错误处理与极端情况............................ 错误!未定义书签。 3.3.5 系统接口..................................... 错误!未定义书签。 3.3.6 质量要求..................................... 错误!未定义书签。 3.3.7 物理环境..................................... 错误!未定义书签。 3.3.8 安全问题..................................... 错误!未定义书签。 3.3.9 资源问题..................................... 错误!未定义书签。 3.4 系统变更............................................. 错误!未定义书签。 3.5 约束( Constraints ) ................................................................................. 错误!未定义书签。 3.6 系统模型............................................. 错误!未定义书签。 3.6.1 用例模型 (6) 3.6.2 对象模型..................................... 错误!未定义书签。 4 附录 .................................................................... 错误!未定义书签。 4.1 NEMA 0183 格式简介 ................................... 错误!未定义书签。

需求规格说明书范本

1. 引言 1.1编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作.本文档面向的读者主要是项目委托单位的管理人员.希望能使本软件开发工作更具体. 1.2项目背景 1.2.1项目委托单位:****公司 1.2.2开发单位:***公司 1.3定义 1.4参考资料 2. 任务概述 2.1目标: <1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理. 2.2运行环境: <1> 硬件方面:Pentium级处理芯片 1兆显存的兼容显卡 256色,1024*768的兼容显示器 标准兼容打印机 <2>软件方面: WIN XP操作系统 2.3条件与限制: 编程用计算机一台 完成期限2000/7/1 无资金供给 3. 数据概述 数据流程图如下:

3.1静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据3.2 动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间3.3数据库描述: 人事管理数据库:公司内人员的个人详细信息,包括档案信息 3.4 数据字典: <1>数据流词条描述: 1.数据流名:登录信息 来源:用户的输入 去向:系统内部检验部分 组成:用户名,密码 流通量:每次登录输入一次 2.数据流名:登录结果 来源:系统 去向:用户 组成:返回信息 流通量:每次登录返回一次 3.数据流名:输入修改信息 来源:用户 去向:系统判断部分 组成:根据各数据库内容而不同 流通量:依用户输入而定 4.数据流名:反馈信息 来源:系统判断部分 去向:用户 组成:系统经判断后发回的字符数据 流通量: 依系统当前信息而定 5.数据流名:识别信息 来源:系统内部检验部分 去向:系统判断部分 组成:系统各数据库的标识信息 流通量:用户每次输入流通一次 6.数据流名:处理信息 来源:系统判断部分

产品编码系统需求规格说明书..

目录 1.引言 (2) 1.1.编写目的 (2) 1.2.背景说明 (2) 2.任务概述 (2) 2.1.目标 (2) 2.2.用户特点 (2) 3.需求规定 (3) 3.1.对功能的规定 (3) 3.1.1. 产品编码方案规定 (4) 3.1.2. 零部件编码方案规定 (6) 3.1.3. 物料编码方案规定 (7) 3.2.对性能的规定 (8) 4.运行环境规定 (9) 4.1.设备 (9) 4.2.运行环境 (9) 5.需求说明 (10) 5.1.用例分析 (10) 5.2.功能描述 (11) 5.2.1. 用户登录 (11) 5.2.2. 用户注册及信息维护 (11) 5.2.3. 产品编码自动生成及维护 (12) 5.2.4. 产品编码信息查询 (12) 5.2.5. 零部件编码自动生成及维护 (12) 5.2.6. 零部件编码信息查询 (13) 5.2.7. 物料编码自动生成及维护 (13) 5.2.8. 物料编码信息查询 (14) 5.2.9. 产品BOM自动生成及维护 (14) 5.2.10. 产品BOM信息查询 (15) 5.2.11. 产品图纸维护和查看 (15) 5.2.12. 产品及零部件库存信息查询 (15) 6.约定和说明 (16) 6.1.零件、部件编码方案进行统一 (16) 6.2.原有电桥平台分为两类,立式电桥、卧式电桥....................... 错误!未定义书签。 6.3.原材料编码方案去除供应商信息 (16) 6.4.产品、零部件编码方案去除客户及供应商信息 (16) 6.5.编码信息的修改和删除 (17)

产品编码需求规格说明书 1.引言 1.1.编写目的 本需求规格说明书是对产品编码管理信息系统调研的总结,并从用户角度对产品编码管理信息系统做出完整准确的定义,是产品编码管理信息系统设计及验收的依据。 1.2.背景说明 项目名称:产品编码管理信息系统 项目与其他系统的关系:产品编码管理信息系统为公司生产部门、管理部门提供规范化、统一化、唯一化的产品编码、零部件编码、物料编码及产品BOM 信息,是公司信息管理平台正常运行的基础和前提。 2.任务概述 2.1.目标 项目目标:建设产品编码管理信息系统,依托完备的网络基础设施、存储、安全及多个业务领域服务系统,为公司提供产品编码、零部件编码、物料编码、产品BOM生成及图纸查阅等功能,为公司其他管理信息系统提供基础的数据保障。 2.2.用户特点 产品、零部件及物料编码是公司生产、运作及管理的基础,因此本系统的应用部门覆盖了公司大部分业务部门,如产品开发部、生产部、生产车间、采供部、财务部、销售部等。其中,产品开发部是本系统的最直接用户,具有系统的全面审阅和维护权限,其他部门人员根据需求分配查阅权限。具体角色和权限分配如下表:

软件产品需求规格说明书(案例)

四川托普集团技术文档 卷号: 卷内编号: V1.0版 多层体系政务框架平台之一 行政服务中心政务平台 软件产品需求规格说明书Software Product Requirements Specification 项目承担部门:中央研究院应用产品开发中心 撰写人(签名): 完成日期: 本文檔使用部门:■主管领导■项目组□客户(市场) ■维护人员□用户 文档验交组(签名): 验交日期: 评审负责人(签名): 评审日期:

软件产品需求规格说明书 Software Product Requirements Specification 1.引言 1.1.目的 本节描述软件产品需求规格说明书(SRS)的目的是: 定义软件总体要求,作为用户和软件开发人员之间相互了解的基础; 提供性能要求、初步设计和对用户影响的信息,作为软件人员进行软件结构设计和编码的基础; 作为软件总体测试的依据。 1.2.定义 Workflow:工作流 1.3.参考资料 行政服务中心政务平台白皮书 行政服务中心政务平台项目审批表

2.软件总体概述 2.1.软件标识 软件全称:多层体系政务框架平台之一行政服务中心政务平台 软件简称:XZFWZXZW 版本号:1.0 2.2.软件描述 2.2.1.系统属性 行政服务中心是改革开放进程中一项新生事物,是实践江总书记“三个代表”重要思想的具体表现,是改善投资环境,扩大开放,吸收外来投资,加快发展的重要举措。为了实现行政服务中心“一站式集中,一条龙服务”,为全社会提供平等竞争的市场条件和长期稳定的投资环境,塑造廉洁,规范,高效的政府形象的目标,充分利用信息化技术,建设先进实用的可扩展性强的行政服务信息系统,实现行政服务信息处理的智能化、网络化、“无纸化”成为一项迫切的工作。为此,托普集团根据行政服务中心的业务需求,设计了行政服务中心政务平台。 2.2.2.开发背景 开发目的:1、公众服务 2、行政服务中心和各级政府部门

需求规格说明书规范

案 智能家居安防系统 需求规格说明书 牛耳公司 版权所有侵权必究 文档信息

修订记录 文档审核/审批 此文档需如下审核。签署过的审批表将作为附件归入PCB的质量控制章节。 文档分发 此文档将分发至如下各人 - 1 -

目录 1引言 (4) 1.1编写目的 (4) 1.2读者对象........................................................................... 错误!未定义书签。 1.3背景................................................................................... 错误!未定义书签。 1.4定义................................................................................... 错误!未定义书签。 1.5约定 (5) 1.6参考文档 (5) 2产品任务 .............................................................................................................. 6是2.1目标 (6) 2.2定位 (6) 2.3前景 (6) 2.4用户角色分析 (7) 2.5假定和约束 (7) 3用户需求 (8) 3.1系统组成 (8) 3.2子系统组成....................................................................... 错误!未定义书签。4需求细节描述 ......................................................................... 错误!未定义书签。 4.1门、窗、阳台的监控和报警........................................... 错误!未定义书签。 4.2火灾的报警....................................................................... 错误!未定义书签。 4.3煤气泄漏告警 ................................................................. 错误!未定义书签。 4.4实时监控和查询............................................................... 错误!未定义书签。 4.5安防模式切换................................................................... 错误!未定义书签。5非功能性需求 (11) 5.1软硬件环境需求(NF-非功能性需求编号) 5.2产品质量需求........................................................................................................

SF06 软件需求规格说明书

文档编号:XXX-SF-06 保密级别: 版本编号:V1.0 软件开发文档 文档名称:需求规格说明书 项目名称:XXXXXXXXXX 项目负责人:XX XX 编写:年___月___日 校对:年___月___日 审核:年___月___日 批准:年___月___日 XXXX电子有限公司 2011年

修订历史记录 (A-添加,M-修改,D-删除)

目录 1概述 (1) 1.1用户简介 (1) 1.2项目的目的与目标 (1) 1.3术语定义 (1) 1.4参考资料 (1) 1.5相关文档 (2) 1.6版本更新信息 (2) 2目标系统描述 (2) 2.1组织结构与职责 (2) 2.2角色定义 (2) 2.3作业流程(业务模型) (3) 2.4单据、账本、报表 (3) 2.4.1单据 (3) 2.4.2账本 (4) 2.4.3报表 (4) 2.5可能的变化 (4) 3目标系统功能需求 (5) 3.1功能需求分析 (5) 3.2功能需求点列表(功能模型) (5) 4目标系统性能需求 (5) 4.1时间要求 (5) 4.2空间性能 (5) 4.3性能需求点列表(性能模型) (6) 5目标系统界面与接口需求 (6) 5.1界面需求 (6) 5.2接口需求点列表(接口模型) (7) 6目标系统其他需求 (7) 6.1安全性 (7)

6.2可靠性 (7) 6.3灵活性 (7) 6.4特殊需求 (7) 7目标系统假设与约束条件 (8)

1概述 本文档是进行项目策划、概要设计和详细设计的基础,也是软件企业测试部门进行内部验收测试的依据。 1.1用户简介 在本章节中要将用户的基本情况描述清楚,以便于分析人员划定系统范围,进行功能、进度、成本、性能等方面的平衡决策。 对于产品开发类项目,需要在此将该产品定义的用户群的特点描述清楚。 1.2项目的目的与目标 项目的目的是对开发本系统的意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。 对于项目的目标可以逐步细化,以便与系统的需求建立对应关系,检查系统的功能是否覆盖了系统的目标。 1.3术语定义 将该需求规格说明书中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术 语与缩写等。 1.4参考资料 说明该用户需求报告使用的参考资料,如: 1)[1] 商务合同 2)[2] 招标书 3)[3] 用户领域的资料 4)[4] 用户需求调查表 5)[5] 用户需求报告 6)[6] 参照的标准 每一个文件、文献要有标题、或文件号,发布或发表日期以及出版单位。

C需求规格说明书规范

附录C 需求规格说明书规范 需求分析应交付的主要文档是需求规格说明。 软件需求规格说明作为分析结果,它是软件开发、软件验收和管理的依据。因此,必须特别重视,不能有一点错误或不当,否则将来可能要付出很大代价。 软件需求规格说明的一般格式如下: 1引言 1.1编写目的 ·阐明开发本软件的目的。 ·说明编写本软件说明书的目的。 ·指明软件需求说明书所预期的读者。 1.2项目背景 ·标识待开发软件产品的名称、代码。 ·列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户。 ·说明该软件产品与其他有关软件产品的相互关系。 1.3术语说明 列出本文档中所用到的专门术语的定义和英文缩写词的原文。 1.4参考资料 列举编写软件需求规格说明时所参考的资料,包括项目经核准的计划任务书、合同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档,以及相关产品的软件需求规格说明。 在这里应该给出详细的信息,包括标题、作者、版本号、发表日期、出版单位或资料来源。 2项目概述 2.1待开发软件的一般描述 描述待开发软件的背景,所应达到的目标,以及市场前景等。 2.2待开发软件的功能 简述待开发软件所具有的主要功能。为了帮助每个读者易于理解,可以使用列表或图形的方法进行描述。使用图形表示,可以采用: ·层次方框图如图1所示。 ·UseCase图。 ·系统流程图。 ·顶层数据流图如图2所示。

图l 层次方框图 图2 顶层数据流图 2.3用户特征 描述最终用户应具有的受教育水平、工作经验及技术专长。 2.4运行环境 描述软件的运行环境,包括硬件平台、硬件要求、操作系统和版本,以及其他的软件或与其共存的应用程序等。 2.5条件与限制 给出影响开发人员在设计软件时的约束条款,例如: ·必须使用或避免使用的特定技术、工具、编程语言和数据库。 ·硬件限制。 ·所要求的开发规范或标准。 3功能需求 3.1功能划分 列举出所开发的软件能实现的全部功能,可采用文字、图表或数学公式等多种方法进行描述。 3.2功能描述 对各个功能进行详细的描述。 4外部接口需求

需求规格说明书

文件编号: 受控状态:■受控□非受控 保密级别:■公司级□部门级□项目级□普通级 记录编号: 分发编号: xxx公司云平台 需求规格说明书 Version 1.0 2014.07.23

需求规格说明书模板

目录 1前言 (4) 1.1编写目的 (4) 1.2文档约定 (4) 1.3读者对象 (4) 1.4术语和缩略词 (5) 1.5参考文档 (5) 2项目概述 (5) 2.1项目背景 (5) 2.2项目目标 (5) 2.3需求范围 (6) 2.4总体框架 (6) 2.5组织机构 (6) 2.6用户特点 (6) 2.7设计约束 (6) 3功能性需求 (6) 3.1总体流程 (6) 3.2角色定义 (7) 3.3系统功能 (7) 3.4功能描述 (7) 4非功能性需求 (11) 4.1软件需求 (11) 4.2硬件需求 (12) 5外围系统和接口 (13) 5.1系统A (13) 5.2系统B (13) 6其他需求 (14) 7数据字典 (14) 8附件 (14)

1 前言 1.1 编写目的 [说明编写这份需求规格说明书的目的,指出预期的读者(一般包括评审人员、软件设计人员、软件开发人员,针对具体情况,还可能包括客户),它是软件开发的基础。] 1.2 文档约定 [描述编写文档时所采用的字体标准或排版约定,包括标题和正文的字体和字号约定。完成文档编写后,文档编写完成后本部分须裁剪] 字体大小约定: 标题1 宋体三号加粗 标题2 宋体小三号加粗 标题3 宋体四号加粗 标题4 宋体小四号加粗 标题5 宋体小四号 正文宋体五号 段落约定:文章中每段落需抬头,即段落开头需有两字元的缩排,单倍行距。 表与图编号约定:文中所有表、图须按章节编号,如:第四章节第二个表,编号为:表4-2。裁剪约定:如标注可裁剪提示信息,表示该部分内容可以裁剪或删除。 1.3 读者对象 [描述本需求规格说明书的主要读者。建议将不同读者的阅读重点与建议以列表方式表现,]

软件需求规格说明书模板

<项目名称> 软件需求说明书 作者: 完成日期: 签收人: 签收日期:

版本情况记录:

目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (1) 1.4 参考资料 (1) 2 项目概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 一般约束 (2) 2.5 假设和依据 (3) 3 具体需求 (3) 3.1 功能需求 (3) 3.1.1 功能需求13 3.1.2 功能需求24 3.1.n 功能需求n (5) 3.2 外部接口需求 (5) 3.2.1 用户接口.. 5 3.2.3 软件接口.. 5 3.3 性能需求 (6) 3.5 属性 (7) 3.5.1 可用性 (7) 3.5.2 安全性 (7) 3.5.3 可维护性.. 7 3.5.5 警告 (8) 3.6 其他需求 (8) 3.6.1 数据库 (8) 3.6.2 操作 (8) 3.6.3 场合适应性需求 (9) 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的,指出预期的读者范围。0.5

1.2 范围 说明: a.待开发的软件系统的名称; b.说明软件将干什么,如果需要的话,还要说明软件产品不干什么; c.描述所说明的软件的应用。应当: 1)尽可能精确地描述所有相关的利益、目的、以及最终目标。 2)如果有一个较高层次的说明存在,则应该使其和高层次说明中的类似的陈述相一致(例如,系统的需求规格说明)。 1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料,如: a.本项目的经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料,包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 2 项目概述 2.1 产品描述 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 产品功能

1-软件需求规格说明书SRS

需求规格说明书 1.引言 (1) 1.1编写目的 (1) 1.2项目背景 (1) 1.3定义 (2) 1.4参考资料 (2) 2.任务概述 (2) 2.1要求 (2) 2.2目标 (2) 2.2运行环境 (3) 2.3假定和约束 (3) 3.功能需求 (3) 3.1功能描述 (3) 3.2数据词典 (8) 3.3 E-R模型 (9) 4.性能需求 (10) 4.1用户数量 (10) 4.2反应速度 (10) 5.运行需求 (10) 5.1用户界面 (10) 5.2硬件接口 (10) 5.3软件接口 (10) 5.4故障处理 (11) 6.其它需求 (11)

1.引言 人事管理系统分析小组对当今社会的人事管理方面的需求进行了认真而全面的调查。根据对企业的人事管理系统的功能需求、业务操作规程及其数据结构等具体要求,调查了单位对人事管理企业的员工基本信息、员工调动、员工奖罚、员工培训、员工考评、员工调薪、员工职称评定,确定了系统性能要求,系统运行支持环境要求,数据项的名称、数据类型、数据规格。以上这一切为统下一步的开发工作奠定了良好的基础。 本软件需求说明书全面、概括性地描述了人事管理系统所要完成的工作,使软件开发人员和用户对本系统中的业务流程及功能达成共识。通过本需求说明书可以全面了解人事管理系统所要完成的任务和所能达到的功能。 1.1编写目的 1.为开发小组成员、客户之间提供共同的协议而创立基础。对企业管理软件功能的实现作 使命描述。让客户指出我们的不足,进一步了解客户的需求。 2.根据人事管理系统的特点,对被开发软件系统的主要功能、性能进行完整描述,为软件 开发者进行详细设计和编程提供基础。 3.本说明书的预期读者为开发小组成员及甲方负责人。本说明能让甲方代表更好地了解本 系统,减少彼此之间交流的困难和开发中因为需求不明确而产生的不必要的麻烦。 1.2项目背景 随着计算机技术、网络技术和信息技术的发展,现在办公系统更趋于系统化、科学化和网络化。网络办公自动化系统是计算机技术和网络迅速发展的一个办公应用解决方案,它的主要目的是实现信息交流和信息共性,提供协同工作的手段,提高办公的效率,让人们从繁琐的有纸办公中解脱出来。现在许多的机关单位的人事管理水平还停留在纸介质的基础上,这样的机制已经不能适应时代的发展,因为它浪费了许多的人力和物力,在信息时代这种传统的管理方法必然被计算机为基础的信息管理所取代。 ××软件公司(简称)主营业务是软件开发,公司目前规模为100人,公司设有人事部、财务部、行政部、研发部、销售部与公关部,人员类型有以下几种:普通员工、部门经理和总经理,其中人事部设有1个人事经理、3个人事助理。目前,公司尚无人事管理系统,公司各项涉及人事业务流程都是由人事部员工手工完成。 本系统是对公司的人事资料进行管理,为人事管理人员提供了一套简单的操作、使用可靠、界面友好、易于管理和使用的处理工具。本系统对人事各种数据进行统一处理,避免数据存取、数据处理的重复,提高工作效率,减少了系统数据处理的复杂性。本系统不仅使公司人事管理人员从繁重的工作中解脱出来,而且提高了人事管理的效率,提高了人事管理的科学性,方便了用户查询、管理人员进行管理。

需求分析规范

1目的 对项目的需求分析活动进行控制,明确需求规格说明书的要求。 2适用范围 适用于项目的用户(包括确定顾客和潜在顾客)需求分析活动。 3职责 ?项目负责人指定人员组成用户需求分析小组,并委任需求分析负责人。 ?需求分析组了解和分析用户的需求,并编制《需求规格说明书》。 ?项目负责人负责组织对需求规格说明书的评审。 4工作流程 4.1确定需求分析人员 在项目立项,完成项目策划后,项目负责人指定人员组成需求分析小组,并委任负责人。 4.2需求分析实施 需求分析小组进行用户需求分析工作,主要了解以下的内容: ?用户业务与项目有关的部分; ?用户的工作流程; ?用户的相关部门及职责; ?使用人员的技术水平; ?用户原有系统的现状; ?用户对项目交付成果的期望和具体要求。 4.3编制《需求规格说明书》 在充分了解用户需求的基础上,需求分析小组编写《需求规格说明书》,要求参见《需求规格说明书》模板。该模板规定了《需求规格说明书》的内容和要求,编写时可根据具体的项目情况进行调整。必要时,可在有关的章节中引述其它资料作为附录。 4.4需求评审 为保证需求定义的正确性、完整性和清晰性,应对《需求规格说明书》进行评审,

评审主要考虑以下准则: ?客户或潜在客户需要的可追溯性; ?与客户或潜在客户需要的一致性; ?可测试性; ?系统(子系统)设计的可行性; ?操作和维护的可行性。 4.5需求管理 《需求规格说明书》经评审后,按《配置管理程序》进行管理;需求的修改与变更,应按照《更改控制程序》执行。 5相关程序文件 序号名称编号 1 配置管理程序QP-013 2 更改控制程序QP-014 6记录 序号名称模板编号 1 需求规格说明书QR-05 2 评审报告QR-06

软件工程--需求规格说明书

文档编号:HHIT-SECD-S101-01T-02 版本号:V1.0 酒店宾馆客房管理系统结构化需求规格说明 书 项目名称酒店宾馆客房管理系统的设计与实现 项目负责人 项目开发单位 项目成员、、、 项目起止时间2013.06.18----2013.06.21 2013年6月21日

软件工程课程设计项目组任务分派单(组长用)班级:组别:组长姓名:时间:2013 年 6 月21日 1、本表由组长为其组员每次上机实践分派任务使用,应认真填写相关任务名称、内容、完成标准等信息; 2、本表在每次任务完成后,由组长按照完成标准验收,并给出每个组员成绩评定(每人 平均70分制),除组长保留一份外,应及时上报任课老师(电子和纸质文档同时上报)。

目录 酒店宾馆客房管理系统结构化需求规格说明书 (1) 软件工程课程设计项目组任务分派单(组长用) (2) 目录 (3) 1引言 (3) 1.1编写目的 (3) 1.2背景 (4) 1.3定义 (4) 1.4参考资料 (4) 2项目概述 (4) 2.1目标 (4) 2.2用户的特点 (5) 2.3假定与约束 (5) 3需求规定 (5) 3.1对功能的规定 (5) 3.2对性能的规定 (17) 3.2.1精度 (17) 3.2.2时间特性要求 (17) 3.2.3灵活性 (18) 3.3输入输出要求 (18) 3.4数据管理能力要求 (18) 3.5故障处理要求 (19) 3.6其他专门要求 (19) 4运行环境规定 (19) 4.1设备 (19) 4.2支持软件 (20) 4.3接口 (20) 4.4控制 (20) 1引言 【】 1.1编写目的 想要做一个好的客房管理系统,首先必须知道用户的需求,这样我们才会开发出真正满足用户的软件产品,在系统的需求分析阶段,开发者应该明确一个好的客房管理系统必须要做什么。

软件需求规格说明书

<项目名称> 软件需求规格说明书 作者:淡新举 完成日期: 签收人: 签收日期: 修改情况记录:

目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (1) 1.4 参考资料 (1) 2 项目概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 一般约束 (3) 2.5 假设和依据 (3) 3 具体需求 (3) 3.1 功能需求 (3) 3.1.1 功能需求1 (3) 3.1.2 功能需求2 (4) 3.1.n 功能需求n (5) 3.2 外部接口需求 (5) 3.2.1 用户接口 (5) 3.2.2 硬件接口 (5) 3.2.3 软件接口 (5) 3.2.4 通信接口 (6) 3.3 性能需求 (6) 3.4 设计约束 (6) 3.4.1 其他标准的约束 (6) 3.4.2 硬件的限制 (7) 3.5 属性 (7) 3.5.1 可用性 (7) 3.5.2 安全性 (7) 3.5.3 可维护性 (7) 3.5.4 可转移\转换性 (8) 3.5.5 警告 (8) 3.6 其他需求 (8) 3.6.1 数据库 (8) 3.6.2 操作 (8) 3.6.3 场合适应性需求 (9) 4 附录 (9)

1 引言 1.1 编写目的 为明确软件需求、安排项目规划与进度、组织软件开发与测试、培训,撰写本文档。本文档供项目经理、设计人员、开发人员参考。 1.2 范围 说明: a.待开发的软件系统的名称; b.说明软件将干什么,如果需要的话,还要说明软件产品不干什么; c.描述所说明的软件的应用。应当: 1)尽可能精确地描述所有相关的利益、目的、以及最终目标。 2)如果有一个较高层次的说明存在,则应该使其和高层次说明中的类似的陈述相一致(例如,系统的需求规格说明)。 1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料,如: a.本项目的经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料,包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的 第1 页

软件需求规格说明书标准模板

软件需求规格说明书 文件编号:QMS—PROC-RD02 版本:1.0 受控签章

修改历史

目录 1引言 (4) 1.1目的 (4) 1.2背景 (4) 1.3术语 (4) 1.4预期读者与阅读建议 (4) 1.5参考资料 (4) 1.6需求描述约定 (5) 2.项目概述 (6) 2.1系统功能 (6) 2.2业务描述 (6) 2.3数据流程描述(可选) (6) 2.4用户的特点 (6) 2.5运行环境要求 (6) 2.6设计和实现上的限制 (6) 3.功能需求的描述 (6) 4.非功能需求 (7) 4.1系统性能要求 (7) 4.2系统安全及保密要求 (7) 4.3系统备份与恢复要求 (7) 4.4系统日志 (7) 5.外部接口说明 (7) 6.其他需求 (8) 7 需求变更识别 (8) 8.功能列表 (8) 9.附件 (8)

1引言 1.1 目的 说明编写这份软件需求规格说明书的目的,如:通过本文档定义XXX产品的需求,以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景,包括: a.需开发的软件系统的名称,和英文缩写(可选),项目编号(可选); b.列出此项目的任务提出者、开发者 c.软件系统应用范围、用户。 d.产生该系统需求的原因或起源,如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料,如: a.本项目经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d.行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

软件需求规格说明书标准模板

软件需求规格说明书 文件编号: QMS—PROC-RD02 版本:1.0 受控签章

修改历史

目录 1引言 (2) 1.1目的 (2) 1.2背景 (2) 1.3术语 (2) 1.4预期读者与阅读建议 (2) 1.5参考资料 (2) 1.6需求描述约定 (2) 2.项目概述 (2) 2.1系统功能 (2) 2.2业务描述 (2) 2.3数据流程描述(可选) (2) 2.4用户的特点 (2) 2.5运行环境要求 (2) 2.6设计和实现上的限制 (2) 3.功能需求的描述 (2) 4.非功能需求 (2) 4.1系统性能要求 (2) 4.2系统安全及保密要求 (2) 4.3系统备份与恢复要求 (2) 4.4系统日志 (2) 5.外部接口说明 (2) 6.其他需求 (2) 7 需求变更识别 (2) 8.功能列表 (2) 9.附件 (2)

1引言 1.1 目的 说明编写这份软件需求规格说明书的目的,如:通过本文档定义XXX产品的需求,以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景,包括: a.需开发的软件系统的名称,和英文缩写(可选),项目编号(可选); b.列出此项目的任务提出者、开发者 c.软件系统应用范围、用户。 d.产生该系统需求的原因或起源,如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料,如: a.本项目经核准的计划任务书或合同、上级机关的批文; b.属于本项目的其他已发表的文件; c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d.行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

软件需求说明书编写规范

{产品名称} 软件需求规格说明书 编写人: 编写日期:年月日

目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义(可选) (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制(可选) (3) 3.功能需求 (3) 3.1.功能划分(可选) (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求(可选) (4) 6.运行需求(可选) (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求(可选) (5) 8.特殊需求(可选) (5) 9.不确定的问题(可选) (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5)

1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的,指出预期的读者。】 1.2.产品名称 【本项目的名称,包括项目的全名、简称、代号、版本号。】 1.3.名词定义(可选) 【对重要的或是具有特殊意义的名词(包括词头和缩写)进行定义,以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介,包括: 1.本产品的开发意图、应用目标及作用范围。 2.概略介绍了产品所具有的主要功能。可以用列表的方法给出,也可以用图形表示主要的需求分组以及它们之间的联系,例如数据流程图的顶层图或类图等。 3.说明本产品与其他相关产品的关系,是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图,或者方框图说明。】 2.2.运行环境 1.硬件环境: 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境: 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制(可选) 【说明本软件在实现时所必须满足的条件和所受的限制,并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如:必须使用或者避免的特定技术、工具、编程语言和数据库;企业策略、政府法规或工业标准;硬件限制,例如定时需求或存储器限制;经费限制、开发期限;项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性,即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述,还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分(可选) 【此部分从用户的角度描述将软件划分成不同的部分,并给出总体功能结构。对于复杂

系统需求规格说明书 (1)

XXX系统或XXX项目 产品需求规格说明书 版本信息 注:状态可以为N-新建、A-增加、M-更改、 对方的所得税说明:版本信息必须更新,审核人和审核时间也必须审核后填写,审核人要求部门经理级别以上。否则开发测试可拒绝评审。审核业务功能是否有遗漏、业务流程是否符合规划、关键业务逻辑是否有合理 目录

1.关于本文档 1.1.内容说明 说明:此处描述的是文档说明,产品需求文档更新需要走修订模式,下次更新前先接受修订,并且每次更新必须更新版本号和版本记录。 例子: 本文档用于描述苏宁开放平台物流状态服务系统的需求定义。包括各个需求的功能描述,处理逻辑规则,界面定义,与其它功能的关系,与其它系统的接口等各个方面的定义。是苏宁物流状态服务系统唯一的全面需求定义文档。 本文档将根据需求管理流程和要求,随系统功能变化进行及时的修订和更新,以确保本文档的全面性,准确性和实效性。因此在阅读使用此文档时,请注意从项目的文档管理系统中获取最新版本。 1.2.名词解释

1.3.参考文档 《系统需求定义规范使用说明》 2.系统概述 2.1.业务背景 说明:此处描述业务背景,不可裁剪,清晰的业务背景描述能更好的帮助研发和测试理解产品需求,明确业务测试场景,此部分是产品需求定位的核心导向。 例子一:电子面单的业务描述 随着电子商务服务和物流服务信息化飞速发展,包裹运单号成为快递公司串联快递单、订单、商家、商品等各种信息的枢纽。相比之下,传统纸质面单价格高、信息录入效率低、信息安全隐患等方面的劣势已愈发凸显。我司在两年前就开始了电子面单在自营物流上的应用,经过长期的的磨合和积累,目前将我司的应用经验推广到社会物流上,让社会上愿意与我司物流合作的伙伴,也同样享受到我司电子面单服务。 例子二:LSQ的业务描述 物流作业状态服务存在不足 1)服务无标准不统一 需物流作业的各渠道订单,作业状态转化为文案描述处理的逻辑系统多,且处理规不统一, -B2C自营订单,逻辑在B2C,数据源在OMS -菜鸟平台/4PS平台订单状态展示,逻辑在LAPI,数据源在LAPI

相关文档
最新文档