软件需求规范手册模板软件需求业务流程图

1. 诚信任何必要的要求信息都不能省略.

遗漏的要求将很难发现.

关注用户的任务而不是系统功能将帮助您避免不完整.

如果您知道缺少一条信息，请使用TBD（“待定”）作为标准指示符，以指示缺少该信息.

在开始开发之前，必须解决需求中的所有待定项目.

2. 一致性一致性是指它不与其他软件需求或高层（系统，业务）需求相矛盾.

在开发之前必须解决所有需求之间的矛盾.

只有进行调查和研究，我们才能知道某个要求是否确实正确.

3. 可修改性必要时应修订SRS，或保留每项要求的变更历史.

这要求每个需求都应单独标记，并与其他需求区分开，以免产生歧义.

每个要求只能在SRS中出现一次.

进行此类更改时很容易保持一致性.

此外软件规格需求说明书，使用目录，索引和交叉引用列表将使修改软件需求规范更加容易.

4. 可追溯性

1. 用户的需求规格是用户的需求，需要与用户确认.

需求规范是系统需求主要是内部的.

用户需求也用于需求管理中.

2. 优点: 用户的语言和设计者的语言不同，因此需要针对不同人员的文档.

缺点: 层越多，信息丢失越多，被误解的可能性越大.

权衡的结果: 基本上取决于项目的大小.

3. 这主要取决于项目管理所采用的标准.

如果CMMI需要它，则取消敏捷.

4. 如果要保存一个，则更倾向于编写用户要求，因为在系统上工作时，必须始终了解用户的想法以及要解决的问题. 要求和规格相对不重要. 您可以使用各种程序，这是用户不关心的.

如果用户的需求被误解了，则软件规范将使用户在放置文本框的位置签名，而布局毫无意义.

“需求管理”文档通常包含需求管理计划，需求清单，需求跟踪表（包括矩阵图），需求变更状态跟踪表以及用于支持输出的指南文件.

“需求开发”文档通常包含需求规范，需求规范清单，需求开发指南等.

需求分析报告: 通常，对于特定市场或客户群，类似于研究报告，重点是反映产品需要满足的功能，以及重点和热点.

需求规范: 它是基于与现场实际客户的沟通来组织客户的需求. CMMI中有一个标准模板，并且从客户的角度着眼于产品功能.

需求规范: 它从业务规则开始，并且细节偏向于软件的轮廓设计.

从开发和测试的角度讲产品功能，它包含原型接口，业务接口，活动图等.

...

在标准化软件开发过程中编写“需求规范”，使其成为整个开发工作的基础.

2适用范围本规范适用于团体开发项目的（软件）“需求规范”的编译.

3个编写内容的技巧1简介3.1.1背景说明解释正在开发的软件的名称，任务作者，用户以及实现该软件的计算机网络.

3.1.2参考资料列出了相关资料（名称，出版日期，出版单位，作者等）.

3.1.3术语和缩写列出了本文档中使用的特定术语的定义以及术语的缩写.

3.2软件概述3.2.1目标软件开发的意图，应用目标，作用范围以及需要说明的背景材料.

3.2.2系统模型图说明了软件的所有功能及其关系和数据传输.

3.2.3假设和约束条件解释影响软件开发，操作环境和系统功能（例如预测错误类型的能力）的某些假设和约束条件.

3.3详细要求详细描述此软件系统的功能要求和性能要求.

3.3.1功能要求对于系统中的每个功能，都需要详细的描述（图片或文字）.

概述描述功能名称，目标和功能.

输入输入此功能的信息.

处理描述函数的功能，如何处理输入信息并将其转换为输出信息.

输出列出内部生成的文件.

3.3.2性能要求定量描述了此软件系统应满足的特定性能要求.

可以考虑以下内容: 3.3.2.1准确性描述了系统的准确性要求，例如: 数据的准确性要求.

数字计算的精度要求.

数据传输的误码率要求.

3.3.2.2时间特征解释了系统的时间特征要求，例如: 解决问题的时间.

查询和更新数据文件的响应时间.

系统各功能的顺序关系.

3.3.2.3灵活性描述了系统适应某些要求变化的能力，并指出了需要设计以适应这些变化的软件组件和过程.

3.3.2.4系统容量包括系统的设计容量和理论（计算）容量.

3.3.3输入和输出逐项说明每种输入和输出数据类型，并逐项说明特定的介质，格式，值范围等.

解释并给出必须标记的软件数据输出和控制输出的示例，包括硬拷贝报告（正常结果输出，状态输出和异常输出）以及图形或显示报告的说明.

3.3.4数据管理功能指示要管理的文件和记录的数量，表和文件的大小和规模，以及数据及其组件的存储需求应基于可预测的增长进行估算.

3.3.5故障处理列出了可能的软件和硬件故障，以及每种性能的后果以及对故障处理的要求.

3.4环境描述了开发的软件运行所需的环境.

3.4.1设备环境描述了运行软件系统所需的设备功能，例如处理器的型号和内存容量.

存储介质的数量.

通信网络（包括网络结构，线路速度和通信协议等的描述.

3.4.2支持软件环境列出了与要开发的软件配合使用的支持软件（包括名称，版本号和文件信息）. 如有必要，还应列出测试软件，并指出该软件，编译器，操作系统和数据管理系统使用的编程语言.

3.4.3接口说明此软件与其他软件之间的接口，数据通信协议等.

3.4.4其他说明本软件系统在安全性和保密性方面的要求以及用户对操作环境的易用性，可维护性，可扩展性，易读性，可靠性和可转换性的特殊要求.

首先，您需要了解为什么需要文档.

您必须了解文档与代码同等重要，这是开发人员的产物.

第二，您需要确定所使用的周期模型和开发方法.

不同的模型或方法将具有不同的文档要求. 这要求您自己定制它，直到适合您的开发团队为止. 不要忘记，该文档还用于提高开发效率和质量，并让开发人员编写过多内容. 无味的文档会降低效率.

同样，您必须制作一些文档模板，以清楚地说明文档的用途和结构.

最后，您可以填写它.

RUP需求描述文档模板1.0简介[介绍本文档的总体结构.

] 1.1目的[描述此软件需求规范的目的.

软件需求规范不仅需要完整描述系统的行为，还需要说明非功能需求，设计约束和其他相关因素.

] 1.2范围[对本需求说明文档所适用的项目/应用程序及其主要功能或其他子系统，相关用例模型以及受其影响的任何其他内容的简要介绍.

] 1.3定义，术语和缩写[详细的定义正确理解了本文档的相关术语，包括定义，首字母缩写词和首字母缩写词.

可以通过引用词汇表来解释.

] 1.4参考文献[描述本文档中引用的任何其他相关文件.

列出文件的标题，文件编号，日期和出版单位，并指明文件的来源.

] 1.5总结[描述本文档其余部分的内容和组织.

] 2.0说明[本节列出了影响产品和要求的一般因素，但无需列出特定要求. 只需描述需求的背景，这将在第3节中详细介绍，以促进对需求的理解.

这包括: 总体产品有效性，产品功能，用户特征，约束，假设和依赖性以及需求子集.

除了对产品或解决方案的描述之外，解释产品是或不是解决方案也特别重要.

] 2.1用例模型[如果使用了用例模型，本节概述了适用于本系统的用例模型或子模型，包括所有用例和角色的名称和简要说明，以及用例图和关系.

用例报告可以在此处作为附件引用.

] 2.2假设和依赖性[描述所有重要的技术可行性，子系统或组件的可用性，或可以作为本手册中所述软件基础的其他相关假设.

] 3.0需求说明[详细描述软件需求.

详细程度使设计师可以设计满足这些需求的系统；测试人员可以测试该系统是否真正满足这些需求.

在对用例进行建模时，这些需求是通过用例和其他可用补充文档捕获的.

] 3.1用例报告[用例模型通常定义系统的主要功能需求和一些非功能需求.

对于用例模型中的每个用例，都需要在此处引用或附加用例报告.

确保每个要求均已清楚标记.

] 3.2补充说明[描述用例中未包括的其他要求.

补充需求描述中应包含适用于该系统的特定需求描述或功能软件规格需求说明书，并进行重新提炼以充分详细地描述系统.

信息可以直接记录在本文档中，也可以作为单独的补充文档进行引用.

还要确保明确定义要求.

] 4.0辅助信息[辅助信息使此文档更易于使用.

这可以是目录，索引，附录，用例图，用户界面原型等的表.

如果包含附录，请明确指出该附录是否是要求的一部分.

]

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-266960-1.html