Activity:
|
Purpose
|
|
Role: Business Designer | |
Frequency: As required, typically occurring multiple times in an iteration, and most frequently in early iterations. | |
Steps | |
Input Artifacts: | Resulting Artifacts: |
Tool Mentors: | |
More Information:
|
Workflow Details: |
For each role (human or system) in the organization, identify a business worker and give it a brief description. Employment positions are a good place to start, but be aware that a person in a specific position is usually required to fulfill more than one role and that various roles are often filled by people in different positions. You can also look at the software systems currently being used. However, you must be aware that-like people-many software systems perform multiple roles within the organization. This integration of sometimes completely different roles is one of the factors that makes software maintenance so difficult and locks a business in to a system.
After you have identified your business workers, walk through each business use case and state which business workers are involved in which steps. This ensures that no business workers have been missed and that the ones that you have listed are all "inside" the part of the business you are modeling.
For more information on business workers, see Guidelines: Business Worker.
To find candidate business entities, consider what information each business worker handles. The information that must be queried, validated, created, or communicated is a good starting point. Only significant, persistent information should be considered as a business entity.
To show how business entities need to "know about" one another, use associations (see Guidelines: Associations in the Business Analysis Model). Give the associations role names for clarification.
If business entities have clear whole-part relationships, show that fact with aggregation-relationships (see Guidelines: Aggregations in the Business Analysis Model).
If business entities are specializations or generalizations of one another, use generalization-relationships to show this (see Guidelines: Generalizations in the Business Analysis Model). It is often wise to wait to establish generalizations until after you have worked on describing the business entities (see Activity: Detail a Business Entity).
Document the relationships in class diagrams (see Guidelines: Class Diagram in the Business Analysis Model).
Walk through the workflow of each business use case to ensure that no business entities have been forgotten. Also, make sure that the ones you have identified are actually participating in a workflow.
For more information on business entities, see Guidelines: Business Entity.
Inspect the interactions between business actors, business workers, and business entities. Business actors may initiate a business use case by sending a business event. Business workers may send business events to business actors or to each other. If a message between two business workers has one of the following characteristics, it might be a business event:
Business events may also be used to send signals between business systems and business use cases.
For more information on business events, see Guidelines: Business Event.
For each business use case, create a Business Use-Case Realization in the Business Analysis Model. The name of the Business Use-case Realization must be the same as the associated business use case. Furthermore, a realization-relationship should be established from the business use case realization to its associated business use case.
Identify which business workers and business entities participate in the execution of each business use case. They form the business use-case realization of the business use case.
Present the business workers and business entities of the business use-case realization in a sequence diagram (see Guidelines: Sequence Diagram in the Business Analysis Model). Show only those interactions that are necessary an understanding of how the business workers and entities perform this business use-case realization workflow. There should be at least one interaction (sequence diagram) for every flow described in the business use case.
Instead of using a sequence diagram, you can present the participating business workers and business entities in a communication diagram (see Guidelines: Communication Diagram in the Business Analysis Model). Sequence diagrams are superior for large and complex interactions, while communication diagrams provide a better overview of relationships between participants.
To clarify the meaning of the communication diagrams, you can describe the workflow of each business use-case realization in terms of its elements-the interacting business workers handling business entities. This is optional, and it only adds value for more complex workflows or parts of workflows. To perform this activity:
For more information on business use-case realizations, see Guidelines: Business Use Case Realization.
Analyze the lifecycle of each business entity. Each one should be created and removed by someone during the life of a business. Make sure that each business entity is accessed and used by a business worker or another business entity. Do this by creating a matrix or generating a report showing which business workers create and use the business entities.
Reduce the number of workers. As you develop your models, it is likely that you will find one or more too many workers per use-case realization. Make sure that each business worker corresponds to a set of tasks that one person typically would do, even though those tasks are divided among more than one business use case. You can do this by deriving and examining the responsibilities required of the business worker from all business use-case realizations in which the business worker participates.
Each business entity should have an owner-that is, someone who is responsible for it. You can model this with an association from the business worker to the business entities for which the business worker is responsible. Some business entities might be owned by people outside the business. If that is the case, make sure that it is mentioned in the brief description of the business entity.
For very large or complex business models, you can use Business Systems for structuring and partitioning. In this case, you can assign business workers, business entities, and business events to a business system. Make sure that the relationships and responsibilities defined by the business systems support the interactions between the business workers, entities, and events. If necessary, the business systems must be slightly adjusted (in consultation with the business process analyst), or the interactions must be refined.
For guidelines on structuring the Business Analysis Model and naming business workers and business entities, see Guidelines: Business Analysis Model.
Evaluate the business use-case realization workflow, along with the text and diagrams documenting it. One way to do this is to conduct a walkthrough. In this method of evaluation, the person responsible for the business use-case realization leads some of the members of the team through the business use-case realization workflow. Another technique is to do role-playing, in which team members act as business actors, business workers, and business entities.
See also checkpoints for Business Analysis Model and Business Use-Case Realizations in Activity: Review Business Analysis Model.
This content developed or partially developed by Empulsys BV. |
Rational Unified Process |