| 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.
|
