OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

id-cloud message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (IDCLOUD-16) Comment from Martin Chapman on Use Case Document PRD01


    [ http://tools.oasis-open.org/issues/browse/IDCLOUD-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30267#action_30267 ] 

Anil Saldhana commented on IDCLOUD-16:
--------------------------------------

1. Please line number review drafts so that it makes it easier to comment!

TC Resolution:  We will incorporate in future version of the Use Case Document.




2. Cover page: There needs to be links to "this" and "latest" version. Discuss with TC Admin.

TC Resolution:  TC Admin will take care of this.


3. Cover page/Abstract: "This document is intended to provide normative use cases..."
   A committee note should not contain normative material, plus it is not clear to me what normative means wrt a use case. Delete the word normative.

TC Resolution:  We have removed "normative" and PRD02 will go for 15 day review.




4. Cover page/Abstract: Delete "be" after may in "These use cases are intended
to be used for further analysis to determine if gaps or requirements may
be exist in current identity management standards that additional open
standards activities could address."

TC Resolution:  We will consider this for PRD02.


5. page 12, references: since a committee note cannot contain normative material, it should not have any normative references. Remove the distinctions between normative and non-normative references.

TC Resolution:  We will remove "normative".



6. section 2.1. A typical use case template should include failure conditions as well as desired outcomes and goals. Has any thought been put into what happens when things don't go according to plan? Regardless of template issues, I only see process flows talking about the successful outcome.

TC Resolution:  Future Version of Use Case Document.



7. Section 3. As part of the overview it would be nice to see a table of all the actors from all the use cases, along with a brief description. This is a common convention in use case documents.

TC Resolution:  Future version of Use Case Document.

> Comment from Martin Chapman on Use Case Document PRD01
> ------------------------------------------------------
>
>                 Key: IDCLOUD-16
>                 URL: http://tools.oasis-open.org/issues/browse/IDCLOUD-16
>             Project: OASIS Identity in the Cloud TC
>          Issue Type: Improvement
>          Components: Public Review, UseCases
>    Affects Versions: 1.0
>            Reporter: Anil Saldhana
>            Assignee: Anil Saldhana
>             Fix For: 1.0
>
>
> These comments are provided by me as an individual member of the TAB and do not constitute an official TAB position.
> Comments are to the pdf version of Identity in the Cloud Use Cases Version 1.0
> Committee Note Draft 02 / Public Review Draft 01
> 23 January 2012
> 1. Please line number review drafts so that it makes it easier to comment! 
> 2. Cover page: There needs to be links to "this" and "latest" version. Discuss with TC Admin.
> 3. Cover page/Abstract: "This document is intended to provide normative use cases..."
>    A committee note should not contain normative material, plus it is not clear to me what normative means wrt a use case. Delete the word normative.
> 4. Cover page/Abstract: Delete "be" after may in "These use cases are intended 
> to be used for further analysis to determine if gaps or requirements may 
> be exist in current identity management standards that additional open 
> standards activities could address."
> 5. page 12, references: since a committee note cannot contain normative material, it should not have any normative references. Remove the distinctions between normative and non-normative references.
> 6. section 2.1. A typical use case template should include failure conditions as well as desired outcomes and goals. Has any thought been put into what happens when things don't go according to plan? Regardless of template issues, I only see process flows talking about the successful outcome.
> 7. Section 3. As part of the overview it would be nice to see a table of all the actors from all the use cases, along with a brief description. This is a common convention in use case documents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]