Services - Revision history

Janewils9: /* Work in Progress */

2011-08-22T13:49:55Z

Work in Progress

← Older revision		Revision as of 13:49, 22 August 2011
Line 52:		Line 52:

	==Work in Progress==		==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.		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 and <span class="plainlinks">[http://cyber.law.harvard.edu/projectvrm/Servicess <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">services</span>].

Joe.andrieu: Reverted edits by KruGer (Talk) to last version by Joe.andrieu

2009-12-01T08:37:40Z

Reverted edits by KruGer (Talk) to last version by Joe.andrieu

← Older revision		Revision as of 08:37, 1 December 2009
Line 53:		Line 53:
	==Work in Progress==		==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.		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.
	~~[http://www.sexalemi.org sikis izle]~~
	~~[http://www.pornositeleri.net porno izle]~~
	~~[http://www.sexalemi.org sex izle]~~
	~~[http://www.sexalemi.org sikis]~~
	~~[http://www.cinsel.name sikis izle]~~
	~~[http://www.cinsel.name.tr sikis]~~
	~~[http://www.hiphopalemi.net hiphop]~~
	~~[http://www.kelebekchat.net kelebek chat]~~
	~~[http://www.kelebeksohbet.org kelebek sohbet]~~
	~~[http://www.chatsohbet.org chat sohbet]~~
	~~[http://www.siberchat.net chat]~~
	~~[http://www.pornositeleri.net porno]~~
	~~[http://www.pornositeleri.org porno izle]~~
	~~[http://www.pornositeleri.org porno siteleri]~~
	~~[http://www.sexpormok.net sex]~~
	~~[http://www.mynetsohbet.net mynet sohbet]~~
	~~[http://www.hiphopalemi.net chat]~~
	~~[http://www.hiphopalemi.net rap]~~
	~~[http://www.kelebekchat.net kelebek]~~
	~~[http://www.gaychat.gen.tr gay chat]~~
	~~[http://www.sempatim.net seviÅme]~~
	~~[http://www.cinsel-sohbet.com cinsel sohbet]~~

KruGer: /* Work in Progress */

2009-11-28T11:27:56Z

Work in Progress

← Older revision		Revision as of 11:27, 28 November 2009
Line 53:		Line 53:
	==Work in Progress==		==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.		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.
			[http://www.sexalemi.org sikis izle]
			[http://www.pornositeleri.net porno izle]
			[http://www.sexalemi.org sex izle]
			[http://www.sexalemi.org sikis]
			[http://www.cinsel.name sikis izle]
			[http://www.cinsel.name.tr sikis]
			[http://www.hiphopalemi.net hiphop]
			[http://www.kelebekchat.net kelebek chat]
			[http://www.kelebeksohbet.org kelebek sohbet]
			[http://www.chatsohbet.org chat sohbet]
			[http://www.siberchat.net chat]
			[http://www.pornositeleri.net porno]
			[http://www.pornositeleri.org porno izle]
			[http://www.pornositeleri.org porno siteleri]
			[http://www.sexpormok.net sex]
			[http://www.mynetsohbet.net mynet sohbet]
			[http://www.hiphopalemi.net chat]
			[http://www.hiphopalemi.net rap]
			[http://www.kelebekchat.net kelebek]
			[http://www.gaychat.gen.tr gay chat]
			[http://www.sempatim.net seviÅme]
			[http://www.cinsel-sohbet.com cinsel sohbet]

Joe.andrieu: switched language from use cases to Services, reflecting current usage

2008-03-16T06:20:14Z

switched language from use cases to Services, reflecting current usage

← Older revision		Revision as of 06:20, 16 March 2008
Line 1:		Line 1:
	'''''Working Draft'''''		'''''Working Draft'''''

	An introduction to Use Cases ~~and how they relate to~~ our work on VRM.		An introduction to VRM Services and how Use Cases inform our work on VRM. (Formerly called Use Cases.)

	==Existing Work==		==Existing Work==
Line 10:		Line 10:

	==Definitions==		==Definitions==
	First, A Use Case is a distinct, complete transaction between an actor and the system.		First, a Service is a bundle of functionality that provides a complete set of value for users.

			Second, A Use Case is a distinct, complete transaction between an actor and the system. A service is a collection of supported Use Cases.

	; Transaction: an actor initiated interaction with the system to produce a specific benefit.		; Transaction: an actor initiated interaction with the system to produce a specific benefit.
Line 16:		Line 18:
	; 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. Every VRM Service will be developed with specific focal actors in mind while incorporating the needs of all supported users.		; 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. Every VRM Service will be developed with specific focal actors in mind while incorporating the needs of all supported users.

	; System: ~~A complete~~ service that provides a bundled set of functionality for actors. VRM Services implement a few focal use cases and multiple supporting use cases in order to provide value to actors. Think of ~~services~~ as a convenient way to organize VRM functionality into implementable systems.		; System: An implemented service that provides a bundled set of functionality for actors. VRM Services implement a few focal use cases and multiple supporting use cases in order to provide value to actors. Think of Services as a convenient way to organize VRM functionality into implementable systems.

	==The Requirements Model==		==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.		Third, 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.

	; Actors: A list of all Actors supported by the system.		; Actors: A list of all Actors supported by the system.

Joe.andrieu: Use Cases moved to Services: Use cases are more properly just one component of our service definition.

2008-03-16T06:16:30Z

Use Cases moved to Services: Use cases are more properly just one component of our service definition.

← Older revision	Revision as of 06:16, 16 March 2008
(No difference)

Joe.andrieu: /* The Requirements Model */

2008-03-12T16:54:38Z

The Requirements Model

← Older revision		Revision as of 16:54, 12 March 2008
Line 21:		Line 21:
	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.		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.		; Actors: 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.		; Roles: 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.		; 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.		; 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.

Joe.andrieu: /* Definitions */

2008-03-12T16:53:59Z

Definitions

← Older revision		Revision as of 16:53, 12 March 2008
Line 12:		Line 12:
	First, A Use Case is a distinct, complete transaction between an actor and the system.		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.		; Transaction: an actor 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.		; 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. Every VRM Service will be developed with specific focal actors 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.		; System: A complete service that provides a bundled set of functionality for actors. VRM Services implement a few focal use cases and multiple supporting use cases in order to provide value to actors. Think of services as a convenient way to organize VRM functionality into implementable systems.

	==The Requirements Model==		==The Requirements Model==

Joe.andrieu: /* The Requirements Model */

2008-03-09T21:47:47Z

The Requirements Model

← Older revision		Revision as of 21:47, 9 March 2008
Line 24:		Line 24:
	; 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 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.		; 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. Developed to enough detail to distinguish what this particular Actor needs from the system design.		; 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.		; 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.		; 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.

Joe.andrieu: /* The Requirements Model */

2008-03-04T09:50:17Z

The Requirements Model

← Older revision		Revision as of 09:50, 4 March 2008
Line 24:		Line 24:
	; 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 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.		; Role Map: A visual representation of the supported Roles and their relationships to one another.
	; ~~Actor~~ Profiles: A detailed description of each ~~Actor~~'s expectations, capability, and requirements for the system. Developed to enough detail to distinguish what this particular Actor needs from the system design.		; Profiles: A detailed description of each Role's expectations, capability, and requirements for the system. 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.		; 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.		; 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.

Joe.andrieu: /* The Requirements Model */

2008-03-04T09:48:22Z

The Requirements Model

← Older revision		Revision as of 09:48, 4 March 2008
Line 22:		Line 22:

	; Actor List: A list of all Actors supported by the system.		; 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~~. ~~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. In short,~~ 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.		; 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.		; Role Map: A visual representation of the supported Roles and their relationships to one another.
	; Actor Profiles: A detailed description of each Actor's expectations, capability, and requirements for the system. Developed to enough detail to distinguish what this particular Actor needs from the system design.		; Actor Profiles: A detailed description of each Actor's expectations, capability, and requirements for the system. 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.		; 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.