When writing the acceptance criteria for a requirement it is important to consider all functional aspects of the target application. This BLOG describes a model of a common business application and each of the components that should be considered when producing the acceptance criteria.
Typically, these component types include:
- Transactions/Use Cases – Description of interactions between an actor(or third party application) and the application.
- Transaction/Use Case step – Step within the transaction typically carried out either by an actor(or third party application) or a responsive action performed by the application.
- Batch – A set of actions performed by the application on a selection of transactions at a scheduled interval.
- Form – Data entry form used by the actor to
interact with the application. This can be windows based, a web page or even a device
application page. These may include:
- Fields – Data entry/display field within a form. This will typically map to an entity attribute.
- Tables – Structure made of rows and columns typically used to display multiple data records in a form
- Links – Link to another URL (this can be either internal or external) within a form
- Action buttons – Button in the form that precipitates an action
- Content – Chart or graphic included in a form. These can either be static or dynamic.
- Attribute – Data item that describes an entity. This can either be entered by an actor in a form, received from another application through an interface or derived by a calculation.
- Entity – Logical entity within the application. Typically part of a transaction. For instance a Quote as part of a New Business Insurance Transaction.
- Entity Relationship – Relationship between two entities such as a Customer can have many quotes.
- Configuration Data – Data used to configure behaviour within the application or used as an input to calculations to derive attributes for an entity.
- Action – A set of processes that the application
will perform in response to an input request. An action will also have input
variables and output variables. An
action consists of the following components:
- Action Step – An individual step within an action. This can be another action as well as a trigger to other process types such as sending an email, generating a document or calling an API for a third party through an interface/service request.
- Interactions with the data model to save and retrieve data.
- Email – Electronic mail generated and sent by the application
- Document – Document generated by the application. Can be stored, printed, attached to an email or included in an output file to a third party for printing etc..
- Message – SMS/MMS sent to a mobile phone number.
- Report – Output from the application in a structured format (see table).
- Service/Interface – Interface to a third party application.
- Search – Criteria for determining which components or transactions are returned.
- API – Input to the application from another third party application.
Each of these components have attributes that determine their behaviours. Subsequent BLOGS will describe the questions that determine the behaviours of the components that between them define the behaviours of the application.