术语

在软件工程中，有如下的术语定义和关系：

软件单元（Software Unit）：软件单元是最小的功能单元，通常由一个或几个源代码文件组成。它是系统中最小的测试和维护单元，通常可以单独编译和测试。软件单元在某些上下文中也可以指具体的类、函数、或方法等。

组件（Component）：组件是由多个软件单元组成的功能模块。组件可以是一个较大的、具有独立功能的软件部分，通常包含多个软件单元。组件可以被多个系统或子系统复用，并且有定义良好的接口与其他组件进行交互。

子系统（Subsystem）：子系统是由多个组件组成的较大功能模块，通常代表系统中的一个主要功能区域。子系统将组件组织起来，提供更高级别的功能和服务，并可能包括多个组件之间的协作。

模块（Module）：模块是一个广泛使用的术语，通常指软件系统中的一个独立功能部分，可以是软件单元、组件、子系统等的集合。模块通常用于描述系统的结构和组织，关注于如何将系统分解为多个部分以便于管理和维护。

关系总结：

• 软件单元是最小的构建块。

• 组件由一个或多个软件单元组成。

• 子系统由多个组件组成。

• 模块可以是软件单元、组件、子系统等的集合，作为系统的一个功能区块来考虑。

这些术语在不同的上下文中可能会有不同的具体含义，但通常它们都围绕着软件系统的组织和结构进行描述。

软件需求

软件需求通常可以分为以下几类：

功能性需求（Functional Requirements）：描述系统应该执行的功能或服务，包括输入、处理和输出。它们定义了系统应如何响应特定输入或条件。

非功能性需求（Non-Functional Requirements）：描述系统的性能标准和质量属性，包括：

• 性能需求：响应时间、吞吐量等。

• 安全性需求：数据加密、用户认证等。

• 可用性需求：系统的可用性和可靠性。

• 可维护性需求：系统的可维护性和可扩展性。

接口需求（Interface Requirements）：描述系统与其他系统或组件之间的交互要求，包括API、用户界面和外部系统的通信协议等。

系统需求（System Requirements）：描述系统内部和外部的需求，包括硬件、软件和网络环境的需求。

约束需求（Constraint Requirements）：描述在开发和实现过程中需要遵循的限制条件，如法律法规、标准和技术限制。

用户需求（User Requirements）：描述用户的期望和需求，包括用户体验和交互流程。关注最终用户的需求和使用场景。

业务需求（Business Requirements）：描述对软件系统的高层期望和目标，通常与商业价值和战略目标相关。

SW RD

软件需求分析，该过程的目的是：将系统需求中与软件相关的部分转化为一组软件需求。

1. 需求分析：首先，需要对系统的功能和非功能需求进行彻底分析。这包括理解用户需求和期望，以及分析需求的可行性、正确性、可验证性和对运行环境的影响 。

2. 需求结构化：将需求进行结构化，以便于管理和跟踪。这包括将需求分类和分组，以及建立需求的层次结构 。

定义需求：在需求分析的基础上，明确和定义软件需求。这包括需求的详细描述、优先级和需求之间的依赖关系 。

• 描述需求：

  • 对每个需求进行详细描述，包括需求编号、需求名称、需求描述、验收标准等。

  • 确保需求是明确、可测试、可追踪的，并且符合SMART原则（具体的、可测量的、可实现的、相关的、有时限的）。

• 定义功能需求：描述系统应具备的具体功能，包括每个功能的输入、处理和输出。

• 定义非功能需求：说明性能、可靠性、兼容性、安全性、可维护性、可扩展性等方面的需求。

• 编写接口需求：描述系统与其他系统或组件之间的接口，包括数据交换格式、通信协议等。

文档管理：确保文档版本控制，记录修改历史。

1. 需求追溯性：确保需求具有双向可追溯性，建立系统需求与软件需求之间的双向追溯性，建立系统架构设计与软件需求之间的双向追溯性。即从需求到设计、实现和测试的可追溯性，以及从这些活动回溯到需求的能力。

2. 需求评审：组织需求评审会议，邀请相关利益相关者参与，确保需求的明确性和无歧义性，并收集反馈进行需求的迭代和改进 。

3. 需求管理计划：制定需求管理计划，包括需求变更的控制流程、需求状态跟踪和需求的版本控制 。

4. 持续监控和维护：在软件开发过程中持续监控需求的状态，对需求变更进行管理，并根据需要更新需求文档。

SW AD

软件架构设计，该过程的目的是：建立软件架构设计，识别将哪些软件需求分配给软件的哪些组件，并依照定义的准则来评估软件架构设计。

1. 需求分析：了解系统需求和软件需求。

2. 高层架构设计：描述系统的总体架构，定义系统的子系统/主要模块及其之间的交互和依赖关系。

3. 设计决策：记录架构设计中的关键决策和选择，论述并比较系统中使用的重要技术方案，分析其优缺点。

4. 定义软件架构目标：明确软件架构设计的目标和约束条件，以及需要满足的关键质量属性（如性能、可维护性、可扩展性等）。

子系统/模块架构设计：详细描述子系统/模块的内部结构(组件)及其交互方式。

组件定义和描述：定义并详细描述每个组件的功能和相互关系。

分配软件需求：将软件需求分配到子系统/模块架构设计的组件。

接口定义：定义组件之间的接口，包括接口功能、输入/输出数据(参数和返回值)和通信协议。

描述动态行为：展示组件间的时序和动态交互，以满足系统所需的动态行为。 动态行为取决于运行模式（例如：启动、关机、正常模式、标定、诊断等）、进程及进程间相互通信、任务、线程、时间片、中断等。

定义资源消耗目标：资源消耗如：内存(ROM、RAM、外部内部 EEPROM 或 数据闪存）、CPU 负载等。

1. 溯源：建立软件需求与软件架构设计要素之间的双向可追溯性。

2. 评审：对架构设计进行内部评审，确保设计符合需求和标准。

3. 文档修订：根据评审反馈修订文档，完善设计细节。

4. 发布与维护：发布最终版本的文档，并确保文档在软件开发过程中的持续更新和维护。

SW DD

软件详细设计和单元构建，该过程的目的是：为软件组件提供经过评估的详细设计，并定义和生成软件单元。

1. 理解需求和架构设计：在开始详细设计之前，需要对软件的需求有深入的理解，并分析系统架构设计，确保详细设计能够满足这些需求 。

2. 定义软件单元：根据软件架构设计划分的组件，并进一步将组件划分为可以独立开发和测试的软件单元 。

设计概述：简要描述组件功能，设计方针。

开发详细设计：具体说明组件的内部设计，包括软件单元的接口、数据结构、内部逻辑以及与其他单元的交互等（每个组件的详细设计都如此，设计完一个组件就继续设计下一个）

• 每个软件单元的功能描述

• 每个软件单元的接口设计（包括数据结构、算法和流程图）

  • 设计外部接口（单元之间的接口也是）

  • 设计内部接口（只在单元内使用的接口）

• 动态行为

  • 外部接口：描述软件组件和其他组件的处理时序，如果AD有明确清晰设计，则省略。

  • 内部接口：描述软件单元之间的动态行为和交互，使用时序图、状态迁移图等来展示。

• 状态机图（如适用）

• 错误处理机制

明确非功能需求：如性能、资源消耗、安全性等。

评价软件详细设计：从互操作性、交互、关键性、技术复杂性、风险和可测试性等方面对软件详细设计进行评价 。

1. 溯源：建立软件需求与软件单元之间的双向可追溯性。建立软件架构设计与软件详细设计之间的双向可追溯性。

2. 评审/发布等：同RD/AD。

SW UT

软件单元验证，该过程的目的是：验证软件单元，以提供软件单元符合软件详细设计和非功能性软件需求的证据。

需要对DD文档中的所有 modify/new 函数做单元测试。

输出物：UTS–>UT code –>UTR。

UTS

UTS是做单元验证的指导书，通过UTS可以确定如何做单元测试，需要多少个测试case。

根据函数的圈复杂度来确定被测函数需要多少个测试case，测试case总是要大于等于圈复杂度。

UT code

做单元测试的测试代码。可以使用tessy或googletest进行验证。

UTR

单元测试报告，将测试结果补充到UTS中就是UTR。

SW IT

软件集成及集成测试的核心目的是：通过逐步将软件单元组合成更大的功能模块，最终形成符合架构设计的完整系统，同时在集成过程中对各组件间的接口及整体功能进行验证，确保系统实现与设计规范（特别是模块间接口）的高度一致性。

文档发布流程

溯源

溯源需在文档评审前完成，评审时需要关注上下游溯源和一致性。

溯源需输出溯源报告，未溯源的要分析原因并备注原因。