Severity Categories

1. Introductie (Voor Klanten & Partners)

Onze Severity Categories definiëren hoe we bugs en incidenten classificeren op basis van hun impact, urgentie en reikwijdte. Door een ernstniveau toe te wijzen, kunnen onze teams efficiënt prioriteit geven aan oplossingen en ervoor zorgen dat kritieke problemen onmiddellijke aandacht krijgen. Dit transparante classificatieproces helpt klanten en partners te begrijpen hoe we problemen beheren en oplossen om de stabiliteit en kwaliteit van het product te waarborgen.

2. Wie Is Betrokken

Rol	Betrokkenheid	Voordeel voor Jou
Productmanager	Beoordeelt incidentrapporten en zorgt ervoor dat de ernstclassificaties in lijn zijn met de bedrijfsprioriteiten.	Helpt ervoor te zorgen dat kritieke problemen snel worden geprioriteerd en aangepakt.
Ontwikkelteam	Analyseert bugs en wijst ernst toe op basis van technische impact en potentiële risico's.	Garandeert dat middelen worden toegewezen op basis van de werkelijke impact van het probleem.

| QA/Testing Team | Valideert de ernst door middel van uitgebreide tests en kwaliteitsbeoordelingen. | Biedt zekerheid dat problemen correct worden geprioriteerd voor oplossing. | | Stakeholders/Clients | Ontvangen updates over kritieke incidenten en de stappen die zijn ondernomen om deze op te lossen. | Zorgt voor transparantie over hoe urgente problemen worden beheerd. |

---

3. Overzicht van Ernstigheidscategorieën

Hieronder staan de primaire ernstigheidsniveaus die we gebruiken om incidenten te categoriseren:

• Kritiek (Ernstigheid 1):

  • Definitie: Problemen die een volledige systeemuitval of kritieke functionaliteitsfout veroorzaken, met ernstige gevolgen voor de gebruikersoperaties.
  • Reactie: Onmiddellijke aandacht met een hotfix die in de huidige sprint wordt uitgerold.

• Hoog (Ernstigheid 2):

  • Definitie: Problemen die de functionaliteit aanzienlijk belemmeren zonder de operaties volledig te stoppen.
  • Reactie: Geprioriteerd voor oplossing in de huidige of volgende sprint.

• Gemiddeld (Ernstigheid 3):

  • Definitie: Problemen die niet-kritieke functionaliteit beïnvloeden of een gematigd effect hebben op de gebruikerservaring.
  • Reactie: Gepland voor oplossing in aankomende sprints, afhankelijk van beschikbare middelen.

• Laag (Ernst 4):

  • Definitie: Kleine problemen, waaronder cosmetische of triviale bugs, die minimale impact hebben op de algehele functionaliteit.
  • Reactie: Aangepakt tijdens reguliere onderhouds- of backlog verfijningssessies.

4. Processtroom / Diagram

Hieronder volgt een overzicht van hoe ernstcategorieën worden toegepast met behulp van dubbele aanhalingstekens voor de Mermaid-labels:

1. **Bug of Incident Gerapporteerd:** Een probleem wordt ingediend via onze rapportagekanalen.
2. **Initiële Triage & Beoordeling:** Onze teams voeren een voorlopige evaluatie uit om de impact van het probleem te bepalen.
3. **Toewijzen van Ernstigheidsniveau:** Op basis van de beoordeling wordt het probleem geclassificeerd als Kritiek, Hoog, Medium of Laag.
4. **Reactie Acties:**  
   - **Kritiek:** Onmiddellijke hotfix.
   - **Hoog:** Geprioriteerd voor de huidige of volgende sprint.
   - **Medium:** Gepland voor oplossing in aankomende sprints.
   - **Laag:** Beheerd tijdens reguliere backlog verfijning.

---

## 5. FAQ

**Q1: Wat zijn Severity Categories?**  
**A1:** Severity Categories zijn classificaties die de urgentie en impact van bugs of incidenten bepalen, en onze reactie- en prioriteringsinspanningen begeleiden.

**Q2: Wie bepaalt de ernst van een probleem?**  
**A2:** De Development en QA teams voeren een initiële triage uit, met toezicht van de Product Manager om ervoor te zorgen dat deze in lijn is met de bedrijfsprioriteiten.

**Q3: Hoe snel worden Kritieke problemen aangepakt?**  
**A3:** Kritieke problemen krijgen onmiddellijke aandacht en worden doorgaans opgelost via een hotfix in de huidige sprint.

**Q4: Hoe profiteert de klant van de ernstclassificatie?**  
**A4:** Het biedt duidelijkheid over ons prioriteringsproces, zodat de meest impactvolle problemen snel worden opgelost om de stabiliteit van het product te waarborgen.

## 6. Volgende Stappen en Aanvullende Bronnen

- **Bug Lifecycle:** Leer meer over hoe problemen voortgaan van rapportage tot oplossing op onze [Bug Lifecycle-pagina](/docs/roadmap/bug-lifecycle).  
- **Backlog Management:** Ontdek onze aanpak voor het beheren en prioriteren van gerapporteerde problemen op onze [Backlog Management-pagina](/docs/roadmap/process/backlog-management).  
- **Neem Contact Met Ons Op:** Voor verdere vragen of dringende zorgen, neem alstublieft contact op via [contact support](mailto:contact+support@aismarttalk.tech) of chat met ons team op onze website.