MDT-SBVR 0.7 Project Plan

Note: This is a draft of the requirements document and is expected to change.

Last revised: 2008-06-12

Please send your feedback on this draft document to the mdt-sbvr.dev@eclipse.org developer mailing list.

Back to SBVR Main Page

This project plan and associated requirements are the result of an open and transparent process and includes input from those who have expressed an interest in the project. That said, the success of the project and its deliverables is soley dependent upon the contributions from its community membership. If you are interested in contributing to the project in the delivery of its stated goals, you are more than welcome!

Requirements

The requirements consist of plan items for the project; see Requirements Overview for a description of how the plan is organized. Each plan item covers a feature or API that is to be added, or some aspect that is to be improved. Each plan item has its own entry in the Eclipse SBVR bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

SBVR Metamodel Implementation

Proposed

• SBVR test cases. Work with the SBVR community to create one or more detailed SBVR test cases stored as XMI files. The test cases should illustrate best practices for organizing and writing vocabularies and rules. (bug#226011)
• Enhance model validation. Add EMF validation constraints for SBVR structural rules in the specification. (bug#226012)
• SBVR 1.1 compliance. Modify the metamodel and XMI interoperability as necessary for compliance with SBVR 1.1. (bug#226013)

Committed

• SBVR exchange document metamodel. Implement the CMOF metamodel delivered with the SBVR 1.0 specification. This metamodel will be used for XMI serialization to the SBVR Exchange Document format. Fix metamodel bugs and provide feedback to the SBVR RTF, as required. (bug#226006)
• SBVR metamodel for tool developers. Design an SBVR metamodel that is optimized for tool development and that enforces structural constraints in the specification. (bug#226010)
• Load and Save XMI compliant with SBVR 1.0. Provide a resource handler or transformation that enables SBVR models to be loaded from and saved to SBVR exchange document XMI files that are compliant with the SBVR 1.0 specification. (bug#226008)

Deferred

SBVR Sample Tools

Proposed

• Project Explorer navigator view. Provide an o.e.sbvr.ui.navigator plug-in that contributes a Project Explorer content provider, support for undo/redo, edit menus, SaveablesProvider, content filtering, and virtual content folders. (bug#226018)
• Import business vocabulary from UML. Work with the SBVR community to define and implement transformation from UML domain models to SBVR vocabulary. (bug#226019)
• Transform SBVR to Platform-Independent Models (PIM). For example, to support IT design and implementaiton using UML and OCL, production rule engines, etc. (bug#226021)

Committed

• Menus for adding new concepts. Implement popup menu actions contributed to sample editor and Project Explorer view, e.g. Add Term, Add Definition, etc. Each action will add and link all required metamodel elements: Concept, Designation, and signifier Expression.(bug#226017)

Deferred

Requirements Overview

Status of a requirement

Plan items reflect new features in this project, or areas where existing features will be significantly reworked. Plan items are indicated using the [Plan Item] keyword and have a state determined by 'Assigned To' and 'Target Milestone' fields in Bugzilla. Below is a list of possible states and what they mean:

Proposed

These are requirements that are being considered for this release. These are items that are either being investigated or items that the project would like to explore but are not yet Committed. Most of the requirements should start as proposed items. After a review and some amount of detailed planning, their status will either become committed or deferred. Bugzillas without an assigned developer are proposed, but not committed for a particular release.

Committed

These are requirements that the project team is definitely going to address in the release. Resources and some amount of detailed plans have been identified for such items. Bugzillas with a target milestone and developer assigned are considered committed in that release.

Deferred

These are valid requirements that started in a Proposed state but will not be addressed in this release. Each such item will have a brief note explaining the cause for the deferral. Bugzillas with an unspecified target milestone are deferred, and not scheduled for the current release.

Flags on a requirement

A requirement can have these additional flags.

Help Wanted

These are valid requirements in the 'Propsed' or 'Deferred' status that require volunteers to work on them. These are especially good candidates for companies or individuals who want to get involved with SBVR in a large way.

Complete File:Checkmark-10x10.gif

This flag is used to mark items as they are mostly finished. While the items might continue to have bugs fixed etc. until the final release, we expect each milestone will have some items to mark as "complete", such as those going into a New and Noteworthy document for that milestone. This flag is a good indication that something is ready to be fully tested, documented, etc.