add skills/GJB438B-2009_prd_skills/
This commit is contained in:
kuangji
28
Handoff-2026-05-18.md
Normal file
28
Handoff-2026-05-18.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Handoff - 2026-05-18
|
||||
|
||||
## Completed Tasks
|
||||
- 创建并完善 `AGENTS.md`，明确仓库结构、文档规范、测试方式和贡献要求。
|
||||
- 编写 `plan.md`，完成 DOCX 规范分析 Web 应用的方案设计，比较 Python 与 HTML/CSS/JavaScript 技术路线，并确定 FastAPI + 简洁前端的实现方案。
|
||||
- 基于 TDD 开发简易 DOCX 规范分析 Web 应用，新增 FastAPI 后端、DOCX 解析、技能加载、技能匹配、模型调用、Markdown 报告生成和下载功能。
|
||||
- 添加简洁 Web UI，支持上传 `.docx` 文件、选择模型供应商、提交分析任务并下载 Markdown 分析报告。
|
||||
- 增加分析进度提示栏，将 `/analyze` 改为后台任务模式，并通过 `/tasks/{task_id}` 实时轮询分析状态。
|
||||
- 暂停 DOCX 报告下载入口，仅保留 Markdown 分析文档下载。
|
||||
- 使用 `test/测评报告.docx` 完成本地分析验证，并用 DeepSeek 配置验证 OpenAI 兼容模型 API 调用链路。
|
||||
- 使用 `uv` 管理项目依赖，补充 `pyproject.toml`、`uv.lock`、测试用例和命令行分析脚本。
|
||||
- 编写并多次修订 `plant.md`，形成 Ubuntu 20.04 内网离线迁移步骤，包括 wheelhouse 打包、清华源使用、`lxml` 构建依赖、便携 Python 运行时准备和 `uv` 离线同步。
|
||||
|
||||
## Blockers
|
||||
- `uv pip download` 在当前 `uv` 版本中不可用，需要改用 `pip wheel` 或 `pip download`。
|
||||
- 当前 `.venv/bin/python3.12` 只是指向系统 Python 的符号链接，不能作为独立可移植 Python 运行时打包。
|
||||
- 系统 `/usr/bin/python3` 初始缺少 `pip`，需要安装 `python3-pip`。
|
||||
- 下载或构建 `lxml==6.1.0` 时可能因镜像源不全或缺少系统编译依赖失败，需要安装 `build-essential`、`libxml2-dev`、`libxslt1-dev`、`zlib1g-dev`、`python3-dev`，并可切换到官方 PyPI。
|
||||
- 使用 `uv python install --install-dir /opt/python-3.12` 需要写入 `/opt` 权限；`sudo uv` 找不到命令时，需要使用 `/home/zjz/.local/bin/uv` 的绝对路径或将 `uv` 复制到 `/usr/local/bin/uv`。
|
||||
- `uv python install` 生成的 Python 可执行文件位于版本子目录，如 `/opt/python-3.12/cpython-3.12.13-linux-x86_64-gnu/bin/python3.12`，不是 `/opt/python-3.12/bin/python3.12`。
|
||||
|
||||
## Next Steps
|
||||
- 按 `plant.md` 在准备机上重新执行离线打包流程，确认 `wheelhouse/` 中包含所有运行依赖。
|
||||
- 使用 `find /opt/python-3.12 -path '*/bin/python3.12' -print` 确认便携 Python 真实路径，并打包 `python-3.12-runtime.tar.gz`。
|
||||
- 将项目源码、`wheelhouse/`、`requirements.txt`、`uv.lock`、`uv` 可执行文件和 Python 运行时包拷贝到 Ubuntu 20.04 内网服务器。
|
||||
- 在内网服务器上创建 `.venv`，执行 `uv sync --frozen --offline` 或使用 wheelhouse 离线安装依赖。
|
||||
- 启动 FastAPI 服务并用 `test/测评报告.docx` 验证上传、进度轮询、模型调用和 Markdown 报告下载流程。
|
||||
- 确认 `configs/api_config.yaml` 的 `intranet` 模型地址、端口和网络连通性，并在验证通过后编写 `systemd` 服务文件用于长期运行。
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
name: 需求可追踪性双向映射规则
|
||||
description: 建立CSCI需求与系统需求之间的双向可追踪性映射，确保每个CSCI需求都能追溯至其来源的系统需求或设计决策，同时每个系统需求都能向下追踪到分配给CSCI的具体需求。在存在系统级需求分解且需进行变更影响分析或覆盖率验证时使用本技能。
|
||||
---
|
||||
|
||||
# 需求可追踪性双向映射规则
|
||||
|
||||
## 何时使用
|
||||
- 已完成系统级需求分解，并存在CSCI（计算机软件配置项）需求；
|
||||
- 需要支持变更影响分析、需求覆盖率验证或合规性审计（如GJB438B）；
|
||||
- 出现无法直接追溯的需求（如由架构设计导出的接口需求），需明确其来源依据。
|
||||
|
||||
## 执行步骤
|
||||
1. **建立自顶向下追踪**：从每个系统/子系统需求出发，列出所有分配给CSCI的具体需求。
|
||||
2. **建立自底向上追踪**：从每个CSCI需求出发，明确其源自的系统需求；若无直接对应项，则追溯至：
|
||||
- 一般性系统需求（如“系统实现”）；
|
||||
- 导致该需求产生的系统设计决策。
|
||||
3. **实现追踪方式**（任选其一或组合使用）：
|
||||
- 在需求条目中添加注释说明来源；
|
||||
- 维护独立的双向追踪矩阵；
|
||||
- 引用接口需求规格说明（IRS）等文档。
|
||||
4. **完整性检查**：确保所有分配给CSCI的系统需求均被完整列出，不得遗漏。
|
||||
5. **支持后续活动**：确保追踪信息可用于变更影响分析与需求覆盖率验证。
|
||||
|
||||
> 注意：即使需求无法直接追溯，也必须说明其来源，不可留空。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: CSCI能力需求结构化
|
||||
description: 将CSCI（计算机软件配置项）的功能性行为按“能力”组织为结构化需求子条。当需要编写或重构CSCI能力需求文档章节，且已识别出若干核心能力时使用本技能。适用于遵循GJB438B等军用软件需求规范的场景。
|
||||
---
|
||||
|
||||
# CSCI能力需求结构化
|
||||
|
||||
## 何时使用
|
||||
- 正在编写CSCI能力需求文档章节（如GJB438B中的3.2节）
|
||||
- 已识别CSCI需具备的若干核心能力
|
||||
- 需将功能性行为按逻辑聚类并结构化表达
|
||||
|
||||
## 执行步骤
|
||||
1. **聚类行为为能力**：将CSCI所需的行为按逻辑聚类为若干“能力”。根据上下文，“能力”可替换为“功能”、“主题”或“对象”等更贴切的术语。
|
||||
2. **设立独立子条**：为每一能力设立独立的需求子条（例如3.2.X格式）。
|
||||
3. **分解子能力（如适用）**：若某能力可进一步分解为子能力，则继续以层级方式分条说明。
|
||||
4. **详述能力需求内容**：每个能力需求子条必须包含以下要素：
|
||||
- CSCI所需的具体行为；
|
||||
- 参数要求，包括响应时间、吞吐时间、时限约束、时序、精度、容量、优先级、连续运行需求、允许偏差；
|
||||
- 在异常、非许可或超限条件下的预期行为；
|
||||
- 错误处理需求；
|
||||
- 紧急时刻保障运行连续性的措施。
|
||||
5. **关联输入/输出需求**：在定义能力相关的输入/输出需求时，必须引用文档中3.3.X节所列的主题清单。
|
||||
|
||||
## 注意事项
|
||||
- 不得将不相关的需求强行归入同一能力。
|
||||
- 能力命名应清晰反映其功能范围（如“导航控制”、“数据加密”）。
|
||||
- 所有参数和行为描述必须可验证、可测试。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: CSCI多状态/方式需求定义
|
||||
description: 当计算机软件配置项（CSCI）需在不同运行情境（如空闲、战时、训练等）下表现出不同行为时，使用本技能定义各状态/方式并关联对应需求。若系统无需多种状态或方式，则明确声明该事实，避免人为划分。
|
||||
---
|
||||
|
||||
# CSCI多状态/方式需求定义
|
||||
|
||||
## 何时使用
|
||||
- 系统需在多种运行情境（如空闲、就绪、活动、训练、战时、紧急情况等）下执行不同功能或行为。
|
||||
- 需求规格说明中存在依赖于特定运行状态或方式的功能要求。
|
||||
- 触发条件：IF CSCI需在空闲、就绪、活动、训练、战时等不同状态下运行 THEN 应定义各状态/方式及其对应需求。
|
||||
|
||||
## 如何执行
|
||||
1. **判断是否需要多状态/方式**：确认CSCI是否确实在不同情境下有不同行为。若否，直接声明“本CSCI无需多种状态或方式”，不得强行划分。
|
||||
2. **明确定义状态和/或方式**：列出所有适用的状态/方式（如`['空闲', '战时', '紧急情况']`），可采用以下任一结构：
|
||||
- 仅用状态
|
||||
- 仅用方式
|
||||
- 方式中的状态
|
||||
- 状态中的方式
|
||||
- 其他有效组合
|
||||
3. **关联需求与状态/方式**：将每个需求或需求组明确关联到对应的状态/方式，可通过以下任一方式实现：
|
||||
- 在需求条目中嵌入表格指明适用状态/方式
|
||||
- 在附录中引用统一的状态-需求映射表
|
||||
- 在需求所在章节直接文字说明
|
||||
4. **输出结果**：生成一份清晰的状态/方式定义表，并确保所有需求均标注其适用状态/方式。
|
||||
|
||||
> **注意**：仅当系统实际需要多状态/方式时才应用此流程；否则必须明确否定，以符合GJB438B规范要求。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: CSCI合格性方法选择与应用
|
||||
description: 为CSCI（计算机软件配置项）需求选择并应用适当的合格性方法，确保每个需求均可被客观验证。在编写或评审软件需求规格说明（如依据GJB438B标准）时，若存在需验证的CSCI需求，则必须使用本技能为每个需求指定至少一种合格性方法。
|
||||
---
|
||||
|
||||
# CSCI合格性方法选择与应用
|
||||
|
||||
## 何时使用
|
||||
- 正在编写或更新CSCI软件需求文档（如SRS）
|
||||
- 需要为第3章中的每个需求分配验证手段
|
||||
- 进行软件验证计划或质量保证活动准备
|
||||
- 遇到安全关键、保密关键或高完整性需求，需组合多种验证方法
|
||||
|
||||
## 如何执行
|
||||
1. **识别所有CSCI需求**：聚焦于需求规格说明第3章中列出的功能性与非功能性需求。
|
||||
2. **为每个需求选择一种或多种合格性方法**：
|
||||
- **演示（Demonstration）**：通过直接运行CSCI或其部分功能，无需专用设备或事后分析即可观察结果。
|
||||
- **测试（Test）**：使用仪器或专用测试设备运行CSCI，采集数据用于后续分析。
|
||||
- **分析（Analysis）**：基于其他方法（如测试）产生的数据进行处理、约简或逻辑推断。
|
||||
- **审查（Review）**：对源代码、设计文档或需求条目进行目视检查。
|
||||
- **特殊合格性方法（Special）**：采用专用工具、技术、规程、设施或受控验收条件。
|
||||
3. **记录映射关系**：
|
||||
- 在需求条目中直接注明所选方法，或
|
||||
- 创建“需求-合格性方法映射表”，明确对应关系。
|
||||
4. **确保可验证性**：
|
||||
- 避免使用主观、模糊或无法客观确认的描述。
|
||||
- 对安全/保密关键需求，应组合多种方法（例如：测试 + 分析 + 审查）以增强置信度。
|
||||
5. **验证约束**：确认每个需求至少指定一种合格性方法，否则视为不完整。
|
||||
|
||||
> **注意**：合格性方法的选择直接影响后续验证活动的可行性与成本，应在需求阶段尽早确定。
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: 数据备份与恢复规程制定
|
||||
description: 制定符合GJB 438B标准的数据备份规程和错误/紧急情况下的恢复操作规程。当软件系统处理重要数据或需满足军用软件文档要求时使用本技能，确保在错误、缺陷、误操作或事故后能有效恢复系统运行。
|
||||
---
|
||||
|
||||
# 数据备份与恢复规程制定
|
||||
|
||||
## 何时使用
|
||||
- 软件系统包含需要保护的持久化关键数据
|
||||
- 需编写符合GJB 438B第5.5条（数据备份）和第5.6条（错误与紧急恢复）的规程文档
|
||||
- 系统可能发生错误、故障或面临紧急事件，需明确恢复与连续性措施
|
||||
|
||||
## 如何执行
|
||||
|
||||
### 一、制定数据备份规程
|
||||
1. **定义备份触发条件**：明确是定期备份（如每日/每周）还是事件驱动（如关键操作后）。
|
||||
2. **描述备份执行步骤**：包括启动方式、执行主体、所需权限等。
|
||||
3. **界定备份范围与内容**：列出需备份的数据类型、数据库表、配置文件等。
|
||||
4. **指定存储位置与介质**：说明本地/异地、磁盘/磁带/云存储等选择依据。
|
||||
5. **制定保留策略**：规定保留期限、保留份数（如3份滚动保留）、过期处理方式。
|
||||
6. **确保安全性与验证**：
|
||||
- 存储加密、访问控制等安全要求
|
||||
- 定期验证备份完整性与可恢复性（如恢复测试）
|
||||
7. **明确备份用途**：声明仅用于替代主数据拷贝以应对错误、缺陷、误动作或事故。
|
||||
|
||||
### 二、制定错误恢复与紧急连续性规程
|
||||
1. **错误/故障恢复部分**：
|
||||
- 提供故障识别方法（日志分析、监控告警等）
|
||||
- 描述系统状态评估步骤（服务是否中断、数据是否损坏）
|
||||
- 给出重启操作序列（顺序、依赖项、超时设置）
|
||||
- 包含数据恢复步骤（从备份还原、事务回滚等）
|
||||
- 设定恢复成功验证标准（功能测试、数据一致性检查）
|
||||
2. **紧急事件连续性部分**：
|
||||
- 定义紧急事件识别标准（如自然灾害、网络攻击）
|
||||
- 列出连续性保障措施（备用电源、冗余链路）
|
||||
- 提供备用系统切换步骤（手动/自动切换流程）
|
||||
- 明确关键功能优先级（哪些功能必须优先恢复）
|
||||
- 说明资源重新分配方法（计算、存储、人力调度）
|
||||
3. **通用要求**：
|
||||
- 所有步骤必须详细到用户可直接执行，避免“酌情处理”等模糊表述
|
||||
- 在涉及安全风险处使用“警告”或“注意”标记
|
||||
- 覆盖从轻微错误到严重故障的全谱系场景
|
||||
|
||||
> **注意**：错误恢复规程聚焦于系统自身故障后的重启与数据还原；紧急连续性规程关注外部重大事件下的业务持续运行。两者必须区分但可协同设计。
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: 数据元素接口特征定义
|
||||
description: 定义接口中单个数据元素的9类特征，适用于涉及数据元素交换的接口规范编制场景（如GJB438B要求）。当接口需明确描述字段级数据属性（如名称、类型、精度、保密性等）时使用本技能。
|
||||
---
|
||||
|
||||
# 数据元素接口特征定义
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及数据元素的提供、存储、发送、访问或接收；
|
||||
- 需满足GJB438B等标准对数据元素接口特征的强制要求；
|
||||
- 需消除发送方与接收方对同一数据元素理解不一致的风险。
|
||||
|
||||
## 执行步骤
|
||||
1. **识别适用的数据元素**：确认CSCI需处理的每个独立数据元素。
|
||||
2. **定义9类特征**：
|
||||
a) **名称/标识符**：包括项目唯一标识符、自然语言名称、数据元素名、技术名（变量/字段名）、缩略名或同义名；
|
||||
b) **数据类型**：如字母、数字、整数、布尔值等；
|
||||
c) **大小和格式**：字符串长度、小数位数、标点符号规则等；
|
||||
d) **计量单位**：如米（m）、千克（kg）等；
|
||||
e) **取值范围或枚举值**：如0–99、["启用", "禁用"]；
|
||||
f) **准确性与精度**：正确程度及有效数字位数；
|
||||
g) **操作约束**：优先级、定时、频率、容量、序列、可更新性、业务规则适用性等；
|
||||
h) **保密性约束**：访问控制、加密要求等；
|
||||
i) **来源与接收者**：明确设置/发送实体及使用/接收实体。
|
||||
3. **说明视角差异**：从接口各参与方角度，标注对同一数据元素在大小、频率等特性上的不同期望。
|
||||
4. **引用外部文档**：若已有数据字典、协议标准等权威文档，可直接引用以避免重复描述。
|
||||
|
||||
## 输出结果
|
||||
生成结构化的数据元素特征表，包含上述9个维度，用于纳入接口规格说明文档。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: 数据组合体接口特征定义
|
||||
description: 定义接口中记录、消息、文件等复合数据结构（数据组合体）的8类特征，适用于存在结构化数据包交换的接口规范编制。当接口传输的是由多个数据元素组成的整体单元（如报文、报表、显示界面）时使用本技能。
|
||||
---
|
||||
|
||||
# 数据组合体接口特征定义
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及记录、消息、文件、报表、显示等结构化数据包的交换；
|
||||
- 需满足GJB438B等标准对复合数据结构接口特征的要求；
|
||||
- 需明确数据组合体的整体结构、媒体依赖或人机交互特性。
|
||||
|
||||
## 执行步骤
|
||||
1. **识别适用的数据组合体**：确认CSCI需处理的每种复合数据结构（如数据库记录、通信消息、输出报表等）。
|
||||
2. **定义8类特征**：
|
||||
a) **名称/标识符**：包括项目唯一标识符、非技术名称、技术名称（如记录类型名）、缩略名或同义名；
|
||||
b) **内部结构**：列出所含数据元素及其编号、顺序、分组关系；
|
||||
c) **介质与存储结构**：如磁盘、内存、网络流，以及在介质上的组织方式；
|
||||
d) **视听特性**：颜色、布局、字体、图标、提示音、亮度等（适用于显示或人机界面）；
|
||||
e) **组合体间关系**：如排序规则、索引方式、存取路径等；
|
||||
f) **操作约束**：优先级、时序、频率、容量、序列、可更新性、业务规则适用性等；
|
||||
g) **保密性约束**：整体或部分数据的访问控制要求；
|
||||
h) **来源与接收者**：明确生成/发送方及消费/接收方。
|
||||
3. **说明视角差异**：标注不同接口实体对同一组合体在频率、容量等方面的期望差异（如发送方支持高频，接收方仅需低频）。
|
||||
4. **引用外部标准**：可引用用户界面规范、通信协议等外部文档以简化描述。
|
||||
|
||||
## 输出结果
|
||||
生成结构化的数据组合体特征表，包含上述8个维度，用于纳入接口规格说明文档。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: 定义保密性需求
|
||||
description: 当涉密CSCI或信息安全系统处理敏感或机密信息时，使用本技能定义其保密性环境、级别、风险及对应安全对策。适用于需满足国家保密法规或军用标准（如GJB438B）的系统开发场景。
|
||||
---
|
||||
|
||||
# 定义保密性需求
|
||||
|
||||
## 何时使用
|
||||
- 系统被认定为涉密CSCI或信息安全系统；
|
||||
- 系统处理秘密、机密或绝密级别的信息；
|
||||
- 需要编制符合国家保密法规、军用标准或认证要求（如CC EAL4+）的保密性需求文档。
|
||||
|
||||
## 执行步骤
|
||||
1. **定义保密性运行环境**：明确CSCI必须部署和运行的保密环境（例如机密级网络、隔离区域等）。
|
||||
2. **确定保密类型与级别**：指定所处理信息的保密级别（如“秘密”、“机密”、“绝密”）及适用范围。
|
||||
3. **识别保密性风险**：列出CSCI可能面临的保密威胁，包括但不限于未授权访问、数据泄露、中间人攻击等。
|
||||
4. **规定安全控制措施**：针对识别出的风险，明确必须实施的安全对策，包括：
|
||||
- 加密算法及其强度要求；
|
||||
- 用户身份鉴别机制（如多因素认证）；
|
||||
- 基于角色或属性的访问控制策略；
|
||||
- 审计日志记录与监控机制。
|
||||
5. **引用合规政策**：列出必须遵循的保密性法规与标准（如《中华人民共和国保守国家秘密法》、GJB438B、军用信息安全标准等）。
|
||||
6. **明确保密责任**：规定CSCI在数据标记、存储、传输和销毁各环节中的保密义务。
|
||||
7. **指定认证认可准则**：说明系统需通过的保密性认证等级或评估保障级别（如Common Criteria EAL4+）。
|
||||
|
||||
> 注意：非涉密系统可省略本流程。
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: 定义数据元素特征
|
||||
description: 当接口、消息或数据库涉及数据元素传输时，使用本技能为每个数据字段定义完整的特征集（包括名称、类型、格式、值域、精度、约束等），以生成标准化的数据字典条目。适用于接口设计、数据建模和信息工程场景。
|
||||
---
|
||||
|
||||
# 定义数据元素特征
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及数据元素传输
|
||||
- 存在跨系统或模块的数据交换需求
|
||||
- 需要编写接口规范文档或数据字典
|
||||
- 已识别接口数据流且需明确字段语义与技术细节
|
||||
|
||||
> **注意**：不适用于无数据交换的控制信号（如纯状态标志或触发信号）。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **名称/标识符定义**
|
||||
- 分配项目唯一标识符
|
||||
- 提供自然语言名称（业务含义）
|
||||
- 给出标准数据元素名称
|
||||
- 指明技术名称（如变量名、数据库列名、JSON键名）
|
||||
- 列出常用缩写或同义名
|
||||
|
||||
2. **指定数据类型**
|
||||
- 明确为以下之一：字符串（STRING）、整数（INTEGER）、浮点数（FLOAT）、布尔值（BOOLEAN）、日期时间（DATETIME）等
|
||||
|
||||
3. **定义大小和格式**
|
||||
- 字符串：最大长度、允许字符集、标点规则
|
||||
- 日期：统一格式（如 YYYY-MM-DD）
|
||||
- 数值：是否带符号、小数位数
|
||||
|
||||
4. **标注计量单位**
|
||||
- 如米（m）、千克（kg）、秒（s）、百分比（%）等
|
||||
|
||||
5. **设定值域**
|
||||
- 数值范围（如 0~99）
|
||||
- 枚举列表（如 ['ACTIVE', 'INACTIVE', 'PENDING']）
|
||||
|
||||
6. **明确精度要求**
|
||||
- 准确度（是否必须真实反映物理量）
|
||||
- 有效数字位数（如保留3位有效数字）
|
||||
|
||||
7. **声明约束条件**
|
||||
- 业务规则（如“订单金额必须大于0”）
|
||||
- 时序要求（如“创建时间不得晚于更新时间”）
|
||||
- 更新权限（谁可修改）
|
||||
- 优先级或必填性
|
||||
|
||||
8. **注明保密性约束**
|
||||
- 是否需加密传输或存储
|
||||
- 访问控制级别（如公开、内部、机密）
|
||||
|
||||
9. **记录来源与接收者**
|
||||
- 发送实体（如“用户服务模块”）
|
||||
- 接收实体（如“支付网关”）
|
||||
|
||||
## 输出结果
|
||||
生成结构化的数据字典条目，可直接用于接口规范文档、数据库设计说明书或API契约。
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: Define Human Factors Requirements for Human-Machine Interfaces
|
||||
description: 定义涉及人机交互的计算机软件配置项（CSCI）所需的人因工程需求。当CSCI需要人工操作或监控、且包含人机界面、操作员交互系统或控制台软件时使用本技能，以确保界面设计符合人的感知、认知和操作能力，并减轻可预见的人为错误影响。
|
||||
---
|
||||
|
||||
# 定义人机界面人因工程需求
|
||||
|
||||
## 何时使用
|
||||
- CSCI 涉及人工操作或监控；
|
||||
- 系统包含人机界面（HMI）、操作员交互系统或控制台软件；
|
||||
- 非全自动系统（全自动系统可省略此步骤）。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **评估人的能力与局限性**：
|
||||
- 视觉与听觉感知能力；
|
||||
- 认知负荷限制；
|
||||
- 典型反应时间；
|
||||
- 疲劳对操作的影响。
|
||||
|
||||
2. **分析可预见的人为错误**（在正常与极端条件下）：
|
||||
- 误按按钮；
|
||||
- 忽略警告信息；
|
||||
- 输入错误数据。
|
||||
|
||||
3. **识别高风险场景**：
|
||||
- 错误后果特别严重的场合（如发射控制、生命支持系统等）。
|
||||
|
||||
4. **制定具体人因工程需求**：
|
||||
- 出错消息的颜色（如红色）和最小持续时间（≥5秒）；
|
||||
- 关键按钮的物理布局（如置于右手易达区）；
|
||||
- 听觉信号参数（如蜂鸣音频率、音量）。
|
||||
|
||||
5. **确保符合标准**：
|
||||
- 所有需求应遵循适用的人机工程标准（如 MIL-STD-1472、GJB438B 等）。
|
||||
|
||||
## 输出
|
||||
生成一份结构化的人因工程需求清单，明确包含针对人为错误的缓解措施。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: 定义输入组成规则
|
||||
description: 为符合GJB 438B标准的软件定义结构化输入的六类组成规则（长度、格式、标记、次序、标点、制约）。当软件具有严格的输入格式要求且需在文档4.2.3节中明确输入规则时使用本技能。
|
||||
---
|
||||
|
||||
# 定义输入组成规则
|
||||
|
||||
## 何时使用
|
||||
- 软件接收结构化输入
|
||||
- 需遵循GJB 438B标准中4.2.3节“组成规则条目”的要求
|
||||
- 输入处理模块需要明确、可验证的输入规范
|
||||
|
||||
## 执行步骤
|
||||
1. **确认前提条件**：确保软件已定义输入格式（4.2.2）和输入词汇（4.2.4），并与之保持一致。
|
||||
2. **逐项定义六类规则**：
|
||||
- **长度限制**：指定输入事务的最大/最小字符数或字段数量。
|
||||
- **格式约定**：说明对齐方式、大小写、空格等排版要求。
|
||||
- **标记方法**：定义用于标识主数据集合的关键标识符及其用法。
|
||||
- **次序要求**：明确输入项的顺序、位置及是否可选。
|
||||
- **标点符号**：规定用于分隔字段、数据组或表示开始/结束的符号（如斜线、星号、空格等）。
|
||||
- **制约条件**：列出禁止使用的字符、参数组合或其他限制。
|
||||
3. **提供正反示例**：每条规则必须附带正确与错误用法的具体示例。
|
||||
4. **增加验证方法**（如适用）：对复杂规则，提供简易验证手段帮助用户确认输入合规性。
|
||||
5. **交叉检查一致性**：确保所有规则与4.2.2（输入格式）和4.2.4（输入词汇）无冲突。
|
||||
|
||||
> 注意：仅适用于需要严格输入格式的软件系统。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: 定义接口通信方法特征
|
||||
description: 当接口涉及数据或信号传输（如网络接口、通信链路、数据传输通道）时，使用本技能定义其完整的通信方法特征。适用于系统工程、接口设计和GJB438B合规场景，确保通信链路在带宽、格式、流控、安全等8个维度上明确一致。
|
||||
---
|
||||
|
||||
# 定义接口通信方法特征
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及远程或跨系统通信
|
||||
- 存在数据或信号传输需求
|
||||
- 需编写接口设计说明文档（如依据GJB438B）
|
||||
|
||||
## 执行步骤
|
||||
1. 为每个通信接口分配项目唯一的标识符。
|
||||
2. 明确通信链路特性：带宽（bps）、频率、传输介质及其物理/电气特性。
|
||||
3. 定义消息格式化规则，包括帧结构、头尾标识、校验方式。
|
||||
4. 规定流控制机制，如序列编号方案和缓冲区分配策略。
|
||||
5. 指明数据传送速率，区分周期性与非周期性传输，并说明传输间隔（秒）。
|
||||
6. 确定路由策略、寻址机制和命名约定（如IP地址、设备ID规则）。
|
||||
7. 描述传输服务特性，包括优先级划分和等级分类。
|
||||
8. 落实安全性/保密性措施，如加密算法、用户鉴别、逻辑隔离和操作审核日志。
|
||||
|
||||
> **注意**：若通信双方存在实现差异（如一方用TCP，另一方期望UDP），需明确说明。可引用标准协议（如TCP/IP、MIL-STD-1553）替代详细描述。
|
||||
|
||||
## 输出结果
|
||||
生成结构化的接口通信方法特征清单，用于接口设计说明文档。
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: define-interface-protocol-characteristics-2
|
||||
description: 当接口使用标准化或自定义通信协议时，用于系统化定义协议的关键特征，包括标识、层级、打包机制、错误处理、同步流程和状态报告。适用于网络接口、软件组件接口及跨系统通信接口的设计阶段。
|
||||
---
|
||||
|
||||
# 定义接口协议特征
|
||||
|
||||
## 何时使用
|
||||
- 接口基于明确的通信协议（如 HTTP、MQTT、自定义二进制协议等）
|
||||
- 存在多个实体间的交互需求，需规范数据交换行为
|
||||
- 正在编写《接口设计说明》文档，需结构化描述协议行为
|
||||
- 不适用于无协议栈的直接硬件连接（如 GPIO、模拟信号线）
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **分配唯一协议标识符**：为当前协议分配项目内唯一的名称或 ID，确保可追溯性。
|
||||
2. **明确协议层级**：指定协议在 OSI 或 TCP/IP 模型中的位置（如应用层、传输层），记录为变量 `protocol_level`。
|
||||
3. **定义打包机制**：
|
||||
- 描述数据分段与重组规则
|
||||
- 说明路由选择逻辑
|
||||
- 规定寻址方式（如 IP 地址、设备 ID、主题名）
|
||||
4. **规定错误处理机制**：
|
||||
- 指定合法性检查方法（如 CRC 校验、校验和）
|
||||
- 定义错误检测与纠正策略
|
||||
- 设定故障恢复流程，包括重传策略和超时处理，并设置 `retransmission_limit`（最大重传次数）
|
||||
5. **描述同步过程**：
|
||||
- 连接建立：定义握手协议（如 SYN/ACK、CONNECT 请求）
|
||||
- 连接保持：配置心跳机制，设定 `heartbeat_interval`（心跳间隔，单位：秒）
|
||||
- 连接终止：实现优雅关闭流程（如 FIN 握手、DISCONNECT 通知）
|
||||
6. **定义状态报告机制**：
|
||||
- 列出所有状态码及其含义
|
||||
- 规范实体标识格式（如 UUID、MAC 地址）
|
||||
- 描述运行时报告内容（如吞吐量、延迟、错误率等性能统计）
|
||||
|
||||
## 输出要求
|
||||
生成结构化的协议特征描述，可直接引用至《接口设计说明》文档中，确保开发、测试与集成团队对协议行为理解一致。
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
name: 定义接口协议特征
|
||||
description: 当接口使用通信协议（如HTTP、MIL-STD等）进行交互时，使用本技能定义其协议层特征。适用于存在协议栈交互的CSCI或系统组件，确保协议在打包、错误控制、同步等6个维度上清晰一致，符合GJB438B等规范要求。
|
||||
---
|
||||
|
||||
# 定义接口协议特征
|
||||
|
||||
## 何时使用
|
||||
- 接口依赖特定通信协议进行交互
|
||||
- 需明确协议在不同实体间的实现一致性
|
||||
- 编写接口设计说明或协议适配文档
|
||||
|
||||
## 执行步骤
|
||||
1. 为每个接口协议分配项目唯一的标识符。
|
||||
2. 明确协议的优先级别或层次（如应用层、传输层）。
|
||||
3. 定义打包机制，包括拆包、重组、路由和寻址方式。
|
||||
4. 规定合法性检查、错误控制和恢复过程。
|
||||
5. 描述同步机制，包括连接建立、保持和终止流程。
|
||||
6. 说明状态、标识及其他报告特性（如心跳、状态码）。
|
||||
|
||||
> **注意**：若协议在不同实体间存在差异（如一方支持重传，另一方不支持），必须明确标注。可直接引用协议标准文档（如RFC、MIL-STD）避免重复定义。
|
||||
|
||||
## 输出结果
|
||||
生成结构化的协议特征表，包含6个维度的完整定义。
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
name: Define Software Test Environment Specification
|
||||
description: 在编制《软件测试计划》且存在多现场测试需求时，使用本技能详细定义每个测试现场的测试环境配置，包括软硬件、材料、网络拓扑、权属信息及差异性分析，以确保测试可重复性和结果有效性。
|
||||
---
|
||||
|
||||
# 定义软件测试环境规范
|
||||
|
||||
## 何时使用
|
||||
- 正在编制《软件测试计划》；
|
||||
- 存在多个测试现场或验证平台；
|
||||
- 需要确保测试环境与目标运行环境的一致性或明确差异影响。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **描述软件项**
|
||||
- 按名称、编号、版本列出操作系统、编译器、通信软件、应用软件、数据库、测试工具等；
|
||||
- 说明每项用途及存储介质（如磁带、磁盘）；
|
||||
- 标识由测试现场提供的项目；
|
||||
- 注明保密处理要求。
|
||||
|
||||
2. **描述硬件和固件项**
|
||||
- 列出计算机、接口设备、通信设备、数据整理设备、外围设备（如打印机）、专用测试设备（如消息生成器、计时器）；
|
||||
- 说明用途、所需数量与使用时间；
|
||||
- 标识现场提供项；
|
||||
- 注明保密要求。
|
||||
|
||||
3. **补充其他项**
|
||||
- 提供网络拓扑图；
|
||||
- 列出未包含在上述类别中的特殊设备。
|
||||
|
||||
4. **列出其他材料**
|
||||
- 包括手册、软件清单、测试数据介质、输出样本等；
|
||||
- 明确区分交付项与现场提供项。
|
||||
|
||||
5. **说明权属信息**
|
||||
- 描述所有者特性、需方权利、许可证状态。
|
||||
|
||||
6. **制定环境部署计划**
|
||||
- 说明获取、安装、测试和控制每个环境元素的方法。
|
||||
|
||||
7. **执行差异性分析**
|
||||
- 对比测试环境与目标运行环境；
|
||||
- 说明差异对测试结果有效性的影响。
|
||||
|
||||
8. **安排测试人员**
|
||||
- 明确所需技能、职责分工、轮班需求及培训计划。
|
||||
|
||||
## 输出成果
|
||||
生成一份完整的测试环境配置清单，确保测试过程可重复、结果可追溯，并支持多现场一致性验证。
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: 描述后台处理要求
|
||||
description: 当软件包含批处理、脱机处理或后台处理（即用户不直接调用但由系统自动执行的处理）时，使用本技能在GJB 438B文档第5.4节中完整描述这些处理的功能、执行条件及用户责任。适用于需符合GJB 438B标准的软件需求规格说明编制场景。
|
||||
---
|
||||
|
||||
# 描述后台处理要求
|
||||
|
||||
## 何时使用
|
||||
- 软件系统包含批处理、脱机处理或后台处理逻辑
|
||||
- 这些处理未在5.3节（用户可调用功能）中描述
|
||||
- 需要明确区分系统自动行为与用户责任
|
||||
- 编制符合GJB 438B标准的软件需求规格说明（SRS）
|
||||
|
||||
## 执行步骤
|
||||
1. **识别所有后台处理**：列出所有未被用户直接调用且未在5.3节中涵盖的处理，包括：
|
||||
- 批处理（如夜间数据汇总）
|
||||
- 脱机处理（如离线数据校验）
|
||||
- 后台处理（如定时任务、服务守护进程）
|
||||
|
||||
2. **详细描述每种处理**：对每项处理说明：
|
||||
- 功能目的
|
||||
- 触发条件或执行时机
|
||||
- 输入来源（是否依赖用户准备）
|
||||
- 输出结果及去向
|
||||
|
||||
3. **明确用户责任**：清晰界定用户在支持该处理过程中需承担的责任，包括：
|
||||
- 必须提供的输入数据或配置
|
||||
- 处理前需完成的准备工作
|
||||
- 需监控的状态或日志
|
||||
- 异常发生时的应对措施
|
||||
|
||||
4. **区分自动与手动部分**：确保描述中明确划分哪些由系统自动完成，哪些依赖用户干预。
|
||||
|
||||
> 注意：本技能不适用于用户直接交互的功能（此类内容应归入5.3节）。
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: 描述系统执行方案
|
||||
description: 当系统包含多个交互部件且存在动态行为（如任务调度、组件交互或运行时状态变化）时，使用本技能生成标准化的系统动态行为描述。适用于软件架构设计、实时系统开发或系统仿真场景，用于明确控制流、数据流、并发模型和异常处理等关键动态特性。
|
||||
---
|
||||
|
||||
# 描述系统执行方案
|
||||
|
||||
## 何时使用
|
||||
- 系统由多个交互组件构成
|
||||
- 存在动态交互需求（如任务切换、状态转换、中断响应）
|
||||
- 需要为实现、验证或仿真提供清晰的运行时行为模型
|
||||
- 系统为实时或分布式架构，需强调时间约束、确定性或容错机制
|
||||
|
||||
## 执行步骤
|
||||
1. **选择合适的图示类型**（如UML序列图、活动图、状态机图、时序图），结合文字说明描述系统动态关系。
|
||||
2. **覆盖以下适用方面**：
|
||||
- **执行控制流**：程序调用顺序、任务切换逻辑
|
||||
- **数据流**：数据在组件间的传递路径与格式
|
||||
- **动态控制序列**：系统启动、运行、关闭的时序逻辑
|
||||
- **状态转换**：定义状态机模型及触发条件
|
||||
- **时序关系**：关键事件的时间约束与先后顺序
|
||||
- **部件优先级**：任务或进程的调度优先级规则
|
||||
- **中断处理**：中断源识别、响应机制及嵌套处理规则
|
||||
- **异常处理**：错误传播路径与恢复流程
|
||||
- **并发执行**：采用的并发模型（如多线程、事件驱动、Actor模型）
|
||||
- **动态资源管理**：运行时内存或对象的分配与释放策略
|
||||
- **动态组件生命周期**：运行时创建或销毁的组件及其触发条件
|
||||
3. **针对特定系统类型强化描述**：
|
||||
- **实时系统**：突出时间约束、截止期限和行为确定性
|
||||
- **分布式系统**：说明网络延迟影响、消息一致性及容错机制
|
||||
4. **输出结果**：生成可用于验证、实现或仿真的系统动态行为模型。
|
||||
|
||||
> 提示：若系统为静态或无交互部件，可简化或省略此描述。
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: 检测无效知识单元
|
||||
description: 当输入内容仅为孤立数字、符号或无上下文片段（如仅包含“93”）且无法构成可解释的概念、规则或过程时，使用本技能判定其为无效知识单元并返回提示。适用于数据预处理、知识提取流水线中识别低质量或缺失语义的内容。
|
||||
---
|
||||
|
||||
# 检测无效知识单元
|
||||
|
||||
## 何时使用
|
||||
- 输入文本仅包含孤立数值（如“93”）、标点或无意义占位符
|
||||
- 文本缺乏单位、上下文、解释性语言或关联概念
|
||||
- 在自动化知识提取流程中需过滤无法形成可操作知识的内容
|
||||
|
||||
## 如何执行
|
||||
1. 检查源文本是否包含除孤立数字、符号或无上下文片段之外的语义内容。
|
||||
2. 若文本仅为孤立数值（例如“93”）且无任何附加说明、单位、上下文或关联概念，则判定为无法构成有效知识单元。
|
||||
3. 返回标准化提示：“提示：源内容不足以形成可操作或可复用的知识单元”。
|
||||
4. 将该结果标记为 Alert 类型输出，用于上游系统记录或跳过后续处理。
|
||||
|
||||
> 注意：此类孤立数值可能代表页码、编号或占位符，但因缺乏应用逻辑、条件或解释，不满足知识单元提取标准。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: Draft Military Software Development Task Document
|
||||
description: 编制军用软件研制任务书（SDTD），用于在启动军用软件开发项目时明确开发目的、技术要求、质量控制、验收标准等核心内容，作为后续所有开发活动的基础和依据。当项目已立项且存在合同或上级指令时使用本技能。
|
||||
---
|
||||
|
||||
# Draft Military Software Development Task Document
|
||||
|
||||
## When to Use
|
||||
- 启动军用软件开发项目时
|
||||
- 需要为计算机软件配置项（CSCI）建立权威技术依据时
|
||||
- 存在合同、上级指令或项目立项文件时
|
||||
|
||||
## How to Execute
|
||||
|
||||
1. **明确文档目的**：描述软件开发的目的、目标、主要任务、功能及性能指标，作为开发全过程的基础和约束。
|
||||
|
||||
2. **编制以下核心内容**：
|
||||
- **运行环境要求**：说明CSCI运行所需的硬件和软件环境。
|
||||
- **技术要求**：详细规定功能、性能、输入/输出、数据处理、接口、固件及关键性要求。
|
||||
- **设计约束**：列出影响软件设计的限制条件。
|
||||
- **质量控制要求**：定义软件关键性等级、适用标准、文档要求、配置管理、测试策略及分承制方管理要求。
|
||||
- **验收和交付要求**：明确验收准则、交付形式（如介质、数量）、交付文档清单及版权保护措施。
|
||||
- **软件保障要求**：描述软件全生命周期中的保障措施。
|
||||
- **进度和里程碑**：制定项目进度计划、关键里程碑及需方参与的评审节点。
|
||||
|
||||
3. **确保合规性**：遵循GJB 438B-2009标准，SDTD应作为合同技术附件或独立技术文件发布。
|
||||
|
||||
4. **验证完整性**：确认不缺少任何关键要素，确保其可作为后续开发、测试和验收的权威依据。
|
||||
|
||||
> 注意：本技能适用于军用软件开发项目，特别是涉及CSCI的场景。
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
name: 建立双向需求可追踪性
|
||||
description: 为子系统级接口实体、CSCI 或配置项建立双向需求可追踪性链接，确保每个需求均可追溯至其上游来源并链接至下游实现。当处理子系统级或更低层级的接口实体且已存在多层级需求体系和完成系统需求分解时使用此技能。
|
||||
---
|
||||
|
||||
# 建立双向需求可追踪性
|
||||
|
||||
## 何时使用
|
||||
- 实体类型为**子系统级接口实体**、**CSCI** 或 **配置项**；
|
||||
- 系统需求已分解为多层级结构；
|
||||
- 需要支持变更影响分析或合规性验证。
|
||||
|
||||
> ⚠️ 注意：系统级接口实体不适用本规则。
|
||||
|
||||
## 执行步骤
|
||||
1. **正向追踪**：为规格说明中的每个需求建立链接，指向其来源的系统或子系统需求 ID（`source_requirement_id`）。
|
||||
2. **反向追踪**：为每个分配给本实体的系统需求建立链接，指向本规格说明中对应的实现需求。
|
||||
3. **处理无法直接追踪的需求**：
|
||||
- 若需求由系统架构设计导出（如 CSCI 间接口），则追踪至“系统实现”类通用需求；
|
||||
- 或追踪至产生该需求的具体设计决策文档，并记录 `derived_reason`。
|
||||
4. **实现方式**：使用注释、表格或专用追踪矩阵，确保每个需求至少有一个上游和一个下游链接。
|
||||
5. **验证与维护**：定期检查追踪完整性；对缺失链接，必须说明原因并正式记录。
|
||||
|
||||
## 输出
|
||||
生成双向需求追踪矩阵，支持后续的变更影响分析。
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: generate-software-configuration-management-report
|
||||
description: 生成符合GJB 438B-2009要求的软件配置管理报告（SCMR），用于在军用软件项目结束或阶段性完成时，系统总结配置管理活动并提供有效性证据。当用户需要为军用软件项目编制SCMR、支持项目验收或满足质量保证要求时使用本技能。
|
||||
---
|
||||
|
||||
# 编制软件配置管理报告（SCMR）
|
||||
|
||||
## 何时使用
|
||||
- 军用软件项目已完成或达到阶段性里程碑
|
||||
- 已实施软件配置管理过程
|
||||
- 需要向质量保证团队、配置管理团队或项目干系人提交配置管理总结文档
|
||||
- 准备项目验收材料，需提供配置管理有效性的客观证据
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **明确报告目的**：描述软件整个研制/开发过程中配置管理的实施情况，证明其完整性、真实性和可追溯性。
|
||||
|
||||
2. **收集必要数据**：确保覆盖整个研制周期，不得遗漏关键配置管理活动。
|
||||
|
||||
3. **按以下结构编写SCMR内容**：
|
||||
- **a) 软件配置管理情况综述**：概述整体实施情况
|
||||
- **b) 软件配置管理基本信息**：包括项目基本信息、配置管理策略等
|
||||
- **c) 专业组划分及权限分配**：说明配置管理组织结构和权限设置
|
||||
- **d) 配置项记录**：列出所有配置项及其标识（configuration_item）
|
||||
- **e) 变更记录**：记录所有变更请求（change_request_id）及其处理结果
|
||||
- **f) 基线记录**：说明各基线（如功能基线、分配基线、产品基线等，baseline_type）的建立与维护
|
||||
- **g) 入库记录**：配置项入库操作日志
|
||||
- **h) 出库记录**：配置项出库操作日志
|
||||
- **i) 审核记录**：配置审核活动详情
|
||||
- **j) 备份记录**：配置项备份操作记录
|
||||
- **k) 测量数据**：配置管理相关度量指标
|
||||
|
||||
4. **验证报告完整性**：确保数据真实、完整、可追溯，且与软件研制总结报告协调一致。
|
||||
|
||||
5. **提交用于项目验收**：SCMR作为GJB 438B-2009新增文档，应与其他交付物一并提交。
|
||||
|
||||
> 注意：本报告必须覆盖整个研制过程，不能仅反映部分阶段。
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
name: GJB 438B 引用文件处理规则
|
||||
description: 在实施 GJB 438B-2009 标准时，用于正确处理引用文件的版本适用性、分类规则及合规性检查。当用户需要引用标准中提及的文件（如 GB/T 11457 或 GJB 2786A-2009）或进行合规性验证时使用本技能。
|
||||
---
|
||||
|
||||
# GJB 438B 引用文件处理规则
|
||||
|
||||
## 何时使用
|
||||
- 在编制符合 GJB 438B-2009 的文档时需引用外部标准
|
||||
- 需确定某引用文件是否适用于当前项目
|
||||
- 进行标准实施的合规性检查
|
||||
- 决定是否可使用引用文件的更新版本
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 1. 判断引用类型
|
||||
- **注日期/版次的引用**：仅所注版本适用；后续修订不自动适用，但鼓励评估最新版本可行性。
|
||||
- **未注日期/版次的引用**：自动适用该文件的最新版本。
|
||||
|
||||
### 2. 确认适用版本
|
||||
- 查阅 GJB 438B-2009 中列出的具体引用文件（如 GB/T 11457、GJB 2786A-2009）。
|
||||
- 根据引用类型确定实际适用的版本（`applicable_version`）。
|
||||
|
||||
### 3. 实施建议
|
||||
- 在项目初期明确所有引用文件及其版本。
|
||||
- 若对注日期引用文件拟使用更新版本，必须执行影响分析。
|
||||
- 在文档中清晰标注所采用的引用文件版本。
|
||||
- 记录版本选择的理由及任何偏离行为。
|
||||
|
||||
### 4. 合规性检查
|
||||
- 验证实际使用的引用文件版本是否符合 GJB 438B-2009 要求。
|
||||
- 确保术语使用与 GB/T 11457 和 GJB 2786A-2009 保持一致。
|
||||
- 记录并说明任何不符合引用规则的情况。
|
||||
|
||||
> 注意：不得随意替换引用文件版本，必须严格遵循标准中的引用规则。
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: GJB 438B附录类型识别与应用
|
||||
description: 本技能用于在使用GJB 438B-2009标准编制或审核文档时，准确区分规范性附录（必须遵守）与资料性附录（仅供参考），并据此执行相应的文档处理流程。当用户涉及军用软件文档的编写、审查或合规性验证时应触发此技能。
|
||||
---
|
||||
|
||||
# GJB 438B附录类型识别与应用
|
||||
|
||||
## 何时使用
|
||||
- 正在依据GJB 438B-2009标准编制技术文档
|
||||
- 审核他人提交的符合GJB 438B-2009的文档
|
||||
- 需要判断某附录内容是否具有强制约束力
|
||||
|
||||
## 如何执行
|
||||
|
||||
### 第一步：识别附录标识符
|
||||
确认所处理附录的字母编号（如A、B、F、AA等）。
|
||||
|
||||
### 第二步：对照附录类型清单
|
||||
- **规范性附录（必须遵守）**：A, B, C, D, E, G, H, I, L, M, N, O, P, Q, R, S
|
||||
- **资料性附录（仅供参考）**：F, J, K, T, U, V, W, X, Y, Z, AA, BB
|
||||
|
||||
### 第三步：应用相应规则
|
||||
- 若为**规范性附录**：严格按照其格式和内容要求执行，不得擅自修改；文档审核时必须验证其符合性。
|
||||
- 若为**资料性附录**：可参考其结构和建议，根据项目实际情况调整内容；不作为强制合规项。
|
||||
|
||||
### 第四步：记录决策依据
|
||||
在文档或审核记录中明确标注所用附录的类型及其合规处理方式，确保可追溯。
|
||||
|
||||
> 注意：附录类型直接决定其法律与标准效力，错误归类可能导致文档不合规或验收失败。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: GJB438B 软件文档章节组织
|
||||
description: 根据 GJB 438B-2009 标准，为软件用户手册、输入/输出手册或中心操作员手册设计符合规范的章节结构。当需要编写符合该国军标的软件使用类文档时使用本技能。
|
||||
---
|
||||
|
||||
# GJB438B 软件文档章节组织
|
||||
|
||||
## 何时使用
|
||||
- 正在编写符合 GJB 438B-2009 标准的软件用户手册、软件输入/输出手册或软件中心操作员手册
|
||||
- 需要根据被文档化软件的特性选择合适的章节组织逻辑
|
||||
- 文档内容涉及菜单、命令语言或功能说明
|
||||
|
||||
## 执行步骤
|
||||
1. **评估软件特性**：分析被文档化软件的使用场景、用户角色和功能特点，确定最适合的章节组织方式。
|
||||
2. **选择组织逻辑**（四选一）：
|
||||
- 按用户工作的组织结构划分章节
|
||||
- 按用户被分配的位置划分章节
|
||||
- 按用户的工作现场划分章节
|
||||
- 按用户必须完成的任务划分章节
|
||||
3. **应用专用章节结构**（如适用）：
|
||||
- 第5章：菜单指南
|
||||
- 第6章：命令语言指南
|
||||
- 第7章：功能指南
|
||||
4. **扩展复杂内容**：若某类规程过长或过于复杂，可按相同条结构新增第6章、第7章等，确保新章节标题与所选组织逻辑一致。
|
||||
5. **统一描述风格**：对同类内容（如菜单项、事务流程）采用一致的描述格式和术语。
|
||||
|
||||
> 注意：本技能仅适用于软件类技术文档，不适用于非软件类技术文档。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: GJB438B 软件环境描述要求
|
||||
description: 按照 GJB 438B-2009 标准，在软件输入/输出手册或操作员手册中完整描述软件运行所需的五类必需资源。当编写包含“3.3 软件环境”条目的技术文档时使用本技能。
|
||||
---
|
||||
|
||||
# GJB438B 软件环境描述要求
|
||||
|
||||
## 何时使用
|
||||
- 正在编写软件输入/输出手册或软件中心操作员手册
|
||||
- 文档需包含“3.3 软件环境”条目
|
||||
- 软件依赖特定运行环境（如集中式或网络环境）
|
||||
|
||||
## 执行步骤
|
||||
1. **基于集中式/网络环境假定**：所有环境描述应以软件部署在计算机中心、集中式系统或网络环境中为前提。
|
||||
2. **列出五类必需资源**，每类需提供具体规格、版本号、数量等详细信息：
|
||||
a) **计算机设备**：终端、打印机、其他 I/O 设备
|
||||
b) **通信设备**
|
||||
c) **其他软件**：操作系统、数据库、网络软件、实用程序等
|
||||
d) **格式、规程或手工操作**
|
||||
e) **其他设施、设备或资源**
|
||||
3. **操作员手册额外要求**（如适用）：
|
||||
- 内存数量要求
|
||||
- 辅助存储数量要求
|
||||
- 永久文件要求
|
||||
- 紧急恢复所需的数据库或数据文件
|
||||
4. **补充保密性说明**：若资源涉及保密要求，应明确标注其安全等级或访问控制措施。
|
||||
|
||||
> 注意：本技能不适用于无需特定运行环境的软件文档。
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: 计算机硬件资源使用需求规范制定
|
||||
description: 用于在需控制CSCI或嵌入式软件硬件资源消耗时，明确定义各类硬件资源的最大使用限额及测量条件。适用于资源受限系统，当需确保资源使用可测试且与系统级分配一致时使用本技能。
|
||||
---
|
||||
|
||||
# 计算机硬件资源使用需求规范制定
|
||||
|
||||
## 何时使用
|
||||
- 开发对象为CSCI、嵌入式软件或资源受限系统；
|
||||
- 需限制硬件资源消耗（如CPU、内存、I/O等）；
|
||||
- 资源充足系统可简化此过程，但资源受限场景必须执行。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **定义最大允许使用量**，覆盖以下硬件资源类型：
|
||||
- 处理机能力（如CPU占用率百分比）；
|
||||
- 内存容量（如RAM字节数）；
|
||||
- I/O设备能力（如磁盘IOPS）；
|
||||
- 辅助存储容量（如硬盘GB数）；
|
||||
- 通信/网络设备能力（如带宽Mbps）。
|
||||
|
||||
2. **明确资源测量条件**，例如：
|
||||
- 典型负载下的使用情况；
|
||||
- 最坏情况（worst-case）下的峰值消耗；
|
||||
- 特定事件（如启动、故障恢复）触发时的瞬时资源占用。
|
||||
|
||||
3. **使用标准化单位**，如处理器能力百分比、KB/s、MB、Mbps等，确保可比性和可测性。
|
||||
|
||||
4. **确保资源限额可测试**，并与系统级资源分配计划保持一致，避免超配或冲突。
|
||||
|
||||
## 输出结果
|
||||
生成一份硬件资源使用上限表，包含资源类型、最大使用量、测量条件及单位，作为性能验证和系统集成的依据。
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
name: 标识并图示外部接口
|
||||
description: 当CSCI（计算机软件配置项）存在与其他系统、配置项或用户的外部接口时，使用本技能为其分配唯一标识并绘制接口关系图。适用于系统集成和GJB438B合规场景，确保接口关系可视化且可追溯。
|
||||
---
|
||||
|
||||
# 标识并图示外部接口
|
||||
|
||||
## 何时使用
|
||||
- CSCI存在外部接口（与HWCI、其他CSCI、用户等）
|
||||
- 需编制接口设计说明文档
|
||||
- 仅适用于有外部接口的CSCI
|
||||
|
||||
## 执行步骤
|
||||
1. 为每个外部接口分配项目唯一的标识符（interface_id）。
|
||||
2. 通过名称、编号、版本、引用文档等方式指明接口实体（如系统、配置项、用户）。
|
||||
3. 明确声明哪些实体具有固定接口特性（需制定接口需求），哪些正在开发中（已有各自接口需求）。
|
||||
4. 使用一张或多张接口图描述接口关系，图中必须体现：
|
||||
- 接口方向（数据流向）；
|
||||
- 实体间交互方式；
|
||||
- 关键接口属性（如实时性、带宽）。
|
||||
5. 将接口图作为正式文档组成部分，支持后续接口需求细化。
|
||||
|
||||
## 输出结果
|
||||
生成带唯一ID的接口清单及配套接口图，用于系统集成与文档交付。
|
||||
129
skills/GJB438B-2009_prd_skills/index.md
Normal file
129
skills/GJB438B-2009_prd_skills/index.md
Normal file
@@ -0,0 +1,129 @@
|
||||
# 《78Dc6F8D-6Aec-44B4-9Bea-A3F0B65Cb8D0》技能集索引
|
||||
|
||||
本技能集源自标准文档《78Dc6F8D-6Aec-44B4-9Bea-A3F0B65Cb8D0》，聚焦于军用软件工程全生命周期中的关键能力，涵盖需求分析、接口定义、系统设计、文档编制、测试环境规范、配置管理及安全性要求等多个核心领域。这些技能旨在支持符合GJB 438B等军用软件开发标准的高质量软件交付，适用于系统工程师、软件架构师、需求分析师及技术文档撰写人员。
|
||||
|
||||
## Available Skills
|
||||
|
||||
| Skill | Description | Use When |
|
||||
|-------|-------------|----------|
|
||||
| [gjb438b-software-document-chapter-organization](gjb438b-software-document-chapter-organization/SKILL.md) | 根据 GJB 438B-2009 标准设计软件使用类文档的章节结构 | 当需要编写符合该国军标的软件用户手册、输入/输出手册或中心操作员手册时使用 |
|
||||
| [data-element-interface-characteristics-definition](data-element-interface-characteristics-definition/SKILL.md) | 定义接口中单个数据元素的9类特征 | 当接口需明确描述字段级数据属性（如名称、类型、精度、保密性等）时使用 |
|
||||
| [establish-bidirectional-requirements-traceability](establish-bidirectional-requirements-traceability/SKILL.md) | 为子系统级接口实体、CSCI 或配置项建立双向需求可追踪性链接 | 当处理子系统级或更低层级的接口实体且已存在多层级需求体系和完成系统需求分解时使用 |
|
||||
| [identify-and-diagram-external-interfaces](identify-and-diagram-external-interfaces/SKILL.md) | 为CSCI的外部接口分配唯一标识并绘制接口关系图 | 当CSCI存在与其他系统、配置项或用户的外部接口时使用 |
|
||||
| [define-interface-communication-characteristics](define-interface-communication-characteristics/SKILL.md) | 定义接口的数据或信号传输通信方法特征 | 当接口涉及网络、通信链路或数据传输通道时使用 |
|
||||
| [define-interface-protocol-characteristics](define-interface-protocol-characteristics/SKILL.md) | 定义接口使用的通信协议层特征 | 当接口使用通信协议（如HTTP、MIL-STD等）进行交互时使用 |
|
||||
| [quick-reference-guide-creation](quick-reference-guide-creation/SKILL.md) | 为复杂软件系统创建或评估快速参考指南内容 | 当软件具备较高复杂度且存在常用功能需供用户快速查阅时使用 |
|
||||
| [define-data-element-characteristics](define-data-element-characteristics/SKILL.md) | 为每个数据字段定义完整的特征集以生成标准化数据字典条目 | 当接口、消息或数据库涉及数据元素传输时使用 |
|
||||
| [interface-identification-and-specification](interface-identification-and-specification/SKILL.md) | 为系统接口、CSCI接口和用户接口分配唯一标识、绘制接口图并编制结构化接口需求规格说明 | 当系统包含多个实体且需确保接口可验证、可测试时使用 |
|
||||
| [hardware-resource-usage-requirements-specification](hardware-resource-usage-requirements-specification/SKILL.md) | 明确定义CSCI或嵌入式软件硬件资源的最大使用限额及测量条件 | 当需控制软件硬件资源消耗且确保资源使用可测试并与系统级分配一致时使用 |
|
||||
| [specify-physical-interface-compatibility](specify-physical-interface-compatibility/SKILL.md) | 定义物理连接部件的几何、机械和电气兼容性参数 | 当接口包含硬件接口、机电连接器或电源接口时使用 |
|
||||
| [需求优先级与关键性标识](需求优先级与关键性标识/SKILL.md) | 对系统、软件或接口需求进行优先级和关键性等级标识 | 当需求对安全性、保密性或任务成功的影响程度不同时使用 |
|
||||
| [system-component-identification-and-description](system-component-identification-and-description/SKILL.md) | 为HWCI、CSCI和人工操作流程等系统部件分配唯一标识并说明其特性 | 当进行系统架构文档编制且已存在系统分解结果和部件清单时使用 |
|
||||
| [合格性方法定义与分配](合格性方法定义与分配/SKILL.md) | 为已文档化的需求分配标准合格性方法（演示、测试、分析、审查或特殊方法） | 当存在需验证的需求时使用 |
|
||||
| [gjb438b-software-environment-description](gjb438b-software-environment-description/SKILL.md) | 按照 GJB 438B-2009 标准描述软件运行所需的五类必需资源 | 当编写包含“3.3 软件环境”条目的技术文档时使用 |
|
||||
| [software-usage-procedure-specification](software-usage-procedure-specification/SKILL.md) | 为GJB 438B标准中5.3.X软件使用子条编写符合要求的交互式功能描述 | 当用户需要撰写或审核软件文档中关于用户直接交互功能的处理规程时使用 |
|
||||
| [data-package-interface-characteristics-definition](data-package-interface-characteristics-definition/SKILL.md) | 定义记录、消息、文件等复合数据结构的8类特征 | 当接口传输的是由多个数据元素组成的整体单元（如报文、报表、显示界面）时使用 |
|
||||
| [define-interface-protocol-characteristics-2](define-interface-protocol-characteristics-2/SKILL.md) | 系统化定义标准化或自定义通信协议的关键特征 | 当接口使用标准化或自定义通信协议时使用 |
|
||||
| [software-development-specification-technical-requirements](software-development-specification-technical-requirements/SKILL.md) | 按国防和行业标准结构化定义软件的技术要求 | 当项目已立项且需方提出初步需求，且必须覆盖合同或上级文件要求时使用 |
|
||||
| [data-backup-and-recovery-procedures](data-backup-and-recovery-procedures/SKILL.md) | 制定符合GJB 438B标准的数据备份与恢复操作规程 | 当软件系统处理重要数据或需满足军用软件文档要求时使用 |
|
||||
| [military-software-document-structure-compliance](military-software-document-structure-compliance/SKILL.md) | 确保军用软件开发文档符合GJB 438B-2009规定的结构组成要求 | 当用户需要编制或审核军用软件开发文档时使用 |
|
||||
| [generate-software-configuration-management-report](generate-software-configuration-management-report/SKILL.md) | 生成符合GJB 438B-2009要求的软件配置管理报告（SCMR） | 当用户需要为军用软件项目编制SCMR、支持项目验收或满足质量保证要求时使用 |
|
||||
| [describe-system-execution-scheme](describe-system-execution-scheme/SKILL.md) | 生成标准化的系统动态行为描述 | 当系统包含多个交互部件且存在动态行为（如任务调度、组件交互或运行时状态变化）时使用 |
|
||||
| [define-software-test-environment-specification](define-software-test-environment-specification/SKILL.md) | 详细定义每个测试现场的测试环境配置 | 当编制《软件测试计划》且存在多现场测试需求时使用 |
|
||||
| [system-level-design-decision-specification](system-level-design-decision-specification/SKILL.md) | 记录和规范系统级设计决策 | 当系统需求已明确但未指定实现方式，且该缺失会影响系统行为时使用 |
|
||||
| [structured-data-collection-specification](structured-data-collection-specification/SKILL.md) | 定义结构化数据集合体的完整特征规范 | 当接口传输复合结构化数据且需明确其组成、约束与使用上下文时使用 |
|
||||
| [software-development-plan-structure](software-development-plan-structure/SKILL.md) | 构建覆盖合同或任务书全部条款的《软件开发计划》活动框架 | 当项目已启动且存在开发任务、需编制符合标准要求的软件开发计划时使用 |
|
||||
| [military-software-user-manual-requirements](military-software-user-manual-requirements/SKILL.md) | 判断是否需编制独立的软件用户手册并明确其核心内容 | 当软件具有用户接口且由最终用户直接运行时使用 |
|
||||
| [draft-military-software-development-task-document](draft-military-software-development-task-document/SKILL.md) | 编制军用软件研制任务书（SDTD） | 当项目已立项且存在合同或上级指令时使用 |
|
||||
| [describe-background-processing-requirements](describe-background-processing-requirements/SKILL.md) | 在GJB 438B文档第5.4节中描述批处理、脱机处理或后台处理的功能与条件 | 当软件包含用户不直接调用但由系统自动执行的处理时使用 |
|
||||
| [military-system-subsystem-specification-structure](military-system-subsystem-specification-structure/SKILL.md) | 编制符合军用标准的系统或子系统规格说明（SSS） | 当已完成运行方案说明、需详细定义系统需求且即将开展系统设计时使用 |
|
||||
| [gjb438b-appendix-type-identification](gjb438b-appendix-type-identification/SKILL.md) | 区分规范性附录与资料性附录并执行相应文档处理流程 | 当用户涉及军用软件文档的编写、审查或合规性验证时使用 |
|
||||
| [military-software-development-summary-report-evaluation](military-software-development-summary-report-evaluation/SKILL.md) | 指导编制和评估《软件研制总结报告》（SDSR） | 当军用软件研制完成、需进行项目总结或准备验收评审时使用 |
|
||||
| [military-software-operational-concept-description](military-software-operational-concept-description/SKILL.md) | 编制符合标准结构的运行方案说明（OCD）文档 | 当需要在需方、开发方、保障机构和用户之间就军用软件系统的运行方案达成共识时使用 |
|
||||
| [错误消息文档化规范](错误消息文档化规范/SKILL.md) | 为软件产生的错误消息、诊断消息创建结构化用户文档 | 当软件具备错误或诊断消息功能，且需符合GJB 438B标准第5.7条要求时使用 |
|
||||
| [detect-invalid-knowledge-unit](detect-invalid-knowledge-unit/SKILL.md) | 判定孤立数字、符号或无上下文片段为无效知识单元 | 当输入内容仅为孤立数字、符号或无上下文片段且无法构成可解释的概念、规则或过程时使用 |
|
||||
| [gjb-438b-reference-file-handling](gjb-438b-reference-file-handling/SKILL.md) | 正确处理GJB 438B-2009引用文件的版本适用性、分类规则及合规性检查 | 当用户需要引用标准中提及的文件或进行合规性验证时使用 |
|
||||
| [military-software-documentation-management](military-software-documentation-management/SKILL.md) | 定义军用软件开发项目所需的28类文档清单并指导剪裁与维护 | 当用户参与军用软件开发项目、需制定或调整项目文档体系、或处理SDP变更时使用 |
|
||||
| [define-input-composition-rules](define-input-composition-rules/SKILL.md) | 为软件定义结构化输入的六类组成规则（长度、格式、标记、次序、标点、制约） | 当软件具有严格的输入格式要求且需在文档4.2.3节中明确输入规则时使用 |
|
||||
| [csci-multi-state-mode-requirement-definition](csci-multi-state-mode-requirement-definition/SKILL.md) | 定义CSCI在不同运行情境下的状态/方式及对应需求 | 当CSCI需在不同运行情境（如空闲、战时、训练等）下表现出不同行为时使用 |
|
||||
| [csci-capability-requirement-structuring](csci-capability-requirement-structuring/SKILL.md) | 将CSCI的功能性行为按“能力”组织为结构化需求子条 | 当需要编写或重构CSCI能力需求文档章节，且已识别出若干核心能力时使用 |
|
||||
| [define-human-factors-requirements-for-hmi](define-human-factors-requirements-for-hmi/SKILL.md) | 定义CSCI所需的人因工程需求 | 当CSCI需要人工操作或监控、且包含人机界面、操作员交互系统或控制台软件时使用 |
|
||||
| [定义安全关键软件的安全性需求](定义安全关键软件的安全性需求/SKILL.md) | 识别两类危险并定义可验证的安全措施 | 当CSCI涉及人身、财产或环境安全风险时使用 |
|
||||
| [csci-qualification-method-selection](csci-qualification-method-selection/SKILL.md) | 为CSCI需求选择并应用适当的合格性方法 | 在编写或评审软件需求规格说明时，若存在需验证的CSCI需求则使用 |
|
||||
| [define-confidentiality-requirements](define-confidentiality-requirements/SKILL.md) | 定义涉密CSCI或信息安全系统的保密性环境、级别、风险及安全对策 | 当系统处理敏感或机密信息且需满足国家保密法规或军用标准时使用 |
|
||||
| [bidirectional-requirements-traceability-mapping](bidirectional-requirements-traceability-mapping/SKILL.md) | 建立CSCI需求与系统需求之间的双向可追踪性映射 | 在存在系统级需求分解且需进行变更影响分析或覆盖率验证时使用 |
|
||||
|
||||
## 快速导航（按类别分组）
|
||||
|
||||
### 需求与追溯性
|
||||
- establish-bidirectional-requirements-traceability
|
||||
- bidirectional-requirements-traceability-mapping
|
||||
- 需求优先级与关键性标识
|
||||
- csci-capability-requirement-structuring
|
||||
- csci-multi-state-mode-requirement-definition
|
||||
- define-human-factors-requirements-for-hmi
|
||||
- 定义安全关键软件的安全性需求
|
||||
- define-confidentiality-requirements
|
||||
|
||||
### 接口与数据元素定义
|
||||
- identify-and-diagram-external-interfaces
|
||||
- interface-identification-and-specification
|
||||
- define-interface-communication-characteristics
|
||||
- define-interface-protocol-characteristics
|
||||
- define-interface-protocol-characteristics-2
|
||||
- data-element-interface-characteristics-definition
|
||||
- data-package-interface-characteristics-definition
|
||||
- define-data-element-characteristics
|
||||
- define-input-composition-rules
|
||||
|
||||
### 系统与组件描述
|
||||
- system-component-identification-and-description
|
||||
- describe-system-execution-scheme
|
||||
- describe-background-processing-requirements
|
||||
- system-level-design-decision-specification
|
||||
- military-system-subsystem-specification-structure
|
||||
|
||||
### 软件开发与技术规范
|
||||
- software-development-specification-technical-requirements
|
||||
- software-usage-procedure-specification
|
||||
- define-software-test-environment-specification
|
||||
- hardware-resource-usage-requirements-specification
|
||||
- specify-physical-interface-compatibility
|
||||
|
||||
### 文档结构与合规性
|
||||
- gjb438b-software-document-chapter-organization
|
||||
- military-software-document-structure-compliance
|
||||
- gjb438b-software-environment-description
|
||||
- gjb438b-appendix-type-identification
|
||||
- gjb-438b-reference-file-handling
|
||||
- military-software-user-manual-requirements
|
||||
- quick-reference-guide-creation
|
||||
- 错误消息文档化规范
|
||||
|
||||
### 计划、报告与管理
|
||||
- software-development-plan-structure
|
||||
- draft-military-software-development-task-document
|
||||
- generate-software-configuration-management-report
|
||||
- military-software-development-summary-report-evaluation
|
||||
- military-software-documentation-management
|
||||
|
||||
### 合格性与验证
|
||||
- 合格性方法定义与分配
|
||||
- csci-qualification-method-selection
|
||||
|
||||
### 其他专项技能
|
||||
- structured-data-collection-specification
|
||||
- data-backup-and-recovery-procedures
|
||||
- military-software-operational-concept-description
|
||||
- detect-invalid-knowledge-unit
|
||||
|
||||
## 使用方法与示例提示
|
||||
|
||||
本技能集可用于指导军用软件项目中的具体任务执行。用户可结合具体场景调用对应技能名称，生成标准化输出。例如：
|
||||
|
||||
- **需求追溯**：使用 `establish-bidirectional-requirements-traceability` 技能，生成从用户需求到软件设计项的双向追溯矩阵。
|
||||
- **接口规范编写**：调用 `define-interface-protocol-characteristics` 技能，明确通信协议的数据格式、时序和错误处理机制。
|
||||
- **文档合规检查**：应用 `military-software-document-structure-compliance` 技能，验证用户手册是否符合GJB 438B章节结构要求。
|
||||
- **安全性需求定义**：通过 `定义安全关键软件的安全性需求` 技能，识别并记录软件在失效情况下的安全约束与响应措施。
|
||||
|
||||
只需在提示中明确引用技能名称，即可获得符合军用标准的专业内容输出。
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: 接口标识与需求规格说明
|
||||
description: 在编写接口设计文档或需要明确定义多个实体间交互需求时，为系统接口、CSCI接口和用户接口分配唯一标识、绘制接口图，并编制结构化的接口需求规格说明（IRS）。当系统包含多个实体（如系统、子系统、HWCI、CSCI、人工操作等）且需确保接口可验证、可测试时使用本技能。
|
||||
---
|
||||
|
||||
# 接口标识与需求规格说明
|
||||
|
||||
## 适用场景
|
||||
- 正在编写接口设计文档
|
||||
- 已识别接口边界并存在多个接口实体
|
||||
- 需要将接口需求作为系统/软件需求规格说明（SRS/SSS）的补充
|
||||
- 系统涉及外部系统或未完全定义的实体
|
||||
|
||||
## 执行步骤
|
||||
1. **分配接口唯一标识符**：为每个接口分配项目唯一ID（如 `IF-001`）。
|
||||
2. **标识接口实体**：使用名称、编号、版本和文档引用明确接口两端的实体（系统、CSCI、用户等）。
|
||||
3. **区分实体开发状态**：
|
||||
- **固定接口特性实体**：直接列出其接口需求
|
||||
- **开发/修改中实体**：说明其当前已知的接口需求
|
||||
- **外部/未涵盖实体**：以假设形式描述（例如：“当[外部系统]执行X时，[本系统]将响应Y”）
|
||||
4. **绘制接口图**：展示实体间连接、数据流向及接口类型（如同步/异步、实时/批处理）。
|
||||
5. **编制接口需求规格说明（IRS）核心内容**：
|
||||
- **范围**：接口完整标识、系统概述、文档概述
|
||||
- **引用文档**：列出相关标准、协议或数据字典
|
||||
- **接口需求章节**：
|
||||
a) 包含接口标识与接口图（复用步骤1–4）
|
||||
b) 按接口ID分节（如 `3.1 IF-001`），每节包含：
|
||||
- 接口优先级
|
||||
- 接口类型要求（如实时数据传送、数据存储检索）
|
||||
- **数据元素特征**：名称/标识符、数据类型、大小与格式、计量单位、值范围、精度、时序约束、保密性、来源与接收者
|
||||
- **数据组合体特征**（如消息、记录、文件）：结构、媒体、视听特性（颜色/字体/图标）、组合关系、保密性
|
||||
6. **引用外部标准**：可引用通信协议、数据字典或用户界面标准替代冗长描述。
|
||||
|
||||
> 注意：IRS不描述接口实现细节，仅聚焦于接口需求本身；IRS与SRS/SSS共同构成设计与合格性测试基础。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: military-software-development-summary-report-evaluation
|
||||
description: 用于指导军用软件项目在研制完成后编制和评估《软件研制总结报告》（SDSR），确保报告完整覆盖研制全过程、客观反映质量与任务指标满足情况，并为项目验收和交付决策提供依据。当军用软件研制完成、需进行项目总结或准备验收评审时使用本技能。
|
||||
---
|
||||
|
||||
# 军用软件研制总结报告（SDSR）评估要素
|
||||
|
||||
## 何时使用
|
||||
- 军用软件研制工作已全部完成
|
||||
- 需要对项目进行正式总结
|
||||
- 准备向需方提交验收材料
|
||||
- 验收评审团队需评估软件是否可交付使用
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **明确SDSR核心目的**：全面描述软件整个研制/开发过程，为项目验收和交付提供客观依据。
|
||||
|
||||
2. **确保报告包含以下必备内容**：
|
||||
- **任务来源与研制依据**：说明项目启动背景及所依据的正式文件。
|
||||
- **软件概述**：简要介绍软件的基本情况（如用途、规模、运行环境等）。
|
||||
- **软件研制过程**：
|
||||
- 概述整体研制流程
|
||||
- 说明各阶段/活动采用的方法与标准
|
||||
- 列出关键工作产品清单
|
||||
- **任务指标满足情况**：对照任务书或合同要求，逐项评估软件功能与性能指标的达成程度。
|
||||
- **质量保证情况**：
|
||||
- 描述质量保证措施的实施情况
|
||||
- 记录重大技术质量问题及其解决过程与结果
|
||||
- **配置管理情况**：
|
||||
- 说明配置管理要求
|
||||
- 描述配置管理实际执行情况
|
||||
- 列出重要的配置状态变更记录
|
||||
- **测量与分析**：提供项目度量数据（如缺陷密度、进度偏差等）及分析结论。
|
||||
- **结论部分**（关键）：
|
||||
- 评述软件工程化实施的整体效果
|
||||
- 明确说明软件是否满足任务要求
|
||||
- 给出清晰的交付建议（可交付 / 不可交付 / 有条件交付）
|
||||
|
||||
3. **遵循约束条件**：
|
||||
- 必须覆盖整个研制周期，不得遗漏关键阶段
|
||||
- 所有陈述必须基于客观数据和事实，禁止主观臆断
|
||||
|
||||
4. **注意标准依据**：SDSR是GJB 438B-2009相比GJB 438A-1997新增的关键文档，编制时应严格遵循该标准要求。
|
||||
|
||||
5. **输出结果**：形成一份结构完整、内容翔实、结论明确的《软件研制总结报告》，直接支持验收决策。
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: military-software-document-structure-compliance
|
||||
description: 确保军用软件开发文档符合GJB 438B-2009标准规定的结构组成要求。当用户需要编制或审核军用软件开发文档时使用此技能，以验证其是否包含封面、修改页、目录、正文和附录等五个基本组成部分，并遵循指定的页码编号规则和表示形式。
|
||||
---
|
||||
|
||||
# 军用软件文档结构合规性检查
|
||||
|
||||
## 何时使用
|
||||
- 编制新的军用软件开发文档时
|
||||
- 审核现有军用软件文档是否符合GJB 438B-2009标准
|
||||
- 准备文档交付物并需确保结构完整性
|
||||
|
||||
## 如何执行
|
||||
1. **确认文档包含以下五个基本组成部分**：
|
||||
- **封面**：包含文档标识及版本号、密级、编制/修订日期、文档名称、编制单位、编写、审核、批准信息
|
||||
- **修改页**：记录修改时间、修改内容及修改人
|
||||
- **目录**：列出章、条、图表、注释和附录的编号、标题及其所在页码
|
||||
- **正文**：包含文档具体内容（详细内容要求参见GJB 438B-2009第5章）
|
||||
- **附录**：提供便于单独发布和维护的信息（如图、表、分类数据），且每个附录必须在正文中被引用
|
||||
|
||||
2. **应用页码编号规则**：
|
||||
- 目录页使用小写罗马数字编号
|
||||
- 正文和附录使用阿拉伯数字顺序编号
|
||||
- 若文档分为多卷，每卷页码应重新从1开始编号
|
||||
|
||||
3. **采用清晰的表示形式**：
|
||||
- 可使用图、表、矩阵或其他可视化方式增强章条信息的可读性
|
||||
|
||||
> 注意：资料性附录结构可略有不同；电子文档格式不影响上述基本结构要求。
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
name: 军用软件文档管理与动态维护
|
||||
description: 根据GJB 2786A-2009标准，定义军用软件开发项目所需的28类文档清单，指导如何对文档进行剪裁、合并或拆分，并动态维护《软件开发计划》（SDP）以确保其与项目实际一致。当用户参与军用软件开发项目、需制定或调整项目文档体系、或处理SDP变更时使用本技能。
|
||||
---
|
||||
|
||||
# 军用软件文档管理与动态维护
|
||||
|
||||
## 何时使用
|
||||
- 项目属于军用软件开发，且采用标准生存周期
|
||||
- 需依据GJB 2786A-2009确定应交付的文档种类
|
||||
- 需对标准文档集进行定制（如合并、拆分或剪裁）
|
||||
- 需编制或动态更新《软件开发计划》（SDP）
|
||||
|
||||
## 如何执行
|
||||
|
||||
### 1. 确定标准文档清单
|
||||
根据GJB 2786A-2009，军用软件项目必须考虑以下28类文档：
|
||||
- 运行方案说明 (OCD)
|
||||
- 系统/子系统规格说明 (SSS)
|
||||
- 接口需求规格说明 (IRS)
|
||||
- 系统/子系统设计说明 (SSDD)
|
||||
- 接口设计说明 (IDD)
|
||||
- 软件研制任务书 (STD)
|
||||
- 软件开发计划 (SDP)
|
||||
- 软件配置管理计划 (SCMP)
|
||||
- 软件质量保证计划 (SQAP)
|
||||
- 软件安装计划 (SIP)
|
||||
- 软件移交计划 (STrP)
|
||||
- 软件测试计划 (STP)
|
||||
- 软件需求规格说明 (SRS)
|
||||
- 软件设计说明 (SDD)
|
||||
- 数据库设计说明 (DBDD)
|
||||
- 软件测试说明 (STD)
|
||||
- 软件测试报告 (STR)
|
||||
- 软件产品规格说明 (SPS)
|
||||
- 软件版本说明 (SVD)
|
||||
- 软件用户手册 (SUM)
|
||||
- 软件输入/输出手册 (SIOM)
|
||||
- 软件中心操作员手册 (SCOM)
|
||||
- 计算机编程手册 (CPM)
|
||||
- 计算机操作手册 (COM)
|
||||
- 固件保障手册 (FSM)
|
||||
- 软件研制总结报告 (SDSR)
|
||||
- 软件配置管理报告 (SCMR)
|
||||
- 软件质量保证报告 (SQAR)
|
||||
|
||||
> 注意：此清单适用于所有符合GJB 2786A-2009适用范围的军用软件项目。
|
||||
|
||||
### 2. 应用文档剪裁与合并规则
|
||||
当项目实际情况允许或要求对标准文档进行调整时：
|
||||
|
||||
**合并规则**：
|
||||
- 选择一个主文档（如SDP）
|
||||
- 将其他文档内容有机整合进主文档
|
||||
- 确保所有要素完整不遗漏
|
||||
- 在注释中明确说明合并情况及理由
|
||||
|
||||
**拆分规则**：
|
||||
- 拆分后各文档结构须符合标准第4.3条要求
|
||||
- 拆分前后要素保持一致
|
||||
- 在其中一个文档的注释中说明拆分情况
|
||||
|
||||
**剪裁规则**：
|
||||
- 按标准标题顺序进行剪裁
|
||||
- 若某章/条无内容，标注“本章无内容”或“本条无内容”
|
||||
- 必须说明剪裁理由
|
||||
- 整章剪裁只需在最高层级标题下标注并说明
|
||||
|
||||
### 3. 动态维护软件开发计划（SDP）
|
||||
SDP不是静态文档，必须随项目进展动态更新：
|
||||
|
||||
- **核心内容**：涵盖新开发、修改、重用、再工程、维护等所有活动
|
||||
- **必备要素**：开发过程、方法、活动途径、进度、组织资源及监督工具
|
||||
- **更新触发点**：
|
||||
- 出现重大偏差时
|
||||
- 到达项目里程碑时
|
||||
- **更新流程**：
|
||||
- 分析偏差或变化影响
|
||||
- 必要时重新策划
|
||||
- 经正式变更控制流程修订SDP
|
||||
- **拆分说明**：SDP部分内容（如SCMP、SQAP、STP）可独立成文，但需保持整体一致性
|
||||
|
||||
> 提示：SDP是项目执行的总体指导文件，必须与实际开发状态保持同步。
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: 编制军用软件运行方案说明（OCD）
|
||||
description: 当需要在需方、开发方、保障机构和用户之间就新开发或修改的军用软件系统的运行方案达成共识时，使用本技能编制符合标准结构的运行方案说明（OCD）文档。适用于系统开发前期阶段，存在明确用户需求且需建立各方共同理解基础的场景。
|
||||
---
|
||||
|
||||
# 编制军用软件运行方案说明（OCD）
|
||||
|
||||
## 何时使用
|
||||
- 系统处于开发前期阶段
|
||||
- 存在明确的用户需求
|
||||
- 需要在需方、开发方、保障机构和用户之间就系统运行方式达成共识
|
||||
- 不用于描述纯技术实现细节，也不替代详细需求规格说明
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **明确OCD核心目的**：描述系统应满足的用户需要、与现有系统或规程的关系以及使用方式。
|
||||
|
||||
2. **发挥双向沟通作用**：
|
||||
- 向开发者清晰表达用户的运行需求
|
||||
- 向用户及其他相关方传达开发者的系统设计思路
|
||||
|
||||
3. **按标准结构组织内容**：
|
||||
a) **范围**：包含系统完整标识、系统概述、文档概述
|
||||
b) **引用文档**：列出所有引用文档的详细信息
|
||||
c) **现行系统或状况**：背景目标范围、运行策略约束、系统描述、用户描述、保障方案
|
||||
d) **更改理由和实质**：更改理由、所需更改说明、更改优先级别、未纳入更改说明、假设约束
|
||||
e) **新系统或修改后系统方案**：背景目标范围、运行策略约束、系统描述、用户描述、保障方案
|
||||
f) **运行场景**：描述系统作用、用户交互、系统接口和所有状态方式（如常规、维护、培训、降级、紧急事件、备选场点、战时、平时）的示例
|
||||
g) **影响综述**：运行影响、组织影响、开发期间影响
|
||||
h) **分析建议系统**：优点概述、缺点限制概述、替代方案权衡
|
||||
i) **注释**：背景、术语、缩略语等辅助信息
|
||||
|
||||
4. **确保系统描述完整覆盖以下要素**：
|
||||
- 运行环境特性
|
||||
- 主要部件互连关系
|
||||
- 外部接口
|
||||
- 能力与功能
|
||||
- 输入输出数据流
|
||||
- 性能特性
|
||||
- 质量属性
|
||||
- 安全性与保密性规定
|
||||
|
||||
5. **根据相关方类型（需方、开发方、保障机构、用户）调整表述重点**，确保各方均能准确理解其关注内容。
|
||||
|
||||
> 注意：OCD不替代详细需求规格说明，仅用于建立高层共识。
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
name: 军用软件用户手册（SUM）适用条件与内容要求
|
||||
description: 判断军用软件是否需要编制独立的软件用户手册（SUM），并明确其必须包含的核心内容。当软件具有用户接口且由最终用户直接运行时使用本技能，尤其适用于CSCI、软件系统或子系统的交付文档规划阶段。
|
||||
---
|
||||
|
||||
# 军用软件用户手册（SUM）适用条件与内容要求
|
||||
|
||||
## 何时使用
|
||||
在以下情况下使用本技能：
|
||||
- 软件具备用户接口（用于接收用户输入或解释输出显示）
|
||||
- 软件由最终用户直接运行
|
||||
- 需要确定是否必须编制独立的《软件用户手册》（SUM）
|
||||
- 规划军用软件交付文档集时评估SUM与其他手册（如SIOM、SCOM）的关系
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 1. 判断SUM是否适用
|
||||
依次验证以下条件：
|
||||
- **条件1**：软件由用户直接运行 → 是
|
||||
- **条件2**：具有用户接口以获取联机用户输入或解释输出显示 → 是
|
||||
|
||||
若两个条件均为“是”，则**原则上需要编制SUM**。
|
||||
|
||||
### 2. 检查例外情况（无需单独SUM）
|
||||
即使满足上述条件，若存在以下任一情况，则**不需要单独编制SUM**：
|
||||
- 软件为硬件-软件系统中的嵌入式软件
|
||||
- 系统级用户手册或操作手册已完整包含SUM所需内容
|
||||
|
||||
### 3. 确认替代关系
|
||||
- SUM可**替代**《软件输入/输出手册》（SIOM）和《软件中心操作员手册》（SCOM）
|
||||
- 反之，SIOM与SCOM**联合使用**也可替代SUM
|
||||
|
||||
### 4. 定义SUM必须包含的内容
|
||||
若需编制SUM，必须涵盖以下三部分：
|
||||
|
||||
#### a) 软件概述
|
||||
- 软件应用场景
|
||||
- 必须安装的所有软件文件清单
|
||||
- 运行环境要求
|
||||
- 软件组织结构与操作概览
|
||||
- 意外事故处理及备用运行状态/方式
|
||||
- 保密性说明
|
||||
- 帮助获取途径与问题报告流程
|
||||
|
||||
#### b) 软件入门
|
||||
- 首次用户所需准备信息
|
||||
- 软件启动、停止和挂起的操作规程与参数说明
|
||||
|
||||
#### c) 使用指南
|
||||
- 日常使用规程
|
||||
- 功能能力、操作约定与处理流程
|
||||
- 数据备份方法
|
||||
- 系统消息含义说明
|
||||
- 错误、故障及紧急情况下的恢复步骤
|
||||
|
||||
> **注意**：SUM还可根据任务需求补充特定位置或特殊任务的操作说明。
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: 军用系统/子系统规格说明（SSS）结构编制
|
||||
description: 编制符合军用标准的系统或子系统规格说明（SSS），用于定义系统级需求并作为后续设计与合格性测试的基础。当已完成运行方案说明、需详细定义系统需求且即将开展系统设计时使用本技能。
|
||||
---
|
||||
|
||||
# 军用系统/子系统规格说明（SSS）结构编制
|
||||
|
||||
## 何时使用
|
||||
- 已完成运行方案说明（Operational Concept Description）
|
||||
- 需要对军用系统、子系统、硬件配置项（HWCI）或计算机软件配置项（CSCI）进行详细需求定义
|
||||
- 准备进入系统设计阶段，需建立权威的需求基线
|
||||
- 需为合格性测试（验证与确认）提供依据
|
||||
|
||||
## 如何执行
|
||||
|
||||
### 1. 构建SSS核心结构（依据附录B）
|
||||
按以下顺序组织文档内容：
|
||||
|
||||
**a) 范围**
|
||||
- 系统标识（名称、编号、版本）
|
||||
- 系统概述（功能、用途、部署环境）
|
||||
- 文档概述（章节说明、读者对象）
|
||||
|
||||
**b) 引用文档**
|
||||
- 列出所有相关标准、规范、接口文档及其他引用文件
|
||||
|
||||
**c) 需求（核心章节）**
|
||||
确保每个需求明确关联到特定的系统状态或运行方式（如空闲、就绪、活动、训练、降级、紧急、战时、平时等）：
|
||||
|
||||
- **3.1 要求的状态和方式**：定义系统所有运行状态及切换条件
|
||||
- **3.2 系统能力需求**：按能力分组，包含响应时间、吞吐量、准确性、容量、优先级、连续运行要求、异常行为、错误处理等
|
||||
- **3.3 系统外部接口需求**：通过接口标识符和接口图描述数据元素、数据组合体、通信方法、协议、物理兼容性等
|
||||
- **3.4–3.6**：如适用，补充内部接口、内部数据、适应性（现场参数）需求
|
||||
- **3.7 安全性需求**：防止危险事件的措施（如故障安全、隔离机制）
|
||||
- **3.8 保密性需求**：保密环境、信息类型、保密等级、风险控制措施
|
||||
- **3.9 系统环境需求**：硬件平台、操作系统、自然环境（温度、湿度）、诱发环境（振动、电磁）、对抗环境（电子战）
|
||||
- **3.10 计算机资源需求**：硬件资源、资源利用率上限、软件依赖、通信带宽/延迟
|
||||
- **3.11 系统质量因素**：功能性、可靠性、易用性、效率、维护性、可移植性的定量指标
|
||||
- **3.12 设计和构造约束**：体系结构限制、强制标准、物理尺寸/重量、未来扩展性
|
||||
- **3.13–3.18**：人员、培训、保障、包装、优先级与关键性等支持性需求
|
||||
|
||||
**d) 合格性规定**
|
||||
- 为每类需求指定合格性方法：演示、测试、分析、审查或特殊方法
|
||||
|
||||
**e) 需求可追踪性**
|
||||
- 建立子系统需求到上级系统需求的双向追踪矩阵
|
||||
|
||||
**f) 注释**
|
||||
- 提供术语解释、背景信息等辅助内容
|
||||
|
||||
### 2. 处理外部接口
|
||||
- 若外部接口复杂，可将详细内容移至独立的《接口需求规格说明》（IRS）
|
||||
- SSS中保留接口概要，并引用IRS
|
||||
|
||||
### 3. 验证完整性
|
||||
- 确保所有需求可验证、无歧义、可追踪
|
||||
- 每个需求必须标注关键性等级（criticality_level）和合格性方法（verification_method）
|
||||
|
||||
> ⚠️ 注意：SSS不得包含详细设计实现细节，仅定义“做什么”，而非“怎么做”。
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: 快速参考指南编制规范
|
||||
description: 为复杂软件系统创建或评估快速参考指南内容。当软件具备较高复杂度且存在常用功能需供用户快速查阅时（如GJB 438B标准5.8条目），使用本技能生成简洁实用的参考材料。
|
||||
---
|
||||
|
||||
# 快速参考指南编制规范
|
||||
|
||||
## 何时使用
|
||||
- 软件系统复杂，用户需频繁查阅关键操作
|
||||
- 正在编写GJB 438B标准第5.8条“快速参考指南”
|
||||
- 需决定是否提供快速参考材料及其内容范围
|
||||
|
||||
## 执行步骤
|
||||
1. **评估适用性**：确认软件复杂度高且存在高频使用的功能，判断是否值得提供快速参考指南。
|
||||
2. **确定呈现形式**：选择指南格式——可作为内置文档、引用外部快速参考卡，或独立页面。
|
||||
3. **聚焦核心内容**：仅包含以下关键类别：
|
||||
- 功能键及其作用
|
||||
- 控制序列（如快捷键组合）及其效果
|
||||
- 常用数据格式规范
|
||||
- 高频命令及其语法
|
||||
- 其他对高效使用至关重要的软件特性
|
||||
4. **优化可读性**：采用表格、项目符号列表或卡片式布局，确保信息一目了然。
|
||||
5. **精简内容**：排除次要或低频信息，只保留最常用、最关键的快捷操作。
|
||||
6. **标注版本信息**：若适用，注明适用的软件版本，确保内容与当前系统一致。
|
||||
|
||||
## 输出要求
|
||||
生成简洁、结构化、便于快速查阅的快速参考指南，内容精准匹配用户高频需求，避免冗余信息。
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: 软件开发计划活动结构
|
||||
description: 本技能用于在制定《软件开发计划》时，系统化构建覆盖合同或任务书全部条款的详细活动计划框架。当项目已启动且存在开发任务、需编制符合标准要求的软件开发计划时使用。
|
||||
---
|
||||
|
||||
# 软件开发计划活动结构
|
||||
|
||||
## 何时使用
|
||||
- 项目已正式启动；
|
||||
- 存在明确的软件开发任务（如CSCI开发、系统集成项目）；
|
||||
- 需要编制或评审《软件开发计划》文档；
|
||||
- 合同或任务书要求提供完整的开发活动计划。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 1. 项目策划和监控
|
||||
- 描述开发策划、各级测试策划、安装/移交策划的方法；
|
||||
- 基于项目规模、工作量、资源等估算制定详细计划；
|
||||
- 明确进度导出方法及计划跟踪与修订机制。
|
||||
|
||||
### 2. 环境建立
|
||||
- 规划软件工程环境、测试环境的搭建；
|
||||
- 定义开发库管理策略；
|
||||
- 制定非交付软件的建立与维护方案。
|
||||
|
||||
### 3. 需求分析
|
||||
- 说明用户需求获取与分析途径；
|
||||
- 描述运行方案与系统/软件需求的推导方法。
|
||||
|
||||
### 4. 系统/软件设计
|
||||
- 规定体系结构设计流程；
|
||||
- 明确详细设计的技术方法与输出标准。
|
||||
|
||||
### 5. 实现与测试
|
||||
- 制定编码规范与单元测试策略；
|
||||
- 规划集成测试流程；
|
||||
- 设计CSCI级与系统级合格性测试方案。
|
||||
|
||||
### 6. 交付准备
|
||||
- 准备可执行软件、配套文档、用户手册及版本说明；
|
||||
- 明确交付物清单与验收标准。
|
||||
|
||||
### 7. 验收支持
|
||||
- 规划需方验收支持活动；
|
||||
- 制定交付与用户培训实施路径。
|
||||
|
||||
### 8. 支撑活动
|
||||
- 编制配置管理、质量保证、风险管理、测量分析等专项计划。
|
||||
|
||||
### 9. 活动通用要求
|
||||
每项活动必须：
|
||||
- 说明技术任务执行途径；
|
||||
- 规定结果记录方式；
|
||||
- 标识交付准备方法；
|
||||
- 识别潜在风险并制定应对计划。
|
||||
|
||||
## 输出
|
||||
生成完整的软件开发活动计划框架，作为《软件开发计划》的核心组成部分，指导项目全生命周期执行。
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: 软件研制任务书技术要求结构化编制
|
||||
description: 用于在编制《软件研制任务书》时，按国防和行业标准结构化定义软件的技术要求。当项目已立项且需方提出初步需求，且必须覆盖合同或上级文件要求时使用本技能。
|
||||
---
|
||||
|
||||
# 软件研制任务书技术要求结构化编制
|
||||
|
||||
## 何时使用
|
||||
- 正在编写《软件研制任务书》；
|
||||
- 适用对象为CSCI、嵌入式软件或应用软件；
|
||||
- 需确保技术要求完整覆盖合同或上级文件规定。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **功能要求**：分条列出所有软件功能、工作模式、容错能力、特殊适应性（如抗干扰）、应急措施和可扩展性。
|
||||
|
||||
2. **性能要求**：明确精度、实时性、时间开销、存储空间占用及余量指标。
|
||||
|
||||
3. **输入/输出要求**：详细说明：
|
||||
- 数据来源、格式、数量、频度、顺序；
|
||||
- 值域、精度、接收/发送方法；
|
||||
- 信号最短间隔、中断数量及优先级；
|
||||
- 与其他软件接口、嵌入式软件固化地址。
|
||||
|
||||
4. **数据处理要求**：
|
||||
- 列出处理条件、参数精度与速度；
|
||||
- 说明数据传递或并行处理关系；
|
||||
- 规定最大信息量（包括容量、流通率、中断队列长度）；
|
||||
- 使用表格列出关键参数（名称、量纲、精度、使用要求）。
|
||||
|
||||
5. **接口要求**：描述与外部系统的接口关系。
|
||||
|
||||
6. **固件要求（若适用）**：明确固化地址、安装操作要求。
|
||||
|
||||
7. **关键性要求**：
|
||||
a) **可靠性**：给出指标、容错冗余机制、健壮性设计（如抗掉电、抗干扰、接口故障容忍）、降级运行策略；
|
||||
b) **安全性**：规定双模块关键功能、看门狗机制、多余物处理、内存保护、故障自动识别；
|
||||
c) **保密性**：定义口令策略、加密机制、访问控制规则。
|
||||
|
||||
## 输出结果
|
||||
形成结构化技术要求清单，作为后续软件开发、测试和验收的依据。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: 软件使用处理规程内容规范
|
||||
description: 为GJB 438B标准中5.3.X软件使用子条编写符合要求的交互式功能描述。当用户需要撰写或审核软件文档中关于用户直接交互功能（如菜单、事务、过程）的处理规程时使用本技能。
|
||||
---
|
||||
|
||||
# 软件使用处理规程内容规范
|
||||
|
||||
## 何时使用
|
||||
- 正在编写GJB 438B标准下的5.3.X“软件使用方面”子条目
|
||||
- 需要描述用户可直接操作的功能、菜单、事务或过程
|
||||
- 文档需满足军用软件文档规范对交互元素的强制性要求
|
||||
|
||||
## 执行步骤
|
||||
1. **明确标题**：标题必须清晰标识被描述的功能、菜单、事务或过程名称。
|
||||
2. **覆盖全部交互元素**：必须包含以下方面的选项与实例说明：
|
||||
- 菜单结构与路径
|
||||
- 图标含义与位置
|
||||
- 数据项表格式与字段说明
|
||||
- 用户输入方式（文本框、下拉列表等）
|
||||
- 可能影响界面的软硬件输入（如外设、快捷键）
|
||||
- 系统输出（显示内容、文件生成等）
|
||||
- 诊断或错误消息示例及含义
|
||||
- 报警机制与触发条件
|
||||
- 联机帮助工具的访问方式与内容概要
|
||||
3. **适配软件特性**：信息格式应匹配软件类型（如嵌入式系统、桌面应用、Web界面）。
|
||||
4. **保持风格一致**：同类元素（如所有菜单或所有事务）的描述方式、术语和结构必须统一。
|
||||
5. **添加安全提示**：在涉及风险操作处，使用“警告”或“注意”标记突出安全相关信息。
|
||||
|
||||
## 输出要求
|
||||
生成完整的软件使用处理规程描述，确保包含所有必需交互元素，语言准确、结构清晰，符合GJB 438B标准。
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
name: 规定物理接口兼容性要求
|
||||
description: 当接口包含物理连接部件（如硬件接口、机电连接器、电源接口）时，使用本技能定义其几何、机械和电气兼容性参数。适用于硬件工程和系统集成场景，确保CSCI与对接实体在物理层面可互连互操作。
|
||||
---
|
||||
|
||||
# 规定物理接口兼容性要求
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及机械或电气物理连接
|
||||
- 需制造、验收或验证硬件接口匹配性
|
||||
- 不适用于纯软件或虚拟接口
|
||||
|
||||
## 执行步骤
|
||||
1. 测量并规定接口实体的几何尺寸（长、宽、高）及允许公差范围（mm）。
|
||||
2. 明确机械负载能力要求，如最大插拔力、振动耐受等级。
|
||||
3. 定义接插件类型、针脚数量、排列方式及互配兼容性标准（如MIL-DTL-38999）。
|
||||
4. 规定电气参数，包括工作电压范围（如+5V±5%）、额定电流、信号电平（如TTL/RS485）。
|
||||
5. 考虑环境适应性，如温度范围、防尘防水等级（IP代码）。
|
||||
6. 验证与现有或目标设备的物理匹配性，必要时提供适配器方案。
|
||||
|
||||
> **注意**：若物理参数不匹配，应发出接口不可行警告。
|
||||
|
||||
## 输出结果
|
||||
形成物理接口规格表，用于制造、验收和集成验证。
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: structured-data-collection-specification
|
||||
description: 定义结构化数据集合体（如消息、文件、数据库记录或API响应体）的完整特征规范。当接口传输复合结构化数据且需明确其组成、约束与使用上下文时使用此技能。
|
||||
---
|
||||
|
||||
# 结构化数据集合体特征定义规范
|
||||
|
||||
## 何时使用
|
||||
- 接口涉及复合数据传输（非单个数据元素）
|
||||
- 数据以结构化形式在系统间交换（如JSON、XML、数据库记录、二进制消息）
|
||||
- 需为协议设计、系统集成或数据治理提供明确的数据契约
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **名称与标识符**
|
||||
- 分配项目唯一标识符（用于追踪和版本管理）
|
||||
- 提供自然语言名称（例如“飞行状态报告”）
|
||||
- 指明技术名称（如C结构体名、Protobuf消息名、JSON Schema ID）
|
||||
- 列出常用缩写或同义名称
|
||||
|
||||
2. **内部结构**
|
||||
- 明确数据元素组成及其数据类型
|
||||
- 定义字段编号顺序（若适用）
|
||||
- 描述分组逻辑（如嵌套对象、数组、联合体）
|
||||
|
||||
3. **存储媒体**
|
||||
- 说明载体类型（内存、磁盘、网络包等）
|
||||
- 指定媒体内结构（如文件路径、数据库表名、Kafka主题）
|
||||
|
||||
4. **视听特性（仅适用于输出型集合体）**
|
||||
- 定义颜色、版面布局、字体、图标、声音提示、亮度等呈现属性
|
||||
|
||||
5. **关系特性**
|
||||
- 说明排序规则（升序/降序、自定义比较逻辑）
|
||||
- 定义索引方式（主键、唯一索引、全文索引）
|
||||
- 描述访问路径（如外键关联、REST资源路径）
|
||||
|
||||
6. **约束条件**
|
||||
- 设置优先级、传输频率、容量上限（记录数或字节数）
|
||||
- 明确修改权限（只读、可更新字段）
|
||||
- 标注适用的业务规则
|
||||
|
||||
7. **保密性约束**
|
||||
- 指明整体加密要求（如TLS、字段级加密）
|
||||
- 定义访问控制策略（RBAC、ABAC规则）
|
||||
|
||||
8. **来源与接收者**
|
||||
- 标识设置/发送实体（系统、服务、角色）
|
||||
- 标识使用/接收实体
|
||||
|
||||
完成以上步骤后，输出一份完整的数据集合体规范文档，用于接口协议设计、系统开发或合规审查。
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: 系统部件标识与描述
|
||||
description: 在系统架构设计阶段，为硬件配置项（HWCI）、计算机软件配置项（CSCI）和人工操作流程等系统部件分配唯一标识、说明其用途、静态关系、开发状态及详细资源特性。当进行系统架构文档编制且已存在系统分解结果和部件清单时使用本技能。
|
||||
---
|
||||
|
||||
# 系统部件标识与描述
|
||||
|
||||
## 适用场景
|
||||
- 正在开展系统架构设计
|
||||
- 已完成系统分解并拥有部件清单
|
||||
- 需要为架构文档准备系统部件清单及资源描述
|
||||
|
||||
## 执行步骤
|
||||
1. **分配唯一标识符**：为每个部件分配项目内唯一的标识符（例如：`SYS-HW-001`、`SYS-SW-002`）。
|
||||
2. **说明静态关系**：描述部件之间的包含、依赖或连接关系，可采用多重关系模型表达。
|
||||
3. **陈述用途与关联**：明确每个部件的功能用途，并关联其对应的系统需求和设计决策（若已在需求分配章节说明，可引用）。
|
||||
4. **标识开发状态/类型**：对每个部件标注以下之一：
|
||||
- 新开发
|
||||
- 原样重用（已有部件）
|
||||
- 设计重用（已有设计）
|
||||
- 再工程（改造已有）
|
||||
- 为重用而开发
|
||||
- 计划用于第N构建版
|
||||
5. **提供重用部件完整信息**：对重用部件，列出名称、版本、文档引用和存储位置。
|
||||
6. **详细描述硬件资源**（仅适用于HWCI）：
|
||||
a) **处理器**：厂商、型号、速度、指令集、编译器、字长、字符集、中断能力
|
||||
b) **存储器**：厂商、型号、大小、类型、速度、配置（如缓存/RAM）
|
||||
c) **I/O设备**：厂商、型号、类型、速度
|
||||
d) **外存**：厂商、型号、类型、容量、速度
|
||||
e) **通信设备**：厂商、型号、速率、拓扑、传输技术、协议
|
||||
f) **其他**：扩展能力、诊断功能、特殊硬件能力
|
||||
7. **绘制规格说明树**：图示所有部件间的规格层级与关系，用于架构文档附图。
|
||||
|
||||
> 注意：数据库可作为CSCI或其子部件处理。
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: 系统级设计决策内容规范
|
||||
description: 当系统需求已明确但未指定实现方式，且该缺失会影响系统行为时，使用本技能记录和规范系统级设计决策。适用于系统架构、用户交互流程和安全机制等对象的高层设计阶段。
|
||||
---
|
||||
|
||||
# 系统级设计决策内容规范
|
||||
|
||||
在系统需求已明确但未规定具体实现细节的情况下，必须通过本技能制定并记录系统级设计决策，以指导后续详细设计工作。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **输入/输出决策**：定义系统与外部系统、配置项或用户的接口行为。可引用《接口设计说明》文档。
|
||||
|
||||
2. **响应行为决策**：
|
||||
- 明确系统执行的具体动作；
|
||||
- 规定响应时间等性能指标；
|
||||
- 描述所模拟的物理系统（如适用）；
|
||||
- 选定算法、方程或业务规则；
|
||||
- 制定对非法输入的处理策略。
|
||||
|
||||
3. **数据呈现决策**：从用户视角定义数据库或文件的组织结构与展示方式。可引用《数据库设计说明》文档。
|
||||
|
||||
4. **安全保密决策**：为满足安全与保密需求，明确采用的具体方法，如加密标准、访问控制模型等。
|
||||
|
||||
5. **硬件选型决策**：确定物理特性（尺寸、颜色、材料）及人机工程相关考量。
|
||||
|
||||
6. **质量属性决策**：为实现灵活性、可用性、可维护性等非功能性需求，选择合适的技术路线。
|
||||
|
||||
7. **关键性需求专项说明**：对涉及安全或保密的关键性需求，必须在设计文档中设立专门章节进行详述。
|
||||
|
||||
8. **状态依赖处理**：若某项设计决策依赖于系统运行状态，需明确建立状态与对应决策之间的映射关系。
|
||||
|
||||
## 使用条件
|
||||
|
||||
- 系统需求已明确；
|
||||
- 需求未指定实现方式；
|
||||
- 该缺失将影响系统行为、接口、安全或质量属性；
|
||||
- 正处于高层设计阶段。
|
||||
|
||||
> 注意：若需求已完全指定实现细节，则无需执行本技能。
|
||||
40
skills/GJB438B-2009_prd_skills/合格性方法定义与分配/SKILL.md
Normal file
40
skills/GJB438B-2009_prd_skills/合格性方法定义与分配/SKILL.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: 合格性方法定义与分配
|
||||
description: 为已文档化的系统、软件或接口需求分配标准合格性方法（演示、测试、分析、审查或特殊方法），以支持验证计划制定。当存在需验证的需求时，必须使用本技能为其指定至少一种合格性方法。
|
||||
---
|
||||
|
||||
# 合格性方法定义与分配
|
||||
|
||||
## 何时使用
|
||||
- 需求已正式文档化；
|
||||
- 存在验证计划或即将制定验证计划；
|
||||
- 需明确每项需求如何被验证或确认。
|
||||
|
||||
> **约束**：不可使用未在五类标准方法中定义的合格性方法。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **从五类标准合格性方法中选择适用方法**：
|
||||
- **演示**：通过可见功能操作直接验证，无需专用仪器（如用户界面操作）；
|
||||
- **测试**：使用专用设备采集数据供事后分析（如性能压力测试）；
|
||||
- **分析**：基于已有数据进行推断、建模或计算（如可靠性预测）；
|
||||
- **审查**：对文档、代码或设计进行目视检查（如需求评审、代码走查）；
|
||||
- **特殊方法**：使用专用工具、技术、规程或设施（需额外说明）。
|
||||
|
||||
2. **为每个需求分配一种或多种方法**，考虑以下因素：
|
||||
- 需求类型（功能、性能、安全、接口等）；
|
||||
- 方法可行性、成本与资源可用性；
|
||||
- 行业或法规强制要求（如 DO-178C、ISO 26262）。
|
||||
|
||||
3. **使用表格记录映射关系**，包含列：
|
||||
- 需求ID；
|
||||
- qualification_method（可多选）；
|
||||
- 执行条件（如环境、工具、前置状态）；
|
||||
- acceptance_criteria（明确的通过/失败标准）。
|
||||
|
||||
4. **对特殊方法补充详细说明**，包括：
|
||||
- 工具名称与版本；
|
||||
- 技术原理简述；
|
||||
- 验收标准量化指标。
|
||||
|
||||
5. **输出需求-合格性方法映射表**，作为验证计划的核心输入。
|
||||
33
skills/GJB438B-2009_prd_skills/定义安全关键软件的安全性需求/SKILL.md
Normal file
33
skills/GJB438B-2009_prd_skills/定义安全关键软件的安全性需求/SKILL.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: 定义安全关键软件的安全性需求
|
||||
description: 当CSCI（计算机软件配置项）涉及人身、财产或环境安全风险时，使用本技能识别两类危险（意外动作与无动作），并定义可验证的安全措施。适用于安全关键CSCI、控制系统及核相关软件的开发初期阶段。
|
||||
---
|
||||
|
||||
# 定义安全关键软件的安全性需求
|
||||
|
||||
## 何时使用
|
||||
- 系统被判定为安全关键（如涉及人身、财产或环境风险）；
|
||||
- 开发对象属于安全关键CSCI、控制系统或核相关软件；
|
||||
- 需要满足GJB438B等系统安全标准；
|
||||
- 触发条件：CSCI可能因意外动作（如误发命令）或无动作（如应触发但未触发）导致危险。
|
||||
|
||||
## 如何执行
|
||||
1. **识别危险类型**：
|
||||
- **意外动作**：系统在不应执行时执行了操作（例如误发“自动导航关闭”命令）；
|
||||
- **无动作**：系统在应执行时未能执行操作（例如应发“自动导航关闭”但失败）。
|
||||
|
||||
2. **为每类危险定义安全措施**，包括但不限于：
|
||||
- 命令确认机制（如二次确认对话框）；
|
||||
- 双人授权流程；
|
||||
- 故障检测与自动切换机制；
|
||||
- 看门狗定时器（Watchdog Timer）以检测程序挂起。
|
||||
|
||||
3. **若涉及核相关部件**，额外增加：
|
||||
- 预防意外爆炸的工程控制措施；
|
||||
- 与国家或行业核安全规则的一致性声明。
|
||||
|
||||
4. **确保所有安全措施**：
|
||||
- 可通过测试或分析进行验证；
|
||||
- 与系统级安全分析（如FTA、HAZOP）结果保持一致。
|
||||
|
||||
5. **输出结果**：生成一份结构化的安全措施清单，每项措施明确关联到具体的危险场景和CSCI功能。
|
||||
36
skills/GJB438B-2009_prd_skills/错误消息文档化规范/SKILL.md
Normal file
36
skills/GJB438B-2009_prd_skills/错误消息文档化规范/SKILL.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: 错误消息文档化规范
|
||||
description: 为软件产生的错误消息、诊断消息及其他系统消息创建完整、结构化的用户文档。当软件具备错误或诊断消息功能，且需符合GJB 438B标准第5.7条要求时使用本技能。
|
||||
---
|
||||
|
||||
# 错误消息文档化规范
|
||||
|
||||
## 何时使用
|
||||
- 软件在运行过程中会产生错误消息、诊断消息或其他系统消息
|
||||
- 需要满足GJB 438B标准中关于“5.7 消息条目”的文档要求
|
||||
- 用户需要明确知道每条消息的含义及应对措施
|
||||
|
||||
## 执行步骤
|
||||
1. **识别所有相关消息**：列出软件在完成用户功能过程中可能产生的全部消息，包括：
|
||||
- 错误消息
|
||||
- 诊断消息
|
||||
- 其他系统消息
|
||||
|
||||
2. **为每条消息提供完整信息**：确保包含以下四项内容：
|
||||
- 消息的完整文本或唯一标识符
|
||||
- 消息的清晰含义解释
|
||||
- 消息出现的根本原因分析
|
||||
- 用户应采取的具体纠正动作
|
||||
|
||||
3. **选择文档组织方式**：
|
||||
- 方式一：直接在需求规格说明的“5.7 消息条目”章节中完整列出所有消息及其信息
|
||||
- 方式二：引用专门附录（必须确保附录包含上述全部四项信息，且用户可无障碍访问）
|
||||
|
||||
4. **分类与排序**：按功能模块或消息严重程度对消息进行分类，便于用户快速定位。
|
||||
|
||||
5. **提供操作指南**：对于复杂的纠正动作，必须给出分步操作说明，而非仅描述性文字。
|
||||
|
||||
## 注意事项
|
||||
- 不得仅提供消息代码而不解释含义
|
||||
- 引用附录时，必须验证附录内容完整性与可访问性
|
||||
- 所有纠正动作必须具体、可执行，避免模糊建议
|
||||
37
skills/GJB438B-2009_prd_skills/需求优先级与关键性标识/SKILL.md
Normal file
37
skills/GJB438B-2009_prd_skills/需求优先级与关键性标识/SKILL.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: 需求优先级与关键性标识
|
||||
description: 对系统、软件或接口需求进行优先级和关键性等级标识，用于指导后续设计、验证和风险管理决策。当需求对安全性、保密性或任务成功的影响程度不同时，必须使用本技能进行分级。
|
||||
---
|
||||
|
||||
# 需求优先级与关键性标识
|
||||
|
||||
## 何时使用
|
||||
- 已完成需求收集且存在多个需求条目；
|
||||
- 需求在安全性、保密性、法规合规性或业务影响方面存在差异；
|
||||
- 需为资源分配、排期或验证策略提供依据。
|
||||
|
||||
> **注意**：若所有需求同等重要，则无需分级，但需明确声明“所有需求具有相等权重”。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. **判断是否存在关键需求**：
|
||||
- 若某需求直接影响系统安全、数据保密性或任务成败，则标记为“关键”，并赋予最高权重（weight_value = 1.0）；
|
||||
- 否则进入下一步。
|
||||
|
||||
2. **评估业务影响并分配优先级等级**：
|
||||
- **高**：直接影响核心功能、法规合规或客户合同义务；
|
||||
- **中**：影响次要功能、性能或用户体验；
|
||||
- **低**：属于优化、美化或未来扩展类需求。
|
||||
|
||||
3. **对关键需求进行特殊处理标注**，包括但不限于：
|
||||
- 要求独立验证；
|
||||
- 增加冗余或容错设计；
|
||||
- 纳入配置管理基线并严格变更控制。
|
||||
|
||||
4. **输出带优先级标签的需求列表**，每项包含：
|
||||
- 需求ID；
|
||||
- criticality_level（关键/高/中/低）；
|
||||
- weight_value（0–1 的相对权重数值）；
|
||||
- 特殊处理说明（如适用）。
|
||||
|
||||
5. **若所有需求权重相等**，在输出中明确声明：“所有需求具有相等权重”，并跳过分级逻辑。
|
||||
Reference in New Issue
Block a user