Process Module: Manage User Relationships
Process Title: Request Service
Definition: Process where user initiates a request for service and the request is filled.
Workflow / Process Diagrams:
Use Cases: Authentication may be optional, depending on factors such as service being requested or local policy. System may contact the user automatically when: 1. their need does not require immediate, or any, human intervention (a predefined response fills the need); 2. a human is not available to provide a direct response but some type of response is required.
Reference(s):
1. (NLA Services Framework 1.1: Authenticate) Verify whether an identity claim made by an individual or entity (the principal) is true. The principal may be a person using a computer, a computer itself or a computer program.
2. (NLA Services Framework 1.7: Alert) Notify a user or system as to the occurrence of an event. The trigger may be time-based or generated as the outcome of an audit.
3. (NLA Services Framework 1.9: Contact) Push a message into a message transport system / get a message from a message transport system. Strategies: Messaging services are essential to most aspects of the Library’s business and may be a way in which business services such as online and real-time reference services are implemented.
4. (e-Framework: Authenticate) Describes authentication, the process of uniquely identifying an individual or entity (the principal) based on objects provided for verification (credentials). Credentials should be difficult to falsify or forge, either by keeping them secret or by making them difficult to replicate. Authentication seeks to ensure that the principal is who they claim to be. The degree of certainty varies according to implementation and business context. Authentication typically verifies the principal’s association with an electronic identifier. Authentication may also determine that the principal has certain attributes or is a member of specified or predetermined groups.
5. (e-Framework: Alert) Details the notion of notifying a user or system as to the occurrence of an event. The event itself could be extra-ordinary (such as a fire alarm), or it could be something more mundane (such as informing students of a cancelled lecture). The important notion in alerting is that the alert data itself is actively propagated to receivers rather than passively propagated. Alerts MUST be pushed.
6. (e-Framework: Receive) Fetch a message from a message transport system
7. (e-Framework: Send) Push a message into a message transport system.
Discussion
No comments for “Manage User Relationship / Request Service”
Post a comment