# How to Build Task Models

You can build a task model by hand, or using a task model editor, such as TAMOT. The TAMOT editor will allow you to create and manipulate the different elements that constitute the task model.

# Task and its decomposition (or description/definition/realisation/etc.)

A task is defined by its goal (expressed by the name given to the task) and the procedure to reach this goal (detailed in the decomposition associated to the task). Tasks are decomposed until you reach the level of elementary tasks, i.e. tasks that will not be decomposed further. Examples of elementary task is button clicks.

When you describe an application, look for verbs and their objects in your description: they identify the tasks and the order these tasks follow.

# Links between Tasks

The order of tasks is either important or not.

- if it is not, the tasks are said to be parallel (ie no link between them) and the task model will show no link (arrow) between them.

- if it is important, when describing the task, the ordering of the actions (or sub-level tasks) will be like : do T1, THEN T2 - the actions will then be linked by arrows that will express the sequence.

- do EITHER T1 OR T2 - the actions will then be linked by the boolean connector XOR
- do T1 OR/AND do T2 - the actions will then be linked by boolean connectors OR or AND

# Style of tasks

Manual task: task that happen with no interaction with the system under consideration

Interactive task: task that requires interaction between the end-user and the system under consideration

Automatic task: task that are solely executed by the system under consideration.

# Feedback on a task

A feedback is a response from the system to an action from the user.

Often automatic tasks can be either represented as an automatic task, or as a feedback.

# Optional versus mandatory tasks

Ideally, applications would only have optional tasks.

In some cases, like for example for security reasons, some identification/confirmation tasks are required, and the system won't go any further until these tasks are done. These will be mandatory tasks.

# Cardinality

The cardinality of a task is the minimum and maximum number of times the task can be executed. By default, the cardinality on a task is [0 , ∞) for optional task and [1 , ∞) for mandatory tasks.

# Pre-condition to a task and condition on a link between tasks

A pre-condition associated to a task must be true for this task to become available, and in the same way, a condition on a link must be true for this link to be followed.

# Terminal event associated to a task

A terminal event associated to a task means that the execution of the task in question implies the normal ending of the current decomposition.

# Comment associated to a task

Comments associated to a particular task are free text. Sometimes, the name of the task and its various attributes is not enough to define the behaviour, or characteristics of the task. In these cases, the comment are there to elaborate, provide algorithms, or just highlight some warning.

# How many high level tasks ?

Ask yourself the question : “What can you do with the application?”

Answer as briefly as you can.

This will give you the high level tasks, and the way they are linked.

# How many levels in the hierarchy of tasks?

For each task that you extract, ask : “How do you do / perform / realise this task ?”

and again, answer as briefly as you can.

This will give you the set of tasks that define the task you're examining. Keep refining and stop at the level you want.

Back to Contents