《XX电子公司项目需求规格说明书.doc》由会员分享，可在线阅读，更多相关《XX电子公司项目需求规格说明书.doc（11页珍藏版）》请在三一文库上搜索。
1、XX电子股份有限公司需求规格说明书年 月文档修改记录版本修订人修订说明批准人发布日期1.0.1.0*初稿，20071107通过同行评审。*20071110说 明本文档中所包含的信息属于商业机密信息，如无恒生电子股份有限公司的书面许可，任何人都无权复制或利用。模版版本信息编辑部门：EPG批准日期：2008/1/22目 录1引言11.1编写目的11.2背景11.3定义11.4参考资料12任务概述12.1目标12.2用户的特点12.3假定和约束12.4需求收集和需求分析过程中采用的方法13需求规定13.1系统需求13.2用户需求13.3功能综述13.4功能需求13.4.1功能名称： 功能编号：13.
2、4.2功能名称： 功能编号：13.5性能需求13.5.1精度13.5.2时间特性要求13.5.3数据管理能力要求13.6运行环境需求13.6.1设备13.6.2支持软件13.6.3接口13.7灵活性需求13.8可靠性要求13.9界面需求13.10故障处理要求13.11安全性要求13.12质量要求13.13与其他系统的集成要求13.14其他专门要求14验收与交付14.1最终交付的工作产品14.2验收准则14.3最后交付的时间1I1 引言1.1 编写目的说明编写这份需求规格说明书的目的（如：给出最终要实现的软件必须满足的功能需求、性能需求、接口和用户介面需求以及属性、设计约束等，为下一步软件设计提
3、供依据）。指出本书的预期读者（如：技术管理人员、项目设计人员、项目开发人员及有关人员）。1.2 背景项目名称项目简称项目编号任务提出者开发者用户同其它系统的关系1.3 业务术语定义列出本文中用到的术语及其定义、外文首字母组词的原词组。1.4 需求文档编写约定列出本文中用到的编写约定，如各需求项属性值：1.4.1 需求优先级必须1优先2一般3可选4未知51.4.2 需求状态接受A 延后D拒绝R废除C待议U1.4.3 需求编号约定（多人分工编写时，需要对需求编号范围进行约定，以便最后合并成一个文档）1.4.4 .1.5 参考资料列出引用的参考资料，如：合同、标准等。2 任务概述2.1 目标叙述该项
4、软件开发的意图、应用目标、使用范围以及应说明的有关该软件开发的背景材料。解释待开发软件与其他有关软件之间的关系，以及体现这种关系的接口的简要说明或图示。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本软件与该系统中其他各组成部分之间的关系，最好用图来表示该系统的组成和本产品同其他各部分的联系和接口。2.2 用户的特点列出本软件的最终用户的特点，分类说明使用人员、操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是设计工作的重要约束。2.3 假定和约束列出进行本软件开发工作的假定和约束，如经费限制、开发
5、期限等。2.4 需求收集和需求分析过程中采用的方法如果是采用机构推荐的方法，则只需要给出方法的名称，并且说明在需求收集和需求分析的哪些步骤中用到了这些方法；如果不是机构推荐的方法，则还应该对于采用的方法进行简要说明。3 需求规定3.1 系统需求（列举对于软件开发的时间、进度、成本、与竞争对手点对比等高层次的需求/要求）本部分需求编制负责人：需求来源：描述组织机构或者客户对于系统、产品的高层次的目标要求。3.2 用户需求需求编制负责人：需求来源：（分节描述了用户使用产品必须要完成的任务。从用户角度描述主要的业务流程，以便理解后继功能需求之间的关系。比如，如果举交易系统为例，则需要描述委托下单流程
6、、日终清算流程等）3.3 功能综述(将全部功能分类综述，也可分等级综述，如分为关键功能需求和一般功能需求，对不同等级的功能需求可以有不同实现要求。最好列表说明，编号与优先级应与“功能需求”一节中的描述保持一致，不一致时以“功能需求”描述为准。)功能等级功能名称功能编号需求优先级简要说明关键一般本项目中如果由于进度、资源等因素造成所有功能无法实现，则至少实现_优先级（包括）以上的所有相关功能需求。3.4 功能需求本部分需求编制负责人：阐述每一功能的需求，内容和格式如下。功能编号系内部约定，便于软件设计和编码。3.4.1 xxx模块/子系统需求编制负责人：模块/子系统功能简述：3.4.1.1 功能
7、名称： 功能编号： 需求状态：需求优先级：需求提出人：需求描述：输入描述：处理流程：输出描述：（包括输出表格形式）需求测试要点描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；测试要点结合典型案例来描述；3.4.1.2 功能名称： 功能编号： 格式同3.4.1.13.4.2 xxx模块/子系统3.4.2.1 功能名称： 功能编号： 格式同3.4.1.13.5 性能需求（需求主要包括响应时间，处理速度、承载客户、并发性能、处理数据容量）3.5.1 精度需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等说明对该软
8、件的输入 、输出数据精度的要求，可能包括传输过程中的精度。3.5.2 时间特性要求需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；说明对于该软件的时间特性要求，如：响应时间、更新处理时间、数据转换和传送时间等的要求。3.5.3 数据管理能力要求需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。3.6 运行环境需求（需求主要为运行环境的限制，包括软硬件开发运行环境、系统开发工具、使用
9、的框架、设计结构、设计模式等）3.6.1 设备列出该软件运行时所需要的硬件设备，用途及配置。3.6.2 支持软件列出支持软件，包括要用到的操作系统、数据库管理系统、开发工具、测试支持软件等，注明名称、版本及供应商。用户基础软件配置：1 操作系统2 数据库管理系统3 相关软件工具4 其他软件开发工具：1 平台： 2 开发工具：测试环境：3.6.3 接口说明该软件同其他软件之间的接口、数据通信协议等。3.7 灵活性需求（需求主要为运行环境的限制，包括软硬件开发运行环境、系统开发工具、使用的框架、设计结构、设计模式等）需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的
10、测试环境能否满足要求等；说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：l 操作方式上的变化；l 运行环境的变化；l 同其他软件的接口的变化；l 精度和有效时限的变化。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.8 可靠性要求（需求主要包括最长无故障时间、系统备份与恢复、监控与报警，包括技术支持方面，如日志的记录、错误的信息提示、在线帮助、管理工具与界面等等）需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；对系统在投入运行后，不发生故障的概率，按实际的运行环境提出要求。列出可能的软件
11、、硬件故障以及所产生的后果并列出对故障的处理的要求。3.9 界面需求需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；此处主要指用户有特别要求的操作介面，一般与具体的功能项相联系。可综合描述整个系统和各项功能操作时的介面设计需求。也可以先罗列介面设计的总的需求（如直观、易学），然后择其要者再分节介绍。3.10 故障处理要求需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；硬件故障：1）工作站硬件故障： 2）通讯故障：3）文件服务器硬件故障：4）数据服务器硬件故障：软件故障:1）前台应
12、用程序故障： 2）后台服务器故障：3.11 安全性要求（需求主要包括数据安全，传输安全、认证的问题、系统相互授信、权限的管理、业务的安全放在功能性需求中）需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；数据保密、用户权限、流程控制等方面的要求。3.12 质量要求对于本部分要求的一个定量描述可以是：每千行代码的错误率；在软件发布时可以允许存在的已知Bug比率等；也可以通过其他可以定量分析的指标论述本软件需要达到的质量属性；3.13 与其他系统的集成要求（需求主要包括在与其他系统配合、整合过程中的特定要求）需求来源：需求的可测试性描述：（对于新需求）描述测试的要点：如值的范围、包括现有的测试环境能否满足要求等；如果设计与其他系统的集成，在此列明对于其他需求的一些前提假设条件。3.14 其他专门要求（需求主要为一些法律性相关的需求，包括文档、版权、商标以及其他必须明确的软件要求）如：用户对安全保密的要求、用户界面要求、对使用方便的要求、对可维护性、可补充性、易读性、运行环境可转换性的特殊要求等。4 验收与交付4.1 最终交付的工作产品4.2 验收准则4.3 最后交付的时间8第 8 页 共 8 页