一份合格的软件需求规格说明书的要求
合格的软件需求规格说明书
软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。
构造并编写软件需求规格说明，并使用户和其它读者能理解它牢记以下可读性的建议：
• 对节、小节和单个需求的号码编排必须一致。
• 在右边部分留下文本注释区。
• 允许不加限制地使用空格。
• 正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。
• 创建目录表和索引表有助于读者寻找所需的信息。
• 对所有图和表指定号码和标识号，并且可按号码进行查阅。
• 使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。
1.5 优秀需求具有的特性
怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（ Davis 1993；IEEE 1998）。让风险承担者从不同角度对S R S需求说明进行认真评审，能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的（尽管并不十分完美）需求文档，同时也会开发出更好的产品。
1.5.1 需求说明的特征
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。
3. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。
5. 划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制
6. 无二义性
对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。
7. 可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。
1.5.2 需求规格说明的特点
1. 完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用T B D (“待确定” )作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的T B D项。
2. 一致性
一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
3. 可修改性
在必要时或为维护每一需求变更历史记录时，应该修订S R S。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在S R S中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4. 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，而不是大段大段的叙述。
一份合格的软件需求规格说明书的要求相关推荐
- 给我一份软件需求规格说明书模板
软件需求规格说明书模板一般由以下几个部分组成:1.背景和范围:2.产品概述:3.功能和性能要求:4.界面要求:5.安全性和可靠性要求:6.可用性要求:7.可维护性要求:8.技术架构要求:9.兼容性要求 ...
- [文档] 软件需求规格说明书
软件需求规格说明书 1 范围 1.1 标识 本条应描述本文档所适用系统和软件的完整标识,适用时,包括其标识号.名称.缩略名.版本号 和发布号. 1.2 系统概述 本条应概述文档适用的系统和软件的用途: ...
- No.7软件需求规格说明书及UML
软件需求规格说明书(SRS)是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础. 软件需求规格说明书 国家标准BG/T 8567 ...
- 软件测试（测试用例、配置管理、bug、软件需求规格说明书、需求）
什么是软件测试 软件测试是不是就是找bug? 软件测试就是证明软件不存在错误的过程. 软件测试就是为了证明程序能够正确运行. 测试与调试的区别: 目的不同. 测试的任务是发现程序中的缺陷. 调试的任务 ...
- 软件需求规格说明书通用模版_通用需求挑战和机遇
软件需求规格说明书通用模版 When developing applications there will be requirements that are needed on more than o ...
- 【软件测试】导致软件缺陷的最大原因是软件需求规格说明书
导致软件缺陷的最大原因是软件需求规格说明书. 因为软件缺陷产生的原因有很多,典型的原因如下: 软件本身的复杂性 开发人员的问题 需求的变化 进度的压力 对文档不重视 沟通不畅 偏差的累积 各种来源导致 ...
- 软件需求工程 高校教学平台 软件需求规格说明书 part 1 （重点！！！）
点击查看 软件需求工程 高校教学平台 卷首语 文章目录 引言 编写目的 项目背景 预期的读者和阅读建议 预期读者 阅读建议 参考资料 总体描述 产品基本信息 产品前景 用户类及其特征 产品功能概述 用 ...
- 如何写《软件需求规格说明书》
转载自:https://www.jianshu.com/p/f9bcf52f4321 一.任务突然从天而降 自己维护一个终端一年多,今天主管突然要求补写一下<软件需求规格说明书>,有些傻眼 ...
- 软件需求规格说明书--文档模板
{ 产品名称} 软件需求规格说明书 编 写 人 : 编写日期 : 年 月 日 文档修订记录 版本编号 说明:如形成文件.变更内容 ...
最新文章
- 多线程学习笔记一之内置锁
- 虚拟化服务器监控,监控服务器虚拟化软件
- ef mysql modelfirst_Entity Framework(EF的Model First方法)
- T-SQL :SQL Server 定义数据完整性 5大约束
- 创新的迷思——2019 Microsoft Hackathon 苏州站回顾
- c语言中 数组 左移,如何将一个数组的元素循环左移？
- 如何让apache支持php,Apache怎么才能支持PHP程序？
- linux系统编程 -- 僵尸进程 孤儿进程
- table td 纵向求和
- 第一课：ASP.NET Core入门之简单快速搭建ASP.NET Core项目结构
- Android涂鸦画板原理详解——从初级到高级（一）
- UVA-12304 测试圆相关模板
- BUUCTF之[Zer0pts2020]Can you guess it? basename函数绕过
- 圣思园张龙-Java SE 第三讲（原生数据类型使用陷阱 Pitfall of Primitive Data Type）
- 2021年职业院校技能大赛“网络安全”项目江西省A模块
- 2021祥云杯 CTF pwn解 wp
- 2020年中国专用汽车行业发展现状分析，物流类专用车比重不断增加「图」
- Flink 入门实战之一HelloWord
- 2021年西式面点师（中级）复审考试及西式面点师（中级）模拟考试
- 那些年，我们一起写过的单例模式