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):

Field name Description
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.

Acknowledgement: Inclusion of Non-functional requirements and Project Issues fields in the template is one of the suggested options in Volère2 and a recommended practice in EMPRESS3.