简介
目的
这部分要描述文档的目的。应该指明读者。说明本需求文档描述了哪个产品的软件需求和设计。
范围
本节应描述文档所包括和不包括的内容。
总体概述
本节描述影响产品和产品需求的一般因素。由以下4个部分构成。有一点需说明的是本节不描述具体的需求，只是使那些将要描述的具体需求更易于理解。
软件概述
项目介绍
描述本软件需求所描述的项目的背景。例如：本项目是一系列版本中的一个，或者是替代某个已经存在的系统，还是一个新的独立的项目。
产品环境介绍
描述的是本产品与其它产品或项目所组成的整体环境。
1.如果本产品是独立的并完全自我包含，在此说明这一点。
2.如果SRS定义的产品是更大的系统或项目的组件（此种情形经常发生），那么应：
A. 描述此大系统或项目每个组件的功能，并且标识接口。
B. 确定本软件产品主要外部接口。（注意：在此部分并不进行这些接口的详细描述；对这些接口的详细描述在SRS的其它 部分提供。）
C. 描述相关产品硬件和所使用的外部设备。（注意：这只是概述性描述。）
通过方块图来描述大系统或项目的主要组件，互连性以及外部接口将是非常有帮助的。本部分不应提出一个具体的设计解决方案或对解决方案的具体设计约束（具体设计约束将在具体需求章节中描述）。本部分内容是产生设计约束的基础。
软件功能
概述软件的必须实现的和通过用户操作实现的主要功能。这里只需要进行简要描述（例如目录列表），详细描述在详细需求部分描述。对需求功能进行组织，以便于读者理解，并能指导后续的设计和测试。可以用图表来表示主要需求群组之间的关系，例如：高层的数据流图，面向对象的分析等。
有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格（如果存在的话）直接引用。
本节不应描述具体需求。但本节内容是具体需求章节的基础。
设计约束
描述可能限制开发人员选择的事项，特性有哪些能力不支持需要描述
假设和依赖关系
描述清楚本迭代的依赖
特性1需求分析&设计
整体介绍
功能需求
功能需求1
用简短词汇作为功能需求名，不要用"功能需求（1）"作为功能名
- 介绍
逐条列出与本特性相关的功能需求。包括项目如何响应预期的错误输入，非法条件和无效输入。需求应该简明，完整，不含糊，可验证，必要的。当需要的信息不确定的时候使用"待定"。
- 输入
本子段落应包含下列内容：
A. 对该功能所有输入数据的详细描述，包括：
输入来源
数量
度量单位
时间要求
包含精度和容忍度的有效输入范围
B. 在适当的地方提供的对接口规格或接口控制文档的参考。
- 处理
本子段落应描述对输入数据所执行的所有操作和如何获得输出的过程。这包括下列规格：
A. 输入数据的有效性检测。
B. 操作的确切次序，包括各事件的时序。
C. 对异常情况的回应，例如：
溢出
通信失败
错误处理
D. 用于把系统输入转换到相应输出的任何方法（诸如方程式，数学算法，逻辑操作）。例如，这可能描述下列方面：
对工资单里代扣所得税的计算公式。
用于气象预报的气象模型。
E. 对输出数据的有效性检测。
- 输出
本子段落应包含：
A. 对该功能所有输出数据的详细描述，这个描述包括：
输出的到何处（如打印机，文件）
数量
度量单位
时序
包含精确度和容忍度的有效输出范围
对非法值的处理
错误消息
B. 在适当的地方提供对接口规格或接口控制文档的参考。
此外，对那些需求集中在输入/输出行为的系统，SRS应描述所有重要的输入/输出行为及输入输出对的次序。对一个需要记忆其行为以根据输入和过去的行为进行反应的系统，输入输出对的次序是要求的；这种功能行为就类似于有限状态机。
功能需求2
非功能需求
可维护性
可测试性
可移植性
可靠性
平台化要求
GE是 onetrack部件，任何地方都不允许区分芯片，但是部分特性涉及E2E交付时，如涉及底层接口调用，如RTS，需要确认清楚RTS接口在各个平台下的支持能力
特性交叉分析
性能
模型编译时长
所有编译时涉及的代码都需要评估新增代码对性能的影响（目前很多客户不再同意从第二次迭代开始算耗时，所以端到端的每个阶段都很重要），识别到的几个关键阶段：optimizeStage1、optimizeStage2、build、loadmodelonline四个阶段。涉及上述四个阶段的代码，3.4.1必填影响评估。
OM大小和加载占用内存
加载占用内存需要考虑对内存比较敏感的场景，新增特性原则上不应该导致内存上涨（实际也属于兼容性问题），如果涉及新增特性需要额外占用内存的，原则上默认关闭
执行性能
所有执行态涉及的代码都需要评估新增代码对性能的影响，影响需要评估到ns级别（小到string操作，打点等），图模式下动态shape GE会直接参与每个算子的调度下发，单算子下固定和动态shape都涉及，都会影响最终执行时长
固定shape场景主要涉及流分配场景等，需要评估是否影响并发
接口设计
新增/修改接口描述
涉及新增/修改接口需要在0层设计文档中维护，此处可以直接参考引用。
接口检查项
| 检查项 | 子检查项 | 是否涉及 |
|---|---|---|
| 接口说明 | 接口是否需要评审，评审需关注接口兼容和接口约束（模块间可选，组件间必选） | |
| 接口说明 | 是否需要补充资料说明 | |
| 接口说明 | 接口文档中是否明确接口原型、功能、返回值等的说明 | |
| 接口兼容 | 接口行为兼容性，修改前后行为是否发生变化，是否要通知相关组件 | |
| 接口兼容 | 接口有无兼容性，新接口在老版本上是否能正常工作，涉及本组件和外组件新增接口 | |
| 接口兼容 | 接口是否涉及使用场景、调用时序等约束 | |
| 接口约束 | 接口调用不满足约束条件时是否能清晰报错 | |
| 接口约束 | 是否需要设计单独的测试用例 |
软件设计
关键数据结构
关键技术/算法
流程设计
对子模块的修改
如果涉及子模块主流程修改的，需要通知MDE更新模块级设计文档
错误处理
系统错误
描述象内存分配失败，任务创建失败等错误是如何被处理的。
接口错误
描述将要产生并给外部实体用的错误码
安全检查
编码军规
参考 编码军规.md
编码检查项
| 检查项 | 检查项说明 | 是否涉及 |
|---|---|---|
| 是否涉及资源生命周期管理（如线程池、内存池等） | 资源生命周期过长可能导致资源不足、响应变慢、系统崩溃等严重系统稳定性和可靠性问题。明确资源的生命周期（进程级/Session级/Graph级等）可以帮助我们更好地控制资源的使用，确保资源的有效利用和及时释放。对于使用生命周期较长的资源，需要上代码设计会议评审或考虑其他技术手段。 | |
| 是否创建新线程 | 1） 新创建的线程需要拷贝ThreadLocalContext、ErrorContext等上下文信息。性能场景作为特例单独分析，如果不用可以不拷贝。 2） 新创建线程需要设置线程名称。 |
兼容性检查
重点需要关注老om在新版本下是否能执行，新om在老版本下执行当前不做强制要求，但是最好确保
DT设计
测试边界
测试入口（基于什么接口做测试），测试出口（做哪些数据校验），打桩模块
测试设计
哪几类用例，导出到用例列表，表格只提供了几个类别，可增加
用例类型: UT、ST、BBIT
| 测试类别 | 关键测试项 | 测试方法 | 用例类型 |
|---|---|---|---|
| 功能 | |||
| 性能 | |||
| 精度 | |||
| 兼容性 | |||
| 特性交叉 |
测试框架设计
当前测试框架是否满足测试要求，如果不满足，添加对应类设计