《ASPICE开发流程》----SWE.1-----软件规范

这篇文章主要叙述了ASPICE开发流程中SWE.1的软件规范需要哪些内容

1、定义

软件规范描述了软件要实现的系统功能。

2、主要目标：

软件规范应用于描述产品软件部分的功能。

3、最低要求：

软件规范的内容取决于产品，但可能包含其他内容
控制逻辑
睡眠和唤醒模式
操作条件
安全功能
执行器控制
引导加载程序
诊断服务

除了正常功能外，要求还应规定出现错误时的行为和需要考虑的边界条件，例如：
边界条件
-系统状态：过电压、诊断会话、故障保护模式
-操作模式：传输模式、引导加载模式、断电
-对其他功能/需求的依赖性
-对DTC/DID/参数的依赖性
-特殊情况下的行为（如何对意外输入做出反应）

4、质量要求

4.1、联系方式

应提供作者的联系方式。

4.2、需求状态

针对于需求要有需求状态，比如正在编写、已经完成、废弃、新建等；

4.3、追溯信息

需要对上下过程中双向追溯性的文档需求编号，确保每一条需求有对应的ID，

4.4、术语缩写

需要对文档中出现的缩写进行提前解释；

4.5、需求类型

软件规范中提到该需求是功能需求还是非功能需求；

4.6、内容要求

规范中要有逻辑性，不能杂乱无章，不能出现一个需求不同的解释方法，

每个需求号中应仅包含一个要求。以便根据需求跟踪实现和测试。

合理的结构为读者提供了选择性阅读的可能性，并支持理解性，因为需求的上下文变得清晰。

一项要求的内容不得在另一项要求中重复。

所有的SWRS应覆盖所有的系统软件规范；

所有的需求应该是可以测试的，不能出现无法验证的需求；

5、产品详细信息

软件规范在整个开发过程中是实时迭代更新的，并不是最开始在SWE.1阶段就已经定版的，需要在后续的开发中实时更新信息，直到整个项目完成结束；

在迭代的里程碑阶段之一结束时，必须完全指定迭代期间要实现的部分。

软件规范的内容来源于结合系统架构的系统规范。这些文件之间必须确保双向可追溯性。

此外，软件规范和软件测试规范之间必须存在双向可追溯性，与的SWE.2阶段的软件架构之间也要有双向可追溯性，如图：

你的软件规范中需要多方向追溯其他阶段的产物

备注

上述所有内容是我最新学习理解的，有什么错误的地方即使提出，作者会及时修改；