Skip to main content
Version: 3.0.1

STD: Known Issues and Behavior Differences (KNOWN-ISSUES)

Version: v1.0.0 Status: Draft SRS Source: docusaurus/docs/traceability/known-issues.md Domain: KNOWN-ISSUES


Overview

This document specifies tests for the Known Issues domain, which serves as a registry tracking discrepancies between SRS requirements and actual implementation behavior.

Domain Characteristics:

  • Primary function: Documentation registry (meta-document)
  • Secondary function: Traceability tracking between issues and affected requirements
  • Nature: Process/documentation domain, not functional system behavior

Test Method Rationale: Unlike functional domains, Known Issues is a documentation registry rather than system functionality. Per Test Plan section 3.2, documentation completeness and process compliance require human judgment, making TM-MAN the primary method. There are no APIs to test or UI workflows to automate - verification focuses on document quality and traceability completeness.

Test Case Convention: Steps describe verification actions for documentation artifacts, not system interactions. Since this domain tracks meta-information about requirements rather than implementing testable behavior, tests verify that the registry itself is complete, consistent, and properly linked.


Coverage Summary

REQ IDTitleACsTestsAC CoverageMethodGaps
PROC-KI-001Issue Registry Completeness5TC-KI-001, TC-KI-0025/5 (100%)TM-MANNone
PROC-KI-002Issue Traceability4TC-KI-003, TC-KI-0044/4 (100%)TM-MANNone
PROC-KI-003Issue Lifecycle Management3TC-KI-0053/3 (100%)TM-MANNone

Totals: 3 Process Requirements, 12 ACs (derived), 5 Test Cases, 100% Coverage

Note: The Known Issues document does not contain traditional REQ-KNOWNISSUES-NNN identifiers. Instead, it defines a process for tracking known issues (KI-NNN). The test cases below verify process compliance and registry completeness rather than functional system behavior. Process requirements are prefixed PROC-KI to distinguish them from functional requirements.


Derived Process Requirements

Since the SRS file known-issues.md is a registry document rather than a traditional requirements specification, the following process requirements are derived from its stated purpose and structure:

PROC-KI-001: Issue Registry Completeness

The Known Issues registry shall maintain complete documentation for each tracked issue.

Acceptance Criteria:

  • AC1: Each known issue has a unique identifier (KI-NNN format)
  • AC2: Each issue documents severity level (Low, Medium, High)
  • AC3: Each issue documents current status (Open, Open - Intentional, In Progress, Closed)
  • AC4: Each issue documents affected SRS requirement reference
  • AC5: Each issue documents resolution options

PROC-KI-002: Issue Traceability

The Known Issues registry shall maintain traceability to affected requirements and design documents.

Acceptance Criteria:

  • AC1: Each issue links to at least one REQ-* identifier
  • AC2: Each issue has a Gap ID reference (GAP-NNN)
  • AC3: Traceability matrix includes all active issues
  • AC4: Each issue links to relevant SDD section

PROC-KI-003: Issue Lifecycle Management

The Known Issues registry shall document issue lifecycle status accurately.

Acceptance Criteria:

  • AC1: Valid status values are documented (Open, Open - Intentional, In Progress, Closed)
  • AC2: Status transitions are reflected in the registry
  • AC3: Discovery source is documented for each issue

Test Cases

TC-KI-001: Issue documentation completeness - required fields

Verifies: PROC-KI-001 (AC1, AC2, AC3)

Method: TM-MAN

Priority: High

Preconditions:

  • Access to Known Issues registry document (docusaurus/docs/traceability/known-issues.md)
  • At least one active known issue exists in the registry

Steps:

  1. Open the Known Issues registry document
  2. For each issue in the "Active Issues" section, verify the issue table contains all required attributes
  3. Verify identifier format matches KI-NNN pattern
  4. Verify severity is one of: Low, Medium, High
  5. Verify status is one of: Open, Open - Intentional, In Progress, Closed

Expected Results:

  • AC1: All issues have unique KI-NNN identifiers (currently KI-001, KI-002)
  • AC2: All issues specify severity level
  • AC3: All issues specify valid status value

Automation Status: Manual (document review)

Jira: N/A - Process verification


TC-KI-002: Issue documentation completeness - requirement linkage

Verifies: PROC-KI-001 (AC4, AC5)

Method: TM-MAN

Priority: High

Preconditions:

  • Access to Known Issues registry document
  • Access to referenced SRS documents

Steps:

  1. For each active issue, verify "Requirement Statement" section exists
  2. Verify the requirement reference (REQ-*-NNN) points to a valid SRS requirement
  3. Open the referenced SRS document and confirm the requirement exists
  4. For each active issue, verify "Resolution Options" section exists with at least one option

Expected Results:

  • AC4: KI-001 references REQ-USERSET-002 (verify exists in docusaurus/docs/srs/user-settings.md)
  • AC4: KI-002 references REQ-SITE-002 AC-05 (verify exists in docusaurus/docs/srs/site.md)
  • AC5: Each issue lists numbered resolution options

Automation Status: Manual (cross-document verification)

Jira: N/A - Process verification


TC-KI-003: Traceability matrix completeness

Verifies: PROC-KI-002 (AC1, AC2, AC3)

Method: TM-MAN

Priority: High

Preconditions:

  • Access to Known Issues registry document
  • Traceability Matrix section exists in document

Steps:

  1. Locate the Traceability Matrix section in the document
  2. Count the number of issues in "Active Issues" section
  3. Count the number of rows in Traceability Matrix
  4. Verify each row contains: Issue ID, Gap ID, SRS Requirement, SDD Section, Status, Verification

Expected Results:

  • AC1: Every active issue (KI-001, KI-002) appears in the traceability matrix with REQ reference
  • AC2: Every row has a Gap ID (GAP-044, GAP-045)
  • AC3: Row count in matrix equals count of active issues (currently 2)

Automation Status: Manual (document audit)

Jira: N/A - Process verification


TC-KI-004: SDD section linkage validity

Verifies: PROC-KI-002 (AC4)

Method: TM-MAN

Priority: Medium

Preconditions:

  • Access to Known Issues registry document
  • Access to referenced SDD documents

Steps:

  1. For each row in Traceability Matrix, note the SDD Section reference
  2. Open each referenced SDD document
  3. Verify the file exists and contains relevant content

Expected Results:

  • AC4: KI-001 links to sdd-security.md - file exists and contains user validation content
  • AC4: KI-002 links to sdd-architecture.md - file exists and contains S3 storage content

Automation Status: Manual (cross-document verification)

Jira: N/A - Process verification


TC-KI-005: Issue lifecycle status accuracy

Verifies: PROC-KI-003 (AC1, AC2, AC3)

Method: TM-MAN

Priority: Medium

Preconditions:

  • Access to Known Issues registry document
  • Issue Lifecycle table exists in document

Steps:

  1. Locate the "Issue Lifecycle" section
  2. Verify all four status values are documented with descriptions
  3. For each active issue, verify its status matches one of the documented values
  4. Verify each issue has a "Discovered" attribute with source information

Expected Results:

  • AC1: Issue Lifecycle table defines: Open, Open - Intentional, In Progress, Closed
  • AC2: Each active issue has status matching defined values
    • KI-001: Status = "Open"
    • KI-002: Status = "Open - Intentional"
  • AC3: Each issue documents discovery source
    • KI-001: "Pass C Code Review (2026-01-19)"
    • KI-002: "Pass C Code Review (2026-01-19)"

Automation Status: Manual (document review)

Jira: N/A - Process verification


Gap Analysis

No gaps identified. All 12 derived acceptance criteria have test coverage.

Coverage Notes

Verification AspectTest CoverageNotes
Issue IdentificationTC-KI-001Verifies KI-NNN format
Severity/StatusTC-KI-001Verifies required fields
Requirement LinksTC-KI-002, TC-KI-003Cross-document verification
Gap ID TrackingTC-KI-003Traceability matrix audit
SDD LinkageTC-KI-004Design document verification
Lifecycle ComplianceTC-KI-005Status value validation

Domain Scope Limitation

This domain is a documentation registry, not functional software. The tests verify:

  • Document completeness (all required fields present)
  • Cross-reference validity (linked requirements exist)
  • Traceability coverage (matrix includes all issues)
  • Process compliance (status values, discovery tracking)

Tests do NOT verify:

  • System behavior (no system implements "known issues")
  • API responses (no API endpoints exist for this domain)
  • UI functionality (no UI displays this registry)

Traceability to Existing Tests

Test CaseJira TestAutomation
TC-KI-001N/AManual
TC-KI-002N/AManual
TC-KI-003N/AManual
TC-KI-004N/AManual
TC-KI-005N/AManual

Note: No automated tests exist for this domain as it is a documentation process, not system functionality. Manual verification during QA review cycles provides process compliance assurance.


Notes

  • Known Issues is a meta-document tracking discrepancies, not a functional requirement specification
  • All test cases use TM-MAN because verification requires human judgment on documentation quality
  • The document references requirements in other domains (USERSET, SITE) - those requirements are tested in their respective STD files
  • Issue resolution (fixing code or updating requirements) is outside the scope of this STD
  • The completion checklist in the SRS document provides an internal self-assessment mechanism