需求说明书编写规范.docx
- 文档编号:22998399
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:16
- 大小:63.02KB
需求说明书编写规范.docx
《需求说明书编写规范.docx》由会员分享,可在线阅读,更多相关《需求说明书编写规范.docx(16页珍藏版)》请在冰豆网上搜索。
需求说明书编写规范
需求规格说明书
软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档,是为了使用户和软件开
发者对软件的规格有一个共同的理解而撰写的,软件需求规格说明有标准的模板
系绽运行支爲f现炀支持测试分析与系统整合『开发書I详细设计
f*
f・¥「
中作人民it利|佝国宅标能
HL*Iiyll
计箕机歌件需求规辎说明规范
屠«|I|.;irl--rrt>IiKcAlIm
wm申.'iI•iw—<.
方法/步骤
第一章是引言
个部分:
1.1编写目的
//对产品(项目)进行定义,在该文档中详尽说明这个产品的软件需求,包修正或发行版本号。
如果这个软件需求规格说明书只与整个系统的一那么只定义文档中说明的部分或子系统。
1.2文档约定
//描述编写文档时所采用的标准或排版约定,包括正文风格,提示区或重符号。
例如,说明高层需求的优先级是否可以被所有细化分需求所继个需求陈述是否都有优先级。
1.3读者对象和阅读建议
//列举软件需求规格说明书所针对的不同读者,例如开发人员、项目经理、销人员、用户、测试人员等。
描述文档中剩余部分的内容及其组织结适合每一类读者阅读文档的建议。
1.4项目范围
//提供对指定的软件及其目的的简短描述,包括利益和目标。
把软件与企业或业务策略相联系。
可以参考项目范围文档,而不是将其内容复制到
1.5参考资料
//列举编写软件需求规格说明书时所参考的资料或其它来源。
可能包括用户风格指导、合同、标准、系统需求规格说明书,用户需求、相关产品说明书。
这里应给出详细的信息,包括标题名称、作者、//版本号、
资料来源,以方便读者查阅这些文献。
//括
//部分有关,
//要
//承,或者每
//营
//构。
提出最
//目标
//这里
//界面//的软件需求规格日期、出版单位或
伯编写目的
软件需求规格说明插述了“自助食堂订餐系统(Cafetena
Oi(lenngSystem,COS)”L0版本的软件功能性需求和非功能性需求。
这一文档计划由实现系统功能和验证系统功能正确的项目团队成员来使用。
除非在其它地方另有说明,这里指定的所有需求都具有高优先级,而且都要在1.0版本中得以实现。
1.2文档约定
牖还編行文样时滞武用的杯沁幻。
敝泌・包銘上文城將祺小心轴瞠?
沾阿乩说“厲區*求的优尢缄[以械丈召W代的當求序雒和或苕毎个镒求陈述崔査都竹优
1・3预期的读者和阅读建议
该软件需求规格说明针对开发人员、项目经理、销售人员、用户及测试人员.本文分别介绍了产品的远景规划、用户功能及运行环境,系统的功能,点具体描述及外郎接口的需求。
1.4项目范国
“自助食堂订餐系统”允许Proc际Impact公司雇员向公司的自助食堂在线订幫,并送餐到公司内的指定地点,详细的项目描述请参见CafeteriaOrdeiingSystemVisionandScope
Doaiinent.(自助食堂订餐系统前景和范
ea
■a
文档)【1】。
文档
中这一部分的标题为“初始版本和后续版本的范围”,列出了按照进度计划在这一版本中实现的全部或部分功弘,
15蔘考资料
(1)1011\Vies*a*;所薯的CafeteriaOrdeiiiiaSystemVisionandS ^"wTw,proces^mpnct,con^proiect^/co^visionmidi;cop€.doc (2)Kaih\ie^eis所著的FigM/InjiKtIntranetDeveiopmeji*Staudanl版本13苴网址是wvw.wroce^^upflctxoiii/cojpcuftte^taiidAr^PIuitiniietdev对d.doc (3)CUishiieZfMUbitO所着的PiecesImpactBussjiLessRules? **I^AAAAJkUAAA-MigAAAAAAr Catnip,M网址是 \^vwi)]Qcessimpnct.€om«>]卩炯贰亡卩观山蹲汙PIbu^iiKrrsr/te.doc 第二章是总体描述。 包含六个部分: 2.1产品前景 //描述软件需求规格说明书中所定义的产品的背景和起源。 说明该产品是否//是产 品系列中的下一个成员,是否是成熟产品所改进的下一代产品,是否//是现有应用程序 的替代品,或者什方E市一个全新的产品。 //如果软件需求规格说明书定义了大系统的一个组成部分,那么就要说明这//部分 软件是怎样与整个系统相关联的,并且要定义出两者之间的接口。 建//议使用系统结构 图或者实体关系图表示 2.2产品的功能 //概述产品所具有的主要功能,详细内容在第4节描述,所以这里只需要概括//总 结,例如用列表的方法给出。 很好地组织产品的功能,使每个读者都易〃于理解。 用图 形表示主要的需求分组以及它们之间的联系。 //建议使用数据流程图(DFD的顶层图或者类图来实现图形化 2.3用户类及其特征 //确定可能使用该产品的不同用户类并描述它们相关的特征。 有一些需求可//能只与特定的用户类相关。 将该产品的重要用户类与那些不太重要的用户//类区分开 2.4运行环境 //组件 //描述软件的运行环境,包括硬件平台、操作系统和版本,还有其它的软件或者与其共存的应用程序。 2.5设计和实现上的约束 //确定影响开发人员自由选择的问题,并说明这些问题为什么成为一种限 //制。 可能的限制包括: //♦必须使用或者避免的特定技术、工具、编程语言、数据库 //■经费、进度、资源等方面的限制 //♦所要求的开发规范或标准 //♦企业策略、政府法规或工业标准 //♦硬件限制,例如定时需求或存储器限制 //♦数据转换格式标准 //♦其它 2.6假设和依赖 九产品远绘规划 “自助食堂兀餐系统"是一个新系统,它取代了当前在Pw刑Imp^t公司自助您堂内以手工方式和电话方式预定及选择午番的过程。 團D丄是一垢关联團,它演示了10版举的外部实体和系统接口。 期望系统演化成若干个版本「最终与本地若干饭店的IntemeTiT餐服务相连接.并提供常用卡和借记卡授权服务。 图D1"自助奠堂订餐羡统丄巾版本的关联图" 4 £・2•用户类和用户功能| 用户类 描述 .顿客(优先老虑) 换客是俶勒冈州Clackamas的ProcessImr>Qct公司的屋员,他们希竟从公司的自助食堂订餐并能送餐上门。 大约有飙)0名港在 吸富.其中估计有400人孜计平均毎星期毎人便用“自助食堂订桜系统”4次(来瀝、根据当前自助食堂的便用数据).额客有时含由于团体專件或有来宾而订好多份餐。 估计沁的IT单是通过公司的内联网而從交的・1W的订单是从栾里槻交的.所有的硕客都可以从他们的办公室访问公祠内联网.有些顾咨希辺建立因定的订餐,毎天送同样的饭菜,或音是自动送当日的特色菜.贖客必须能修改对菓一具体日期的仃咎. 自助食堂工作人 员 Process: D叩Mt公司自助食堂目前飕佣了大约20名“自助食堂工作人员”,他们从“自助食堂订餐系统”接受订单,准备饭菜,对要送蜜上门的饭菜进行打包'打印送餐说明,并请求送餐.自助食堂工作人员需要接受坷训,学会如何使用计停机、Web浏览器和由金営订饗系统”・ 食當经理 菜单管理人是自助食堂的厲员,也许就是會堂经理,他负责建立并维护自助食堂有效的食物条目日常菜单,和某一天每一个食物条目的有效时间.有些饭菜不适宜于送货上门.菜单管理人也奥定文食堂的每日倖色菜.菜单经理还需要定期编辑菜单,以反映计划内的无效的、或价格发生了变更的會物. 送餐人员 当自助儉堂工作人员准备订单所雯求送的饭菜时,他们打印送餐说明并向送餐人员发出送餐请求,送蚩人员是食堂的其他庖员或者是承包人.送咬人员要为每顿餐挑 选食物和准备送餐说明,幷将它送劲顾客手里。 送餐人员与系统的主要交互是偶尔重新打印送礬说沪4胸认餐已送到(或没有送到)顾客手中。 OE-n“自助食堂订餐系统”的操作将通过如下的Web浏览器来龙成: MicrosoftInternetExplore版本5.0和6.0,NetscapeConununicator版本4.7和Netscape版本6和版本~。 OE・2: “自助食堂订饗系统”将运行在一个服务器中,该服务器的操作凉统是当前由公司批准的RedH^tLinvx版本和HTTPScrvei» OE-3: “自助食堂订餐系统”将允许用户通过公司内联网来访问,如果用户被授权在公司的外部穿过防火墙来访问,那么用户也可以在家里通过Internet来访问该系统• 4•设计和实现的约束条件(constraint) CO-1: 系统的设计、编码和维护文档将遵照PiImpact IntranetDevelopmentSt CO・2;系统将采用标准的数据库引皐。 CO-31所有HTML代码将逍照HTML4.0标准。 CO4所有脚本都用Peil语喜来编写。 SJS)S(Assumption)和依赖(Dependency) 兀S小只要是要求员工在岗的每一个公司工作日#自助食堂在 早餐"午養和晚菴时都会营业。 DE-1;白自助食堂订餐系欲的运行依赖于“薪资杉算系统円 所做出的变更,它接受闿’‘自助倉堂订餐系统''订餐的付费 请求" DEC: “宜助食堂订餐系统^的运行依赖于"自助倉堂库存系 统丹所做出的变更,当接受“自勒食堂订餐系统并订单盾, 它更新食物条目的有效性。 第三章是系统功能。 需要列出每个功能点,每个功能点包含 以下三个方面: 3.X.1描述和优先级 3.X.2请求/响应序列 3.X.3功能性需求 //详细列出提交给用户的软件功能,用户可以使用所提供的功能执行服务// 或者使用所指定的用例执行任务。 并且描述产品如何响应可预知的出错//条件或非 法输入或动作。 丄•丄描述和优先级 自助食堂的顾客其身份得到验证之后,他们就可以订餐,并可以要求送到公司内指定的地点,也可以去食堂内就餐。 只要所订餐还没有准备好,顾客就可以取消或改变订单。 优先级为高 丄.2请求响应序列 请求: 顾客请求订養,可以是一份或多份。 响应: 条统向顾客询问订餐细节、付费方式和送餐说明请求土顾客请求改变订单。 响应: 如果订单状态是“已接受”,则系统允许用户编辑以前的订单. 请求戈顾客请求取消订单。 响应: 如果订单状态是“已接受”,则系统収消订总。 丄3功能性需求 OideiPlMe 登录到"自助食堂订餐系统穴的顾客可以通过该系统订餐,可以订一份或多饴都可以 I 系统将确认订餐的顾客所注册的付费方 式是从工资中扣除餐费的伯费方式 Order,Place.R^giste iNo 如果顾客没有注册从工资中扣除餐费的彳寸费方式,那么系统将为顾客提供一些选择方案,顾客可以现在注册并继续逬行订餐,也可以 订餐后去食堂用餐1不送餐),或者还可以退出锥自助食堂订餐至统力 第四章是外部接口需求。 包含四个部分: 4.1用户界面 //包括 //户界 //陈述所需要的用户界面。 描述每个用户界面的逻辑特征。 以下是可能要 的一些特征: //4将要采用的用户界面标准或产品系列的风格 //♦屏幕布局或解决方案的限制 //4将出现在每个屏幕的标准按钮、功能或导航链接 //♦快捷键 //4错误信息显示标准 //对于用户界面的细节,例如特定对话框的布局,建议写入一个独立的用 面规格说明中,不要写入软件需求规格说明书中 4.2硬件接口 //描述系统中硬件每个接口的特征。 可能包括支持的硬件类型、软硬件之间//交流的数据和控制信息的性质以及所使用的通信协议 4.3软件接口 //描述产品与其它外部组件的连接,包括数据库,操作系统,工具库和集成//的商 业组件。 明确并描述在软件组件之间交换数据或信息的目的,描述所//需要的服务及内 部组件通信的性质,确定将在组件之间共享的数据。 如果//必须用一种特殊的方法来实 现数据共享机制,那么就必须把它定义为一种//实现上的限制 4.4通信接口 //描述与产品所使用的通信功能相关的需求,包括电子邮件、WEB浏览器、//网络 通信标准或协议及电子表格等,定义相关的信息格式、规定通信安全//或加密问题、数 据传输速率和同步通信机制 1.用户界面(UserInterface,Uf) LTidt摄自助倉堂订程寡统"的屏專is面梅遵照氏g ImpactInternetApplicationUserMerfaceStandard(Pre Impact公司的Ii止创口衬应用程序用户界面标准丿版本丄山【总】 系统禅所显示的毎个HTML网贡都提供带助糙 按,解释如诃便用这些网页. UI小面的全部导航和食物疑且选择,除了综含 使用鼠标裁键盘共同克威外,还可以只通过犍盘来叮牲弋成、 3.软件接口(SoftwareInterfaces,SI) SI4: 自助險堂库存系统 SI-1h自助食堂订餐系统通过程序界面向自助食堂库存系统发生所订的食物条目和数量 SM.2: 自助食堂订餐系统将询问自助食堂库存东统,以确定所请求的食物是否有效 SL13t当自助偸堂库存系统通知自助食堂订餐系统某一指定的食物条目已经没货时启助食堂订覆系统会从当日的菓单中将该食鞭条2刮除 第五章是其他非功能性需求。 包含四个部分: 5.1性能需求 〃阐述不同的应用领域对产品性能的需求,并解释它们的原理以帮助开 //发人员做出合理的设计选择。 确定相互合作的用户数或者所支持的操//作,响应时间以及与实时系统的时间关系;还要定义容量需求,例如存//储器和磁盘空间的需求或者存储在数据库中表的最大行数。 也可能需要 //针对每个功能需求或特性分别陈述其性能需求 5.2安全性需求 //陈述与系统安全性、完整性相关的需求,包括产品创建或使用的数据保//护。 明确产品必须满足的安全性或保密性策略。 5.3软件质量属性 //详细陈述与客户或开发人员至关重要的质量特性。 这些特性必须是确定//的、定量的并可检验的。 至少应指明不同属性的相对侧重点。 5.4其它需求 //理、 //定义至今未出现的需求。 例如国际化需求、法律上的需求、有关操作、管维护、安装、配置、启动、关闭、修复、容错、监控等等方面的需求 1,性能需求 PE4: 在当地时间早農S点到10点这一段高峰期间, 系统将能适应加。 个用卢,平均錄个会话估计捋续8分钟" PE-2*系统生成的所有Web页面,通过速率为40KBpS; 的调制解调緡庄不超过丄。 秒的时间内可以全部下戟F来* PE-3: 用户提交了査询之后,对萱询的响应时间不能粗 过P在此时间内将要査询緒果显示在屏專上, PE-4: 用户向系统提空信息后,系统将在4秒内向用户 显示确认消息中 £妥全性<Securify>需求 SE-lt所有涉及功能信息或个人身份信息的网络事务, 都娶按照BR-5A进行加密操作。 SE-2除浏览菜单外+用户必须登录到“自助食堂订寮系 统”才能克成苴他所有操作® SE3顾客的登录受计算机条统访问控制策略的隔制,具 体请 SE-1: 勒禽宜的工作人员,只貢那些授权为藥单管理员的, 才能通过系统创建或编辑菜单,具体请参照BR-21. SF-5只有那些被攪权可以在家访问公司内联网的用户, 才可以在公司以外的地方使用“自助食堂订程杀STa GET;系统只允许顾智浏览他们自己以前的订单.而不箴刮览 茸他除客的订单. 4.软件质量属性 Availability何用性)小“自助食堂订餐系统”将对公司内联网的用户可用,拨号用在当地时间早晨5点到晚上12点内99.9。 。 的时间可用,当地时间晚上12点到早晨,点92。 的时间可用。 Robustness®壮性)如果在订单得到确认或取消之前, 用户和系统的连接中断,那么用户应该能通过“自助食堂订 餐系统"恢复不主整的订单• 第六章是数据字典。 包含两个部分: 6.1实体关系图 6.2实体定义 埒齐懺卷肚疔刊匕: 说啾対K怦的业莽證炭泾亚弄嫌韓) H ■U八肘 J7/ 第七章是业务规则与业务算法: 7.1业务规则 //列举出有关产品的所有操作规则。 例如什么人在特定环境下可以进行何种//操作。 这些规则不是功能需求,但它们可以暗示某些功能需求执行这些规//则。 业务规则的 范例如下图所示: 7.2算法说明 //用于实施系统计算功能的公式和算法的描述,类似于业务规则。 如神州行 //套餐的计费标准说明。 //a.每个主要算法的概况; //b.用于每个主要算法的详细公式。 |T面是单独业务规则収点沖皆RuleBR)类别的一个范何h n> 规则宦义 规则类型 来源 送餐的时间窗□是上分钟,以澤一劃钟开始 事实 静态 自助億堂 经理 BR-2 送餐必须在当地时间上午E点和下午2点之间左成 约束 动态 自助禽堂 经理 BR-3 一张订单上的所有 饭菜必须送到同一 个地点 静态 自助金堂 经理 BRU 一张订单上的所有饭菜必须采用同一种付费方找来支忖費用 约束 静态 自助儉堂 经理 BR-S 订单必须在用餐日 前14内预定 约束 动态 I 肖助債堂 1.文档的最后是附录部分,包括: 附录A: 分析模型(包括涉及的数据流图、类图、状态转换图) 附录B: 待确定问题的列表 附录C: 编写文档的原则 ffiDJ**自助食堂订餐系統】■。 版本的部分数擔模型” 图D.3订单状态的状蛊转换图 步骤阅读
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 说明书 编写 规范