Re: Process proposal

On the subject of process and proposals, I was wondering if there were 
any tools or formats that W3C working groups were recommended to use for 
describing requirements, use cases, threats, risks and other 
pre-specification data?

For the security model deliverable it seems unlikely that there will be 
much agreement (or productive discussion) until there is a consensus on 
the requirements, assets and threat model.  Or at least what the scope 
of this working group is.  As such, these seem like essential documents 
to put together and collaborate on.  I know that there are many 
different processes (Trike / Octave / Microsoft's / CORAS / etc) but 
most of the actual output is likely to be the same, particularly if 
there is a consistent vocabulary and format.

Wikis and documents are a bit limited when it comes to describing and 
linking requirements and their related artefacts.  When working on other 
projects we've used our own tool, CAIRIS [1] and published the data [2], 
but we've also found it easier to collaborate using spreadsheets 
(indeed, I'm using Google Docs to try and do *some* of parts 1-4 of Josh 
Soref's excellent suggestions now [3,4]).If there are any commonly-used 
tools for this purpose I would be very grateful to be pointed in their 
direction.

Thanks,

John

[1] https://github.com/failys/CAIRIS
[2] https://github.com/webinos/webinos-design-data
[3] Some consolidated threats and assets - 
https://docs.google.com/spreadsheet/ccc?key=0As1cqcmobbEvdEhyOFN3ZU82QlMyR1FDUjlMSWRuM3c
[4] Background analysis - 
https://docs.google.com/document/d/175vNhHLPdjYb7iwRBlLmSa3SsSIATpYZ7kpFyy-eYI0/edit


On 26/10/12 19:27, Josh Soref wrote:
> I've spent a bit of time in a number of groups and think that a lesson learned could be useful.
>
> CoreMob (really Facebook) did research into an area and then moved straight to trying to publish roughly a "specification".
>
> Then people asked "what UC/Requirements are you addressing?" (roughly: "why are you doing this?"), and CoreMob didn't have an answer - because it hadn't published its research.
>
> For defining an API, these are the things which I think should be answered:
>
> 1. [UC] What are the general Use Cases which you're trying to address?
> 2. [Req] What are the specific technical Requirements to address the UCs?
> 3. [API] How have others tried to address these UCs and Reqs?
> 4. [Use] Given others' APIs for these UCs/Reqs, what have people produced which uses this solution?
> 5. [QQs] What questions have people asked about others' APIs?
>
> * [UC]+[Req] can be published as a single combined Use Case and Requirements document, or as separate documents, but they should be published.
> * [API] can be initially a wiki and will probably end up in an informative appendix to a published specification.
> * [Use] should be a survey - roughly producing a spreadsheet, preferably with some charts showing popularity/use - preferably highlighting which UCs/Reqs are addressed/how well/how used.
> * [QQs] can initially be some sort of wiki/spreadsheet - it should show which are the most common causes of confusion / problems that aren't easily solved for the existing APIs. It doesn't need to be published per se, but being able to reference it informatively from the spec is useful "we tried to avoid (most) these problems when we wrote our specification". Sources for this include sites like "Stack Overflow" (as well as any group's actual FAQ pages).
>
> I think that SysApps (and really every other group) should keep this in mind when it tries to produce any API.
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>

Received on Tuesday, 6 November 2012 09:11:46 UTC