Services: Difference between revisions

From Project VRM
Jump to navigation Jump to search
(First, incomplete draft.)
 
(→‎The Use Model: - added several items to Use Model and stated new section Standards & Compliance)
Line 20: Line 20:
; High Level Use Cases: A list of all supported use cases in the system, identifying all focal and required use cases by title, ordered by priority.
; High Level Use Cases: A list of all supported use cases in the system, identifying all focal and required use cases by title, ordered by priority.
; Scenarios: Prose descriptions of a user's interaction with the system as one example of the Use Case that explains the context, the interaction, and the benefit. Each Use Case requires at least one Scenario.
; Scenarios: Prose descriptions of a user's interaction with the system as one example of the Use Case that explains the context, the interaction, and the benefit. Each Use Case requires at least one Scenario.
; Abstract Use Case Narratives: An implementation and technology-free chronological ordering of user intention and system responsibilities for a particular use case. Based on one or more specific Scenarios,  
; Abstract Use Case Narratives: An implementation and technology-free chronological ordering of user intention and system responsibilities for a particular use case. Based on one or more specific Scenarios, define the specific, yet technology-free, interactions that are required for the use case. These narratives will be normative, that is, they will ultimately define the requirements of the functioning system.
 
; Specific Use Case Narratives: Implementation-specific sequences of user action and system response for a use case. These narratives will be illustrative, that is, they will show how a particular set of technologies can implement a particular use care--or how a specific set of technologies might require or suggest changes to the use case.
Third, we propose that any implementation that fully implements the Use Model for a VRM Service, including all constraints and interoperability requirements, meets the VRM Standard for that Service.
; Use Case Diagrams: Both abstract and specific use cases may be diagramed visually to represent the transaction flow between various system components. For abstract use cases, the diagrams will be normative. For specific use cases, they will be illustrative.
; Use Case Maps: A visual representation of the multiple use cases that comprise a particular service and their relationship to one another.
; Constraints & Requirements: In addition to responding to specific use cases appropriately, every Service shall define its own set of constraints and requirements to complete the specification of the service. Many requirements will be applicable to most, if not all, VRM services, such as those inspired by tenets of data portability and user-centric identity. When mapping out the first Change of Address use case, it became clear that the core Use Cases were already substantially met by such online services as Plaxo and LinkedIn, raising the question of what would actually make a Change of Address service VRM-compliant. That led directly to a handful of simple requirements that assure the user and vendors have appropriate access and controls.
===Standards and Compliance===
Third, we propose that any implementation that fully implements all of the normative requirements of the Use Model for a VRM Service, including all constraints and interoperability requirements, meets the VRM Standard for that Service.

Revision as of 03:59, 3 February 2008

Working Draft

A few words about Use Cases and how they relate to our work on VRM.

Definitions

First, A Use Case is a distinct, complete transaction between a user and the system.

Transaction
a user initiated interaction with the system to produce a specific benefit.
User
any entity, human or automated, that initiates and drives a transaction in order to create value for itself or its beneficiary. Users include end-users, administrators, vendors, vendor's CRM systems, and customers. Users are sometimes referred to as an actor in Use Case literature. Every VRM Service will be developed with specific focal users in mind while incorporating the needs of all supported users.
System
A complete service that provides a bundled set of functionality for users. VRM Services implement a few focal use cases and multiple supporting use cases in order to provide value to users. Think of services as a convenient way to organize VRM functionality into implementable systems.

The Use Model

Second, in developing a complete VRM Standard, we will create several Use Case-related documents, which will define exactly what value the system will product for which users. These documents together comprise the Use Model for the Standard.

Users Specification
A list of all Users supported by the system, specifying one or two focal users.
User Map
A visual representation of the supported users and their relationship to one another.
User Profiles
A detailed description of each user's expectations, capability, and requirements for the system. Developed to enough detail to distinguish what this particular user needs from the system design.
High Level Use Cases
A list of all supported use cases in the system, identifying all focal and required use cases by title, ordered by priority.
Scenarios
Prose descriptions of a user's interaction with the system as one example of the Use Case that explains the context, the interaction, and the benefit. Each Use Case requires at least one Scenario.
Abstract Use Case Narratives
An implementation and technology-free chronological ordering of user intention and system responsibilities for a particular use case. Based on one or more specific Scenarios, define the specific, yet technology-free, interactions that are required for the use case. These narratives will be normative, that is, they will ultimately define the requirements of the functioning system.
Specific Use Case Narratives
Implementation-specific sequences of user action and system response for a use case. These narratives will be illustrative, that is, they will show how a particular set of technologies can implement a particular use care--or how a specific set of technologies might require or suggest changes to the use case.
Use Case Diagrams
Both abstract and specific use cases may be diagramed visually to represent the transaction flow between various system components. For abstract use cases, the diagrams will be normative. For specific use cases, they will be illustrative.
Use Case Maps
A visual representation of the multiple use cases that comprise a particular service and their relationship to one another.
Constraints & Requirements
In addition to responding to specific use cases appropriately, every Service shall define its own set of constraints and requirements to complete the specification of the service. Many requirements will be applicable to most, if not all, VRM services, such as those inspired by tenets of data portability and user-centric identity. When mapping out the first Change of Address use case, it became clear that the core Use Cases were already substantially met by such online services as Plaxo and LinkedIn, raising the question of what would actually make a Change of Address service VRM-compliant. That led directly to a handful of simple requirements that assure the user and vendors have appropriate access and controls.

Standards and Compliance

Third, we propose that any implementation that fully implements all of the normative requirements of the Use Model for a VRM Service, including all constraints and interoperability requirements, meets the VRM Standard for that Service.