cs330软件工程
软件需求规范（SRS）模板
要作为文档的一部分保留的项目是粗体的，说明性注释为斜体文本。使用纯文本，您可以在其中插入关于项目的措辞。
此文件中的文档注释大纲指定软件的要求，适应从IEEE软件需求规格说明书（STD 830-1993）。
裁缝这您的需要，删除解释意见，因为你走。如果您决定省略一节，请保留标题，但插入一条注释，说明为什么省略数据。
1.介绍
软件需求规格（SRS）文档的以下小节应提供整个SRS的概述。你写这篇文章时要记住的是你是 告诉系统必须做什么-这样设计者最终可以构建它。不要使用此文档进行设计！！！
1.1目的
确定SRS及其预期受众的目的。在本节中，描述特定SRS的目的并指定SRS的预期用户。
1.2适用范围
在本款：
（1）识别由名称产生的软件产品
（2）解释软件产品将如何，如果必要的话，将不做
（3）描述指定的软件的应用，包括相关的利益，目标和目标
（4）如果它们存在，则在更高级别的规范中与类似语句一致
这应该是一个行政级别的总结。不要在这里列举整个需求清单。
1.3定义，缩写和缩写
提供正确解释SRS所需的所有术语、缩写和缩写的定义。此信息可由SRS中的一个或多个附录提供参考或参考 文件效力。此信息可提供参考附录。
1.4参考文献
在本款：
（1）提供SRS中其他地方引用的所有文件的完整列表
（2）按标题、报告编号（如适用）、日期及出版机构确定每份文件指定可以获得引用的源。
此信息可由附录或其他文档提供。如果您的应用程序使用特定的协议或RFC的，那么参考他们在这里，所以设计师知道在哪里找到他们 。
2.总体描述
描述影响产品的一般因素及其要求。本节不规定具体要求。相反，它提供了一个背景，这些要求，这是定义 D在第3节，使他们更容易理解。从某种意义上说，本节讲述了简单的英语消费需求。第三部分将包含一个规范的书面 对于开发商。
2.1产品的视角
将产品与其他相关产品透视。如果产品是独立的，完全独立的，应该在这里说明。如果SRS定义了一个产品 一个更大的系统中，经常会发生，那么本款涉及的较大的系统的要求，对软件的功能和标识系统和软件之间的接口 重新.如果您正在建立一个真正的系统，比较它的相似性和差异，在市场上的其他系统。如果你正在做一个研究性的项目，那么相关的研究和系统相比 干你打算建。
显示较大系统、互连和外部接口的主要组成部分的框图可以有所帮助。这不是一个设计或建筑图片。更多的是提供上下文 ，特别是如果你的系统将与外部行动者互动。您正在建设的系统应该显示为一个黑盒子。让设计文件呈现内部。
下面的小节描述了软件如何在各种约束条件下运行。
2.2产品功能
提供软件将执行的主要功能的摘要。有时功能总结，这部分是必要的，可以直接从更高级别的指定部分 性（如果存在的话），分配特定的功能的软件产品。
为了清晰：
该功能应组织的方式，使功能列表的可理解的客户或任何人阅读文件的第一次。
文本或图形的方法可以用来显示不同的功能和它们之间的关系。这样的图表不是为了显示产品的设计，而是简单地显示了逻辑关系 变量之间的。
这描述了系统的功能，在客户的语言。具体设计的系统要做什么？图纸 很好，但是请记住这是一个系统需要做什么的描述，而不是你将如何构建它。（在设计文档中）。
2.3用户的特点
描述产品的预期用户的一般特征，包括教育程度、经验和技术专长。不要陈述具体要求，而是提供 某些特定要求后来在第3节中指定的原因。
你的潜在用户群对设计有什么影响？他们的经验和舒适与技术将推动UI设计。其他特性可能会影响内部设计 系统的。
2.4约束
提供任何限制开发人员选项的其他项目的一般说明。这些可以包括：
（1）监管政策
（2）硬件限制（例如，信号时序要求）
（3）与其他应用程序的接口
（4）并联操作
（5）审计职能
（6）控制功能
（7）高阶语言要求
（8）信号的握手协议（例如，xon-xoff，ack-nack）
（9）可靠性要求
（10）申请的临界性
（11）安全及安全方面的考虑
本节捕获客户语言中的非功能性需求。一个更正式的介绍将发生在第3节。
2.5假设与依赖
列出影响SRS中规定的每个因素。这些因素不是软件上的设计限制，而是对它们的任何改变，都会影响需求 在SRS。例如，一个假设可能是特定的操作系统将在软件产品指定的硬件上可用。如果，事实上，操作系统不可用 标签，SRS会发生相应的变化。
这部分是所有其他可能影响系统的设计，不适合在任何类别以上。
3.变更管理流程
识别变更管理流程，用于识别、记录、评估和更新SRS以反映项目范围和需求的变化。你打算如何控制变化的要求 的要求。顾客可以打电话要求新的东西吗？你的团队必须达成共识吗？如何改变需求提交给团队？正式书面，电子邮件或电话 电话吗？
4.文件的批准
确定SRS文档的审批。批准人姓名、签名和日期，应使用。支持信息，支持信息使SRS更容易使用。它包括：表的内容和指数。
5.附录
附录并不总是被视为实际需求规范的一部分，并不总是必要的。它们可能包括：
（一）样本I/O格式、成本分析研究、用户调查结果
（二）支持或背景资料，可以帮助读者的SRS
（三）软件要解决的问题的描述
（四）守则和媒体的特殊包装指示，以满足安全，出口，初步加载，或其他要求
当附录包括，SRS应明确说明是否附录被视为需求的一部分。
