软件需求规格说明指导书模版.docx

软件需求规格说明书模版文件改变统计单版本编号*改变状态简明说明变更人变更日期同意人同意日期*改变状态：A增加，M修改，D删除文件同意单职务签字日期1. 引言提出对软件需求规格说明书纵览，帮助读者了解文档怎样编写而且怎样阅读和解释。1.1 编写目标对产品（也可能是项目，不过我们统称为产品）进行定义，在该文档中详尽说明这个产品软件需求，包含修正或发行版本号。假如这个软件需求规格说明书只和整个系统一部分相关，那么只定义文档中说明部分或子系统。1.2 文档约定描述编写文档时所采取标准或排版约定，包含正文风格、提醒区或关键符号。比如，说明高层需求优先级是否能够被其全部细化需求所继承，或每个需求陈说是否全部有优先级。1.3 预期读者和阅读提议列举软件需求规格说明书所针正确不一样读者，比如开发人员、项目经理、营销人员、用户、测试人员等。描述文档中剩下部分内容及其组织结构。提出最适合每一类型读者阅读文档提议。1.4 产品范围提供对指定软件及其目标简短描述，包含利益和目标。把软件和企业目标或业务策略相联络。能够参考项目范围文档，而不是将其内容复制到这里。1.5 参考资料列举编写软件需求规格说明书时所参考资料或其它起源。可能包含用户界面风格指导、协议、标准、系统需求规格说明书、用户需求、相关产品软件需求规格说明书。这里应该给出具体信息，包含标题名称、作者、版本号、日期、出版单位或资料起源，以方便读者查阅这些文件。2. 综合描述这一部分概述了正在定义产品和它所运行环境、使用产品用户和已知限制、假设和依靠。2.1 产品前景描述软件需求规格说明书中所定义产品背景和起源。说明该产品是否是产品系列中下一个组员，是否是成熟产品所改善下一代产品、是否是现有应用程序替换品，或是否是一个全新产品。假如软件需求规格说明书定义了大系统一个组成部分，那么就要说明这部分软件是怎样和整个系统相关联，而且要定义出二者之间接口。提议使用系统结构图或实体关系图表示。2.2 产品功效概述产品所含相关键功效，具体内容在第4节描述，所以这里只需要概括总结，比如用列表方法给出。很好地组织产品功效，使每个读者全部易于了解。用图形表示关键需求分组和它们之间联络。提议使用数据步骤图（DFD）顶层图或类图来实现图形化。2.3 用户类和特征确定可能使用该产品不一样用户类并描述它们相关特征。有部分需求可能只和特定用户类相关。将该产品关键用户类和那些不太关键用户类区分开。2.4 运行环境描述软件运行环境，包含硬件平台、操作系统和版本，还有其它软件组件或和其共存应用程序。2.5 设计和实现上限制确定影响开发人员自由选择问题，并说明这些问题为何成为一个限制。可能限制包含：w 必需使用或避免特定技术、工具、编程语言、数据库；w 经费、进度、资源等方面限制；w 所要求开发规范或标准；w 企业策略、政府法规或工业标准；w 硬件限制，比如定时需求或存放器限制；w 数据转换格式标准。w 其它。2.6 假设和依靠列举出在对软件需求规格说明书影响需求陈说假设原因。可能包含计划要用商业组件或相关开发或运行环境问题。你可能认为产品将符合一个特殊用户界面设计约定，不过另外一个分析员却不这么认为。假如这些假设不正确、不一致或被更改，全部会使项目受到影响。另外，确定项目对外部原因存在依靠。比如，假如你计划把其它项目开发组件集成到系统中，那么你就要依靠哪个项目能否按时提供正确组件。假如这些依靠已经统计到其它文档（如项目计划）中了，那么在此就能够参考其它文档。2.7 关键点说明本软件需求规格说明书中关键点（比如：关键功效、关键算法和所包含关键技术等）。3. 外部接口需求确定能够确保新产品和外部组件正确连接需求。关联图表示了高层抽象外部接口。需要把对接口数据和控制组件具体描述写入数据字典中。假如产品不一样部分有不一样外部接口，那么应该把这些外部接口具体要求并入到这一部分实例中。3.1 用户界面陈说所需要用户界面软件组件。描述每个用户界面逻辑特征。以下是可能要包含部分特征：w 将要采取图形用户界面标准或产品系列风格；w 屏幕布局或处理方案限制；w 将出现在每个屏幕标准按钮、功效或导航链接；w 快捷键；w 错误信息显示标准。对于用户界面细节，比如特定对话框布局，提议写入一个独立用户界面规格说明中，不要写入软件需求规格说明书中。3.2 硬件接口描述系统中软件和硬件每个接口特征。可能包含支持硬件类型、软硬件之间交流数据和控制信息性质和所使用通信协议。3.3 软件接口描述产品和其它外部组件（由名字和版本识别）连接，包含数据库、操作系统、工具、库和集成商业组件。明确并描述在软件组件之间交换数据或信息目标，描述所需要服务和内部组件通信性质，确定将在组件之间共享数据。假如必需用一个特殊方法来实现数据共享机制，那么就必需把它定义为一个实现上限制。3.4 通信接口描述和产品所使用通信功效相关需求，包含电子邮件、WEB浏览器、网络通信标准或协议及电子表格等，定义相关信息格式、要求通信安全或加密问题、数据传输速率和同时通信机制。4. 功效需求4.1 功效分类将功效性需求先粗分再细分，下表中 Feature A, Function A.1等符号应该被替换成有含义名称。也能够用功效结构图表示功效类别功效Feature AFunction A.1Function A.2Feature BFunction B.1Function B.24.2 系统特征Feature A 4.2.1 说明和优先级提出对该系统特征简短说明并指出该特征优先级是高、中还是低。4.2.2 功效需求具体列出和该特征相关功效需求。这些是必需提交给用户软件功效，使用户能够使用所提供特征实施服务或使用所指定用例实施任务。描述产品怎样响应可预知犯错条件或非法输入或动作。4.2.2.1 功效 function A.1（1）说明本功效简明说明（2）角色 本功效实施人员（3）前置条件 该功效开启前提条件（4）输入描述本功效输入信息（包含需要访问存放信息）。（5）过程对本功效将做什么进行具体描述。（6）输出描述本功效输出信息（包含需要访问存放信息）。（7）后置条件 该功效结束退出条件（8）业务规则列举出和该功效相关操作规则。比如什么人在特定环境下能够进行何种操作。4.2.2.2 function A.1 图书借阅（1）说明借阅人经过此功效向系统查询并提交借书请求（2）角色 借阅人（3）前置条件w 借阅人借阅证件在使用期内w 借阅人没有逾期未归还图书（4）输入借阅证（5）过程主过程描述1用户用借阅证提供帐号登录系统，系统显示我图书馆界面2.用户选择查询图书，系统显示查询界面3.用户按书名、作者、出版社查询，系统显示查询结果4.用户可单选或多选书本，并确定借阅。系统显示确定借阅图书清单。5.用户选择确定借阅，系统显示借阅定单及费用6用户选择提交定单，系统显示提交结果和定单号7.系统实施后置条件分支过程描述2.1.1用户选择查看原有定单，系统实施4;4.1.1用户可单选或多选书本，放入借书篮，系统显示借书篮现有内容4.1.2.1.1用户选择继续借书，系统实施2；4.1.2.2.1用户选择提交借书篮，系统实施44.2.1 用户选择放弃，系统实施2；6.1.1用户选择保留定单，系统保留并实施1；6.2.1用户选择放弃，系统实施1；异常过程描述1.1.1借阅证已过期，拒绝登录，结束1.2.1借阅人有逾期未归还书本，开启“归还图书”功效5.1.1用户余额不足，系统显示余额和所需金额5.1.2.1.1用户选择续费，开启“交纳借阅费”功效5.1.2.2.1用户选择放弃，系统实施1（6）输出费用统计借阅定单（7）后置条件w 创建借书定单w 更新借阅人借阅统计（8）业务规则每次每人最少选择一本,至多选择三本4.3 系统特征Feature B 5. 非功效需求5.1 性能需求叙述不一样应用领域对产品性能需求，并解释它们原理以帮助开发人员做出合理设计选择。确定相互合作用户数或所支持操作、响应时间和和实时系统时间关系；还要定义容量需求，比如存放器和磁盘空间需求或存放在数据库中表最大行数。也可能需要针对每个功效需求或特征分别陈说其性能需求，而不是把它们集中在一起陈说。比如：“在运行WINDOWS 450MHZ Pentium II 计算机上，当系统最少有50%空闲资源时，95%目录数据库查询必需在两秒内完成”。5.2 安全性需求陈说和系统安全性、完整性或私人问题相关需求，这些问题将会影响到产品使用和产品所创建或使用数据保护。明确产品必需满足安全性或保密性策略。一个软件系统安全需求范例以下：“每个用户在第一次登录以后，必需更改她最初登录密码。最初登录密码不能重用。”5.3 软件质量属性详尽陈说和用户或开发人员至关关键质量特征。这些特征必需是确定、定量并可验证。最少应指明不一样属性相对侧关键，比如易用程度优于易学程度，或可移植性优于有效性。5.4 其它需求定义至今未出现需求。比如国际化需求、法律上需求、相关操作、管理、维护、安装、配置、开启、关闭、修复、容错、登录、监控等等方面需求。说明本产品在可使用性、可维护性、可移植性、可靠性和安全性等方面要求。6. 数据字典6.1 实体关系图6.2 实体定义指出数据项名、定义、项结构组成、项范围、项类型。实体名称Be_图书实体描述每本图书全部经有上架，预定，借出，返回待查和下架多个状态，具体请参看图书状态图属性名称类型精度说明(属性业务含义及业务规则)图书编号字符12图书类别编号(3位)+图书购入年份(4位)+流水号(5)位图书分类字符3图书分类名称字符100书本封面名称作者字符20书籍作者出版社字符100书籍标明出版社出版日期日期书籍标明出版日期版本信息字符100书籍标明出版社介绍字符1000书籍内容介绍，上架时录入状态字符1书籍状态，请参看图书状态图7. 业务规则和业务算法7.1 业务规则列举出相关产品全部操作规则。比如什么人在特定环境下能够进行何种操作。这些规则不是功效需求，但它们能够暗示一些功效需求实施这些规则。业务规则范例以下：“只有持有管理员密码用户才能实施100元以上退款操作”。借出规则说明: 读者已借书数未超出最大借书数、该书有库存，而且该读者拥有借阅该书权限，则实施该操作。罚款规则说明：1.超期罚款：超期天数超期罚款率。2.丢失罚款：图书价格丢失赔率7.2 算法说明用于实施系统计算功效公式和算法描述，类似于业务规则。如某神州行套餐计费标准说明。a.每个关键算法概况；b.用于每个关键算法具体公式。附录A：分析模型（也能够纳入 4功效需求章节中描述）包含或包含到相关分析模型位置，比如数据流图、类图、状态转换图等。顶层数据流图：第1层数据流图：第2层数据流图：附录B：待确定问题列表编辑一张在软件需求规格说明书中待确定问题列表，其中每一表项全部是编上号，方便跟踪调查。附录C：编写文档标准编写文档时，要求含有本规范要求全部条目假如某条目无内容，则填写“无”，并在可能情况下说明理由。必需时，可增加合适条目。编写优异需求文档没有现成固定方法，最好是依据经验进行。很多需求文档能够经过使用有效技术编写风格和使用用户术语而不是技术术语方法得以改善。你在编写需求文档时，应切记以下几点提议： 保持语句和段落简短； 采取主动语态表示方法； 语法正确，句子完整； 使用术语和词汇表中所定义术语一致； 避免模糊、主观术语如用户友好、轻易、简单、快速、有效、很多、最新技术、优越、可接收、健壮等等； 避免使用比较性词汇如提升、最大化、最小化、最好化等。定量说明所需要提升程度或说清部分参数能够接收最大值和最小值。含糊语句表示将引发需求不可验证。 因为需求编写是层次化，所以，能够把顶层不明确需求向低层具体分解，直到消除不明确性为止。编写具体需求文档，所带来益处是假如需求得到满足，那么用户目标也就达成了，不过不要让过于具体需求影响了设计。假如你能用不一样方法来满足需求，而且这种方法是可接收，那么需求具体程度也就足够了。然而，假如评审需求规格说明书设计人员对用户意图还不甚了解，那么就需要增加额外说明，以降低因为误解而产生返工风险。 需求文档编写人员总是努力争取寻求到恰如其分需求具体程度。一个有益标准就是编写单个可测试需求文档。假如你想出部分相关测试用例能够验证这个需求，那么就达成了合理具体程度。假如你预想测试很多而且很分散，那么就要将部分集合在一起需求分离开。 必需以相同具体程度编写每个需求文档。 不应该把多个需求集中在一个冗长叙述段落中。在需求中，诸如“和”，“或”之类连词就表明了该部分集中了多个需求。不要在需求说明中使用“和/或”，“等等”之类连词。 不应该出现需求冗余。