Services

Working Draft

An introduction to Use Cases and how they relate to our work on VRM.

Existing Work

• Service/Use Case Brainstorming
• Services Under Development
  • Working Drafts
    • Personal Address Manager Service

Definitions

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

Transaction

a user initiated interaction with the system to produce a specific benefit.

Actor

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 Requirements Model

Second, in developing a complete VRM Standard, we will create several documents, which will define exactly what value the system will product for which actors. These documents together comprise the Requirements Model for the Standard.

Actor List

A list of all Actors supported by the system.

Role List

A list of all Roles support by the system, specifying one or two focal Roles. Roles specify an Actor in terms of their relationship with the system so that we know why they are interacting, what they need to do, and what they expect from the system. More formally, a Role is an abstract collection of needs, interest, expectations, behaviors, and responsibilities characterizing a relationship between a class or kind of actors and a system.

Role Map

A visual representation of the supported Roles and their relationships to one another.

Profiles

A detailed description of each Role's expectations, capability, and requirements for the system, forming an operational context for that particular role. Developed to enough detail to distinguish what this particular Actor 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 Role'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 Actor intention and System responsibilities for a particular use case. Based on one or more specific Scenarios. The abstract narrative defines 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 Actor 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 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.

Technology Review

A review of existing technologies that can be leveraged to implement a complete service, either directly--by incorporating the technology into a deliverable solution, or indirectly--by learning from the technology to assure a more complete solution.

Formats & Protocols

The data formats and protocols that are required for implementing the service. This includes interoperable data formats as well as open standard transport protocols for moving data around.

Standards and Compliance

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

Toward that end, the normative documents for the Requirements Model will be drafted, revised, and vetted via an open process, accessible to anyone. Our expectation is that the governing committee of the VRM effort, and the VRM Standards Committee in particular, will oversee the development of new services from brainstorming through to publication. The VRM Standards Committee will Propose complete standards to the governing committee once sufficient development and public review demonstrates to the committee that such a standard is ready for publication. Ultimate authority for publication will remain with the governing committee itself; we anticipate VRM Standards being published as "Recommendations" in similar spirit to long standing Internet Engineering Task Force (IETF) practices.

The VRM Compliance Committee will oversee compliance to published standards, authenticating vendors right to claim their technology or services are "VRM Compliant."

Process

As a Service is defined by its working group, it will proceed through different levels of maturity.

Working Draft

any work at a stage before the working group considers it to be a complete spec. Straight numeric progression of versions, e.g., WD 1, WD 2, etc.

Working Specification

approved by the working group as a specification, but not yet at the stage where it has been approved by the VRM powers-that-be. At this stage the key goal is to “prove” the spec via implementations and interop testing. A Working Specification can go back into more Working Drafts if the Working Group decides further revisions are needed. Another straight numeric progression of versions, i.e., WS 1, WS 2, etc. This level is achieved by a majority vote of the members of the Working Group.

Recommended Specification

A Working Spec that has been approved by the VRM powers-that-be. A “final” VRM standard, fixed by version # and suitable for widespread adoption. To become a Recommended Specification, a Working Specification must go through a minimum public review period and have some number of interoperable implementations (OASIS is three; don’t know about IETF). Also another numeric progression of versions, i.e., RS 1, RS 2, etc. This level is achieved by a majority vote of the VRM Steering Committee.

Work in Progress

The VRM initiative is early in its development. The proposed processes are likely to evolve over time. Given the fluid yet inherently dated nature of wikis and web pages, any particular document may or may not reflect the current--or ultimate--disposition of the VRM community. However, we have to start somewhere. We look forward to your input.