Skip to content

List of known anomalies

Company: Nikted
Document Name: list-of-known-anomalies
Document Number: HAD-RPT-154-Rev1 Author: Ghafar Nosrati
Date (Persian Calendar): 1404/06/31

Revision History

Rev. no. Description Author(s) Reviewers Date (Persian) Authors' Signature Reviewers' Signature
1. Initial version Ghafar Nosrati Erfan Khebrati 1404/06/31

Purpose of This Document (according to IEC 62304)

The purpose of this document is to explain and describe the process of identifying, tracking, and managing software bugs and anomalies throughout the development and release cycle.
This document serves as an official compliance record with IEC 62304 and acts as a complement to the Release Notes.

This document is specifically used to:

  • Describe the process through which bugs are collected from multiple sources (developers, users, QA team), validated, and then logged in the official bug tracking system (Jira).
  • Clarify that in Jira, bugs are categorized, and the status of each bug (including related version, priority, and other details) is defined.
  • Provide transparency regarding bug status for each release by referring to Jira: which bugs have been fixed (Fixed) and which remain unresolved (Known Issues).

Therefore, this document is not intended as a full bug list, but rather as an explanation of the official process for tracking, categorizing, and managing bugs in Jira, and as compliance evidence with IEC 62304 clauses 5.7.5 and 5.8.2 / 5.8.3.

Regulatory references
IEC 62304:2006 Para. 5.7.5, 5.8.2 / 5.8.3

Bug Tracking and Review Process

In Nikted software projects, all bugs are recorded and maintained in an official bug tracking system at:
Bug Tracking Address: nikted-jira.darkube.app

This system serves as the main reference for identifying, logging, categorizing, evaluating, and monitoring the status of bugs.

Sources of Bug Identification

  • Developers: discover bugs during development and testing.
  • App Users: report bugs via the in-app feedback functionality.
  • Validation Process: incoming reports are reviewed by the responsible person/team. If the bug is confirmed, all required details (title, description, discovery date, method, related version, responsible person) are documented and the bug is registered in Jira.

Review Steps

  1. Bug Registration: each validated bug is entered into Jira.
  2. Pre-Release Review: before each release, the complete bug list is reviewed and status is determined:
  3. Fixed in this Release (Fixed)
  4. Known Issues (Unresolved)

  5. Documentation Reference: Fixed and unresolved bugs are documented and maintained in the dedicated Git repository.
    Bug Documentation

  6. Release Attachment: A reference (link) to this repository is included in each release package to provide transparent information to internal teams and regulatory bodies.

Example – Release Summary

Version v1.2.0 (Example)

This section provides an example of how release information should be documented. For each new version, a similar section must be completed.

What's Changed - Changed application icon - Set NikTone Client for client versions and NikTone Tolid for manufacturing versions

  1. Fixed Bugs
  2. Bug A – [Short description of fixed bug]

  3. Bug B – [Short description of fixed bug]

  4. Known Issues (Not Fixed in this Release)

  5. Bug C – [Short description of unresolved bug]
  6. Bug D – [Short description of unresolved bug]

🔹 Note: This example is for demonstration purposes only. For each release, this section must be updated accordingly.