Functional Requirements

[nmcb]

The overall example use-case (or saga, should you prefer that term) is a functional web-service within a company that service being the source of organisational truth of all past, present and future customer contacts that occurred between a representative of that company and a customer of that company. We model these customer contacts being able to provide the following functional information:

• id : the universally unique identifier of the contact. (UUID)
• customer : the universally unique identifier of the customer. (UUID)
• agent : the universally unique identifier of the company's agent. (UUID)
• start : the future or present moment in time the contact will (or has) happen(ed). (ISO-8601)
• state : the state the contact is currently in, i.e. Open, Active or Closed
• duration : the duration of the contact; i.e. the planned duration until the state transfers to Closed at which time duration will transfer to the actual contact duration. (seconds)
• parent : the (optional) universally unique identifier of the contact from which the contact originated. (UUID)

This provides for a context of usability from which many technical requirements can be derived and which will probably yield a couple interdependent micro services. That is, we will probably need a contact, an agent, and a customer service or related endpoints.

[nmcb]

This issue now addresses the functional requirement only after the technical and non-functional requirements were split of as separate tasks. Note that the original text is kept in the description history (item 3 from the bottom).