软件需求分析案列_聊一聊软件需求分析

| 但愿人长久 千里共婵娟 |—祝大家中秋节快乐 —前言

根据最新的ASPICE V3.1流程，介绍了软件需求分析的开发流程。(PS：未考虑功能安全)

众所周知，当前主流的软件开发是按照V型开发流程进行的。早期的有瀑布式开发流程，最近敏捷开发流程也比较火。前段时间去欧洲出差，发现欧洲很多软件公司都在推敏捷开发流程。

V型开发流程的步骤如下图所示：

软件需求分析->软件架构设计->详细设计和代码实现->单元测试->集成测试->软件测试

今天我们讨论的是软件的需求分析。

软件需求分析(software requirement analysis)在ASPICE里面的Process ID是SWE.1。SWE是Procee Group的名字。ASPICE里面有很多流程组，软件开发流程组称为Software Engineering Process Group。

软件需求分析的目的

首先我们需要明确为什么要做软件需求分析。

软件需求分析的目的是将系统需求中与软件需求相关的部分转换成一系列软件需求的集合。

这是ASPICE的定义，是从软件需求来源的角度定义的。软件需求不是从客户那里来的，而是从系统需求那边划分得到的。即通过与客户的沟通，我们会得到客户的系统需求，产生系统需求文档。系统需求文档会输入给系统架构工程师，产生系统架构文档。以系统需求文档和系统架构文档作为输入，产生软件的需求文档。

下图是由系统需求和系统架构得出软件，硬件，传感器的需求示例(暂不考虑功能安全)：

备注：我们还可以从其他角度来分析软件需求分析的目的，或者说是作用

a.       软件需求分析中需要包含对架构设计文档的认识，理解以及记录

b.       需求文档使得任何变动，澄清以及后续的分解变得易于管理

c.       为软件架构设计，详细设计，测试提供了依据

2.1对软件需求进行详细说明(Specify software requirements)

根据ASPICE SWE.1 BP1的描述，首先需要对软件需求进行详细说明。

这里先介绍个人在公司使用的软件需求管理软件，PTC Integrity。我们的软件需求文档，架构设计文档，单元设计文档，单元测试文档，集成测试文档，软件测试文档都可以通过该工具进行编写和管理。

1)对于第一步，细化到具体实践，需要在工具中先新建一下软件需求分析的文档，包括一下内容：文档的ID，文档名字，创建人，Feature Owner，创建日期，版本号这些基本内容，文档的状态(处于Open状态)。

2)然后我们再谈具体应该怎么编写软件需求，ASPICE是这样描述的：

Use the system requirements and the system architecture and changes to system requirements and architecture to identify the required functions and capabilities of the software. Specify functional and non-functional software requirements in a software requirements specification.

也就是说需要根据现有的系统需求和系统架构文档，以及它们的更改，识别出软件的功能和软件的能力，详细定义其功能需求和非功能需求。

这里引入一个概念，就是功能需求和非功能需求。这个描述其实很多地方都有提到，我们可以参考AutoSAR的任意模块的需求文档，里面都有相应的介绍：

进一步解释一下：

所谓的功能需求，就是和该软件模块相关的功能开发需求，比如软件配置，初始化，LifeCycle的状态操作等等。

所谓的非功能需求，就是与该模块本身开发无关，但是也属于整个系统开发的一些边界条件，比如一些Runnable的时间要求，占用多少RAM空间，开发的软件工具，平台等等。

备注：功能需求和非功能需求只是软件需求分析文档的主体，软件需求分析还应该描述一些软件接口，比如外部模块需要提供的接口，给外部模块的接口。可以不细化到具体的函数名，因为在项目的初期不可能定义那么具体，具体的函数名在架构设计里面可以有更加清晰的表述。此外，一些设计限制等等也应该在软件需求分析里面说明。

2.2软件需求结构化表述(Structure software requirements)

第二步其实和第一步是同时进行的，都是对文档内容和形式的一些要求。一般而言，各个公司的软件需求文档会有相应的模板，主体结构是固定的，我们只需要按照模板的要求来做。前提是公司有ASPICE的流程，Level 2的流程表示已经依葫芦画瓢做出个样子出来了。

ASPICE对结构化有如下要求：

• grouping to project relevant clusters,

• sorting in a logical order for the project, 

• categorizing based on relevant criteria for the project,

• prioritizing according to stakeholder needs. 

也就是说需要我们的软件需求文档需要根据项目进行分类，需要有一定的逻辑，有一定的标准和优先级等等。总之就是模板。

备注：到这一步，软件需求文档的主体内容就完成了。但是离最终发布还早着呢

2.3 对软件需求进行分析(Analyze software requirements )

既然是软件需求分析，哪有不分析的道理。ASPICE对于分析的内容定义如下：

Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact.

也就是说我们需要从关联性，技术可行性，可验证性等角度对每一条软件需求进行评估。有一个很著名的SMART模型可以帮助我们做这部分工作。

此外，关于每一条具体的软件需求的描述，可参考下面的句型：

值得注意的是，英文里面会对Shall、Should、Must等等这些词特别敏感，这里给出AutoSAR的软件需求文档里面的一些解释，可以方便大家理解。

2.4 分析在操作环境中的影响(Analyze the impact)

ASPICE里面的具体表述如下：

Analyze the impact that the software requirements will have on interfaces of system elements and the operating environment。

操作环境还是可以根据SMART模型来分析，兼顾句型即可。

2.5 开发验证标准(Develop verification criteria )

ASPICE里面的表述如下：

Develop the verification criteria for each software requirement that define the qualitative and quantitative measures for the verification of a requirement.

如SMART模型表述，所有的需求是可以测试的，如果不能衡量，我们怎么知道这个需求是否被满足。PTC Inergrity里面可以定义Test Method。我们在软件需求分析的时候需要明确说明每一条需求的测试标准，以及测试方法。是Design Review还是需要编写Test Case来做验证。

2.6 建立双向链接(Establish bidirectional traceability )

ASPICE里面的表述如下：

Establish bidirectional traceability between system requirements and software requirements. Establish bidirectional traceability between the system architecture and software requirements.

如之前所说，软件需求文档的来源是系统需求和系统架构文档。因为我们需要将每一条软件需求和系统需求，系统架构一一对应，当然，可以一对多，也可以多对一。

关于双向链接，没有专门的软件需求管理工具，做起来可能比较麻烦。但是在PTC Integrity里面其实是很容易的事情。

备注：软件需求是这么做，同样硬件需求分析也是这么做。都是需要做双向链接的。后续软件开发的各个阶段，架构设计文档，单元设计文档，代码，测试文档，测试用例等等都是需要做双向链接的。

2.7 确保一致性(Ensure consistency )

ASPICE里面的表述如下：

Ensure consistency between system requirements and softwarerequirements. Ensure consistency between the system architecture and softwarerequirements.

这里说的是在review之前需要坚持软件需求和系统需求，系统架构的一致性。为后面的review做准备。

2.8 交流同意软件需求(Communicate agreed software requirements. )

ASPICE的表述如下：

Communicate the agreed software requirements and updates to software requirements to all relevant parties

也就是我们的Review工作了。这就不需要过多介绍了。

备注：值得注意的是，整个过程中会有大量的输出文档，

13-04 Communication record

13-19 Review record

13-21 Change control record 

13-22 Traceability record

15-01 Analysis report

17-08 Interface requirements specification

17-11 Software requirements specification

17-50 Verification criteria  

包括每次讨论的记录，review的记录，需求变更的记录，做双向链接的记录，分析报告，接口需求文档，验证标准，当然也有我们最关心的软件需求文档。用PTC Integrity的话，；里面的很多东西其实可以覆盖，比如变更， 双向链接，验证标准等等。

总结

从软件需求分析的流程来看，其实前两部是写软件需求，3,4,5,6,7步是对需求进行分析。第8步是评审。我们在执行需求设计和分析的时候其实并没有严格的先后顺序，而是穿插着一起进行的。很多时候还需要拉着架构工程师，硬件工程师，功能安全工程师，项目管理以及客户一起讨论，最终把软件需求写好。

今天的分析就到这里，谢谢大家