When new requirements are introduced they take the following generic form

When new requirements are introduced they take the

This preview shows page 78 - 79 out of 100 pages.

contains requirements specific to a YAWL engine component. When new requirements are introduced, they take the following generic form comprised of three parts. Firstly, a requirement reference code of the form REQ-### . Secondly, a short text description in italics, and finally, a deeper discussion of the requirement is supplied in the paragraph immediately following. Below is an example: REQ-000 : This is an example requirement comprised of a reference code and description Following each requirement is a detailed discussion of the motivations that go into forming the requirement. The requirements identified in this document are to ensure that participants interact with the work items offered by YAWL as intended by the newYAWL technical report. The requirements are described in an im- plementation independent manner, allowing differing implementations of YAWL to support the requirements identified as best suits each implementation. Each requirement is classified as either core or non-core . The distinction can be rather arbitrary at times. The guiding heutistic for deciding whether a requirement is core or not is whether the requirement supplies necessary support for the concept of interaction points and their ability to be system or user initiated, described later. Non-core requirements can take advantage of this concept but do not necessarilly add to the fundamental behaviour of interaction points. At times, this rule has been broken if it was felt by the author that classifying a requirement as non-core would make a system, constructed to only core requirements too limiting to its users. B.2.1 Workflow Designer Requirements In YAWL, atomic tasks and multiple-atomic tasks both represent potential interaction points with workflow participants. If these tasks are allocated a “worklist handler decomposition” at design-time, runtime-instances of these tasks will cause the appropriate worklist handler to offer participants work items where they can receive work data and check new data back into the workflow system. For atomic tasks, there is one work item per task instance. For multiple-atomic tasks, there are a number of work items per multiple-atomic task instance. A graphical summary of requirements for a YAWL design tool supporting the newYAWL resource perspective is supplied in figure B.1. The requirements are laid out in a hierarchical mind-map. Colour coding is used to isolate a group of requirements that could all belong to the same page of a wizard walk-through type screen that workflow designers could use to construct a complete resourcing definition for a task. If a group of one colour exists closer to the root of the tree, requirements from that group will be needed as prerequisites to requirement groups that appear further out. The requirements listed in figure B.1, along with related design-time requirements are described in further detail next.
Image of page 78
Image of page 79

You've reached the end of your free preview.

Want to read all 100 pages?

  • Spring '17
  • Sui
  • yawl

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

Stuck? We have tutors online 24/7 who can help you get unstuck.
A+ icon
Ask Expert Tutors You can ask You can ask You can ask (will expire )
Answers in as fast as 15 minutes