Artifact: Business Worker
| A business worker is an abstraction of a human or software system that represents a role performed within business use case realizations. A business worker collaborates with other business workers, is notified of business events and manipulates business entities to perform its responsibilities. | |
| Other Relationships: | Part Of Business Analysis Model |
| Role: | Business Designer |
| Optionality/Occurrence: | Can be excluded. Business workers must be modeled if changes to the organization need to be considered. |
| Templates and Reports: | - Report: Business Worker |
| Examples: | |
| UML Representation: | Class, stereotyped as <<business worker>>. |
| More Information: | - Guideline: Business Worker - Checklist: Business Worker - Report: Business Worker |
| Input to Activities: - Detail a Business Worker - Review the Business Analysis Model | Output from Activities: - Detail a Business Worker - Find Business Workers and Entities |
Purpose
A business worker is used to represent the role that a human or software system will play within the organization. This abstraction allows us to identify potential improvements in business processes and consider the effect of business process automation or business process outsourcing.
Stakeholders use business workers to confirm that the responsibilities and interactions of the business worker correctly reflect how work is performed, or should be performed. Business workers are also used for considering the impact of changes to the organization (such as business process automation). A business designer describes the workflow details (realizations) of each business use case using business workers. Business workers are also useful for systems analysts when identifying software system actors and use cases and deriving software requirements.
Properties
| Property Name | Brief Description | UML Representation |
|---|---|---|
| Name | The name of the business worker. | The attribute “Name” on model element. |
| Brief Description | A brief description of the role and purpose of the business worker. | Tagged value, of type “short text”. |
| Responsibilities | A survey of the responsibilities defined by the business worker. This may include the business worker’s lifecycle. | A (predefined) tagged value on the superclass “Type”. |
| Relationships | The relationships, such as generalizations, associations, and aggregations, in which the business worker participates. | Owned by an enclosing package, via the aggregation “owns”. |
| Operations | The operations defined by the business worker. | Owned by the superclass “Type” via the aggregation “members”. |
| Attributes | The attributes defined by the business worker. | Owned by the superclass “Type” via the aggregation “members”. Some attributes could be stereotyped <<skilltype>>. |
| Characteristics | Used primarily for human business workers: The physical environment of the business worker, the number of individuals the business worker represents, the business worker’s level of domain knowledge, the business worker’s level of computer experience, other applications the business worker is using, and other general characteristics such as gender, age, cultural background, etc. | Tagged value, of type “formatted text”. |
| Diagrams | Any diagrams local to the business worker, such as interaction diagrams or statechart diagrams. | Owned by an enclosing package, via the aggregation “owns”. |
Timing
Business workers are initially identified during the Inception phase and refined and detailed during the Elaboration phase.
Responsibility
A business designer is responsible for the integrity of the business worker, ensuring that:
- The name and brief description are explanatory.
- The responsibilities are correctly described.
- The business worker has the appropriate relationships, attributes, and operations defined to fulfill its responsibilities.
Tailoring
If you only intend to model the way the business use case realizations are currently performed, you can use business workers to represent the positions and software systems within the organization. In this case, you could use the stereotype name <<worker>> and <<system>> to represent humans and software systems instead.