XDI Requirements and Use Cases

Transcription

1 1 2 3 XDI Requirements and Use Cases Working Draft 01, April 19 th Document identifier: xdi-requirements-and-use-cases-document-04 Location: Editors: [Editors listed here] Contributors: [Contributors listed here] Abstract: [Summary of the technical purpose of the document.] Status: [The status and stability of the specification and where to send comments.] Copyright OASIS Open All Rights Reserved. Page 1 of 11

2 15 Table of Contents Purpose Introduction Notes on This Document Requirements Goals Non Goals Use Cases and Scenarios... 6 Use Case 1: Name... 6 Steps... 6 Scenario 1.1: Name References Normative... 8 Appendix A. Acknowledgments... 9 Appendix B. Revision History Appendix C. Notices Copyright OASIS Open All Rights Reserved. Page 2 of 11

3 Purpose This document describes the consensus of the XRI Data Interchange Technical Committee as to the requirements and Use Cases for the XDI protocols to be created by the Technical Committee. Copyright OASIS Open All Rights Reserved. Page 3 of 11

4 Introduction This document provides the set of Use Cases and Requirements for the OASIS XDI TC ultimate product, XDI protocol, a [insert description] 2.1 Notes on This Document Requirements are specified as a lost of goals and non goals for the project. Use Cases in this document are illustrated with UML (Unified Modeling Language) diagrams. A link to the UML home page is provided below. UML diagrams are analysis and design tools and each diagram format can support multiple levels of abstraction. In this document a balance had been struck between using a standard diagram format for requirements elaboration and maintaining a high level of abstraction. The document uses UML-style use-case diagrams to illustrate high-level use cases. The following list is probably sufficient as a crash course in UML use-case diagrams: Stick figures represent actors or roles in a scenario. These can be human beings or software systems. Ellipses represent use cases, i.e. actions or units of functionality in a system. Lines between actors and use cases indicate a participation of the actor in the use case. Note that no direction or payload of data flow is expressed by the lines between actors and use cases. The document uses UML sequence diagrams to illustrate detailed use case scenarios. For quick reference, a sequence diagram works as follows: Boxes at the top of the diagram represent an actor in the scenario. Arrows with a solid head represent a message sent from one actor to another. The arrow points from sender to receiver. Arrows with a line head represent the return value of a message. The arrow points from the receiver of the earlier message to the sender. A dotted line ("swim lane") running down the diagram from a box indicates that arrows whose endpoints (tail or head) is on the line apply to that actor. Intersections between arrows and dotted lines are meaningless. Vertical layout represents time. Messages (arrows) farther down on the page happen after messages higher on the page. Horizontal layout has no formal meaning. Since right-pointing arrows look better, actors that initiate a scenario tend to appear leftward of actors they send messages to. Note that sequence diagrams are often used for more concrete design, and that actors and messages are often objects and object methods. They provide value for this document in that they give a clearly ordered message layout. The actors and messages in the sequence diagrams below are more properly roles in a scenario and actions associated with that scenario. Readers will probably be interested in the accompanying glossary (REF) and issues list (REF) Copyright OASIS Open All Rights Reserved. Page 4 of 11

5 Requirements The requirements describe the scope of the XDI standard.\ 3.1 Goals [R-NameOfRequirement] Description of goal 3.2 Non Goals Description of non goals Copyright OASIS Open All Rights Reserved. Page 5 of 11

6 Use Cases and Scenarios This section provides a set of high-level use cases for the XDI Protocol and use case scenarios that illustrate the use case. They give a very abstract view of the intended use of the SAML format. Each use case has a short description, a use case diagram in UML format, and a list of the steps involved in the case. Note that, for each use case, the mechanics of how the actions are performed is not described. More detail provided in the detailed use case scenarios. Each of these high-level use cases has one or more specializations in the detailed use-case scenarios. Each scenario contains a short description of the scenario, a UML sequence diagram illustrating the action in the scenario, a description of each step, and a list of requirements that are related to the scenario. Use Case 1: Name In this use case, Actor A interacts with Actor B to achieve a result Fig 1. Name Steps 1. Step 1 2. Step 2 Scenario 1.1: Name This scenario is an elaboration of the [Name] Use Case. In this model, the Actor A does this and the Actor B does that and the result is this. Copyright OASIS Open All Rights Reserved. Page 6 of 11

7 Fig 2: Name Associated requirements: [R-Name], [R-Name], [R- Name], [R-Name] [R-Name]. Copyright OASIS Open All Rights Reserved. Page 7 of 11

8 111 5 References Normative [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March Copyright OASIS Open All Rights Reserved. Page 8 of 11

9 Appendix A. Acknowledgments The following individuals were members of the committee during the development of this specification: Member name and company Copyright OASIS Open All Rights Reserved. Page 9 of 11

10 Appendix B. Revision History [This appendix is optional, but helpful. It should be removed for specifications that are at OASIS Standard level.] Rev Date By Whom What Copyright OASIS Open All Rights Reserved. Page 10 of 11

11 Appendix C. Notices OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. Copyright OASIS Open All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright OASIS Open All Rights Reserved. Page 11 of 11