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:  <mailto:steve.battle@sysemia.co.uk> steve.battle@sysemia.co.uk
Web:  <http://www.sysemia.com/> 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.