Examples of use:
These fields are included in the template to describe an (existing) collaborative application (component, service product) or a new one for which the requirements are being gathered and analysed (information actant, service solution, application):
|Name||The name(s) of the application (component)|
|Class (and Tier)||Interfacing technology within one of: operational work area (OWA), containing business environment (CBE), or wider environment (WE). It is a software, hardware or mechanical — that must have a defined interface with the solution. Depending on the architectural style used1, it is recommended to position an application component at one of the tiers.|
|Interfaces||Which application interfaces does the application provide|
|Services||Which application services does the application provide?|
|Data||Which data objects does the application (component) exchange with collaborating applications and store?|
|Non-functional requirements||List non-functional requirements that are specific and important for the application, tag them as one or more of the listed types of non-functional requirements|
|Project Issues||List project issues that are specific and important for the application, tag them as one or more of the listed types of project issues|
The availability of an enterprise architecture - preferably as part of an enterprise repository - will impact the amount of work that must be invested in describing both existing applications and applications that must be designed and developed.
In an enterprise architecture described in accordance with the ArchiMate framework: application component descriptions are included in the application layer. The rationale for their inclusion in a requirements engineering initiative will often be related to their role in Application collaborations among application components.