- The requirement attributes are likely to differ somewhat between classes, making that you might want to use different templates,
- A service taxonomy supports a proper positioning of services in the application and technical architecture,
- A service taxonomy supports a proper layering of services.
First of all the following (more or less atomic) classes of services can be distinguished:
Business Services that are recognized as such by the business, like Retrieve Customer Profile, Print Order Confirmation.
Data Services that query or store data, like Retrieve Customer, Retrieve Customer Orders, Update Order.
Application Services, being all other services, like Print File and other 'utility' services.
The above classes concern atomic services, meaning that the services have a restricted, clear responsibility and therefore in principle are re-usable. When used in the context of use cases (or business processes) they typically will not cross steps.
Whenever applicable, you can also recognize Process Services as being the type of services that deal with service orchestration. Process services typically have a specific use case / business process as a scope. That use case can be a user-goal or summary use case (spanning multiple lower level use cases).
Batch Services are a specific kind of orchestration services that process multi-record messages in an asynchronous way.
Other Taxonomy Aspects
Your taxonomy can leverage more than one kind of classification, for example one that organizes business and process services by business domain.
Also different levels of services could be distinguished. This is where we talk about service granularity. For example, a higher level data service Retrieve Customer Data can consist of two lower level services Retrieve Customer and Retrieve Customer Address. The level of a service won't have much impact on the way you specify it functionally though. Also, specifying finer grained services is more likely to be the subject of analysis and design rather than requirements definition. The discussion about service granularity for requirements definition is likely to be that of user-goal versus summary use cases.
Be aware that the taxonomy you use during requirements does not necessarily need to be 1:1 with the one that is used for analysis and design. The meta-requirement for the taxonomy used during the requirements definition, is that it should be recognizable by business people. There should be a clear mapping to the taxonomy that you will use during analysis and design, though.
Generic Requirement Attributes
The requirement attributes of all service could consist of the following:
- purpose (one, two sentences max)
- description (what does it functionally, i.e. without getting technical)
- type (within the taxonomy)
- triggering events
- synchronous/asynchronous (request/response vs fire & forget)
- message format in
- message format out
- list of values (for attributes where applicable)
- validation of incoming message
- list of (logical) errors that can be the result
- business indicators (e.g. to collect BAM metrics)
- consumer has been authenticated and authorized to use the service
- message format in complies to the XSD, meaning failing to do so will result in technical error
- attribute names
- data type
- format mask
Transformations typically are captured using a two-column-format, one column describing the "query" (just one source attribute, or multiple attributes with some operations), the other the target attribute.
The validations to specify concern checks that are not considered to be part of the pre-conditions.
Metrics can have the following sub-attributes:
- average calls/per time unit
- peak volumes
- max response time
In case of Data Services also the following attributes can be applicable:
- data source (name of the database, or other)
- a (restricted) data model
- key attributes
- (logical) query, insert or update statement
Application and Batch Services typically also can have the following attribute:
Process Services also have a process orchestration that is described using an activity diagram (preferable using the BMPN notation) or a sequence diagram. Process Services often have a human interaction being involved.
Generic Supplemental Requirements
In case of asynchronous services you are likely to have a need for an "error hospital". Preferably you have some generic mechanism for that. For each individual service you then only need to specify how long and with what frequency a retry needs to be done, before it will end up in the error hospital. The requirements for the error hospital itself will be generic, describing how a systems or application administrator can cancel or retry the service (when possible).
Other generic supplemental requirements might concern:
- audit requirements