ASPICE_SWE.1_01_02_SQ3RNote

Ref

• ASPICE V3.1

1. Survery

• ASPICE V3.1 level 1
• UML 需求表示方法，待续。
• SysML，需求表示方法，待续。

2. Question

Q1. What’s the Contents of SW requirements ?
Q2. Why
Q3. Who
Q4. When
Q5. How

3. Read

3.1 Process Reference Model

3.1.1 Process purpose

The purpose of the Software requirements analysis process is to transform software related System requirements to a set of software requirements.

3.1.2 Process outcome

• The software requirements to be allocated to the software elements of the system and their interfaces are defined
• software requirements are catogrized and analyzed for correctness and verifiability
• The impact of Software requirements on operating environment is analyzed
• Prioritization for implementing the software requirements is defined
• Consistency and bidirectional traceability are established between system requirements and software requirements; Consistency and bidirectionaly traceability are established between system architectural design and software requirements
• Software requirements are evaluated for cost, schedule and technical impact
• The software requirements are agreeed and communicated to all affected parties

3.2 Process performance process attribute

3.2.1 BP, Base Practice

• BP1. Specify SW requirements
  SW requirements may address

  • Functional parts to be implemented in software including safety and/or security related functions
  • Hardware related functions
  • Receving signals from electronic sensors
  • Processing of signals
  • Control of electronic hardware(actuators)
  • Strucuture and storage data
  • Parameters defining the software behavior
  • Non-functional requirements(e.g. safety, security, quality requirements)
    SW requirements have to be
  • granular
  • understandable
    SW requirements shouldn’t be
  • Unclear

• BP2. Structure SW requirements
  Software requirements are structured by grouping, sorting and categorizing to support a priorization and to map the required functionality to future release.
  The structure and categorization of the software specification enables the project to manage the requirements in terms of e.g. organization, technical, legal and internal topics.

• BP3. Analyze SW requirements

• BP4. Analyze the impact on the operating environment
  The analysis of the impact on the operating environment covers the impact on the software in scope as well as the impact on other software parts, other system or the entire vehicle considering the following possible aspect:

  • Interfaces
    • signals and signal quality
    • Voltage and current
  • Environment
    • Temperature
    • EMC
  • Performance
    • Interface response time(signal response, sample time, cycle, bus load, signal delay, jitter)
    • Micro contrller response time(processing time)
  • Resources
    • RAM/ROM memory usage
    • EEPROM/DataFlash memory usage

• BP5. Develop verification criteria

• BP6. Establish bidirectional traceability

• BP7. Ensure consistency

• BP8. Communicate agreed SW requirements

3.2.2 WP, work product

• 13-04 Communication Record
• 13-19 Review Record
• 13-21 Change Control Board
• 13-22 Traceability record
• 15-01 Analysis report
• 17-08 Interface requirements specification
• Software requirements specification
• Verification criteria

4. Recite

此过程之主旨，在于将系统需求中关于软件的部分转换为软件需求。

软件需求分析过程，需要对软件进行以下分析

1. 正确
2. 可测试性
3. 对运行环境的影响

此过程工作流如下图所示

4.1 需求定义阶段

总体要求

• 详细说明软件需求

• 结构化软件需求

• Input doc

  • Software related part of system requirement
  • System architectural design to be allocated to SW

• Output work product

  • SW requirement specification
  • Interface requirement specification

4.2 需求分析阶段

• 分析软件需求的正确性，可测试性
  • 能否实现，相互依赖关系
  • 是否可以验证？
• 分析软件对运行环境的影响， 运行环境包括
  • 其他软件部分
  • 其他系统
  • 整车
  • 资源
    • 计算资源，CPU load
    • 存储资源
      • RAM
      • ROM

4.3 确定需求测试标准

确定需求测试通过的标准

• identification of the requirement to be specified
• verification method
  • test
  • inspection
  • peer review
  • audit
  • walkthrough
  • analysis
• Verification environment
• Precondition or special condition
• Constraints
• Success Criteria

4.4 评估软件需求分析工作

保证软件需求与上游输入需求的一致性，双向追溯性。上游需求包括

• Software related part of System requirements
• System architectural design

4.5 发布

已沟通好的软件需求应及时发布给相关人员，包括软件架构，软件测试。

5. Review

软件需求分析过程主要包含以下几步

• 1. 做
     定义好软件需求，并要分组，结构化
• 2. 分析
     分析定义好的软件需求，内容包括软件需求内容本身正确性，可测试性，以及其对运行环境的影响
• 3. 开发软件需求验证标准，确定如何测试可以满足需求的条件
• 4. 评估上述软件需求分析过程是否完整覆盖了上游需求，数量上有追溯，质量上保持内容一致
• 5. 发布
     若上述过程执行顺利，向相关人员发布定义好的软件需求，进入下一阶段工作。