Welcome, Guest. Please login or register.

Author Topic: Hey, tech folks... project req doc  (Read 430 times)

0 Members and 1 Guest are viewing this topic.

Offline chornbe

  • Contributor
  • Member
  • Location: Wilmington, Delaware
  • Posts: 6976
    • The Pace Motorcycle Podcast
  • Motorcycles: Honda DN-01
Hey, tech folks... project req doc
« on: February 22, 2020, 10:17:31 PM »
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
this signature on hold pending review

Offline Cookie

  • Super Moderator
  • Member
  • Location: Most of the time I'm not 100% sure.
  • Posts: 14318
  • Tacos are life.
  • Motorcycles: '16 MG Audace, '10 Ural T, '19 Ural Gear Up and from out of nowhere, the surprise '06 KLR 650!
Re: Hey, tech folks... project req doc
« Reply #1 on: February 23, 2020, 01:29:26 AM »
Are you fucking high?
“Government is the Entertainment division of the military-industrial complex.”

― Frank Zappa

Offline sleazy rider

  • Contributor
  • Member
  • Location: White Lake, Michigan
  • Posts: 3149
  • Trapped!
    • Da Blog!
  • Motorcycles: 1990 Suzuki DR350S
Re: Hey, tech folks... project req doc
« Reply #2 on: February 23, 2020, 05:18:19 AM »
Rough guess?
--Tom

Offline bungie4

  • Member
  • Location: Sudbury, Ontario
  • Posts: 821
    • Assistance List
  • Motorcycles: 2013 FJR
Re: Hey, tech folks... project req doc
« Reply #3 on: February 23, 2020, 07:53:30 AM »
Sorry, I didn't read it, but I skimmed it.  It's one of those documents that everybody just wings.  Just keep in mind that the contractee can use in court.  I usually skip with the supporting software etc and focus on the functionality.  If it's not written down in that document, it's subject to additional charges (LOL! I said that with a straight face!).

Otherwise, pretty good.
-Steve
SnowMexican
WWPD
choo choo mf'r.

Offline chornbe

  • Contributor
  • Member
  • Location: Wilmington, Delaware
  • Posts: 6976
    • The Pace Motorcycle Podcast
  • Motorcycles: Honda DN-01
Re: Hey, tech folks... project req doc
« Reply #4 on: February 23, 2020, 08:49:15 AM »
Here are some questions I followed up with:


me: "What's your single sign-n model?"
them: "You don't need to worry about that yet."
me: "Well, how do I authenticate a user for a working model?"
them: "Just write a user logon system"
me: "Even though it may be completely incompatible with your existing system...?"
them: "Can't you?"
me: O_o



me: "You're a security company. JWTs aren't encrypted, and you never want to return to the user auth system. That means you, as a security company, have to be ok with certain pieces of IID being in the JWT, even if it's not clear who that person is. Are you ok with that?"
them: "I don't think you know how JWTs work.
them: ** turns to junior associate and says ** "Please explain to Chris how JWTs work"
me: "Look, what I'm saying is, even if I can't look at the data in a JWT and say that it points to bob jones who lives in philly, i'll still know that there's user with id 1234 with certain permissions. If someone gets hold of this token, they'll have *some* amount of information more than they had before they got hold of the token. I'll I'm asking is, are you OK using unencrypted data in a token. That's it. If you say yes, let's move on."
them: "yeah, you really don't understand JWTs, do you? I don't think we need you on this."
me: ** chuckling ** "Thanks anyway. I appreciate your time."

this signature on hold pending review

Offline minimac

  • Member
  • Location: C.N.Y., Central Fl.
  • Posts: 315
  • Practicing Neanderthal, Nuclear Nomad
  • Motorcycles: GL1500A, Silverwing, ̶M̶a̶j̶e̶s̶t̶y̶, Morphous
Re: Hey, tech folks... project req doc
« Reply #5 on: February 23, 2020, 10:08:08 AM »
Can't fix stoopid.
old enough to know better

Offline sleazy rider

  • Contributor
  • Member
  • Location: White Lake, Michigan
  • Posts: 3149
  • Trapped!
    • Da Blog!
  • Motorcycles: 1990 Suzuki DR350S
Re: Hey, tech folks... project req doc
« Reply #6 on: February 23, 2020, 11:22:41 AM »
Ru hard, run fast, don't look over your shoulder.
--Tom

Offline Bounce

  • Contributor
  • Member
  • Location: USA
  • Posts: 3827
    • FJR-Tips
  • Motorcycles: Yes
Re: Hey, tech folks... project req doc
« Reply #7 on: February 23, 2020, 12:53:05 PM »
me: "Look, what I'm saying is, even if I can't look at the data in a JWT and say that it points to bob jones who lives in philly, i'll still know that there's user with id 1234 with certain permissions. If someone gets hold of this token, they'll have *some* amount of information more than they had before they got hold of the token. I'll I'm asking is, are you OK using unencrypted data in a token. That's it. If you say yes, let's move on."
them: "yeah, you really don't understand JWTs, do you? I don't think we need you on this."
me: ** chuckling ** "Thanks anyway. I appreciate your time."

I got through to the Approaches breakouts. Sorry.

I had ONE instance of that in my entire career. It ended with MY boss' boss siding with the regional employee that hadn't bothered to research the 1 concern I had. The boss' boss actually used the word "incompetent" in her office later (just me and my boss). I came back with the research supporting my concern, and the regional employee brushed it off (what would have been fine for all their new machines would have left nearly ALL of the machines at my facility at risk). Her response? "Well, I always thought that should be done manually anyway." My boss later told me that was as close to an apology as she'd ever given.

Online Vulcanbill

  • Contributor
  • Member
  • Location: it's a secret, WV
  • Posts: 3651
  • no thank you ... still
  • Motorcycles: XT250, Ninja 500R
Re: Hey, tech folks... project req doc
« Reply #8 on: February 23, 2020, 04:52:32 PM »
Can't fix stoopid.

Don't be like that.  Chris isn't THAT old and he has plenty of time to fix this deficiency. Maybe someday he WILL learn about how JWTs work and he can ace the next interview. Chin up, little buckaroo. You can do anything you set your mind to.




😁
If a person's primary concern is increasing freedom, they should prepare for a reduction in average lifespan.  ---  Misanthropist

If you say "Gullible" real slow, it sounds like "Orange"

Online coho

  • Contributor
  • Member
  • Location: Pacific NorthWet
  • Posts: 4940
  • Probably not wearing pants.
  • Motorcycles: R1100RT (Gentleman's Express) - StFU200 (The Dumbbike) - Guzzi V7II (Tiny Musclecar)
Re: Hey, tech folks... project req doc
« Reply #9 on: February 23, 2020, 05:17:42 PM »
Can't fix stoopid.

Don't be like that.  Chris isn't THAT old and he has plenty of time to fix this deficiency. Maybe someday he WILL learn about how JWTs work and he can ace the next interview. Chin up, little buckaroo. You can do anything you set your mind to.




😁

Out.
If it weren't for the therapeutic properties of the occasional off-camber decreasing radius downhill right-hander I'd almost certainly go completely sane.

"I like the beverages."  -CLAY

Offline Cookie

  • Super Moderator
  • Member
  • Location: Most of the time I'm not 100% sure.
  • Posts: 14318
  • Tacos are life.
  • Motorcycles: '16 MG Audace, '10 Ural T, '19 Ural Gear Up and from out of nowhere, the surprise '06 KLR 650!
Re: Hey, tech folks... project req doc
« Reply #10 on: February 23, 2020, 05:27:30 PM »
Can't fix stoopid.

Don't be like that.  Chris isn't THAT old and he has plenty of time to fix this deficiency. Maybe someday he WILL learn about how JWTs work and he can ace the next interview. Chin up, little buckaroo. You can do anything you set your mind to.




😁


Aaaand



POP!
“Government is the Entertainment division of the military-industrial complex.”

― Frank Zappa

Online Skee

  • Contributor
  • Member
  • Location: SE PA
  • Posts: 2271
  • Motorcycles: 2019 Versys
Re: Hey, tech folks... project req doc
« Reply #11 on: February 23, 2020, 08:25:02 PM »
"The mistake you cannot make is to judge the past through the eyes of the present.  Judge the past on its own terms."  
João Zilhão on the Assimilation Model of Human Origin

"The fishermen know that the sea is dangerous and the storm terrible, but they have never found these dangers sufficient reason for remaining ashore."   Vincent van Gogh

Offline chornbe

  • Contributor
  • Member
  • Location: Wilmington, Delaware
  • Posts: 6976
    • The Pace Motorcycle Podcast
  • Motorcycles: Honda DN-01
Re: Hey, tech folks... project req doc
« Reply #12 on: February 23, 2020, 08:38:20 PM »
Can't fix stoopid.

Don't be like that.  Chris isn't THAT old and he has plenty of time to fix this deficiency. Maybe someday he WILL learn about how JWTs work and he can ace the next interview. Chin up, little buckaroo. You can do anything you set your mind to.




😁

BWAAAHAHAHAHAHAHAHAHAHAAHAHA

Thank you. I needed that laugh.
this signature on hold pending review

Offline minimac

  • Member
  • Location: C.N.Y., Central Fl.
  • Posts: 315
  • Practicing Neanderthal, Nuclear Nomad
  • Motorcycles: GL1500A, Silverwing, ̶M̶a̶j̶e̶s̶t̶y̶, Morphous
Re: Hey, tech folks... project req doc
« Reply #13 on: February 27, 2020, 09:19:18 AM »
Can't fix stoopid.

Just to clarify- it wasn't Chris I was referring too.  He knows why I don't want to piss him off! ;)
old enough to know better