[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [legalxml-econtracts] eContracts Requirements Process
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 ProcessScenario - #1#
IntroductionThis 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
RequirementsThe 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
Non-Functional Requirements
Notes[Any additional notes]. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC