[legalxml-econtracts] eContracts Requirements Process

[Jason Harrop <jharrop@speedlegal.com>]

Hi everyone

Please find below the process we are now running with.  This supercedes 
the draft posted on December 22.

It can be fine-tuned if necessary as we go.

cheers,

Jason


----------------------

ECONTRACTS REQUIREMENTS PROCESS

Version 1
Document dated 16 January 2003



Scenario development
---------------------

Ask people to post scenarios (standards-compliant HTML docs of between 1 
para and a couple of pages in length) to the mailing list.  As these 
stabilise, they will be posted to the eContracts web site.

The scenario should follow the general layout/format of the template 
attached.  The intent is that the scenario should explain why it is 
important/significant.

The scenario document is to include a scenario statement, and a set of 
requirements extracted from the scenario statement.  The requirements 
should be split into functional and non-functional requirements.

Each scenario will be "owned" by the person who contributed it.  Others
can ask the scenario owner to add their suggestions to the scenario, or
otherwise create a new scenario of their own. If a scenario owner
accepts a contribution, that person may be listed as a contributor by 
the scenario owner unless the contributor asks otherwise (perhaps 
because he/she doesn't agree with the entirety of the scenario).

A contributor need not be a member of the eContracts TC, or of OASIS. 
Circulation of the Scenarios outside the TC is encouraged.

The scenario owner may revise the scenario (dating and numbering the 
revision).  If a contributor doesn't agree with it anymore, he/she may 
ask that his/her name no longer be listed on that revision).  For ease 
of reference in mailing list discussions, any given requirement should 
retain the same number across revisions.  This may necessitate hard 
coding the numbers in the document.

Ask people to forward copies of contracts they'd like to be able to
represent (ideally, referenced in and attached to a scenario).


Requirements list (not prioritised)
------------------------------------

Extract business requirements from the scenarios as they are received.
Note next to each requirement which scenario (or scenarios) it came 
from, who owns it.

Attempt to present the business requirements categorised according to
the step in the contract lifecyle that they relate to:

- draft
- negotiate
- sign/exchange
- manage
- amend/dispute
- renew

.. or capture as a technical requirement

Keep the list online, updated as we receive scenarios.

Open mailing list discussion of requirements
-------------------------------------

We'll need some time to discuss/clarify the requirements, and get a feel
for what people think of them.

Vote for requirements
---------------------

At close of requirements gather process, TC members could vote for the
requirements they think are important, so we get agreed list of
mandatory, nice to have etc.



Publish draft prioritised requirements
--------------------------------------

Query whether we need to allow time for TC members to circulate the
requirements outside the TC for additional comments/validation.


Possible timetable:
==================
Scenario development (Jan)
Requirements List (Jan - early Feb)
Mailing list discussion (Feb)
Vote (end Feb)
Publish draft prioritised reqs (mid March)

Title: OASIS LEGALXML ECONTRACTS TC - SCENARIO

OASIS LegalXML eContracts TC Requirements Process

Scenario - #1#

Name	#1
Principal Stakeholders	#2
Scenario Owner	#3
Draft Number	1
Draft Date	#4
Contributors	#5

Introduction

This document is a scenario developed as part of the eContracts requirements process.

The purpose of a scenario is to provide a context for a set of requirements important to some group of end-users (in this case, #2). A scenario is intended to help members of the working group to understand the drivers behind stated requirements.

To that end, this document contains a Scenario Statement, and a set of Requirements extracted from the Scenario Statement.

As per the requirements process, contributions to this scenario are welcome. Please send your contributions to the Scenario Owner. The Scenario Owner will decide whether to accept your contribution or not. If your contribution is not accepted, you may create your own Scenario. For further details, please refer to the process document

Scenario Statement

[TYPE YOUR SCENARIO STATEMENT HERE..]

Sub headings are allowed

[TYPE YOUR SCENARIO STATEMENT HERE..]

Summary of Key Benefits to Stakeholders

1. Better 1
2. Better 2
3. Better 3

Requirements

The following requirements have been extracted from the Scenario Statement.

Important Note regarding Traceability: Why each requirement is important should be clear from the scenario above. If it isn't, the scenario or the requirements should be amended.

Functional Requirements

100. First requirement

101. Second requirement

     1. first bit

     2. second bit

102. Etc

Non-Functional Requirements

200. First requirement

201. Second requirement

     1. first bit

     2. second bit

202. Etc

Notes

[Any additional notes].