Example: mapping table (in E-Parliament Tagger debategraph).


These fields are included in the template to describe a (Product) Use Case ((P)UC) which a service solution (product or application component) is expected to provide:

Field name Description
PUC Name The name of the (Product) Use Case
Actors/usage The users or business services that are being served by the product use case
Preconditions What conditions must be satisfied for this PUC to be executed?
Postconditions Successful the state after the successful execution of the PUC; and Alternative possible other states after the PUC completes.
Workflow-basic The expected or normal flow of application events (and application data). This flow could be described as a application process.
Alternative Workflows The possible alternative flows of events.
Business rules
Application objects The data objects that are being used or created by the PUC.
Non-functional requirements List known or expected properties of the use case that matter to non-functional requirements and are specific and important for this PUC. Tag these properties with the relevant type of non-functional requirement. Example: if a PUC is typically performed hundred times an hour, then this is relevant to the NFR 12f : Performance requirements / Capacity.
Project Issues List project issues that are specific and important for this PUC, tag them as one or more of the listed types of project issues. Example: if the PUC is currently supported by an application X, then this is relevant as a project issue of type PI 22 : Migration to the New Product.

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



Other sub-sections under Requirements templates and patterns


Questions, answers and comments

Add a New Comment

FAQ