Use-Case Metadata

Abstract

As defined previously in Chapter 5, a “Use Case constitutes a complete course of events initiated by an Actor and it specifies the interaction that takes place between the actor and the system.” Actors are people, functional roles, or interfacing systems that interact with the enterprise. One or more use cases are developed for each non-system actor. The following table represents a form that has been used to document use cases and the information that is gathered for each use case. Note that, the bracketed text explains the content expected to be included in the section.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

As defined previously in Chapter 5, a “Use Case constitutes a complete course of events initiated by an Actor and it specifies the interaction that takes place between the actor and the system.”¹ Actors are people, functional roles, or interfacing systems that interact with the enterprise. One or more use cases are developed for each non-system actor. The following table represents a form that has been used to document use cases and the information that is gathered for each use case. Note that, the bracketed text explains the content expected to be included in the section.

Example Use-Case Format

Use-Case Name	Receive a Reinsurance Request
Unique ID	UC000001
Course of Action	[Does the use case represent an “ideal” or “alternative” course of action? • Ideal: The steps (processes, decisions, deliverables, etc.) taken by the actor(s) within the context of the use case, under ideal circumstances. • Alternative: The alternative steps (processes, decisions, deliverables, etc.) and the conditions under which the ideal may not be followed.]
Parent Use Case	[The name of a use case from which this use case is derived.]
Use-Case Description	[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this description.]
Primary Actor	[The primary role that performs the work associated with the business functionality represented by the use case.]
Support Actor(s)	[The roles that assist (support) the work effort associated with the business functionality represented by the use case.]
Preconditions	[A precondition of a use case is the state of the system that must be present prior to a use case being performed.]
Assumptions	[An assumption helps to scope the use case and provide context for its execution.]
Measures of Success	[Tangible metrics and intangible factors (key components of business goals and objectives) that management has determined are success factors for the functionality represented by the use case.]
Use-Case Location(s)	[The location(s) where the use-case functionality takes place.]
Use-Case Frequency	[The frequency (per hour, day, etc.) by which the work effort associated with the use-case functionality is conducted.]
Main Course	[This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and what the system does in response. It is phrased in the form of a dialogue between the actor and the system. The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer information. It is better to say the actor enters the customer’s name and address. A glossary of terms is often useful to keep the complexity of the use case manageable—you may want to define things like customer information there to keep the use case from drowning in details. Simple alternatives may be presented within the text of the use case. If it only takes a few sentences to describe what happens when there is an alternative, do it directly within the main course section. If the alternative flow is more complex, use a separate section to describe it. For example, an alternative course subsection explains how to describe more complex alternatives. A picture is sometimes worth a thousand words, although there is no substitute for clean, clear prose. If it improves clarity, feel free to paste graphic depictions of user interfaces, process flows, or other figures into the use case. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations, or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.] 1. Triggering Event 1 2 a. Decision 1-1 i. Business Rules 1-1-1: Decision Criteria ii. Business Rules 1-1-2: Decision Criteria iii. … iv. Business Rules 1-1-n: Decision Criteria b. Decision 1-2 i. Business Rules 1-2-1– Decision Criteria ii. Business Rules 1-2-2– Decision Criteria iii. … iv. Business Rules 1-2-n– Decision Criteria c. Process 1-1-1 d. Process 1-1-2 2. Triggering Event 2 a. Decision 2-1 i. Business Rules 2-2-1– Decision Criteria ii. Business Rules 2-2– Decision Criteria b. Decision 2-2 i. Business Rules 2-1– Decision Criteria c. Process 2-1-1 d. Process 2-1-2 3. If X then Alternate 1 else Alternate 2 4. Step 4
Alternate Course 1	[More complex alternatives are described in a separate section, referred to in the main course subsection of the flow of events section. Think of the alternative course subsections as an alternative behavior—each alternative flow represents an alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.] 1. Step 1 2. Step 2
Alternate Course 2	[There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative flow separate to improve clarity. Using alternative flows improves the readability of the use case, as well as prevents use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
Postconditions	[A postcondition of a use case is a list of possible states the system can be in immediately after a use case has finished.]
Nonfunctional Requirements	[These are typically specific to a use case but are not easily or naturally specified in the text of the use case’s event flow. Examples of these requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance, or supportability requirements. Additionally, other requirements—such as operating systems and environments, compatibility requirements, and design constraints—should be captured in this section.]
Business Rules	[Use cases may contain specific business rules or logic. These are defined as the criteria by which a decision is made within a flow of events. If these rules are complex or lengthy and do not affect the flow of the use case, they should be described here.]
Issues	[During the requirements-gathering and analysis process, issues will crop up. These issues can initially be captured here if they pertain to this use case.]

The following “For Each Use Case” table gives an explanation of the information gathered for each use case.

	For Each Use Case
Type of Information	Description of Information	When Needed
Use-Case Name	The name that will be used by business personnel to represent business functionality encompassing a set of input and output deliverables, actors (roles), processes, decisions, business rules, triggering events, and other information that provides adequate business context to develop automated IT support mechanisms.	Business Requirements Definition
Course of Action	Does the use case represent an “ideal” or “alternative” course of action? Ideal: The steps (processes, decisions, deliverables, etc.) taken by the actor(s) within the context of the use case, under ideal circumstances. Alternative: The alternative steps (processes, decisions, deliverables, etc.) and the conditions under which the ideal may not be followed.	Business Requirements Definition
Parent-Use Case	The name of a use case from which this use case is derived.	Business Requirements Definition
Use-Case Description	An overview of the work that is accomplished within the business scenario scope represented by the use case. For example, an overview of the courses of action taken by the actor(s), within the context of the use case, under ideal circumstances or alternative courses of action and the conditions under which the ideal may not be followed.	Business Requirements Definition
Expected Use-Case Results	The results (e.g., expected outputs such as products or other deliverables) as expected from the execution of the processes defined within the use case.	Business Requirements Definition
Preconditions	None	Business Requirements Definition
Assumptions	None	Business Requirements Definition
Measures of Success	Tangible metrics or intangible factors (key components of business goals and objectives) that management has determined are success factors for the functionality represented by the use case.	Business Requirements Definition
Primary Actor	The primary role that performs the work associated with the business functionality represented by the use case.	Business Requirements Definition
Support Actor(s)	The roles that assist (support) the work effort associated with the business functionality represented by the use case.	Business Requirements Definition
Use-Case Location(s)	The location(s) where the use-case functionality takes place.	Business Requirements Definition
Use-Case Frequency	The frequency (per hour, day, etc.) by which the work effort associated with the use-case functionality is conducted.	Business Requirements Definition

As shown in the Example Use-Case Format table and as explained in Chapter 5, within both the main course and alternative courses there are a series of events, decisions, and rules that need to be defined. The information types may be data attributes within the Use Case Metadata Model as show in Figure 5-3 and explained in the next “For Each Use Case Course of Action” table.

	For Each Use Case Course of Action
Type of Information	Description of Information	When Needed
Use-Case Name	The name that will be used by business personnel to represent a business functionality encompassing a set of input and output deliverables, actors (roles), processes, decisions, business rules, triggering events, and other information that provides adequate business context to develop automated IT support mechanisms. An entry should be established in the general use-case information spreadsheet prior to generating this entry in the use-case course of action spreadsheet.	Business Requirements Definition
Event Name	The name commonly referred to for a business event that triggers the execution of one or more business processes within the use-case scope. This attribute is repeated for each event that can occur within the use-case scope.	Business Requirements Definition
Event Description	A short definition for a business event that triggers the execution of one or more business processes within the business scenario scope defined by the use case. This attribute is repeated for each event that can occur within the use-case scope.	Business Requirements Definition
Event Frequency Mean	The average number of times this business event is expected to occur over a specific time (day, week, etc.) period. For example, guests booked 200 times per day on average. This attribute is repeated for each event that can occur within the use-case scope.	Business Requirements Definition
Maximum Event Frequency	The maximum number of times this business event is expected to occur over a specific time (day, week, etc.) period. For example, guest bookings could reach 1,000 per day during the busiest seasons. This attribute is repeated for each event that can occur within the business scenario scope defined by the use-case scope.	Business Requirements Definition
Spontaneity	Is the business event scheduled, schedulable, or randomly occurring from the perspective of the business-user community? This attribute is repeated for each event that can occur within the use-case scope.	Business Requirements Definition
Scheduling Method	The method for determining the scheduling of the business event. For example, monthly, at the first of the month, daily at 12:00 p.m., etc. This attribute is repeated for each event that can occur within the business scenario scope defined by the use case. In addition, this attribute is optional depending on the type of event spontaneity.	Business Requirements Definition
Event Location(s)	The specific location(s) (e.g., Epcot Welcome Center) or location type(s) (e.g., hotels) where the business event occurs. This attribute is repeated for each event that can occur within the business-scenario scope defined by the use case. In addition, this attribute is optional depending on the type of event spontaneity.	Business Requirements Definition
Decision Name	The name commonly referred to for a business decision that represents the outcome of one or more business rules. A decision is more completely defined within the context of an activity diagram where one or more processes are related to each branch (decision output path) of the decision. This attribute is repeated for each decision that can occur within each event and within the use-case scope.	Solution Design
Decision Description	The short description that defines a business decision that represents the outcome of one or more business rules. This attribute is repeated for each decision that can occur within each event and within the use-case scope.	Solution Design
Business-Rule Description	The name of a business condition or group of conditions that drive a decision to execute one or more business processes. This attribute is repeated for each business rule, within each decision that can occur within each event and within the use-case scope.	Solution Design
Business-Rule Source	The business SME (subject-matter expert) responsible for defining or maintaining the business rule. This attribute is repeated for each business rule, within each decision that can occur within each event and within the use-case scope.	Solution Design
Business-Rule Entity/Object Name	The descriptive name of a real-world object that contains information used to derive business-rule results and thus determine a business decision. This attribute is repeated for each entity/object name, required by each business rule, within each decision that can occur within each event and within the use-case scope.	Business Requirements Definition
Business-Rule Attribute Name	The name of a discrete, atomic element of information associated with a real-world business object that contains information used to derive business-rule results and thus determine a business decision. This attribute is repeated for each entity/object name, required by each business rule, within each decision that can occur within each event and within the use-case scope.	Solution Design

Decision events, as discussed in Chapter 5, trigger system or business processes. In the following “For Each Use-Case Process” table, the class names are decision event actions.

	For Each Use Case Process
Type of Information	Description of Information	When Needed
Use-Case Name	The name that will be used by business personnel to represent business functionality encompassing a set of input and output deliverables, actors (roles), processes, decisions, business rules, triggering events, and other information that provides adequate business context to develop automated IT support mechanisms.	Business Requirements Definition
Event Name	The name commonly referred to for a business event that triggers the execution of one or more business processes within the scope defined by the use case.	Business Requirements Definition
Process Name	The name of a business process representing a real-world business activity or software routine that is triggered by a business event. This attribute is repeated for each process triggered by each event that can occur within the scope defined by the use case.	Business Requirements Definition
Business-Process Description	The short description of a business process representing a real-world business activity or software routine that is triggered by a business event. This attribute is repeated for each process triggered by each event that can occur within the scope defined by the use case.	Business Requirements Definition
Process Frequency Mean	The average number of times this business process is expected to occur over a specific time (day, week, etc.) period. For example, “guest credit check” occurs 300 times per day on average. This attribute is repeated for each process triggered by each event that can occur within the scope defined by the use case.	Same as above
Maximum Process Frequency	The maximum number of times this business process is expected to occur over a specific time (day, week, etc.) period. For example, “guest credit check” could reach 1,000 per day during the busiest seasons. This attribute is repeated for each process triggered by each event that can occur within the scope defined by the use case.	Same as above
Process Location(s)	The specific location(s) (e.g., Epcot Welcome Center) or location type (e.g., hotels) where the business process is executed. This attribute is repeated for each event that can occur within the scope defined by the use case. In addition, this row is optional depending on the type of event spontaneity.	Business Requirements Definition
Required Response	Must an immediate response occur or can a delayed (e.g., batch) response satisfy the requirement? If the response may be delayed, what is the acceptable timeframe? This attribute is repeated for each event that can occur within the scope defined by the use case. In addition, this row is optional depending on the type of event spontaneity.	Business Requirements Definition
Process Entity/Object Name	The descriptive name of a real-world object that contains information used to develop outputs (deliverables) from a business process. This attribute is repeated for each entity/object name, required by each business rule, within each decision that can occur within each event and within the scope defined by the use case.	Business Requirements Definition
Process Attribute Name	The name of a discrete, atomic element of information associated with a real-world business object that contains information used to develop outputs (deliverables) from a business process. This attribute is repeated for each entity/object name, required by each business rule, within each decision that can occur within each event and within the scope defined by the use case.	Business Requirements Definition

In Chapters 5 and 6, we introduce data models using UML class models. In the data model examples (Figures 5-4, 6-8, and 6-9, among others in Chapters 7, 8, and 9), we presented class names. The following “For Each Class or Data Entity“ table shows the metadata attributes for each class or data entity.

	For Each Class or Data Entity
Type of Information	Description of Information	When Needed
Class/Data Entity Name	The descriptive name of a real-world object (person, place, thing, event, concept, or event) and information represented by that object that is of importance to the enterprise.	All Data Entities must be included in the Conceptual Data Model
Synonyms	By what other names is this data entity called?	Logical Data Model
Data-Entity Description	What is a short description of the data entity from a business perspective?	Conceptual Data Model
Responsible Person	Who is responsible for maintaining the quality of the information in this data entity?	Conceptual Data Model
Metadata Supplier	Who supplied the information used to populate the data entity metadata?	Conceptual Data Model
Instance Example	What would be an example of an instance of this data entity if needed to understand the nature of it?	Conceptual Data Model
Supertype Data Entity	If this is a subtype data entity, what is the supertype?	Conceptual Data Model
Uniqueness Identifier	What data element(s) uniquely identify the data entity?	Logical Data Model
Other Data Elements	What data elements are contained within this data entity, including foreign keys and derivable data elements?	Logical Data Model
Average Volume	What is the expected number of instances (records or rows) that this data entity may occur?	Required for Database Design (Logical Data Model)
Maximum Volume	What would be the largest number of instances (records or rows) that this data entity may occur?	Required for Database Design (Logical Data Model)
Growth Rate	What is the annual rate of increase of the number of instances?	Required for Database Design (Logical Data Model)
CRUD Actor(s)	What business role(s) creates, retrieves, updates, and deletes (CRUD) this data entity?	Required for Database Design (Logical Data Model)
Archiving Rules	How long will information be kept, and how should the history be handled?	Required for Database Design (Logical Data Model)
Data-Content Quality Rules	What domain rules and valid value sets should apply?	Required for Database Design (Logical Data Model)
Data-Presentation Quality Rules	What data-presentation quality should apply to information-bearing documents and media such as reports or screens presenting the results of queries from data to database?	Required for Database Design (Logical Data Model)
Data-Residency Business Rules	How long should data reside in the various levels of storage (e.g., operational data store, data warehouse, or archive)?	Required for Database Design (Logical Data Model)
Security Rules	What security rules govern the adding, accessing, and updating of this data entity?	Required for Database Design (Logical Data Model)
Data Source	What system or existing database will be used to populate this data entity?	Required for Database Design (Logical Data Model)
Refreshment Timing	How often should this data entity be refreshed?	Required for Database Design (Logical Data Model)
Availability Requirements	What, if any, special rules govern the availability of these data?	Required for Database Design (Logical Data Model)

The following “For Each Data Attribute” table shows metadata attributes for each data attribute. (See Figure 6-8 for an example.)

	For Each Data Attribute
Type of Information	Description of Information	When Needed
Data-Attribute Name	The name of a discrete, atomic element of information associated with a real-world business object that is of importance to WDW.	All Data Elements must be included in the Logical Data Model
Synonyms	By what other names is this data attribute called?	Logical Data Model
Data-Attribute Description	What is a short description of the data attribute from a business perspective?	Logical Data Model
Metadata Source	Who supplied the information used to populate the data attribute metadata?	Logical Data Model
Example	What would be an example of an instance of this data entity if needed to understand the nature of the data attribute?	Logical Data Model
Responsible Person	Who is responsible for maintaining the quality information in this data attribute?	Logical Data Model
Data Entity (where contained)	What data entity contains this data attribute?	Logical Data Model
Data Type	What is the nature of the data attribute? Is it always alphabetic (character), alphanumeric, binary, text, iconic, etc.?	Logical Data Model
Maximum Characters	What is the maximum number of characters or digits required for this attribute?	Logical Data Model
Decimal Position	What is the maximum number of characters right of a decimal point?	Logical Data Model
Required or Optional	Must this data attribute always be entered when the data entity is added? A data attribute should be considered optional unless it is required under all circumstances.	Logical Data Model
Percentage of Used	What percentage of the time will an optional data attribute contain data?	Logical Data Model
Conditions Used	Under which conditions will an optional data attribute be populated? For instance, the shipment date would be populated only when the shipment is made.	Logical Data Model
Edit Rules	What rules determine whether an entry is valid? It may be a formula, range of characters, or a list of valid values.	Logical Data Model
Default Value	This is the standard value that should be entered if no information is provided at the stage that an entity occurrence.	Logical Data Model
Derived?	Does this data attribute represent a lowest common denominator data value or is it derivable from one or more atomic data attributes?	Logical Data Model
Derivation Rules	For derived data attributes, how is this data attribute derived?	Logical Data Model
Processing Rules	What business rules govern the adding, updating, and deletion of information in this data attribute? For instance, if the shipment date is entered, the shipment data entity may need to be added and an invoice may need to be generated.	Logical Data Model
CRUD Actor(s)	What business role(s) creates, retrieves, updates, and deletes (CRUD) this data attribute?	Required for Database Design (Logical Data Model)
Archiving Rules	How long will information be kept, and how should the history be handled?	Required for Database Design (Logical Data Model)
Data-Content Quality Rules	What domain rules and valid value sets should apply?	Required for Database Design (Logical Data Model)
Data-Presentation Quality Rules	The data-presentation quality that should apply to information bearing documents and media such as reports or screens presenting the results of queries from data to database.	Required for Database Design (Logical Data Model)
Data-Residency Business Rules	How long should data reside in the various levels of storage (e.g., operational data store, data warehouse, or archive)?	Required for Database Design (Logical Data Model)
Privacy Indicator	Indicates the privacy component that should be invoked.	Required for Database Design (Logical Data Model)
Privacy Rules	What privacy rules govern the adding, accessing, or updating of this data attribute?	Required for Database Design (Logical Data Model)
Encryption Indicator	Indicates whether an encryption component should be used.	Required for Database Design (Logical Data Model)
Encryption Rules	What encryption rules govern?	Required for Database Design (Logical Data Model)
Security Rules	What security rules govern the adding, accessing, and updating of this data attribute?	Required for Database Design (Logical Data Model)
Data Source	What system or existing database will be used to populate this data attribute?	Required for Database Design (Logical Data Model)
Availability Requirements	What, if any, are the special rules governing the availability of these data?	Required for Database Design (Logical Data Model)
Refreshment Timing	How often should this data attribute be refreshed?	Required for Database Design (Logical Data Model)
Abbreviated Name	What acceptable abbreviation can be used on a screen or report?	Needed for prototyping

The following “For Each Data Relationship” table shows metadata attributes for each class or data relationship shown in the various data models.

	For Each Data Relationship
Type of Information	Description of Information	When Needed
Data Relationship Name	How is the data relationship to be referred to?	All Data Relationships must be included in the Conceptual Data Model
Data Entities Related	How do the two data entities relate to each other?	Conceptual Data Model
Nature of the Relationship	What is the business purpose of each side of the relationship? For example, “A customer places a customer order.”	Conceptual Data Model
Expected Cardinality	How many times will each side of the relationship occur? For instance, a customer is expected to place 200 customer orders a year, but a given customer order may be placed by one and only one customer.	Conceptual Data Model
Maximum Cardinality	What is the maximum number of times each side of the relationship may occur? For instance, a customer may place 1,200 customer orders during the busiest year.	Logical Data Model
Insert Referential Integrity Rule	What is the impact on the related data entity when a new instance of the data entity is added? For instance, a customer order may not be added unless the customer who placed the order exists in the system. A new customer may be added even though there are no customer orders to be added. The referential integrity rules will use both business terminology and data modeling terminology.	Logical Data Model
Delete Referential Integrity Rule	What is the impact on the related data entity when a new instance of the data entity is deleted? For instance, a customer order may be deleted independent of the customer who placed the order. A customer may not be deleted if there are still outstanding customer orders in the system. If a customer order is deleted, all order line items are also deleted. The referential integrity rules will use both business terminology and data-modeling terminology.	Logical Data Model
Relationship Constraint Rule	Is there any business rule that impacts or constrains the relationship?	Logical Data Model