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.
You have full access to this open access chapter, Download chapter PDF
Keywords
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.”Footnote 1 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 Footnote 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 |
Notes
- 1.
I. Jacobsen, Software Engineering. Addison-Wesley, 1992, p. 159.
- 2.
See Chapter 5 for the explanation of this content.
Author information
Authors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (http://creativecommons.org/licenses/by-nc-nd/4.0/), which permits any noncommercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this chapter or parts of it.
The images or other third party material in this chapter are included in the chapter’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2014 Michelle Finneran Dennedy
About this chapter
Cite this chapter
Dennedy, M.F., Fox, J., Finneran, T.R. (2014). Use-Case Metadata. In: The Privacy Engineer’s Manifesto. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4302-6356-2_15
Download citation
DOI: https://doi.org/10.1007/978-1-4302-6356-2_15
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4302-6355-5
Online ISBN: 978-1-4302-6356-2
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)