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: 
Examples: 
     
UML Representation:  Class, stereotyped as <<business worker>>.
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

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 To top of page

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 To top of page

Business workers are initially identified during the Inception phase and refined and detailed during the Elaboration phase.

Responsibility To top of page

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 To top of page

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.



Rational Unified Process   2003.06.13