Iepd analyze Requirements Use Cases for edxl situation reporting messages Draft Version 4
Download 212.64 Kb.
|
- Navigate this page:
- 1.2.Required Messages / Message Types
- 1.5.Out of Scope Statements determined by the team to be outside the requirements of this messaging standard. 1.6.Other Notes
- 4.Guidance for Use Case Template
- 4.1.3Use Case History 4.1.4Created By
- 5.Use Case Definition 5.1.Use Case Description
- 5.6.Post-conditions Describe the state of the system at the conclusion of the use case execution. Number each post-condition. 5.7.Normal Flow
- 5.11.Priority Indicate the relative priority (Low, Medium, High) of implementing the required information sharing to allow this use case to be executed. 5.12.Frequency of Use
- 5.13.Business Rules List any business rules that influence this use case. 5.14.Special Requirements
1.Summary InformationThis section consolidates and summarizes requirements and information flows driven out during execution of the scenario and development of multiple use cases. 1.1.General Information-Sharing RequirementsThis section specifies specific requirements driven out through the use cases exercise, that the final product must meet. 1.2.Required Messages / Message TypesThis section summarizes the list of messages or types of messages identified through the use case exercise. This section may also include message elements that make up each message. 1.3.Open IssuesA list of issues that have not been resolved by the team. 1.4.Closed IssuesA list of issues with description of their resolution. 1.5.Out of ScopeStatements determined by the team to be outside the requirements of this messaging standard. 1.6.Other NotesMiscellaneous information that may contribute to information-sharing requirements. 2.Scenario Events ChronologyA Chronological list of events is often constructed from the selected scenario, and sometimes includes extensions or tailored events to specifically exercise the scenario for the particular standard being addressed. The list of events provides general preconditions, and includes the date/time, Description of the Activity or Task, actors (senders / recipients) and Remarks. 3.Use Case ListThis is simply a reference list of all use cases contained in this document. It includes the Use case ID, Use Case name, and Primary Actor(s). 4.Guidance for Use Case TemplateDocument each use case using the template shown at the end of this document. This section provides a description of each section in the use case template. 4.1.Use Case Identification4.1.1Use Case IDGive each use case a unique integer sequence number identifier. Alternatively, use a hierarchical form: X.Y. Related use cases can be grouped in the hierarchy. 4.1.2Use Case NameState a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some cases:
4.1.3Use Case History4.1.4Created BySupply the name of the person who initially documented this use case. 4.1.5Date CreatedEnter the date on which the use case was initially documented. 4.1.6Last Updated BySupply the name of the person who performed the most recent update to the use case description. 4.1.7Date Last UpdatedEnter the date on which the use case was most recently updated. 5.Use Case Definition5.1.Use Case DescriptionProvide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions / information flows, and the outcome of executing the use case 5.2.Chronology Step(s)Refer here to the Event Chronology step(s) that this use case supports. (See section 2). 5.3.Business Process SupportedList the overall function or business process supported by this use case or information flow (e.g. Emergency Planning, Preparedness, Mitigation, Response, Management, and Recovery), and sub-process if applicable. 5.4.ActorsAn actor is a person, organization or other entity external to the EDXL message being specified who interacts with the EDXL compliant system and performs the use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the sender and recipient actors that will be initiating and participating in this use case / information exchange. 5.5.PreconditionsList any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. 5.6.Post-conditionsDescribe the state of the system at the conclusion of the use case execution. Number each post-condition. 5.7.Normal FlowProvide a detailed description of the user actions and information flows that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I Information elements contained in each information flow will be detailed or referred to another document, and detailed definitions developed. 5.8.Alternative FlowsDocument other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative flow, and describe any differences in the sequence of steps and information flows that take place. Number each alternative flow in the form “X.Y”, where “X” is the Use case ID and Y is a sequence number for the alternative flow. For case, “5.3” would indicate the third alternative flow for use case number 5. Detail changes compared to the “normal flow” steps, information flows or the elements they contain. 5.9.ExceptionsDescribe any anticipated exceptions to the “normal flow” and conditions that could cause these exceptions. Define the alternate use case and how this might affect desired information flow / sharing. 5.10.IncludesList any other use cases that are included (“called”) by this use case. Common information flows that appear in multiple use cases can be split out into a separate use case that may be included by the ones that need these common information flows. 5.11.PriorityIndicate the relative priority (Low, Medium, High) of implementing the required information sharing to allow this use case to be executed. 5.12.Frequency of UseEstimate the number of times this use case will be performed by the actors per some appropriate unit of time. 5.13.Business RulesList any business rules that influence this use case. 5.14.Special RequirementsIdentify any additional requirement, for the use case that may need to be addressed during design or implementation. 5.15.AssumptionsList any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description. 5.16.Notes and IssuesList any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is. Copyright © 2004 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. Directory: committees -> download.php download.php -> Emergency Interoperability Consortium Membership Meeting download.php -> Technical Communicators, Get ready: Here comes Augmented Reality! Rhonda Truitt download.php -> Oasis set tc download.php -> Technical Committee: oasis transformational Government Framework tc chair download.php -> Ibops protocol Version 0 Working Draft 2 9 March 2015 Technical Committee download.php -> Reliability of Messages Sent as Responses over an Underlying Request-response Protocol download.php -> Service Component Architecture sca-j common Annotations and apis Specification Version 1 Committee Draft 03 – Rev1 + Issue 127 download.php -> Scenario Two – Hurricane Warning download.php -> Technical Committee: oasis augmented Reality in Information Products (arip) tc chairs download.php -> This is intended as a Non-Standards Track Work Product. [Type the document title] Download 212.64 Kb. Share with your friends:
|