Work Product (Artifact): Operation

This artifact represents a 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.

Purpose

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

Relationships

Container Artifact	Design Model
Roles	Responsible: Capsule Designer Designer	Modified By: Designer
Input To	Mandatory: Operation Design	Optional: None	External: None
Output From	Operation Design

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 Use Cases that this operation supports.
- The context in which the operation is used (i.e. a particular Use Case) may be not be captured (e.g. it may be specified in terms of supporting the minimum performance requirement when all Use Cases are considered)
Pre-conditions
Post-conditions
Superordinate system traceability
Optional: use-case (steps) traceability

In most of the cases, the Operations are defined for the system under development 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:

Architects will describe the main services supported by the architecturally significant elements.
Analysts will work with the Architects for mapping the use-case steps into the system's operations.
Designers will use them as inputs during the refinement and refactoring stages, the operations being the building blocks for the Interface Design Specifications.
Testers will derive their test cases based on the specified operations.
Managers will use them as a basis for phase and iteration planning.

Properties

Optional
Planned

Key Considerations

The 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 use-case steps have been established
proper coverage of the 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 system and its main subsystems. Usually the starting point are the system use cases, so there is an assumption that operations will be used in conjunction with use cases.

The main tailoring decisions are:

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

If Interface Design Specifications need to be produced, the level of detail and formalism for the operations which will be part of these specification will increase to the point where the resulted artifacts could be used for implementation and testing.