1. Project Overview & Philosophy

• Author: Luc Calaresu (luc@calaresu.com)
• Project Name: OpenBumpy (Bumpy's Arcade Fantasy Modern Remake)
• Core Technology Stack: Custom 2D Game Engine built using C# and MonoGame (.NET).
• Architecture Philosophy: Strict end-to-end traceability. Every gameplay mechanic discovered via reverse engineering must be explicitly linked down to its functional requirement, software technical design, and automated/manual test execution blocks.
• Automation Friendliness: Documents are managed using StrictDoc (.sdoc). This allows automated tools to extract metrics, map test coverage, and generate the Requirements Traceability Matrix (RTM).
• Version: 1.0

2. The Documentation Suite Lifecycle (The Hierarchy)

The documentation suite is split into six distinct standalone documents that must be authored chronologically as development progresses.

2.1. Document Descriptions & Roles

1. [DBSM] Documentation Blueprint & Standards Manual: Governance, coding style guides, documentation rules, and parsing parameters.
2. [GDD] Game Design Document: Functional breakdown of the 1992 game mechanics and physics logic.
3. [FRD] Functional Requirements Document: Engine capacity checklist defining what the game engine must support.
4. [SDD] Software Design Document: Technical codebase blueprint (Classes, Game loops, ECS structures). Also referred to as TDD / Technical Design Document.
5. [STP] Software Test Plan: High-level testing philosophy, environments, and automated test run strategies.
6. [STD] Software Test Description: Step-by-step unit and integration test scripts to verify original behavior match.

2.2. Nomenclature & UID Prefixes Standard

To maintain strict global identification and structural alignment across the entire OpenBumpy technical stack, all elements within their respective documents MUST observe the following UID prefix conventions:

Document	Type de contenu	Préfixe d'UID	Exemple d'UID
DBSM (Standards Manual)	Règles / Normes	RULE-OB-	RULE-OB-001
GDD (Game Design)	Gameplay & Mechanics	GAME-OB-	GAME-OB-012
FRD (Functional Req.)	Exigences Func.	REQ-OB-	REQ-OB-045
SDD (Software Design)	Architecture & Tech.	SPEC-OB-	SPEC-OB-008
STP (Test Plan)	Stratégie & Jalons	PLAN-OB-	PLAN-OB-002
STD (Test Description)	Cas de tests op.	TEST-OB-	TEST-OB-103

2.3. Vertical Mapping Framework

Requirements MUST trace linearly downstream to ensure absolute verification coverage. This vertical relationship dictates that every engineering level directly answers or validates its upstream parent:

• A Functional Requirement (FRD) item explicitly targets and maps back to its parent Game Design (GDD) specification.
• A Software Design (SDD) component targets and maps back to the specific Functional Requirement (FRD) block it fulfills.
• A Software Test Description (STD) test script links directly to the Software Design (SDD) or Functional Requirement (FRD) component it exercises via StrictDoc RELATIONS.

3. Specification Writing Standards

This chapter defines the mandatory rules, syntax, and formatting conventions for writing project requirements. Every specification documented within this project MUST comply with these quality criteria to ensure clarity, testability, and unambiguous interpretation by all project stakeholders.

3.1. Requirement Verification Methods

Every specification MUST be assigned an explicit verification method to guarantee testability. Compliance MUST be proven using one of these four engineering standards:

1. Test (T): Actively running the software or engine using automated tools and test scripts to collect exact numerical data. * Example: Executing a C# xUnit test to check bounding box collision responses.
2. Demonstration (D): Operating the game or user interface to visually observe a functional behavior without deep instrumentation. * Example: Verifying that clicking the "Quit Game" button safely closes the application.
3. Inspection (I): Examining a static artifact, source code file, or document without compiling or executing the software. * Example: Reviewing a document file to check for correct specification text formatting.
4. Analysis (A): Using math equations, physics simulations, or analytical data to prove a rule is met when direct testing is impossible. * Example: Proving mathematically that the jump equation prevents objects from passing through solid blocks.

3.2. Requirement Priority Definitions

The table below establishes the evaluation matrix used to assign the Priority field for each specification item:

Priority Level	Technical Criteria	Impact of Non-Compliance
Critical	Core system functionality, safety regulation, or key.	The project or product cannot be delivered/deployed.
High	Major feature or critical performance metric required.	Serious degradation of utility; high workaround cost
Medium	Secondary feature, optimization, or enhancement.	Minor impact on operations; acceptable workaround.
Low	Aesthetic preference, minor convenience, QoL feature.	Negligible impact; can be deferred.

3.3. Quality Rules & Specifications

PREFIX: RULE-OB-

OB-SQMP-KEYW

3.3.1. RFC 2119 Keyword Usage

UID: OB-SQMP-KEYW

RULE-OB-001

3.3.1.1. Compliance Keyword Capitalization UID: RULE-OB-001 STATUS: Approved STATEMENT:

The author MUST write all compliance keywords (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY) in uppercase letters.

RATIONALE:

Ensures compliance keywords stand out visually and match standard RFC 2119 parsing engines.

VERSION:

1.0

PRIORITY:

Critical

SOURCE:

RFC 2119

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

✅ The system MUST encrypt all stored passwords.

RULE-OB-002

3.3.1.2. Prohibition of Vague Language UID: RULE-OB-002 STATUS: Approved STATEMENT:

The author MUST NOT use ambiguous terms such as generally, fast, ideally, or user-friendly within a specification description.

RATIONALE:

Ambiguity leads to subjective testing and variance in implementation.

VERSION:

1.0

PRIORITY:

High

SOURCE:

INCOSE Guide for Writing Requirements

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ The webpage SHOULD load fast.

✅ The webpage MUST load within 200 ms.

RULE-OB-003

3.3.1.3. Justification for Deviations UID: RULE-OB-003 STATUS: Approved STATEMENT:

The implementation team SHOULD document a technical justification whenever a SHOULD or SHOULD NOT requirement is bypassed.

RATIONALE:

Ensures that bypassing recommended practices is a deliberate, recorded engineering decision.

VERSION:

1.0

PRIORITY:

Medium

DEPENDENCIES:

RULE-OB-001

SOURCE:

RFC 2119

VERIFICATION_METHOD:

Inspection (I)

OB-SQMP-STRU

3.3.2. Sentence Structure and Architecture

UID: OB-SQMP-STRU

RULE-OB-004

3.3.2.1. Single Requirement Principle UID: RULE-OB-004 STATUS: Approved STATEMENT:

Each specification description MUST contain exactly one unique requirement.

RATIONALE:

Compound requirements create partial verification states where a test is both passed and failed.

VERSION:

1.0

PRIORITY:

Critical

SOURCE:

ISO/IEC/IEEE 29148:2018

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ The device MUST weigh under 1 kg and it MUST be painted black.

✅ The device weight MUST be under 1 kg.

RULE-OB-005

3.3.2.2. Active Voice Enforcement UID: RULE-OB-005 STATUS: Approved STATEMENT:

The author MUST write specification descriptions using the active voice.

RATIONALE:

Active voice explicitly assigns responsibility to a specific component or actor, eliminating ambiguity.

VERSION:

1.0

PRIORITY:

High

SOURCE:

INCOSE Guide for Writing Requirements

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ An email MUST be sent by the server.

✅ The server MUST send an email.

RULE-OB-006

3.3.2.3. Sentence Component Anatomy UID: RULE-OB-006 STATUS: Approved STATEMENT:

The author MUST structure every specification sentence using the sequence: [Subject] + [Keyword] + [Active Verb] + [Measurable Target or Condition].

RATIONALE:

Establishes syntactic consistency, allowing automated natural language processing (NLP) validation tools to audit specs.

VERSION:

1.0

PRIORITY:

High

DEPENDENCIES:

RULE-OB-001, RULE-OB-005

SOURCE:

INCOSE Guide for Writing Requirements

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

✅ The application [Subject] MUST log [Keyword + Active Verb] all errors [Condition].

RULE-OB-007

3.3.2.4. Sentence Length Limit UID: RULE-OB-007 STATUS: Approved STATEMENT:

The length of a specification description sentence SHOULD NOT exceed 15 words.

RATIONALE:

Shorter sentences maximize readability and minimize misinterpretation by non-native readers or suppliers.

VERSION:

1.0

PRIORITY:

Medium

SOURCE:

INCOSE Guide for Writing Requirements

VERIFICATION_METHOD:

Inspection (I)

OB-SQMP-METR

3.3.3. Metrics and Quantifiable Data

UID: OB-SQMP-METR

RULE-OB-008

3.3.3.1. Measurable Criteria Requirement UID: RULE-OB-008 STATUS: Approved STATEMENT:

Every performance or physical criterion MUST include a quantifiable, testable numerical value.

RATIONALE:

Prevents arguments between validation engineers and developers over whether an unquantified goal was hit.

VERSION:

1.0

PRIORITY:

Critical

DEPENDENCIES:

RULE-OB-002

SOURCE:

ISO/IEC/IEEE 29148:2018

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ The database MUST handle many connections.

✅ The database MUST support 5000 concurrent connections.

RULE-OB-009

3.3.3.2. Standard Unit System UID: RULE-OB-009 STATUS: Approved STATEMENT:

The author MUST express all physical units of measurement using the International System of Units (SI).

RATIONALE:

Avoids costly conversions and translation errors when working with global multi-tier supply chains.

VERSION:

1.0

PRIORITY:

High

DEPENDENCIES:

RULE-OB-008

SOURCE:

ISO 80000 (SI Standard)

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ The cable length MUST be 10 feet.

✅ The cable length MUST be 3.0 m.

RULE-OB-010

3.3.3.3. Mathematical Tolerance Notation UID: RULE-OB-010 STATUS: Approved STATEMENT:

The author SHOULD use standard mathematical symbols (e.g., ≤, ≥, ±) to define acceptable boundary limits and tolerances.

RATIONALE:

Standardizes numerical windows and removes prose variations like "up to" or "at least".

VERSION:

1.0

PRIORITY:

Medium

DEPENDENCIES:

RULE-OB-008

SOURCE:

ISO/IEC/IEEE 29148:2018

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

✅ The operational temperature MUST remain within 25 °C ± 5 °C.

OB-SQMP-IDEN

3.3.4. Identification and Labeling Rules

UID: OB-SQMP-IDEN

RULE-OB-011

3.3.4.1. Global Identification Regex Constraints UID: RULE-OB-011 STATUS: Approved STATEMENT:

The author MUST assign a unique identifier to every specification item across all project documentation that strictly matches the regular expression structure: ^[A-Z]{4,5}-OB-[0-9]{3,4}$.

RATIONALE:

Establishes a predictable text pattern allowing custom linting scripts and automated CI/CD tools to validate documentation parsing integrity.

VERSION:

2.0

PRIORITY:

Critical

SOURCE:

Traceability Architecture Validation

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

✅ REQ-OB-045

✅ RULE-OB-011

RULE-OB-012

3.3.4.2. Document Prefix Code Classification UID: RULE-OB-012 STATUS: Approved STATEMENT:

The author MUST restrict the prefix of requirements to one of the exact six system tokens defined in the Nomenclature Standard: RULE-OB-, GAME-OB-, REQ-OB-, SPEC-OB-, PLAN-OB-, or TEST-OB-.

RATIONALE:

Ensures immediate structural identification of requirement ownership and context mapping across the technical stack.

VERSION:

2.0

PRIORITY:

Critical

DEPENDENCIES:

RULE-OB-011

SOURCE:

Traceability Architecture Validation

VERIFICATION_METHOD:

Inspection (I)

RULE-OB-013

3.3.4.3. Sequential Number Padding Strategy UID: RULE-OB-013 STATUS: Approved STATEMENT:

The author MUST format the numeric ID variable as a sequential integer left-padded with zeros up to a minimum length of three digits.

RATIONALE:

Fixed-width numeric padding protects table layout alignment and guarantees correct alphabetical sorting inside tools.

VERSION:

2.0

PRIORITY:

High

DEPENDENCIES:

RULE-OB-011

SOURCE:

Project Automation Standard

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

❌ REQ-OB-5

✅ REQ-OB-005

OB-SQMP-REVI

3.3.5. Version Control and Lifecycle Management

UID: OB-SQMP-REVI

RULE-OB-014

3.3.5.1. Deprecated Identifier Preservation UID: RULE-OB-014 STATUS: Approved STATEMENT:

The author MUST NOT reuse or reassign the ID of a deleted or deprecated specification.

RATIONALE:

Prevents historical data corruption and tracking matrix mismatches across old releases.

VERSION:

1.0

PRIORITY:

Critical

DEPENDENCIES:

RULE-OB-011

SOURCE:

Regression Prevention Plan

VERIFICATION_METHOD:

Inspection (I)

EXAMPLES:

✅ If RULE-OB-009 is retired, its ID remains archived eternally.

RULE-OB-015

3.3.5.2. Specification Lifecycle Status Field UID: RULE-OB-015 STATUS: Approved STATEMENT:

The author MUST update the STATUS field to Deprecated when a specification is retired from the project scope.

RATIONALE:

Flags old requirements cleanly, allowing databases to filter out inactive scope elements instantly.

VERSION:

1.0

PRIORITY:

High

SOURCE:

Regression Prevention Plan

VERIFICATION_METHOD:

Inspection (I)

RULE-OB-016

3.3.5.3. Version Increment Rule UID: RULE-OB-016 STATUS: Approved STATEMENT:

The author MUST increment the version number by a step of 0.1 for minor cosmetic changes and by 1.0 for major technical modifications.

RATIONALE:

Tracks iteration impact levels, indicating to down-line managers if a verification reset is needed.

VERSION:

1.0

PRIORITY:

Medium

SOURCE:

Regression Prevention Plan

VERIFICATION_METHOD:

Inspection (I)

RULE-OB-017

3.3.5.4. Mandatory Context Fields UID: RULE-OB-017 STATUS: Approved STATEMENT:

The author MUST provide non-empty values for RATIONALE, DEPENDENCIES, and VERIFICATION_METHOD within every specification item.

RATIONALE:

Guarantees absolute auditing capability, dependency resolution, and test mapping for all requirements.

VERSION:

1.0

PRIORITY:

Critical

DEPENDENCIES:

RULE-OB-004

SOURCE:

Verification Standard

VERIFICATION_METHOD:

Inspection (I)