Re: Process proposal

I'd recommend starting with the System Applications wiki:

http://www.w3.org/wiki/System_Applications

If we need something fancier later, we can switch to something more complex.

Adam


On Tue, Nov 6, 2012 at 1:11 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:
> 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 15:49:23 UTC