1 简介
1.1 目的
确定本文档中指定了软件要求的产品，包括修订或发布号。描述本 SRS 涵盖的产品范围，特别是当本 SRS 仅描述系统的一部分或单个子系统时。
1.2 文档约定
描述编写此 SRS 时遵循的任何标准或印刷惯例，例如具有特殊意义的字体或突出显示。 例如，说明是否假定更高级别需求的优先级 1由详细需求继承，或者每个需求陈述是否都有自己的优先级。
1.3 目标读者和阅读建议
描述文档针对的不同类型的读者，例如开发人员、项目经理、营销人员、用户、测试人员和文档编写者。 描述此 SRS 的其余部分包含的内容及其组织方式。建议阅读文档的顺序，从概述部分开始，然后阅读与每种读者类型最相关的部分。
1.4 产品范围
提供所指定软件及其用途的简短描述，包括相关优势、目标和目的。 将软件与公司目标或业务战略 2联系起来。如果有单独的愿景和范围文档，请参考它，而不是在此处重复其内容。
1.5 参考文献
列出此 SRS 引用的任何其他文档或网址。 这些可能包括用户界面风格指南、合同、标准、系统需求规范、用例文档或愿景和范围文档。 提供足够的信息，以便读者可以访问每个参考资料的副本，包括标题、作者、版本号、日期和来源或位置。
2 总体描述
2.1 产品视角
最近，社交媒体上有关用户的数据激增，这引起了人们对使用大数据和机器学习原理对这些数据进行情绪分析以了解人们的兴趣的极大兴趣。 这个项目打算执行相同的任务。这个项目与其他情绪分析工具的区别在于，它将根据主题标签而不是存储的档案对推文进行实时分析。
描述此 SRS 中指定的产品的背景和来源。例如，说明该产品是产品系列的后续成员、某些现有系统的替代品还是新的独立产品。 如果 SRS 定义了较大系统的组件，则将较大系统的要求与此软件的功能联系起来，并确定两者之间的接口。显示整个系统的主要组件、子系统互连和外部接口的简单图表可能会有所帮助。
2.2 产品功能
- 实时收集推文，即根据指定的主题标签从 Twitter 直播流中收集推文
- 从这些收集的推文中删除冗余信息。
- 将格式化的推文存储在 MongoDB 数据库中
- 对数据库中存储的推文执行情感分析，以对其性质进行分类，即积极、消极等。
- 使用机器学习算法来预测人们对该话题的“情绪”。
;总结产品必须执行或必须让用户执行的主要功能。 第 3 节将提供详细信息，因此这里只需要一个高级别的总结（例如项目符号列表）。 组织这些功能，使 SRS 的任何读者都能理解。相关需求的主要组及其关系的图片（例如顶级数据流 3程图或对象类图）通常很有效。
2.3 用户类别和特征
确定您预计会使用该产品的各种用户类别。 用户类别可以根据使用频率、使用的产品功能子集、技术专长、安全或权限级别、教育水平或经验进行区分。 描述每个用户类别的相关特征。某些要求可能只适用于某些用户类别。区分该产品最重要的用户类别和不太重要的用户类别。
2.4 运行环境
描述软件运行的环境，包括硬件平台、操作系统和版本，以及必须与之和平共处的任何其他软件组件或应用程序。
2.5 设计和实施约束
描述任何会限制开发人员可用选项的项目或问题。 这些可能包括：公司或监管政策；硬件限制（时间要求、内存要求）；与其他应用程序的接口；要使用的特定技术、工具和数据库；并行操作；语言要求；通信协议；安全考虑；设计惯例或编程标准（例如，如果客户的组织将负责维护交付的软件）。
2.6 用户文档
列出将随软件一起交付的用户文档组件（例如用户手册、在线帮助和教程）。确定任何已知的用户文档交付格式或标准。
2.7 设和依赖关系
列出可能影响 SRS 中所述要求的任何假设因素（而不是已知事实）。这些因素可能包括您计划使用的第三方或商业组件、开发或操作环境方面的问题或约束。如果这些假设不正确、未共享或发生变化，则项目可能会受到影响。此外，还要确定项目对外部因素的任何依赖关系，例如您打算从其他项目重用的软件组件，除非它们已在其他地方记录（例如，在愿景和范围文档或项目计划中）。
3 外部接口要求
3.1 用户界面
描述软件产品与用户之间每个界面的逻辑特征。这可能包括示例屏幕图像、要遵循的任何 GUI 标准或产品系列样式指南、屏幕布局约束、每个屏幕上显示的标准按钮和功能（例如帮助）、键盘快捷键、错误消息显示标准等。定义需要用户界面的软件组件。用户界面设计的详细信息应记录在单独的用户界面规范中。
3.2 硬件接口
描述软件产品与系统硬件组件之间每个接口的逻辑和物理特性。这可能包括支持的设备类型、软件与硬件之间的数据和控制交互的性质以及要使用的通信协议。
3.3 软件接口
描述该产品与其他特定软件组件（名称和版本）之间的连接，包括数据库、操作系统、工具、库和集成商业组件。识别进入和输出系统的数据项或消息，并描述每个数据的用途。描述所需的服务和通信的性质。请参阅描述详细应用程序编程接口协议的文档。识别将在软件组件之间共享的数据。如果必须以特定方式实现数据共享机制（例如，在多任务操作系统中使用全局数据区），请将此指定为实现约束。
3.4 通信接口
描述与该产品所需的任何通信功能相关的要求，包括电子邮件、Web 浏览器、网络服务器通信协议、电子表格等。定义任何相关的消息格式。确定将使用的任何通信标准，例如 FTP 或 HTTP。指定任何通信安全或加密问题、数据传输速率和同步机制。
4 系统特点
此模板说明了如何按系统功能（产品提供的主要服务）组织产品的功能需求。您可能希望按用例、操作模式、用户类别、对象类别、功能层次结构或这些的组合来组织此部分，只要对您的产品而言最合理即可。
4.1 系统特点1
不要真的说“系统功能 1”。只需用几个词说明功能名称。
4.1.1 描述和优先级
提供该功能的简短描述，并指出其优先级是高、中还是低。 您还可以包括特定优先级组件评级，例如好处、惩罚、成本和风险（每个评级都按相对等级从最低 1 到最高 9 进行）。
4.1.2 刺激/反应序列
列出刺激此功能定义的行为的用户操作和系统响应序列。这些将对应于与用例相关的对话元素。
4.1.3 功能要求
逐项列出与此功能相关的详细功能要求。这些是用户执行功能提供的服务或执行用例所必须具备的软件功能。包括产品应如何响应预期的错误情况或无效输入。要求应简洁、完整、明确、可验证且必要。使用“TBD”作为占位符来表示尚无必要信息。
每个需求都应该用一个序列号或某种有意义的标签来唯一地标识。
- 要求-1：
- 要求-2：
4.2 系统特征2（等等）
5 其他非功能性需求
5.1 性能要求
如果产品在各种情况下都有性能要求，请在此处说明并解释其理由，以帮助开发人员理解意图并做出合适的设计选择。 指定实时系统的时序关系。尽可能具体地说明这些要求。您可能需要针对单个功能要求或特性说明性能要求。
5.2 安全要求
指定与使用产品可能造成的损失、损坏或伤害有关的要求。 定义必须采取的任何保障措施或行动，以及必须防止的行动。参考任何外部政策或法规，这些政策或法规规定了影响产品设计或使用的安全问题。 定义必须满足的任何安全认证。
5.3 安全要求
指定有关使用产品或保护产品所用或创建的数据的安全或隐私问题的任何要求。 定义任何用户身份验证要求。参考任何包含影响产品的安全问题的外部政策或法规。定义必须满足的任何安全或隐私认证。
5.4 软件质量属性
指定对客户或开发人员来说重要的产品的其他质量特性。 需要考虑的一些特性包括：适应性、可用性、正确性、灵活性、互操作性、可维护性、可移植性、可靠性、可重用性、稳健性、可测试性和易用性。 尽可能将这些特性写得具体、定量且可验证。至少，明确各种属性的相对偏好，例如易用性优于易学性。
5.5 业务规则
列出有关产品的任何操作原则，例如在特定情况下哪些个人或角色 4可以执行哪些功能。这些本身不是功能要求，但它们可能暗示某些功能要求来执行规则。
6 其他要求
定义 SRS 中未涵盖的任何其他要求。这可能包括数据库要求、国际化要求、法律要求、项目的重用目标等。添加与项目相关的任何新部分。
7 附录
7.1 附录 A：词汇表
定义正确解释 SRS 所需的所有术语，包括首字母缩略词和缩写。 您可能希望构建一个涵盖多个项目或整个组织的单独词汇表 5，并在每个 SRS 中仅包含特定于单个项目的术语。
7.2 附录 B：分析模型
可选地，包括任何相关的分析模型，例如数据流图、类图、状态转换图或实体关系图。
7.3 附录 C：待定清单
收集 SRS 中剩余的 TBD（待确定）参考的编号列表，以便可以跟踪它们直至结束。