Critique this req doc I was given.
Go!
---
[Product] Ticketing Requirements
The following defines the requirements for the [Product] ticketing application. These requirements outline the architecture and basic functionality to kick-off the ticketing application project. These requirements do not define all future features or the architecture to support them, but some are mentioned in this document for tracking purposes.
Goals
These are the high-level goals of the [Product] ticketing application.
1. Replace the existing ticketing software with a [Company] developed solution.
2. Create a single and centrally accessible point for [Company] to review client tickets.
3. Implement and maintain ticketing workflow associated with [OtherProduct1] and the [Company] MDR service offering.
4. Implement and maintain reporting requirements associated with [OtherProduct1] and the [Company] MDR service offering.
5. Integration with [OtherProduct1], [Product] Cloud, and [Product] On-Prem.
Users
There are two groups of users for the ticketing application, [Company] personnel and Client personnel. Within these groups are Admins and Users. [Company] users will have access to all client instances based on the their roles as Admins or Users. Client users will be restricted to their specific client instance as the roles to which they belong.
Authentication and Authorization
Final implementation must leverage single sign-on via the [Product] Portal for authentication and authorization via group membership. However, initial development of functionality should leverage a local authentication model for the sake of simplicity. Once functionality has been built, integration with external authentication and authorization should be built. Having a standalone authentication model may be desirable in certain scenarios and building it out initially this way may be worthwhile.
The initial model should be built so that authentication and group membership is identified in one function and the results are used throughout the application. The application must not rely on continuous validation of user rights through the user session. To be precise, changing the authentication model should not result in changes to code outside the authentication function.
Site Map
The ticketing application must have a single UI that can be used in a multi-tenant fashion ([Company]) as well as in a single-tenant manner (Clients). This will be made possible through configuration of the UI to include one or more “client configurations”. These configurations will be an array of elements consisting of the client name and database connection information. The UI will leverage each of those elements to define a list of clients. If only one is configured, then the single-tenant mode is activate. If multiple configurations are present then the multi-tenant mode is active.
This illustrates single vs multi-tenant mode of operation based on number of configured elements.
Page Descriptions
The above site map contains the basic functionality of the ticketing application. The descriptions for each page are as follows:
• Home – A set of statistics that provides an at-a-glance view of the current volume of open tickets.
• Search – Provides a mechanism to search across all tickets based on a number of criteria, including full text search.
• Tickets/ClientX – Provides a list of all tickets, including quick views into open vs closed tickets. Offers the means to create a new ticket and page through existing tickets. Clicking on a ticket opens that ticket.
• Admin – Administrative functions
Wireframes
These are rudimentary wireframes for the above pages. Home Wireframe -
https://wireframe.cc/hx17J2 Search Wireframe -
https://wireframe.cc/yqpQFc Ticket List Wireframe -
https://wireframe.cc/nbUneF Ticket Wireframe -
https://wireframe.cc/qfueEj Tenancy Approach
Tenancy Approach 1
• Ticketing UI is the same for both multi-tenant and single-tenant views
• Difference is in back-end configuration of the UI that contains either a single tenant or multiple
tenants
• Configuration is client name + client-specific database connection
• Databases housed on cloud Db server or on-prem dbas module
• [Company] UI will have all tenants configured
• Client UIs will have their own single tenant configured
• [Company] UI will live on [OtherProduct1] or Sonar web instance
• Client UI will live in client containers or on-prem http module
• This approach is currently used in the cloud environment
Tenancy Approach 2
• Same as approach 1, but the databases are moved to client container environment.
• This is more secure as client UI not have layer 4 access to Db housing other client data.
• Potentially more scalable and Db maintenance could be done on single clients instead of all clients at once.
• Accessibility into containers is problematic and would requite architecture changes to accommodate.
• Options regarding how this could be accomplished should be discussed.
• Current approach is implemented with TBG using Approach 1.
• Current approach with [Product]’s User Db settings is implemented using Approach 1.
Architecture Considerations
The On-Prem and Cloud architectures will leverage the Tenancy Approach 1 as noted above. While each will work well in this model, accessing on-prem ticketing databases may prove problematic and not worth the incurred risks by allowing the a cloud host to access those databases over the [Product] network.
It may be worth discussing moving those ticketing systems to the cloud environment. This would introduce challenges with single factor authentication from on-prem to the cloud ticketing system. Each scenario poses its own benefits, troubles, and risks.
These constraints should not impede development of the ticketing application, but are noted here as potential implementation and integration issues.
Platform and Languages
Here is the list of preferred platforms and languages: • Linux
• NGINX
• PHP
• Go
• TypeScript
The initial look and feel may not meet production standards and initial development is designed to implement functionality. Once functionality is established the aesthetics can be adjusted. However, modern design elements should be considered when building UI functionality. To that end, prototyping via Bootstrap should be utilized.
https://getbootstrap.com/ Functional Elements
Db Schema
Up to the discretion of the developer. Tickets and user settings must be their own tables.
Notifications
Workflow items such as ticket creation, updates, and closing should trigger an email notification. Notification must consider the user settings.
Ticket Fields
• Client
• Category (e.g., Informational, Operational, Security Event, Security Incident)
• Event Type (e.g., Reconnaissance, Compromised Account, External Threat)
• Severity
• Status
• Assignment
• Name
• Summary
• Recommendation
• Affected Resources
• Comments
• History (timestamp workflow actions)
• Deleted Boolean
Workflow Items
• Create Ticket
• Create Ticket via [OtherProduct1] button (auto-adds elements to ticket)
• Status Change (Open/Close)
• Assignment Change
• Create Comment
• Upload Screenshot
• Delete Ticket (soft delete)
User Settings
• Email address
• Notification settings by category
◦ Ticket Creation ◦ Ticket Updates ◦ Ticket Close
Admin Settings
• Manage User Settings
◦ Users exist in separate directory, but application settings remain in Db ◦ Notification Email
◦ Notification Settings as described in User Preferences
• Create Notification Distribution List ◦ By Category
◦ Ticket Creation
◦ Ticket Updates
◦ Ticket Close
• Add Categories/Event Types
Future Feature Considerations
API integration with major third party ticketing systems Ticket templates based on category and event type Reports and Trends
