Need Ability to Represent a Work Ticket Concept (i.e.; a help desk ticket)

Question

Need Ability to Represent a Work Ticket Concept (i.e.; a help desk ticket)

Opened this issue a year ago · 13 comments

Answer 1 · 2023-09-28T14:22:12.000Z

@vulnmaster , thank you for posting this. I'm happy to raise this at the October 26th Ontology Committees meeting. It would be helpful if you would be able to present this at that meeting. Please let me know if you haven't received the invitation. I have some follow-on remarks after this, but the end of this fiscal month has become a bit complicated on my end, so I apologize in advance if I trail off for a little while.

Answer 2 · 2023-09-28T14:29:23.000Z

I have some questions on what falls into the set of a Work Ticket, asking in part because I'm not familiar with your main exemplar Zendesk. First, let's start with an assumption that the class you're requesting will be called observable:ActionTicket, though I can see reasons we might change that. I'll describe a few other workflow-management systems to frame my questions¹.

Jira has a "help desk" system that seems to use something similar to what you'd suggested, sharing a lot of functionality with a higher-level "Ticket" that Jira provides a few specializations of - Story, Issue, Bug, and user-customizable issues. Epics appear to be slightly different in technical implementation from how they tie to Jira's "Timeline" (formerly "Roadmap") feature, but in spirit, they appear to also be "Tickets". Does a Jira Ticket (Story, Issue, etc.) structurally behave similar to the ActionTicket you're requesting?
Does a GitHub Issue (/GitLab Issue) behave similar to the ActionTicket you're requesting?
Does a GitHub Pull Request (/GitLab Merge Request) behave similar to the ActionTicket you're requesting?

I ask about those two in particular because they tend to be identified by URLs that could serve as RDF IRIs. And this could help us sketch the scenarios you had provided in English. (And thank you for the examples!) The smartphone processing you suggested could be a supplement to the CASE website's Urgent Evidence narrative.

I would like to see a semi-implemented example in the "Competencies Demonstrated" section, sketched in Turtle, JSON-LD to show "This includes something I want to find"; or SPARQL, for "Here's how I would look for something I'm interested
in". Again, have a look at the Urgent Evidence example's implemented SPARQL queries for what I'm looking for. (The tables below each chalkboard-code block are live answers from the data on that page.)

Disclaimer: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. ↩

Answer 3 · 2023-09-28T16:24:35.000Z

I have a hunch that the requirements might need to be spelled differently. There's a few levels of recursive dependencies suggested in there that I'm not entirely sure we've exercised yet in examples, but there's no reason we can't start now if we haven't. E.g. Requirement 1 suggests ability to tie a ticket to a workflow, which we have two classes that can potentially implement this, action:ActionLifecycle and action:ActionPattern. UCO and CASE have not to date exercised anything under pattern:Pattern in an example (per this list of concepts used across CASE-Examples, CASE-Corpora, and the CASE website), but I think action:ActionPattern would be what we would use to represent a set of actions not actually performed, but expected to be performed - i.e. specifying a workflow.

Let's assume a workflow similar to what you suggested in Requirement 1:

ticket created
ticket reviewed
ticket dispositioned
ticket closed

To me, these are more suggest there are two things to consider: The status of the ticket, and transitions between statuses. Consider especially the last two workflow points, "ticket dispositioned" and "ticket closed". If those are to be "nodes" in a graph, they would look something like this:

flowchart LR

Dispositioned -- some work happens --> Closed

I think this means we need to take some care in when we're describing actions (specifically uco-core:Actions), and when we're describing "Resting states", which we could model as either a core:Event or a core:UcoObject. (This reminds me to post a remark on "lifespans" over on the endurants-and-perdurants Issue.)

Here is what I think would be a high-level pattern for a ticket workflow of "created," "reviewed", "dispositioned", "closed (finished)", "closed (won't-do)". I think each of those workflow descriptors are actually of Actions, so I'll use them to annotate the edges between state transitions:

flowchart TB

formulating
awaiting_review
awaiting_implementation
completed
left_not_completed

formulating -- Submitted --> awaiting_review
awaiting_review -- Disposition, assign\nfor implementation --> awaiting_implementation
awaiting_implementation -- Request review\nof implementation --> awaiting_review
awaiting_review -- Close, marking\naccomplished --> completed
awaiting_review -- Close, marking\nwon't-do --> left_not_completed
completed -- Reopen --> awaiting_review
left_not_completed -- Reopen --> awaiting_review

With this sketch for reference, or dispute if there's disagreement: What would tie to actions, and what would tie to events? To both branches of that question: As class models, and as external data references?

The blocking modeling question I think we're going to have to answer is: How does UCO relate an instance of an ActionPattern to a realized Action? UCO hasn't exercised nearly anything under pattern:Pattern's class hierarchy in a public example yet, and I see several ways this could go here, e.g. UCO Relationship objects, or OWL meta-classes.

Answer 4 · 2023-09-30T00:15:38.000Z

@ajnelson-nist here is my first crack at designing the observable:ActionTicket class and properties. I've added a few other common properties that one might find across ticket management systems. There might be others.

{
"@context": {
"uco": "https://unifiedcyberontology.org/ontology/uco/",
"observable": "https://unifiedcyberontology.org/ontology/uco/observable#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"xsd": "http://www.w3.org/2001/XMLSchema#"
},
"@id": "observable:ActionTicket",
"@type": "rdfs:Class",
"rdfs:subClassOf": "observable:Observable",
"rdfs:label": "Action Ticket",
"rdfs:comment": "A record in a ticketing system representing a work request or issue.",
"rdfs:isDefinedBy": "https://unifiedcyberontology.org/ontology/uco/observable",
"observable:property": [
{
"@id": "observable:title",
"@type": "rdfs:Property",
"rdfs:label": "Title",
"rdfs:comment": "A brief description of the issue or request.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:description",
"@type": "rdfs:Property",
"rdfs:label": "Description",
"rdfs:comment": "A detailed explanation of the issue or request.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:type",
"@type": "rdfs:Property",
"rdfs:label": "Type",
"rdfs:comment": "The nature of the ticket, e.g., Bug, Feature Request, Task.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:priority",
"@type": "rdfs:Property",
"rdfs:label": "Priority",
"rdfs:comment": "The level of urgency or importance, categorized as low, normal, high, or urgent.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:status",
"@type": "rdfs:Property",
"rdfs:label": "Status",
"rdfs:comment": "The current state of the ticket, e.g., Open, In Progress, Resolved.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:assignee",
"@type": "rdfs:Property",
"rdfs:label": "Assignee",
"rdfs:comment": "A URL to the name record of the assigned person responsible for actioning the ticket.",
"rdfs:range": "xsd:anyURI"
},
{
"@id": "observable:reporter",
"@type": "rdfs:Property",
"rdfs:label": "Reporter",
"rdfs:comment": "The individual or entity that reported the issue or made the request.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:requestor",
"@type": "rdfs:Property",
"rdfs:label": "Requestor",
"rdfs:comment": "A URL to the name record of the submitter of the ticket.",
"rdfs:range": "xsd:anyURI"
},
{
"@id": "observable:ticketID",
"@type": "rdfs:Property",
"rdfs:label": "Ticket ID",
"rdfs:comment": "A unique identifier for the ticket, represented as an integer.",
"rdfs:range": "xsd:integer"
},
{
"@id": "observable:created",
"@type": "rdfs:Property",
"rdfs:label": "Created",
"rdfs:comment": "The date and time when the ticket was created.",
"rdfs:range": "xsd:dateTime"
},
{
"@id": "observable:updated",
"@type": "rdfs:Property",
"rdfs:label": "Updated",
"rdfs:comment": "The date and time when the ticket was last updated.",
"rdfs:range": "xsd:dateTime"
},
{
"@id": "observable:createdVia",
"@type": "rdfs:Property",
"rdfs:label": "Created via",
"rdfs:comment": "The medium through which the ticket was created, e.g., web, email.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:organization",
"@type": "rdfs:Property",
"rdfs:label": "Organization",
"rdfs:comment": "The name of the organization of the requestor.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:interestedIn",
"@type": "rdfs:Property",
"rdfs:label": "I am interested in",
"rdfs:comment": "Classification assigned by the assignee from a list unique to the organization.",
"rdfs:range": "xsd:string"
},
{
"@id": "observable:tags",
"@type": "rdfs:Property",
"rdfs:label": "Tags",
"rdfs:comment": "One or more tags assigned by the assignee to further classify the ticket.",
"rdfs:range": "xsd:string"
}
]
}

Answer 5 · 2023-09-30T00:40:16.000Z

@ajnelson-nist here is my first crack at a SPARQL query similar to the CASE Investigative personae example but where the query incorporates a search for an ActionTicket where it is in a status of "assigned", and where the other provenance, action, and performer queries are true. Then to order the results by last name and ticketID

PREFIX case-investigation: https://ontology.caseontology.org/case/investigation/
PREFIX uco-action: https://ontology.unifiedcyberontology.org/uco/action/
PREFIX uco-core: https://ontology.unifiedcyberontology.org/uco/core/
PREFIX uco-identity: https://ontology.unifiedcyberontology.org/uco/identity/
PREFIX uco: https://unifiedcyberontology.org/ontology/uco/
PREFIX observable: https://unifiedcyberontology.org/ontology/uco/observable#
PREFIX xsd: http://www.w3.org/2001/XMLSchema#

SELECT DISTINCT ?lLastName ?ticket ?title ?description ?ticketID
WHERE {
GRAPH http://example.com/graphs/cyber-investigation {
?ticket a observable:ActionTicket ;
observable:title ?title ;
observable:description ?description ;
observable:assignee ?assignee ;
observable:status ?status ;
observable:ticketID ?ticketID ;
observable:exhibitNumber ?exhibitNumber .
FILTER (?status = "assigned"^^xsd:string)
}

?nOriginalProvenanceRecord
a case-investigation:ProvenanceRecord ;
case-investigation:exhibitNumber ?exhibitNumber ;
uco-core:object ?nExhibitDevice ;
.

?nInvestigativeAction
a case-investigation:InvestigativeAction ;
uco-action:performer ?nPerformer ;
uco-action:result ?nActionProvenanceRecord ;
.

?nActionProvenanceRecord
a case-investigation:ProvenanceRecord ;
uco-core:object ?nExhibitDevice ;
.

?nPerformer
a uco-identity:Person ;
uco-core:hasFacet ?nSimpleName ;
.

?nSimpleName
a uco-identity:SimpleNameFacet ;
uco-identity:familyName ?lLastName ;
.

FILTER (?nPerformer = ?assignee)
}
ORDER BY ?lLastName ?ticketID

Answer 6 · 2023-10-25T21:21:30.000Z

I think there is a design issue with this proposal that digs into UCO's behaviors with respect to time. My concern boils down to the "Observables being independent of observations" matter described in the background of Issue 535.

I think because an ActionTicket has a lot of parts that can change for a variety of reasons---e.g. assignee due to availability, priority due to finding unexpected critical path influence, update-date because plans change---there are some properties from @vulnmaster 's list that would work fine as properties ...

createdVia
reporter
requestor
ticketID (depending on the ticketing system's ability to migrate tickets or not)

... but there are others that change depending on when the ticket is looked at, and those would be better represented as Qualitys from UCO Issue 535. "Who is assigned to this ticket" is almost, but not quite, the right question to ask, because it leaves time implicit as "Who is assigned to this ticket (right now)." UCO should be able to support these questions for the suggested assignee property, which I suggest instead is a Quality:

"Is anyone currently assigned to this ticket?" (This could be Yes or No given the day.)
"Who was ever assigned to this ticket?"
"Who was ever assigned to this ticket, and in what order were they assigned?"
"Based on our observations, who has been assigned to this ticket, and at what times did we see them have that assignment?"
"Who was ever assigned to this ticket, and when were they assigned?" (This may require the system's API or backend database to answer.)

Before resolution of Issue 535, questions 1 and 2 can be answered with UCO's current design basis, but questions 3--5 can't without wrestling with some base RDF issues like separation of graphs and/or named graphs.

(It's possible reporter should be treated the same way. Some ticketing systems have this as a fixed property, and some have this as a mutable property. E.g. I don't think the reporter (poster) of a GitHub Issue can change (except possibly if an account is deleted - then they seem to become Ghost), but I think with sufficient administrative permissions, a Jira ticket can have its reporter changed.)

So, I think these proposed properties can remain as properties, because changing them means you're describing a different object:

observable:created (Note - possibly redundant with observable:observableCreatedTime; do we wish to treat this as a specialized property observable:workTicketCreated, similar to observable:profileCreated?)
observable:createdVia
observable:organization
observable:reporter
observable:ticketID

But these would be more appropriate as qualities because of their mutability:

observable:assignee
observable:description
observable:interestedIn
observable:priority
observable:requestor
observable:status
observable:tags
observable:title
observable:type
observable:updated (Note: Redundant with observable:modifiedTime?)

If the latter list is retained in this proposal without waiting for Issue 535, UCO should be prepared to adapt them to becoming qualities.

I would like to answer this before we vote:

How firmly does WorkTicket need to adhere to the independence-of-observation principle?

Meanwhile, I have a few implementation-sketch concerns that are closer to nits:

I suggest several of the names be revised to specialize the properties to work tickets.
Some properties (/qualities) that would work better as owl:ObjectPropertys rather than owl:DatatypePropertys (they self-identify by having a range of xsd:anyURI). We should have classes suggested for their ranges, e.g. assignee should probably have range observable:ApplicationAccount.

Answer 7 · 2023-10-25T21:44:56.000Z

PR #555 stores the current state of this in-discussion proposal's implementation, with overall patch-state reviewable here.

Answer 8 · 2023-10-26T04:39:50.000Z

I have a hunch that the requirements might need to be spelled differently. There's a few levels of recursive dependencies suggested in there that I'm not entirely sure we've exercised yet in examples, but there's no reason we can't start now if we haven't. E.g. Requirement 1 suggests ability to tie a ticket to a workflow, which we have two classes that can potentially implement this, action:ActionLifecycle and action:ActionPattern. UCO and CASE have not to date exercised anything under pattern:Pattern in an example (per this list of concepts used across CASE-Examples, CASE-Corpora, and the CASE website), but I think action:ActionPattern would be what we would use to represent a set of actions not actually performed, but expected to be performed - i.e. specifying a workflow.

I don't think action:ActionPattern is really relevant here.
An action:Action can be any action that has not occurred yet, may be occurring at present, or has occurred in the past.

A sequence of actions that could occur is an action:ActionLifecycle.
action:ActionLifecycle is currently a subClass of action:Action which is appropriate but it should also be a subClass of action:ActionPattern.
Its definition is "An action lifecycle is an action pattern consisting of an ordered set of multiple actions or subordinate action lifecycles.".

A workflow of actions such as would exist in any ticketing system would be conveyed as an ActionLifecycle.
That being said I don't think we should worry about defining any specific such workflow as THE lifecycle for the ActionTicket concept given that almost every ticketing system defines its own lifecycle and there is not standard one. Keeping flexibility at this point is important and any formalization of a workflow using UCO can just use the structures available such as Action, ActionLifecycle, etc to define a separate ActionLifecycle instance for each tool.

Answer 9 · 2023-10-26T04:52:59.000Z

Let's assume a workflow similar to what you suggested in Requirement 1:

ticket created

ticket reviewed

ticket dispositioned

ticket closed

To me, these are more suggest there are two things to consider: The status of the ticket, and transitions between statuses. Consider especially the last two workflow points, "ticket dispositioned" and "ticket closed". If those are to be "nodes" in a graph, they would look something like this:
flowchart LR

Dispositioned -- some work happens --> Closed
Loading
I think this means we need to take some care in when we're describing actions (specifically uco-core:Actions), and when we're describing "Resting states", which we could model as either a core:Event or a core:UcoObject. (This reminds me to post a remark on "lifespans" over on the endurants-and-perdurants Issue.)

Here is what I think would be a high-level pattern for a ticket workflow of "created," "reviewed", "dispositioned", "closed (finished)", "closed (won't-do)". I think each of those workflow descriptors are actually of Actions, so I'll use them to annotate the edges between state transitions:
flowchart TB

formulating
awaiting_review
awaiting_implementation
completed
left_not_completed

formulating -- Submitted --> awaiting_review
awaiting_review -- Disposition, assign\nfor implementation --> awaiting_implementation
awaiting_implementation -- Request review\nof implementation --> awaiting_review
awaiting_review -- Close, marking\naccomplished --> completed
awaiting_review -- Close, marking\nwon't-do --> left_not_completed
completed -- Reopen --> awaiting_review
left_not_completed -- Reopen --> awaiting_review
Loading
With this sketch for reference, or dispute if there's disagreement: What would tie to actions, and what would tie to events? To both branches of that question: As class models, and as external data references?

The blocking modeling question I think we're going to have to answer is: How does UCO relate an instance of an ActionPattern to a realized Action? UCO hasn't exercised nearly anything under pattern:Pattern's class hierarchy in a public example yet, and I see several ways this could go here, e.g. UCO Relationship objects, or OWL meta-classes.

I don't think we need to go anywhere near this level of attempted design at this point. ActionTicket can simply have an ActionTicketStatus property of type string that can be used to track its status.
If there is a desire of a given adopter or user to characterize actions taken on the ticket they can simply use Action instances to do so. The pre-action ActionTicket can be one of the objects acted on and the updated ActionTicket can be in the results.
I do recognize that there is some nice value in having the the statuses be represented with objects related to the ActionTicket using Relationships. This lets you use the same ActionTicket (without creating new versions for each modification) as its status progresses just by adding new 'hasStatus' Relationships from the ActionTicket to the status object along with the relevant timeframe. I am not sure what objects we would use for status though and I am not sure we are ready to fully tackle that in a first cut. Maybe string-based status property is enough for now.
Events could also be used to characterize state transitions occuring in a action lifecycle if so desired.

NOTE: For any standardized action names I would strongly propose we use present tense rather than past tense (e.g., Submit rather than Submitted) given that Action exists across the temporal spectrum.

Answer 10 · 2023-10-26T05:16:42.000Z

The stab at a draft json-ld ontology above (quote reply trashes all formatting) looks like a pretty good start with a few issues to note.

"observable:ActionTicket" should be a subClass of "observable:ObservableObject" rather than "observable:Observable"
The property definitions should not be embedded inside the observable:ActionTicket" definition (there is not such thing as "observable:property").
Each property definition needs to explicitly assert whether it is a DatatypeProperty or an ObjectProperty
Almost all of the properties (e.g., title, description, type, status, assignee, reporter, requestor, ticketID, created, updated, createdVia, interestedIn, tags, etc.) should be named with actionTicket as a prefix (e.g., actionTicketTitle) becuase they are too general without it and WILL conflict with other ObservableObject properties.
The organization property should be actionTicketRequestorOrganization to deconflict with general use of 'organization' as well as being specific that it is requestor organization rather than reporter, assignee, etc.
requestor, reporter and assignee should all likely be ObjectProperties and have range of identity:Identity rather than xsd:anyURI or xsd:string
ticketID should have range of xsd:string rather than xsd:integer. Not all ticketing systems use integer ids. many use strings. xsd:string can handle expressing both strings and numbers as strings.

Answer 11 · 2023-10-26T05:21:41.000Z

I think there is a design issue with this proposal that digs into UCO's behaviors with respect to time. My concern boils down to the "Observables being independent of observations" matter described in the background of Issue 535.

I think because an ActionTicket has a lot of parts that can change for a variety of reasons---e.g. assignee due to availability, priority due to finding unexpected critical path influence, update-date because plans change---there are some properties from @vulnmaster 's list that would work fine as properties ...

createdVia

reporter

requestor

ticketID (depending on the ticketing system's ability to migrate tickets or not)

... but there are others that change depending on when the ticket is looked at, and those would be better represented as Qualitys from UCO Issue 535. "Who is assigned to this ticket" is almost, but not quite, the right question to ask, because it leaves time implicit as "Who is assigned to this ticket (right now)." UCO should be able to support these questions for the suggested assignee property, which I suggest instead is a Quality:

"Is anyone currently assigned to this ticket?" (This could be Yes or No given the day.)

"Who was ever assigned to this ticket?"

"Who was ever assigned to this ticket, and in what order were they assigned?"

"Based on our observations, who has been assigned to this ticket, and at what times did we see them have that assignment?"

"Who was ever assigned to this ticket, and when were they assigned?" (This may require the system's API or backend database to answer.)

Before resolution of Issue 535, questions 1 and 2 can be answered with UCO's current design basis, but questions 3--5 can't without wrestling with some base RDF issues like separation of graphs and/or named graphs.

(It's possible reporter should be treated the same way. Some ticketing systems have this as a fixed property, and some have this as a mutable property. E.g. I don't think the reporter (poster) of a GitHub Issue can change (except possibly if an account is deleted - then they seem to become Ghost), but I think with sufficient administrative permissions, a Jira ticket can have its reporter changed.)

So, I think these proposed properties can remain as properties, because changing them means you're describing a different object:

observable:created (Note - possibly redundant with observable:observableCreatedTime; do we wish to treat this as a specialized property observable:workTicketCreated, similar to observable:profileCreated?)

observable:createdVia

observable:organization

observable:reporter

observable:ticketID

But these would be more appropriate as qualities because of their mutability:

observable:assignee

observable:description

observable:interestedIn

observable:priority

observable:requestor

observable:status

observable:tags

observable:title

observable:type

observable:updated (Note: Redundant with observable:modifiedTime?)

If the latter list is retained in this proposal without waiting for Issue 535, UCO should be prepared to adapt them to becoming qualities.

I would like to answer this before we vote:

How firmly does WorkTicket need to adhere to the independence-of-observation principle?

Meanwhile, I have a few implementation-sketch concerns that are closer to nits:

I suggest several of the names be revised to specialize the properties to work tickets.

Some properties (/qualities) that would work better as owl:ObjectPropertys rather than owl:DatatypePropertys (they self-identify by having a range of xsd:anyURI). We should have classes suggested for their ranges, e.g. assignee should probably have range observable:ApplicationAccount.

I think you have a valid point here about some of the properties being prone to change over time and having them be direct properties on the object would force either creation of new objects associating provenance back to the old ones with relationships or updating the object directly with some change tracking provenance capability that we have not yet implemented.
I agree that it makes more sense to have some of the properties be separable as other objects associated using Relationships rather than as direct ObjectProperties.
The DatatypeProperties prone to change are a little trickier. The Qualities proposal may offer a potential solution but we have not yet had a chance to fully discuss it so I am not yet sure if it is the right solution.

I would like to answer this before we vote:

How firmly does WorkTicket need to adhere to the independence-of-observation principle?

I would argue that it must adhere to this principle like all other ObservableObjects.

Answer 12 · 2023-10-26T13:49:48.000Z

Re: @sbarnum

I do recognize that there is some nice value in having the the statuses be represented with objects related to the ActionTicket using Relationships. This lets you use the same ActionTicket (without creating new versions for each modification) as its status progresses just by adding new 'hasStatus' Relationships from the ActionTicket to the status object along with the relevant timeframe.

I think this would be appropriate given UCO's current implementation.

I am not sure what objects we would use for status though and I am not sure we are ready to fully tackle that in a first cut. Maybe string-based status property is enough for now.

What about a Status class, subclass of UcoInherentCharacterizationThing? A Relationship object can't tie a string-literal as the status.

Answer 13 · 2023-10-26T13:56:29.000Z

Re: @sbarnum

An action:Action can be any action that has not occurred yet, may be occurring at present, or has occurred in the past.

A sequence of actions that could occur is an action:ActionLifecycle.

An aside:
There's a bit more to dig into here with respect to the CASE Forensic Lifecycle example. CASE has never, to my recollection, demonstrated an Action (with no subclassing other than InvestigativeAction) that has not occurred yet. ActionLifecycle has been demonstrated once, in the Forensic Lifecycle example, and by subclassing is the one demonstration of an Action that has not occurred yet. But, its demonstration looks a bit like a class specification. And I see some dangling TODOs in that demonstration c/o migrating from the Ordered List Ontology to the Collections Ontology.

Since the workflows-as-action-lifecycle discussion might be blocked, we might be better off not blocking this proposal on settling that.

Need Ability to Represent a Work Ticket Concept (i.e.; a help desk ticket)

Background

Requirements

Requirement 1

Requirement 2

Requirement 3

Risk / Benefit analysis

Competencies demonstrated

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

Coordination

Background

Requirements

Requirement 1

Requirement 2

Requirement 3

Risk / Benefit analysis

Competencies demonstrated

Competency 1

Competency Question 1.1

Result 1.1

Competency Question 1.2

Result 1.2

Solution suggestion

Coordination

Footnotes