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.
| ✅ DO | ❌ DO NOT |
|---|---|
| ----------- | ------------ |
| Load this skill when user sends raw documents (SRS, SDD, STPr, SRTM, etc.) and asks you to audit/review/check them | Load this skill to audit comment sheets or review feedback documents — those are inputs for learning, not audit targets |
| Trigger phrases: "审核这个SRS", "check this SDD", "audit this document", "review this software doc", "does this STPr cover all requirements?" | Expect automated scripts or tools — this skill provides thinking patterns, not automation |
| Apply consultant thinking patterns to raw documents | Use this for non-software documents (hardware specs, contracts, etc.) |
Step 1: Load This Skill
Step 2: Provide the Document
read_file, vision_analyze (for images), or summarizeStep 3: Get Consultant-Style Feedback
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.
Consultant Logic:
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")
Consultant Logic:
REQ_SRS_02005 → REQ_SDD_02005)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")
Consultant Logic:
REQ_SRS_02005 in SRS but REQ_SDD_2005 in SDD)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}")
Consultant Logic:
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")
Consultant Logic:
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}")
Consultant Logic:
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}")
| Doc Code | Full Name | What Consultants Check |
|---|---|---|
| ---------- | ----------- | ------------------------ |
| SPMP | Software Project Management Plan | Planning, scheduling, resource allocation |
| SQAP | Software Quality Assurance Plan | QA activities, standards compliance |
| SCMP | Software Configuration Management Plan | Version control, change management |
| SRS | Software Requirements Specification | Functional/non-functional requirements, ID format |
| SRTM | Software Requirements Traceability Matrix | COMPLETE traceability chain (SRS→SDD→STP) |
| SDD | Software Design Description | Design elements matching SRS IDs |
| SIS | Software Interface Specification | All interfaces documented |
| STP | Software Test Plan | Test strategy, coverage goals |
| STPr | Software Test Procedure | 100% SRS coverage, no "TBD" |
| SLR | Software Lifecycle Requirements | Safety lifecycle |
| SVVP | Software Verification & Validation Plan | V&V activities for safety |
| SITR | Software Integration Test Report | Test results, pass/fail |
| SVVR | Software Verification & Validation Report | Final V&V results |
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
For each document, ask:
Use the phrasebook below to phrase findings like a real consultant:
Phrasebook:
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
| Status | Consultant Means | Action |
|---|---|---|
| -------- | ------------------- | -------- |
| Conforms | No issues found | ✅ Approve |
| Conforms as Noted | Minor issues, explain in response | ⚠️ Approve with comments |
| Revise as Noted and Resubmit | Major issues fixed | 🔄 Fix + resubmit |
| Rejected – Resubmit | Critical failures | ❌ Major rework |
| Open | Issues pending | ⏳ Wait |
| Closed | Approved | ✅ Done |
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%."
When auditing any document, use this mental checklist:
Full checklist template available at: templates/audit_checklist.md
| What You Get | What You DON'T Get |
|---|---|
| -------------- | ------------------- |
| ✅ 6 audit dimensions with consultant logic | ❌ No automated scripts or tools |
| ✅ Real consultant phrases (phrasebook) | ❌ No "one-click" audit button |
| ✅ Cross-document audit workflow | ❌ No file format restrictions (works with any text) |
| ✅ Input/output examples | ❌ No GUI or web interface |
| ✅ Checklist template | ❌ No automatic document parsing (you provide the text) |
Key point: This skill teaches thinking patterns. You (the AI) read the document text, apply these patterns, and generate consultant-style feedback.
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:
共 2 个版本