Designing an Internal IT Support Ticketing System: Requirements, Architecture Decision Matrix, and Prototype
Systems Analytics and Enterprise Management
Systems analysis for an internal IT helpdesk ticketing system — requirements definition, a weighted decision matrix comparing three architecture alternatives, and a working front-end prototype
Apply systems analysis techniques — requirements elicitation, alternative evaluation, and structured decision-making — to design enterprise information systems that align with organizational needs.
Designing an Internal IT Support Ticketing System
Kun Zhang
Ottawa University · IT 7000: Systems Analytics and Enterprise Management
Week 4 Assignment — Alternative Decision Matrix
Problem Statement
Most mid-size organizations still route IT support requests through email or chat, which gives staff no reliable queue, no priority signal, and no audit trail. The Week 4 deliverable for this course was a Software Design Specification (SDS) for an internal IT support ticketing system, followed by a structured evaluation of the architecture alternatives available to implement it. This essay summarizes the requirements the system had to satisfy, walks through the weighted decision matrix used to choose between three candidate architectures, and links to a working front-end prototype of the resulting ticket submission flow.
Requirements Baseline
The SDS defined the following functional and non-functional requirements, which also became the evaluation criteria in the decision matrix below:
- FR-01 — Standardized ticket submission with required diagnostic fields (requester, category, priority, subject, description).
- FR-02 / NFR-03 — Centralized ticket queue that supports concurrent access from multiple technicians.
- FR-03 — Dynamic priority-tier assignment, adjustable by IT staff after intake.
- FR-05 — Automated status-update notifications back to the requester.
- FR-06 — Data consistency and reporting support for queue metrics.
- NFR-01 / NFR-02 — Browser-based access with no client install, and a codebase the existing team can maintain.
- NFR-04 — Role-based access control for technicians versus requesters.
- NFR-05 — Support for phased, incremental adoption rather than a big-bang rollout.
Alternatives Considered
Three architectures were scored against that baseline:
- Alternative A — Three-tier + relational database. The architecture originally proposed in the SDS: a browser client, a stateless application server, and a relational database holding tickets, users, and status history.
- Alternative B — Monolithic + relational database. Same relational schema, but client and server logic are bundled into a single deployable unit to reduce operational overhead.
- Alternative C — Microservices + document (NoSQL) database. The workload is split into independent services (intake, queueing, notifications), each backed by its own document store.
Weighted Decision Matrix
Each criterion was weighted by business importance (weights sum to 1.0) and scored 0–10 per alternative; weighted score = points × weight.
| Criterion | Weight | A — Three-tier | B — Monolith | C — Microservices |
|---|---|---|---|---|
| Standardized submission with diagnostic fields (FR-01) | 0.10 | 0.90 | 0.70 | 0.70 |
| Centralized queue, concurrent access (FR-02, NFR-03) | 0.12 | 1.08 | 0.72 | 0.96 |
| Dynamic priority-tier assignment (FR-03) | 0.10 | 0.90 | 0.60 | 0.80 |
| Automated status-update notifications (FR-05) | 0.05 | 0.40 | 0.30 | 0.35 |
| Development cost / implementation difficulty | 0.08 | 0.56 | 0.64 | 0.32 |
| Scalability for future growth | 0.08 | 0.56 | 0.32 | 0.72 |
| Security and role-based access control (NFR-04) | 0.10 | 0.80 | 0.60 | 0.50 |
| Browser compatibility, no client install (NFR-01, NFR-02) | 0.10 | 0.90 | 0.80 | 0.80 |
| Data consistency and reporting support (FR-06) | 0.05 | 0.45 | 0.40 | 0.25 |
| Maintainability, team familiarity (NFR-02) | 0.10 | 0.80 | 0.60 | 0.40 |
| Phased / incremental adoption support (NFR-05) | 0.05 | 0.40 | 0.25 | 0.45 |
| Overall alignment with prioritized requirements | 0.07 | 0.63 | 0.42 | 0.35 |
| TOTAL | 1.00 | 8.38 | 6.35 | 6.60 |
Result and Rationale
Alternative A (three-tier, relational database) won with a weighted score of 8.38 / 10, ahead of Microservices + NoSQL (6.60) and the Monolith (6.35). The relational schema scored highest on exactly the criteria carrying the most weight: concurrent queue access (0.12), standardized intake fields, priority handling, security, browser compatibility, and maintainability (each 0.10). A ticketing system is fundamentally relational — tickets, users, and status history reference one another and need consistent, transactional updates — so a relational store fit the domain better than splitting state across independent document stores. Alternative C scored better on raw scalability and phased adoption, but it loses on development cost and on maintainability, since the team has no existing microservices experience. Alternative B is cheaper to build but caps future scalability and concurrent-access support, which are core to the requirements. The three-tier architecture was therefore carried forward into implementation.
Prototype: Ticket Submission Flow
To make the SDS tangible, the client tier of Alternative A was built out as a working front-end prototype: a ticket submission form implementing FR-01 (required diagnostic fields), FR-03 (an editable priority selector), and a live preview panel that mirrors the data a technician would see land in the queue (FR-02). Submitting the form generates a ticket ID, stores a local record of the request, and hands off to a confirmation screen where the ticket can be downloaded as a backup file — a simple stand-in for the automated notification in FR-05.
It’s a static, client-side demo built for this course rather than a connected backend, but it reproduces the intake experience the SDS describes end to end.