Artifact: Business Operation
A business service that can be requested from an object to effect behavior. An operation specifies the name, type, parameters, and constraints for invoking an associated behavior.
Work Product Kinds: Model Element
Purpose

The primary purpose of the Operations is to capture the provided and required business services that an element supports or needs.

Relationships
Description
Main Description

An operation specification has the following outline:

  • Description
  • Input/Output Parameters
  • Non-functional requirements:
    • These are derived from the non-functional requirements associated with the steps in the various Business Use Cases that this operation supports.
    • The context in which the operation is used (i.e. a particular Business Use Case) may be not be captured (e.g. it may be specified in terms of supporting the minimum performance requirement when all Business Use Cases are considered)
  • Pre-conditions
  • Post-conditions
  • Superordinate system traceability
  • Optional: business use-case (steps) traceability

In most of the cases, the Operations are defined for the business system and the main subsystems, going with the decomposition as deep as needed, in a recursive fashion. The Operations are grouped around interfaces along the main responsibilities of the (sub)system under consideration.

Depending on the granularity level and the usage context, different roles specify, define, refine or use operations as main inputs for their associated tasks:

  • Business Architects will describe the main services supported by the architecturally significant elements.
  • Business Analysts will work with the Business Architects for mapping the business use-case steps into the system's operations.
  • Business Designers will use them as inputs during the refinement and refactoring stages, the operations being the building blocks for the Interface/Contract Specifications.
Key Considerations
The Business Designer is responsible for the integrity of the operation set, ensuring that:
  • the operations are unique and there is no overlap between them
  • the related operations are logically grouped around interfaces
  • each operation is properly documented
  • the traceability relationships to other operations and/or business use-case steps have been established
  • proper coverage of the business use cases or system's operations, based on the scope of the current iteration
Tailoring
Representation Options

The operation-based approach is a more formal, rigorous way of defining the services supported by the business system and its main subsystems. Usually the starting point are the business use cases, so there is an assumption that operations will be used in conjunction with business use cases.

The main tailoring decisions are:

  • describe only architectural significant operations (those which relate to the most important business use cases)?
  • how "deep" the subsystem logical decomposition should go?
  • fully describe pre-conditions and post-conditions?
  • need to maintain traceability between operations and business system operations and/or business use cases?