Proposed refinements on features doc regarding Activity state modeland status reporting

[Johannes Lehtinen <johannes.lehtinen@rossum.fi>]

Hello!

Here are proposed refinements on features doc regarding Activity state model and status reporting (on both Activity and Work Request level).

These are based on the latest version of Israel's proposed changes at:
 http://www.oasis-open.org/committees/download.php/43229/FFMII-BusinessUseCasesFeaturesREQ-v1.0-wd01-07252011%20following%20discussion%20of%2016-Aug-11.docx



6.2.2.3 Support for dynamically specified workflow on Activity level


Extend first paragraph:

FFMII interface shall support definition of dynamically specified

workflow
on Activity level. ERMS specifies the States and Steps of an Activity
as well as the available transitions between the Steps dynamically as
part of the structural definition of a Work Request. A different state
model can be specified for each Activity, typically depending on the
type of the Activity or the containing Work Request. The specified
state model also forms the basis for tracking the status of Activities.


Add new paragraph after first one:

Each dynamically specified State is explicitly associated with one of the predefined Status Categories,
indicating the overall status of the Activity from Assignee perspective
when in the particular State. Status Category does not affect state
model execution but may be used by the Implementation for, for example,
visualization purposes. Status Categories are described in Section
6.2.4.2.



Note
5 (about dependencies) should be moved to 6.2.2.4 Work Request state
constraints which intends to cover different kind of validity
constraints on Work Request state, including dependencies between
Activities.




6.2.4.2 Work Request status reporting and Activity status reporting


Proposed revised title: “Work Request status evaluation and reporting”


Proposed revised text below as is:



FFMII
Interface shall include a concept of overall Work Request status
complementing the detailed Work Request history as discussed in Section
6.2.4.1.


Work
Request status shall be derived from the current state of underlying
Activities using a fixed set of rules and can therefore be consistently
evaluated by both Manager and Implementation. The status information
shall be exposed to Manager for retrieval and filtering purposes. Same
information may also be leveraged by Implementation for, for example,
visualization purposes.


The overall Work Request status is described using Status Categories. The same Status Categories are also used on Activity level.


The following Status Categories shall be used:

• New (i.e. Assignee has not started working yet)
• Active (i.e. Assignee is actively pursuing the work in question)
• Inactive (i.e. Assignee has started work but is not actively working now)
• Closed (i.e. work is of no relevance to Assignee anymore)

NOTE:
The overall Work Request status on FFMII level does not necessarily
have to be the same as the status value shown to users of the related
systems. For example, the Manager may maintain much more fine grained
status based on the work history.


FFMII
specification shall also define a set of predefined more detailed
Status values, each of which belongs to one Status Category. The
detailed Status values may be optionally used in the workflow
specification to give a more detailed generic classification of a
particular Activity State or Work Request closing state.



Rationale: 

In
some use cases it may be sufficient for the Manager to act solely based
on the high level status of the Work Request.  For example, waste
collection task may only involve acknowledgement of completion.
Furthermore, even if full Work Request history is used for reporting
purposes, the high level status may be sufficient to trigger related
business process and tasks flows on ERMS level.


Additionally,
it is also important to establish a common, consistent understanding
between Manager and Implementation about the current overall state of a
Work Request and the contained Activities to avoid misunderstandings
between parties responsible for work planning and delivery. This
requires a set of common predefined high level Status Categories,
layered on top of the detailed dynamically specified Activity state
model. Predefined vocabulary is also needed to be able to specify fixed
set of rules for determining overall Work Request status.



[Note
for reviewers: I do not have strong opinions on what the predefined
Status values would be as long as they are commonly understood and
domain agnostic. However, I think this level of detail should
preferably go directly to actual specification and not in requirements
doc.]



BR, Johannes

-- 
Johannes Lehtinen
gsm +358 40 734 7049
Rossum Oy