| Ver No | Date | Change Information | Author | Approver |

|-------|-------------|--------------------|------------------|--------------|

| V1.0 | 16 Mar 2026 | Initial Draft | Melisha Dsouza | Pooja Thorat |

Effective document management is essential for maintaining consistency, traceability, and organization within project and process documentation. A standardized naming convention helps ensure that all documents and files created across projects and process areas are easily identifiable, searchable, and properly version-controlled.

This document defines the standard naming conventions for files and artifacts within the Quality Management System (QMS). It provides guidelines for naming documents, spreadsheets, images, videos, diagrams, and other project-related files. By following these conventions, teams can maintain uniformity in documentation practices and support efficient document management across the organization.

The purpose of this document is to define a standard naming convention for all documents, files, and artifacts created within the Enovate IT Quality Management System (QMS).

- Consistent document naming

- Easy document identification

- Proper version control

- Efficient document organization across projects

This naming convention applies to all documentation and files created within organizational processes and project environments, including:

- Word documents

- Spreadsheets

- Presentations

- Images

- Videos

- Drawings and diagrams

- PDF documents

- Text files

- Source code files

- Archive files

All project teams and stakeholders must comply with this naming standard.

In this document, “Documents” refers to formal, text-based files such as Microsoft Word documents (.doc or .docx) used to create requirements, design specifications, procedures, plans, and reports within projects and organizational processes.

- Software Requirement Specification (SRS)

- High Level Design (HLD)

- Low Level Design (LLD)

- Project Plans

- Procedures

- Reports

These documents are typically editable files that undergo review, approval, and version control.

This format is used for formal and controlled documents that require version tracking and updates.

Example: `EnovateIT_QMS_TS_DS01_Acanis_HLD_V1.0`

- Review and approval processes

- Version updates

- Document control procedures

For documents that are organizational standards, policies, procedures, or process assets and are not associated with a specific project, the ProjectName field should be replaced with “Organization”. This indicates that the document applies across the entire organization rather than to a specific project.

This format is used for supporting Word documents that do not require formal version control.

- Code review documents

- Supporting checklists

- Flow descriptions

- Reference notes

- Internal review documents

**Format:** `EnovateIT_QMS_[ProcessArea]_[ProjectName]_[DocName]_[DDMMYYYY]`

**Example**: `EnovateIT_QMS_PQA_Acanis_CodeReview_16032026`

Format: `EnovateIT_QMS_[ProjectName]_[PlanName]_V[Version]`

- EnovateIT_QMS_Acanis_ReleasePlan_V1.0

- EnovateIT_QMS_Acanis_TestPlan_V1.0

**Example**: `EnovateIT_QMS_PQA_L01_Acanis_DefectLog_V1.0`

**Format 1**: `TraceabilityMatrix_Client_[ProjectName]_Release_V[Version]`

**Example:** `TraceabilityMatrix_Client_Acanis_Release_V1.0`

**Example**: `EnovateIT_QMS_VV_RTM_Acanis_V1.0`

**Images** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(ImageName)`

**Videos** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(VideoName)`

**Drawings / Diagrams** `EnovateIT_QMS_(ProcessArea)_(ProjectName)_(DrawingName)`

**Example**: `EnovateIT_QMS_TS_Acanis_SystemArchitecture`

**Format**: `[ProjectKey]_Sprint_[Number]`

**Example**: `ACM_Sprint_01`

| Document Type | Code |

|------------------|------|

| Procedure | P |

| Checklist | C |

| Log | L |

| Form | F |

| Plan | PL |

| Template | T |

| Item List | I |

| Report | R |

| Drawing | D |

| Design Document | DS |

| Specification | S |

DocTypeNumber represents a combination of the Document Type Code and a unique sequential number assigned to a specific document type.

**Format**: `DocTypeNumber = Document Type Code + Serial Number`

- **PL**- Document Type = **Plan**

- **01**- Serial number of that document type

The number is assigned sequentially for documents under the same Document Type within a process area.

**Example in file name:**

| Category | Description |

|----------|-------------|

| Word Documents | Text-based documents used for requirements, design, and reports |

| Spreadsheets | Used for logs, matrices, and data tracking |

| Presentations | Slide-based documents used for meetings and project presentations |

| Images | Graphic files such as screenshots and diagrams |

| Videos | Demonstration or training recordings |

| Drawings / Diagrams | System architecture and workflow diagrams |

| PDF Documents | Finalized documents shared in non-editable format |

| Text Files | Plain text files used for notes or configurations |

| Source Code Files | Programming files used in application development |

| Archive Files | Compressed files used for storing multiple documents |

To ensure cross-platform compatibility and script-friendliness, all files must adhere to these syntax rules:

- **No Spaces:** Use underscores `(_)` instead of spaces.

- **Case Sensitivity:** Use PascalCase for descriptive names (e.g., `UserManual`, `not usermanual`).

- **Special Characters:** Do NOT use any of the following: `! @ # $ % ^ &( ) + = { } [ ] | \ : ; " ' < > ? / ,`

- **Date Format:** When a date is required in a filename (e.g., for Meeting Minutes), use the ISO 8601 format: `YYYYMMDD.`

For traceability in communication, all project-related emails should follow this format: `[ProjectID] [ProcessArea] - [Subject Brief]`

**Example**: `[ACM] [RDM] - Review of Requirement Specs V0.1`

To maintain a clear distinction between "Work in Progress" and "Approved" documents, the following sub-versioning rules apply:

**Version format:** `V[Major].[Minor]`

| Ver | Status | Description |

|-------|-----------------|-------------|

| V0.x | Draft | Initial creation and internal team reviews (e.g., V0.1, V0.2) |

| V1.0 | Approved | First formal release after stakeholder sign-off |

| V1.x | Minor Update | Editorial changes, typo fixes, or small formatting updates |

| V2.0 | Major Revision | Significant change in scope, process, or project requirements |

All project teams must follow this naming convention to maintain consistency, traceability, and organized documentation across the organization.

The Process Quality Assurance (PQA) team may review documents periodically to ensure compliance with this standard.

| Term | Definition |

|--------------------|------------|

| QMS | Quality Management System used to manage organizational processes and documentation |

| Process Area | Functional area responsible for specific organizational processes |

| Document Type Code | Short identifier used to classify the type of document |

| Version | Numeric identifier used to track document revisions |

| Artifact | Any document, file, or output generated during project execution |

| Process Area | Code |

|---------------------------------------|------|

| Requirement Development Management | RDM |

| Estimating | EST |

| Planning | PLAN |

| Monitoring and Control | MC |

| Managing Performance and Measurement | MPM |

| Peer Review | PR |

| Process Management | PCM |

| Product Integration | PI |

| Technical Solution | TS |

| Process Quality Assurance | PQA |

| Configuration Management | CM |

| Verification and Validation | VV |

| Risk and Opportunity Management | ROM |

| Process Asset Development | PAD |

| Organizational Training | OT |

| Decision Analysis and Resolution | DAR |

| Governance | GOV |

| Implementation Infrastructure | II |

| Causal Analysis and Resolution | CAR |

| Supplier Agreement Management | SAM |

All documents following this naming convention must be:

- Stored in the approved project repository

- Maintained with version control

- Reviewed periodically by the QA or process team

- Updated whenever significant changes occur

| Abbreviation | Full Form |

|--------------|-----------|

| QMS | Quality Management System |

| SRS | Software Requirement Specification |

| HLD | High-Level Design |

| LLD | Low-Level Design |

| RTM | Requirements Traceability Matrix |

| PQA | Process Quality Assurance |

| SDLC | Software Development Life Cycle |

[The document can be accessed and downloaded from the following link](https://docs.google.com/document/d/1-W37LGdJ9Km6REh6BwGCtksbtQB17bsj1hS8rpqRvJE/edit)