Artifact: Use-Case Model
|
| The use-case model is a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers. The use-case model is used as an essential input to activities in analysis, design, and test. |
|---|---|
| Other Relationships: |
Contains
|
| Role: | System Analyst |
| Optionality/Occurrence: | Required |
| Templates and Reports: |
|
| Examples: |
|
| UML Representation: | Model, stereotyped as <<use-case model>> |
| More Information: |
|
|
|
Purpose
The following people use the use-case model:
- The customer approves the use-case model. When you have that approval, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development.
- Potential users use the use-case model to better understand the system.
- The software architect uses the use-case model to identify architecturally significant functionality.
- Designers use the use-case model to get a system overview. When you refine the system, for example, you need documentation on the use-case model to aid that work.
- The manager uses the use-case model to plan and follow up the use-case modeling and also the subsequent design.
- People outside the project but within the organization, executives, and steering committees, use the use-case model to get an insight into what has been done.
- People review the use-case model to give appropriate feedback to developers on a regular basis.
- Designers use the use-case model as a basis for their work.
- Testers use the use-case model to plan testing activities (use-case and integration testing) as early as possible.
- Those who will develop the next version of the system use the use-case model to understand how the existing version works.
- Documentation writers use the use cases as a basis for writing the system's user guides.
Properties
| Property Name | Brief Description | UML Representation |
|---|---|---|
| Introduction | A textual description that serves as a brief introduction to the model. | Tagged value, of type "short text". |
| Survey Description | A textual description that contains information not reflected by the rest of
the use-case model, including: · Typical sequences in which the use cases are employed by users. · Functionality not handled by the use-case model. | Tagged value, of type "formatted text". |
| Use-Case Packages | The packages in the model, representing a hierarchy. | Owned via the association "represents", or recursively via the aggregation "owns". |
| Use Cases | The use cases in the model, owned by the packages. | Owned recursively via the aggregation "owns". |
| Actors | The actors in the model, owned by the packages. | - " - |
| Relationships | The relationships in the model, owned by the packages | - " - |
| Diagrams | The diagrams in the model, owned by the packages. | - " - |
| Use-Case View | The use-case view of the model, which is an architectural view showing the significant use-cases and/or scenarios. | - " - |
Timing
The use-case model primarily sets the functional requirements on the system, and is used as an essential input to analysis and architectural design. It can be used early in the inception phase to outline the scope of the system, as well as during the elaboration phase. The use-case model is refined by more detailed flows of events during the construction phase. The use-case model is continuously kept consistent with the design model.
Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle.
Responsibility
A System Analyst is responsible for the integrity of the use-case model, and ensures that the use-case model as a whole is correct, consistent, and readable. However, the use-case model contains elements that play an important role in the architectural view (as captured in the use-case view) of the system model, and as such architect has governing responsibility for the integrity of those elements. For more information, refer to Role: Software Architect.
Note that details of use-case packages, use cases, actors, relationships, and diagrams are the responsibilities of the corresponding requirements specifier. For more information, refer to Role: Requirements Specifier.
Tailoring
Tailor to support project needs. This may include including only a subset of the sub-artifacts (properties), tailoring the level of formality in which the sub-artifacts are created and managed, and tailoring of the individual sub-artifacts.
