Skip to end of metadata
Go to start of metadata

Overview of "Conduct Negotiation" Use Case

Negotiate agreement (or not) between agents


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Agents, on behalf of Principals
References UC.R1.32 Conduct Negotiation
CIAD COI OV Governance Framework
UC.R2.30 Define Interaction
Uses  
Is Used By  
Extends  
Is Extended By  
Dependencies  
In Acceptance Scenarios AS.R2.03A Modelers Integrate External Model with OOI
Technical Notes The actors are 'Negotiators': agents that can take on a negotiation role, and which act on behalf of people or systems. The roles of the respective agents could be varied — Consumer / Resource, Principal / Org, or any two Orgs creating an agreement.
At each step, both parties are Negotiators; at each step we take the perspective of one of them and refer to the other one as the counterparty.
This use case blends the original 'single-shot' and 'alternating offers' negotiation use cases.
Lead Team COI
Primary Service Federated Facility Services (Virtual Organization) Part 1
Version 1.2
UC Priority 3
UC Status Mapped + Ready
UX Exposure PGM

Summary

This information summarizes the Use Case functionality.

The agents for two parties undertake to reach an agreement on terms by exchanging proposals and related responses (accept or reject, or a counterproposal). The contract is created through a series of communicative acts. A negotiation is initiated when one party proposes to another party. The parties may make zero or more counterproposals to each other. The negotiation ends when one of the parties rejects the last proposal or all the parties accept.

Assumptions

  • All messages in all negotiations are logged for later inspection.

Initial State

Negotiators exist; the initating Negotiator has access to address of the counterparty (to which proposals can be sent).

Scenario for "Conduct Negotiation" Use Case

  1. A Negotiator sends a PROPOSAL message to the counterparty specifying the terms for a proposed engagement
  2. A Negotiator receiving a PROPOSAL message responds with one of three messages: an ACCEPT_PROPOSAL (specifying the terms in the immediately preceding incoming PROPOSAL from the same counterparty), a REJECT_PROPOSAL (specifying the terms in the immediately preceding incoming PROPOSAL from the same counterparty), or a PROPOSAL as in the previous step (this functions as a counterproposal).
    1. Upon receiving or sending an ACCEPT_PROPOSAL or REJECT_PROPOSAL, neither Negotiator sends further messages (so this negotiation is closed).
    2. A valid ACCEPT_PROPOSAL means that the Negotiators are committed to the terms specified in the ACCEPT_PROPOSAL.
    3. An ACCEPT_PROPOSAL is valid only if it occurs prior to the expiration of the PROPOSAL that it refers to, and has the identical terms as that PROPOSAL.
  3. <2> A Negotiator sends a new PROPOSAL message within an existing conversation to subsume previous proposals.
    1. All previous PROPOSAL messages sent by the Negotiator or the counterparty in the same negotiation conversation lose their significance to the subsequent engagement.*
    2. In other words, a PROPOSAL dissolves all previous PROPOSALs arising in the same negotiation.
  4. An ACCEPT_PROPOSAL message results in registration of the accepted PROPOSAL, and an event confirming the PROPOSAL acceptance.
    1. All accepted PROPOSALs should be registered in a searchable registry.

Final State

Proposal has been negotiated and resolved, either accepted (and registered) or not.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

This use case should be expanded to include concepts of identity management to satisfy DOORS requirements.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.