[Pgi-wg] OGF PGI Requirements - Flexibility and clarity versus Rigidity and confusion

[Etienne URBAH]

Balazs, Morris, Luigi, Johannes and all,


Concerning the capture and discussion of the requirements :


I think that the main problem is NOT the large number of requirements, 
but the fact that many original requirements were formulated in a very 
confusing manner.

In particular, many original requirements simultaneously present :
A) mainly, the WAY the Execution Service would perform a desired 
functionality,
B) sometimes, the INTERFACE which a Client would use to access this 
functionality,
C) implicitly, the NEED for this functionality.

This causes us to lose much time in useless discussions, because this 
requires to use following process :
-  First, focus on C) to precisely define the functionality, and assess 
its usefulness,
-  Second, focus on B) to define the Client interface,
-  Third, verify that there is no garbage from A) left anymore.

Working on the original explicit, implicit or hidden requirements found 
inside the documents, this is exactly the process which I personally 
followed, splitting complex confusing requirements into simpler and 
clearer ones.
This permitted that requirements which I personally wrote down could be 
often quickly understood, discussed, and even sometimes quickly labeled 
YES (positively agreed) or NO (No agreement yet).


For the many requirements which are still unclear, I therefore urge you 
to accept that I split them into simpler smaller requirements :

-  Apparently, it will increase the total number of requirements,

-  But in fact, after an easy work, that will increase the percentage of 
requirements labeled YES and diminish the percentage of requirements 
labeled UNCLEAR.


As example, please study following requirement, labeled 'Still UNCLEAR 
after 10 mn discussion' :

-  JD20  (115)  Job Description document should offer a new re-usable 
structure to define 'scalabletime' requests optionally depending on 
benchmark results.


I will split it into the 4 following requirements :


-  Description of the needed functionality :

    JD20.1  For 'Wall clock time' and 'CPU time' limits, the Execution 
Service SHOULD accept Client requirements independently of the speed of 
the Computing Resource on which the Activity will run


-  Description of the conceptual Client interface :

    JD20.2  For 'Wall clock time' and 'CPU time' limits, the Job 
Description document SHOULD offer a new re-usable structure permitting 
to describe requirements independently of the speed of the Computing 
Resource on which the Activity will run


-  First option for a precise description of the Client interface :

    JD20.3  For 'Wall clock time' and 'CPU time' limits, the re-usable 
structure permitting to describe requirements independently of the speed 
of the computing resource on which the Activity will run SHOULD be the 
ordered pair (Value, Unit) where :
    - 'Value' is the max number of operations allowed for the Activity,
    - 'Unit'  is as unit suitable for a total number of operations, from 
a closed list to be refined (such as 'Specint2006 * hours' or 'Billions 
of floating point operations')
    This method is already used by BOINC and has proved it robustness.


-  Second option for a precise description of the Client interface :

    JD20.4  For 'Wall clock time' and 'CPU time' limits, the re-usable 
structure permitting to describe requirements independently of the speed 
of the computing resource on which the Activity will run SHOULD be a 
'scalabletime' specified by a (Value, BenchmarkType, BenchmarkValue) 
triplet as described in chapter 7.2 of the Specification Draft


I am absolutely certain that these 4 simple requirements will be quickly 
understood.
I am quite sure that we will immediately obtain a YES for JD20.1 and 
JD20.2, and perhaps quickly a YES to either JD20.3 or JD20.4 (and a NO 
to the other one).


In the same way of thinking, I will re-propose following dropped 
requirements.  With sometimes an improved title, they describe the NEED 
for a precise Client interface, WITHOUT specifying the precise component 
which will implement them :

-  IS10  For requests querying Status of finished Activity, the 
Information functionality MUST accept, as input parameter, 1 Activity ID

-  IS12  For requests querying Activity Status, the Information 
functionality MUST accept, as input parameter, complex queries on 
Activities expressed according to the GLUE2 model without explicit 
specification of the Activity IDs.  The Information functionality MAY 
support multiple query languages in addition to the mandatory one.

-  LB4   For all requests, the Query functionality for Activity Logs 
MUST accept, as input parameter, 1 Activity ID

-  LB6   For all requests, the Query functionality for Activity Logs 
MUST accept, as input parameter, complex queries on Activities expressed 
according to the GLUE model without explicit specification of the 
Activity IDs.  The Logging and Bookkeeping functionality MAY support 
multiple query languages in addition to the mandatory one.


Besides, I just detected that we forgot to study following requirement, 
which was mentioned in my mail dated 26 April 2010.  Is it possible to 
associate spreadsheet ID 172 to it ?

-  IS14  In order to prevent overloading the Execution Service (which 
has performance requirements for Activity Management), the Information 
functionality SHOULD be separated from the Execution Service


Thank you in advance for accepting that, when starting with original 
confusion :
- rigidity prevents improvement and favors endless confusion,
- flexibility favors improvement and then clarity.


Best regards.

-----------------------------------------------------
Etienne URBAH         LAL, Univ Paris-Sud, IN2P3/CNRS
                       Bat 200   91898 ORSAY    France
Tel: +33 1 64 46 84 87      Skype: etienne.urbah
Mob: +33 6 22 30 53 27      mailto:urbah at lal.in2p3.fr
-----------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5073 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20100430/e72c8cef/attachment.bin