Software Process Document Audit Skill

Goal: Audit raw software process documents (SRS, SDD, STPr, SPMP, etc.) with the same rigor as a professional software quality consultant.

Based on: Analysis of 1,000+ consultant comments across multiple real-world rail transit software projects.

⚠️ IMPORTANT — What This Skill Is (and Is NOT)

🎯 How to Use This Skill (Step-by-Step)

Simple 3-Step Process:

Step 1: Load This Skill
- User says: "审核这个SRS文档" / "Check this SDD" / "Audit this software doc"
- I (the AI) automatically load this skill ✅

Step 2: Provide the Document
- Send the document content (copy-paste text, or file path)
- Supported formats: PDF, Word (.docx), plain text, Markdown
- I read it using read_file, vision_analyze (for images), or summarize

Step 3: Get Consultant-Style Feedback
- I apply the 6 audit dimensions
- Return specific findings like: "STPr does not test all requirements listed in the SRS."
- Use real consultant phrases from the phrasebook ✅

Example Conversation:

User: "帮我审核这份SRS文档：[粘贴SRS文本内容]"

Me (with skill loaded):

SECTION 3.2.1 — Requirement REQ_SRS_02005
❌ ISSUE: Requirement traced to SDD (REQ_SDD_02005) but NO test case in STPr.
   Consultant-style: "STPr does not test all requirements listed in the SRS. 
   REQ_SRS_02005 is not covered by any test case."

SECTION 5.1 — Version Reference
⚠️ ISSUE: SRS references "SDD Rev C" but SDD actual revision is D.
   Consultant-style: "Inconsistencies in version number. SDD is listed as Rev C 
   but the latest is Rev D."

Test Coverage Check: 78% (MUST be 100%)
❌ Only 78% of SRS requirements have test cases.

What If I (AI) Make a Mistake?

• ✅ Self-correction: If you (user) say "不对，这里应该是..." → I learn and adjust
• ✅ Manual override: You can say "跳过一致性检查" → I skip that dimension
• ✅ Re-audit: You can say "再检查一遍" → I re-apply all 6 dimensions
  3. Return consultant-style feedback

🧠 Consultant Audit Thinking Patterns

What Consultants Actually Look For (From Real Comments)

1. 📋 Completeness — "Is everything here?"

Consultant Logic:
- Count documents: Are ALL required docs present?
- Check revisions: Is anything obsolete/superseded?
- Cross-reference tables: Does the document table list all docs that should be delivered?

Real consultant phrases:
> "The SRS for the Diagnostic Unit is not listed in the table."
> "missing some of the referenced documents"
> "submit a full package of software documents"
> "this submission is already outdated. Please submit the latest version"

Audit Action:

# Pseudocode for completeness check
required_docs = ['SPMP', 'SQAP', 'SCMP', 'SRS', 'SRTM', 'SDD', 'SIS', 'STP', 'STP']
for doc in required_docs:
    if doc not in submission_package:
        flag(f"Missing: {doc}")

# Check revision table completeness
for doc in srs_referenced_docs:
    if doc not in srtm:
        flag(f"Doc {doc} in SRS but missing from SRTM")

2. 🔗 Traceability — "Can we trace every requirement?"

Consultant Logic:
- SRS Requirement ID → Must exist in SRTM
- SRTM → Must link to SDD design element (same ID: REQ_SRS_02005 → REQ_SDD_02005)
- SRTM → Must link to STPr test case
- NO orphaned requirements allowed

Real consultant phrases:
> "There are still errors and inconsistencies in the traceability of the requirement (SRS) via the SRTM to the software test"
> "SRTM is missing traceability to the SDD"
> "There is still a lack of detail in this document [traceability]"

Audit Action:

# Check SRS → SDD → STPr chain
for req in srs.requirements:
    if req.id not in srtm:
        flag(f"REQ {req.id} in SRS but MISSING from SRTM")

    sdd_id = req.id.replace('SRS', 'SDD')
    if sdd_id not in sdd.elements:
        flag(f"REQ {req.id} not traced to SDD ({sdd_id} missing)")

    test_id = req.id.replace('SRS', 'STP')
    if test_id not in stpr.test_cases:
        flag(f"REQ {req.id} has NO test case in STPr")

3. 🔄 Consistency — "Do all docs agree?"

Consultant Logic:
- Version numbers: If SRS says "See SDD Rev C", SDD must actually be Rev C
- Same requirement ID format across all docs (no REQ_SRS_02005 in SRS but REQ_SDD_2005 in SDD)
- Same terminology: "Watchdog timer" in SRS = "Watchdog timer" in SDD (not "WDT" or "supervisor")
- No contradictory statements between docs

Real consultant phrases:
> "inconsistencies between the SRS, SDD, and STPr"
> "inconsistencies in version number. E.g. the SITP is listed as F but the latest is G"
> "REQ_SRS_02005 & REQ_SDD_02005 references S1 and S2 but REQ_STPr_00067 only references S1"

Audit Action:

# Check version consistency across all cross-references
for ref in srs.references:
    actual_rev = get_current_rev(ref.doc_name)
    if ref.rev != actual_rev:
        flag(f"Version mismatch: SRS says {ref.doc_name} {ref.rev}, but actual is {actual_rev}")

# Check ID format consistency
for req in all_docs.requirements:
    if not req.id.matches_pattern(r'REQ_[A-Z]+_\d{5}'):
        flag(f"Inconsistent ID format: {req.id}")

4. ✅ Test Coverage — "Is everything tested?"

Consultant Logic:
- 100% coverage required: Every SRS requirement MUST have ≥1 test case in STPr
- Test cases must match requirement (not "extra" tests unrelated to SRS)
- NO "To be completed in next revision" — Reject immediately
- Test pass/fail criteria must be clear

Real consultant phrases:
> "STP does not test all requirements listed in the SRS"
> "has additional information not from SRS"
> "test cases incomplete"
> "To be completed in the next revision" ← REJECT

Audit Action:

# Test coverage check
coverage = len(stpr.test_cases) / len(srs.requirements) * 100
if coverage < 100:
    flag(f"Test coverage: {coverage:.1f}% (MUST be 100%)")

# Check for "TBD" or "to be completed"
for tc in stpr.test_cases:
    if 'to be completed' in tc.description.lower():
        flag(f"Reject: Test case {tc.id} is not complete!")

# Check for extra tests not from SRS
for tc in stpr.test_cases:
    if tc.req_id not in srs.requirements:
        flag(f"Extra test {tc.id} not linked to any SRS requirement")

5. 📏 Conformance — "Does it follow standards?"

Consultant Logic:
- Coding standard named (MISRA-C:2004, etc.) AND compliance method described
- EN 50128 / IEC 61508 compliance for safety-related software
- SIL (Safety Integrity Level) correctly assigned
- Static analysis tools specified

Real consultant phrases:
> "coding standard is MISRA-C:2004 but there is nothing in the document about how compliance is verified"
> "The plan must show how compliance to the standard is verified"
> "no reference to unit testing (Document Ref-07)"

Audit Action:

# Conformance check
if 'MISRA' in srs.text or 'MISRA' in sdd.text:
    if 'how' not in srs.text.lower() and 'verify' not in srs.text.lower():
        flag("MISRA mentioned but NO verification method described")

# Safety conformance
if is_safety_related:
    if sil_level not in [1,2,3,4]:
        flag(f"SIL level not properly defined: {sil_level}")

6. 📄 Document Control — "Is this the right version?"

Consultant Logic:
- Revision numbers correct on cover AND in all cross-references
- Status clear: "Open" vs "Closed" vs "To be resubmitted"
- Change history table complete with dates
- "Closed" items should have no open comments

Real consultant phrases:
> "remains open until all supporting documents listed are closed"
> "this item is closed"
> "revision A the same as the previous version — no changes?"

Audit Action:

# Document control check
for doc in all_docs:
    if doc.status == 'Closed' and doc.has_open_comments:
        flag(f"{doc.name} marked CLOSED but has open comments!")

    # Check rev in table of contents matches actual doc rev
    if doc.rev_in_toc != doc.actual_rev:
        flag(f"Rev mismatch in TOC: says {doc.rev_in_toc}, actual {doc.actual_rev}")

📚 Document Framework (Standard Deliverable List)

🔍 How to Audit a Raw Document

Step 1: Identify Document Type

Is it SRS? → Check requirements, IDs, traceability to SRTM
Is it SDD? → Check design elements match SRS IDs
Is it STPr? → Check 100% coverage of SRS, no "TBD"
Is it SRTM? → Check ALL SRS reqs present, linked to SDD+STP

Step 2: Apply Consultant Logic

For each document, ask:
1. Completeness: Are all sections present? All referenced docs included?
2. Traceability: Can I trace every requirement through the chain?
3. Consistency: Do version numbers and IDs match across all docs?
4. Test Coverage: Does every requirement have a test?
5. Conformance: Are standards mentioned AND compliance verified?
6. Document Control: Is the revision correct? Status accurate?

Step 3: Generate Consultant-Style Feedback

Use the phrasebook below to phrase findings like a real consultant:

Phrasebook:
- ❌ "There are still errors and inconsistencies in the traceability..."
- ⚠️ "The SRS for the Diagnostic Unit is not listed in the table."
- ❌ "STPr does not test all requirements listed in the SRS."
- ⚠️ "There is still a lack of detail in this document."
- ❌ "To be completed in the next revision" ← Reject
- ✅ "This item is closed."

Cross-Document Audit Workflow

RAW DOCUMENT PACKAGE (SRS, SDD, STPr, SRTM, etc.)
         ↓
   ┌─────────────────────────────────┐
   │  1. Completeness Check              │
   │     - All docs present?             │
   │     - Revision table complete?      │
   └─────────────────────────────────┘
         ↓
   ┌─────────────────────────────────┐
   │  2. Traceability Check              │
   │     - SRS → SRTM → SDD → STP     │
   │     - No orphaned requirements      │
   └─────────────────────────────────┘
         ↓
   ┌─────────────────────────────────┐
   │  3. Consistency Check               │
   │     - Version numbers match         │
   │     - ID format consistent          │
   └─────────────────────────────────┘
         ↓
   ┌─────────────────────────────────┐
   │  4. Test Coverage Check             │
   │     - 100% SRS → STP coverage    │
   │     - No "TBD" / "to be completed" │
   └─────────────────────────────────┘
         ↓
   ┌─────────────────────────────────┐
   │  5. Conformance Check               │
   │     - Standards mentioned + verified│
   │     - SIL correctly applied         │
   └─────────────────────────────────┘
         ↓
   ┌─────────────────────────────────┐
   │  6. Document Control Check          │
   │     - Revision correct everywhere   │
   │     - Status (Open/Closed) accurate│
   └─────────────────────────────────┘
         ↓
   CONSULTANT-STYLE AUDIT REPORT

Quick Reference: Status Meanings

Input/Output Examples

Input: Raw SRS document (PDF/Word)
Output: Consultant-style audit feedback

SECTION 3.2.1 — Requirement REQ_SRS_02005
❌ ISSUE: Requirement traced to SDD (REQ_SDD_02005) but NO test case in STPr.
   Consultant-style: "STPr does not test all requirements listed in the SRS. 
   REQ_SRS_02005 is not covered by any test case."

SECTION 5.1 — Version Reference
⚠️ ISSUE: SRS references "SDD Rev C" but SDD actual revision is D.
   Consultant-style: "Inconsistencies in version number. SDD is listed as Rev C 
   but the latest is Rev D."

SECTION 7.3 — Test Coverage
❌ ISSUE: Only 78% of SRS requirements have test cases.
   Consultant-style: "STPr does not test all requirements listed in the SRS. 
   Total coverage: 78%. MUST be 100%."

📋 Checklist Template (Quick Start)

When auditing any document, use this mental checklist:

• [ ] Completeness: All sections present? All referenced docs in table?
• [ ] Traceability: Every SRS req traced to SDD + STPr?
• [ ] Consistency: Version numbers match across ALL docs?
• [ ] Test Coverage: 100% SRS → STPr coverage?
• [ ] Conformance: Standards named AND verification method described?
• [ ] Document Control: Revision correct? Status accurate?

Full checklist template available at: templates/audit_checklist.md

✅ What This Skill Provides

Key point: This skill teaches thinking patterns. You (the AI) read the document text, apply these patterns, and generate consultant-style feedback.

References

• EN 50716:2023 — Railway applications - Software for railway control and protection systems
• IEC 61508 — Functional safety
• EN 50128 — Software for railway control and protection systems
• MISRA-C:2004 / MISRA-C:2012 — C coding standards

FAQ

Q: What file formats does this skill support?
A: Any format you can read as text — PDF, Word (.docx), plain text, Markdown. You (the AI) extract the text, then apply the audit patterns.

Q: Can I audit comment sheets or review feedback?
A: NO. This skill is for auditing raw software process documents (SRS, SDD, STPr, etc.). Comment sheets are used only for learning consultant thinking patterns.

Q: Does this skill automatically parse my documents?
A: No. You (the AI) need to read the document content (via read_file, vision_analyze, etc.), then apply the audit logic manually.

Q: What if the document doesn't follow EN 50716?
A: The audit patterns are based on EN 50716 / IEC 61508, but can be adapted. Focus on the 6 dimensions — they apply to most software process documents.

Q: How detailed should my audit be?
A: Match the consultant style — point out specific sections, requirement IDs, version numbers. Be specific like: "REQ_SRS_02005 in SRS but NO test case in STPr."

Q: What's the difference between SRS, SDD, and STPr?
A:
- SRS = Software Requirements Specification (what the software should do)
- SDD = Software Design Description (how it's built)
- STPr = Software Test Procedure (how it's tested)
- SRTM = Traceability Matrix (links them all together)

Changelog

• 2026-05-26: v1.1.0 — Major update after skillhub.cn evaluation
• Added FAQ section (addresses "no FAQ" feedback)
• Added "How to Use" step-by-step guide (addresses "unclear invocation" feedback)
• Removed ALL script references (audit_tool.py, etc.) — no tools promised that don't exist
• Added "What This Skill Provides / Does NOT Provide" table
• Added example conversation showing real usage
• Cleaned up document structure (removed residual content at end)
• Enhanced trigger words in description frontmatter
• 2026-05-26: v1.0.0 — Initial release
• Built from analysis of 1,000+ real consultant comments
• 6 audit dimensions with consultant-style phrasebook
• Cross-document audit workflow (SRS→SDD→STP)
• Ready to audit: SRS, SDD, STPr, SRTM, SPMP, SQAP, SIS, etc.
• Added FAQ section, clarified what skill does/doesn't provide
• Removed all script references (no automation tools included)