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.
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.
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.
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.
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.
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.
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.
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.
A terminal event associated to a task means that the execution of the task in question implies the normal ending of the current decomposition.
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.
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.
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.