需求说明书编写规范.docx

1、需求说明书编写规范需求规格说明书软件需求规格说明书是软件开发过程需求分析阶段需要产出的文档， 是为了使用户和软件开发者对软件的规格有一个共同的理解而撰写的，软件需求规格说明有标准的模板系绽运行支爲 f现炀支持 测试分析与系统整合 开发書 I 详细设计f*f中作人民it利|佝国宅标能HL* I i yll计箕机歌件需求规辎说明规范屠|I|.； irl-rrt IiKc Al Imwm申.i I iw .方法/步骤第一章是引言个部分：1.1 编写目的/ 对产品 （项目 ）进行定义，在该文档中详尽说明这个产品的软件需求，包 修正或发行版本号。如果这个软件需求规格说明书只与整个系统的一 那么只定义文档

2、中说明的部分或子系统。1.2 文档约定/ 描述编写文档时所采用的标准或排版约定，包括正文风格，提示区或重 符号。例如，说明高层需求的优先级是否可以被所有细化分需求所继 个需求陈述是否都有优先级。1.3 读者对象和阅读建议/ 列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、 销人员、用户、测试人员等。描述文档中剩余部分的内容及其组织结 适合每一类读者阅读文档的建议。1.4 项目范围/ 提供对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业 或业务策略相联系。可以参考项目范围文档，而不是将其内容复制到1.5 参考资料/ 列举编写软件需求规格说明书时所参考的资料或其它来源。

3、可能包括用户 风格指导、合同、标准、系统需求规格说明书，用户需求、相关产品 说明书。这里应给出详细的信息，包括标题名称、作者、 / 版本号、资料来源，以方便读者查阅这些文献。/ 括/ 部分有关，/ 要/ 承，或者每/ 营/ 构。提出最/ 目标/ 这里/ 界面 / 的软件需求规格 日期、出版单位或伯编写目的软件需求规格说明插述了 “自助食堂订餐系统（CafetenaOi（lenng System, COS）” L0版本的软件功能性需求和非功 能性需求。这一文档计划由实现系统功能和验证系统功能正 确的项目团队成员来使用。除非在其它地方另有说明，这里 指定的所有需求都具有高优先级，而且都要在1.0版

4、本中得 以实现。1.2文档约定牖还編行文样时滞武用的杯沁幻。敝泌包銘上文城將 祺小心轴瞠？沾 阿乩 说“厲區*求的优尢缄以械丈召W代的當求序雒和或苕毎个镒求陈述崔査都竹优13预期的读者和阅读建议该软件需求规格说明针对开发人员、项目经理、销售人员、 用户及测试人员.本文分别介绍了产品的远景规划、用户功 能及运行环境，系统的功能，点具体描述及外郎接口的需求。1.4项目范国“自助食堂订餐系统”允许Proc际Impact公司雇员向公司 的自助食堂在线订幫，并送餐到公司内的指定地点，详细的 项目描述请参见 Cafeteria Ordeiing System Vision and ScopeDoaiine

5、nt.（自助食堂订餐系统前景和范eaa文档）【1】。文档中这一部分的标题为“初始版本和后续版本的范围”，列出 了按照进度计划在这一版本中实现的全部或部分功弘，15蔘考资料(1)1011 Vies*a*；所薯的 Cafeteria Ordeiiiia System Vision and S卩炯贰亡卩观山蹲汙 PI buiiKrrs r/te.d oc第二章是总体描述。包含六个部分:2.1产品前景/描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否 /是产品系列中的下一个成员， 是否是成熟产品所改进的下一代产品， 是否 /是现有应用程序的替代品，或者什方E市一个全新的产品。/如果软件

6、需求规格说明书定义了大系统的一个组成部分，那么就要说明这 /部分软件是怎样与整个系统相关联的， 并且要定义出两者之间的接口。 建 /议使用系统结构图或者实体关系图表示2.2产品的功能/概述产品所具有的主要功能，详细内容在第 4节描述，所以这里只需要概括 /总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易 于理解。用图形表示主要的需求分组以及它们之间的联系。/建议使用数据流程图（DFD的顶层图或者类图来实现图形化2.3 用户类及其特征/ 确定可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可 / 能只 与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户 / 类

7、区分开2.4 运行环境/ 组件/ 描述软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件 或者与其共存的应用程序。2.5 设计和实现上的约束/ 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限/ 制。可能的限制包括：/ 必须使用或者避免的特定技术、工具、编程语言、数据库/ 经费、进度、资源等方面的限制/ 所要求的开发规范或标准/ 企业策略、政府法规或工业标准/ 硬件限制，例如定时需求或存储器限制/ 数据转换格式标准/ 其它2.6假设和依赖九产品远绘规划“自助食堂兀餐系统是一个新系统，它取代了当前在 Pw刑Impt公司自助您堂内以手工方式和电话方式预定 及选择午番的过程。

8、團D丄是一垢关联團，它演示了 10版 举的外部实体和系统接口。期望系统演化成若干个版本最 终与本地若干饭店的IntemeT iT餐服务相连接.并提供常用卡 和借记卡授权服务。图D1 自助奠堂订餐羡统丄巾版本的关联图42 用户类和用户功能|用户类描述.顿客（优先老虑）换客是俶勒冈州Clackamas的ProcessImrQct公司的屋员，他们 希竟从公司的自助食堂订餐并能送餐上门。大约有飙）0名港在吸富.其中估计有400人孜计平均毎星期毎人便用“自助食堂 订桜系统”4次（来瀝、根据当前自助食堂的便用数据）.额客有 时含由于团体專件或有来宾而订好多份餐。估计沁的IT单是 通过公司的内联网而從交的1

9、W的订单是从栾里槻交的.所有 的硕客都可以从他们的办公室访问公祠内联网.有些顾咨希辺 建立因定的订餐，毎天送同样的饭菜，或音是自动送当日的特 色菜.贖客必须能修改对菓一具体日期的仃咎.自助食堂工作人员Process：D叩Mt公司自助食堂目前飕佣了大约20名“自 助食堂工作人员”，他们从“自助食堂订餐系统”接受 订单，准备饭菜，对要送蜜上门的饭菜进行打包打印 送餐说明，并请求送餐.自助食堂工作人员需要接受坷 训，学会如何使用计停机、Web浏览器和由金営订 饗系统”食當经理菜单管理人是自助食堂的厲员，也许就是會堂经理，他 负责建立并维护自助食堂有效的食物条目日常菜单，和 某一天每一个食物条目的有效

10、时间.有些饭菜不适宜于 送货上门.菜单管理人也奥定文食堂的每日倖色菜.菜 单经理还需要定期编辑菜单，以反映计划内的无效的、 或价格发生了变更的會物.送餐人员当自助儉堂工作人员准备订单所雯求送的饭菜时，他们 打印送餐说明并向送餐人员发出送餐请求，送蚩人员是 食堂的其他庖员或者是承包人.送咬人员要为每顿餐挑选食物和准备送餐说明，幷将它送劲顾客手里。送餐人 员与系统的主要交互是偶尔重新打印送礬说沪4胸认 餐已送到（或没有送到）顾客手中。OE-n “自助食堂订餐系统”的操作将通过如下的Web浏 览器来龙成：Microsoft Internet Explore 版本 5.0 和 6.0, Netscap

11、e Conununicator 版本 4.7 和 Netscape 版本 6 和版本 。OE2: “自助食堂订饗系统”将运行在一个服务器中，该服务 器的操作凉统是当前由公司批准的Red Ht Linvx版本和 HTTP ScrveiOE-3： “自助食堂订餐系统”将允许用户通过公司内联网来 访问，如果用户被授权在公司的外部穿过防火墙来访问，那 么用户也可以在家里通过Internet来访问该系统4 设计和实现的约束条件(c on straint)CO-1:系统的设计、编码和维护文档将遵照PiImpactIntranet Development St规则宦义规则类型来源送餐的时间窗是 上分钟，以澤一劃 钟开始事实静态自助億堂经理BR-2送餐必须在当地时 间上午E点和下午 2点之间左成约束动态自助禽堂经理BR-3一张订单上的所有饭菜必须送到同一个地点静态自助金堂经理BRU一张订单上的所有 饭菜必须采用同一 种付费方找来支忖 費用约束静态自助儉堂经理BR-S订单必须在用餐日前14内预定约束动态I 肖助債堂1.文档的最后是附录部分，包括：附录A:分析模型（包括涉及的数据流图、类图、状态转换图 ）附录B:待确定问题的列表附录C:编写文档的原则ffiDJ *自助食堂订餐系統】。版本的部分数擔模型”图D. 3订单状态的状蛊转换图步骤阅读