Re: FW: ACTION-9: Propose a new structure for the Use Cases and Requirements document

I like the proposed approach quite well.  I think it would help me get a 
better feel of how well it works if we have some real content to test 
drive it with.  Perhaps we can create a "sandbox" page for now and leave 
the current one as a "catalog" of items.  We can merge (eliminate the 
sandbox) once we are happy with the layout.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net


> From: Arnaud Le Hors/Cupertino/IBM@IBMUS
> To: public-ldp-wg@w3.org, 
> Date: 08/24/2012 12:19 PM
> Subject: Re: FW: ACTION-9: Propose a new structure for the Use Cases and 
 
> Requirements document
> 
> [resent to the proper list] 
> See below.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> 
> 
> From:        "Steve Battle" <steve.battle@sysemia.co.uk> 
> To:        Arnaud Le Hors/Cupertino/IBM@IBMUS, Steve K Speicher/Raleigh/
> IBM@IBMUS, <michael.hausenblas@deri.org>, 
> Date:        08/24/2012 08:45 AM 
> Subject:        FW: ACTION-9: Propose a new structure for the Use Cases 
and 
> Requirements document 
> 
> 
> 
> Arnaud, Steven, Michael, 
> 
> I sent the following email to the mailing list yesterday, but as this 
was 
> the first message I’d sent to the list, it appears to have been delayed 
(I 
> have given archival approval ) . 
> Anyway, the content is reproduced below, for yourself and the use case 
co-
> editors to review. 
> I’m happy to discuss this Monday. 
> 
> Steve Battle 
> 
> 
> From: Steve Battle [mailto:steve.battle@sysemia.co.uk] 
> Sent: 23 August 2012 18:05
> To: public-ldp-wg@w3.org
> Subject: ACTION-9: Propose a new structure for the Use Cases and 
Requirements document
> 
> The following is the proposed structure of the LDP 'Use Cases and 
> Requirements' Document. Rather than basing this template on any one 
prior 
> example, I've chosen to look to these as exemplars of a particular 
feature, 
> with the aim that this document will combine the best of the best.  The 
main
> change is the relabeling of the existing use-cases as 'User Stories', 
and 
> the introduction of a new 'Use Cases' section that will catalogue the 
> complete set of behaviours of LDP compliant systems. The text below is 
> representative of the document outline, using wikitext to indicate 
section 
> levels. I hope not to ignite any wars over the terms 'user story', 'use 
> case', and 'scenario' as used in different communities; aiming to be 
> compatible with as many different approaches as possible, from 
lightweight 
> to formal. The most contentious point may be the distinction between 
user 
> stories and use cases, to allow the relationship between them to be 
> something other than 1 to 1, as is often the case with larger multi-line 
user stories.
> 
> I invite comment on the layout (particularly from my co-editors), and if 
the
> response is favourable, I'll edit the wiki accordingly. The actual work 
on 
> isolating, identifying, and documenting the use-cases will remain work 
to-be-done. 
> 
> Steve. 
> 
> 
> =Linked Data Platform Use Cases And Requirements= 
> 
> ==Scope and Motivation== 
> 
> ==User Stories== 
> ===<USER STORY>=== 
> A statement about system requirements written from a user or application 

> perspective. They can be obtained during informal discussion with users, 

> often as a prelude to a more formal requirements gathering process [1]. 
They
> are lightweight and informal and can run from one line to a paragraph or 
two. 
> (e.g. <
http://www.w3.org/2005/Incubator/webid/wiki/User_Stories_and_Use_Cases>). 
> ====Analysis==== 
> Analysis of the user story can reveal specific use-cases and 
non-functional 
> requirements (e.g. <http://www.w3.org/TR/dap-policy-reqs/>). We don't 
> presume that each user story corresponds to a single use case. 
> 
> ==Use Cases== 
> Functional requirements modeled as use cases. This section provides a 
> catalogue of use cases, each of which may be derived from one or more 
user stories. 
> ===<USE CASE>=== 
> Use cases, while still telling a story, are more structured [2], 
cataloguing
> who does what with the system, for what purpose, but without dealing 
with 
> system internals [3]. We would typically identify the use case with a 
> reference number (see e.g. <http://www.w3.org/TR/rdb2rdf-ucr/>), along 
with 
> a description, actors, pre/post conditions, and behaviours. UML use case 

> diagrams (a form of behaviour diagram) may be used, but aren't 
necessary. 
> Use cases act like the hub of a wheel; with spokes supporting 
requirements 
> review and traceability, scenario-based analysis, end-to-end testing, 
and 
> integration with non-functional, or quality requirements. 
> ====<SCENARIO>==== 
> Scenarios are more focused still, representing a single instance of a 
use 
> case. Scenarios may be lightweight narratives (e.g. <
http://www.w3.org/TR/

> media-frags-reqs/>), or modeled as interaction diagrams. Each scenario 
may 
> lead to the development of one or more test cases (e.g. 
http://www.w3.org/

> TR/xquery-use-cases/) 
> 
> ==Requirements== 
> ===Accepted Requirements=== 
> Use-Cases may document behaviours that are ultimately deemed out of 
scope. 
> This section may identify use cases that are accepted (e.g. http://
> www.w3.org/TR/skos-ucr/) 
> ===Additional Functional Requirements=== 
> This section lists supplementary functional requirements that are not be 

> captured as use-cases. These may be specific algorithms, state-machines, 

> business processes, or other behavioural models that define what a 
system is
> supposed to accomplish. 
> ===Non-Functional Requirements=== 
> This section lists non-functional or quality requirements, and the use 
cases
> they are derived from (if any) (e.g. <
http://dvcs.w3.org/hg/gld/raw-file/

> default/dcat-ucr/index.html>). These may be derived from and organized 
by 
> quality attributes. 
> 
> ==Acknowledgements== 
> Including acknowledgement of input from other working groups (e.g. 
<http://
> www.w3.org/TR/powder-use-cases/>). 
> 
> ==References== 
> [1] Alistair Cockburn, Writing Effective Use Cases, ISBN: 0201702258. 
> [2] Derek Coleman, A Use Case Template: draft for discussion, <http://
> www.bredemeyer.com/pdf_files/use_case.pdf>. 
> [3] Ruth Malan, Dana Bredemeyer, Functional Requirements and Use Cases, 
<
> http://www.bredemeyer.com/pdf_files/functreq.pdf> 
> 
> -- 
> Steve Battle
> Semantic Engineer
> 
> Mobile: +44 (0)7503 624 613 
> E-mail: steve.battle@sysemia.co.uk
> Web: www.sysemia.com 
> 
> Sysemia Limited
> The Innovation Centre, Bristol &  Bath Science Park, Dirac Crescent, 
> Emerson's Green, Bristol BS16 7FR
> Registered in England and Wales. Company Number: 7555456
> 
> DISCLAIMER 
> Information contained in this e-mail is intended for the use of the 
> addressee only, and is confidential and may also be privileged. If you 
> receive this message in error, please advise us immediately. If you are 
not 
> the intended recipient(s), please note that any form of distribution, 
> copying or use of this communication or the information in it is 
strictly 
> prohibited and may be unlawful. Attachments to this e-mail may contain 
> software viruses which may damage your systems. Sysemia Ltd have taken 
> reasonable steps to minimise this risk, but we advise that any 
attachments 
> are virus checked before they are opened. 
>

Received on Friday, 24 August 2012 16:42:55 UTC