Login | Register
My pages Projects Community openCollabNet

Introduction

The core product facilitates requirements management in a file-based architecture. Its internal model is analogous to the internal model of a Java project within the Eclipse integrated development environment.

A requirement is embodied in a requirement file, such as RML. Requirements files exist within a directory, or a requirements package. Requirements packages exist relative to mount directories, or requirements folders. Finally, requirements folders are maintained within the scope of a requirements project.

So, you need to establish the relevant folders for your projects. Optionally, you may want to configure your default requirement, your filters, and your sorters.

Overview for the impatient

  • download and install the product;
  • define your project configuration directory in the workbench.properties file;
  • define a set of project properties files, identifying their names, descriptions, and configuration directories;
  • for each project and in their identified configuration directory, define a set of folder properties files, identifying their names, descriptions, and mount points (directories);
  • define the default requirement (which is used to create new requirements);
  • define any filter instances that you deem necessary;
  • define any sorter instances that you deem necessary.

Project configuration

Projects are the highest level grouping within a Workbench and a Project can have any number of Folders assigned to it.  A Folder serves as a "mount" point for requirements directories and files.  A Requirement (embodied in a requirements file) will be assigned to a Package based on the directory structure between its requirement file and its assigned Folder.  Thus, Packages are implicit rather than explicit (i.e. they are not defined in the requirements file).

 

The project configuration communicates how the sets of Requirements you'll be managing should be organized.  Particularly, it identifies the Projects and their Folders.  For example, the project configuration can communicate that you wish to organize your Requirements into two Projects: Project 1 and Project 2.  Further, assume that Project 1 should have three Folders: Folder 1, Folder 2, and Folder 3 and that Project 2 should have two Folders: Folder 1 and Folder 2. 

 

Project configuration is completed by editing and/or creating properties files that will be read by the system when it initializes (or reinitializes).  Projects and Folders are static in the sense that they are defined at startup time.  Packages and Requirements are dynamic in the sense that they can be reorganized at runtime.

 

Files distributed with the product illustrate how this configuration can be done.

 

workbench configuration file

 

Take a look at the config/workbench.properties file.

 

Inside it, it defines the directory where the system should read the Project properties from; by default, this value is projects.directory=workbench/projects.

 

Note that the config directory is part of the Java classpath, enabling relative references to files within it.  If you wish, you can move files around and change their references.

 

project configuration files

 

So, let's take a look at the config/workbench/projects directory.  The system reads all of the properties files in this directory and creates Projects for them.  Two projects are defined: Project 1 (project1.properties) and Project 2 (project2.properties).

 

A Project's name and its description are defined in its configuration file.  Additionally, a directory which defines the Folders for the Project is defined here.  For Project 1 it defines the following: project.folders.directory=workbench/projects/project1. 

 

folder configuration files

 

If we look at the config/workbench/projects/project1 directory, we see three more properties files.  Each of these define a Folder that serves as a basis (or a mount point) for Requirements.  Project 1 has three Folders mounted: Folder 1 (folder1.properties), Folder 2 (folder2.properties), and Folder 3 (folder3.properties).

 

A Folder's name and its description are defined in its configuration file.  Additionally, a directory mount point is defined for the Folder.  For Project 1::Folder 1 it defines the following: folder.directory=@PROJECT_SRC_ROOT@/project1/folder1.  If you just want to get the example running quickly, download the requirement samples, place them somewhere on your hard drive, and then replace the @PROJECT_SRC_ROOT@ token with the root directory where you placed the samples. Do this for each of the folder directories.

 

Using the default configuration as an example, go ahead and configure your Projects and their Folders by adding, changing, and deleting the Workbench, Project, and Folder configuration files.

 

Once the Projects and Folder configuration is complete, you can begin maintaining Requirements.  Optionally, you can configure the filters, sorters, reporters, and transformers for your system.  However, these aren't really needed until your Requirement set gets larger.

Default Requirement configuration

Take a look at the config/workbench.properties file.

 

Inside it, it identifies the file that should be used as the default requirement.  Initially, the file is identified with the following property key: default.requirement.filename.  The requirement embodied in the default file can be as simple or as complex as you want...it must simply be a valid RML file.

Filter configuration

An installation includes a set of Filter Types and a set of Filter Instances.  You should not need to configure the Filter Types.  Filter Instances are stored in Requirements Filter Markup Language (RFML) files.  You may or may not need to change or add Filter Instances.

 

Filter Types define the primitive and composite filters for the system.  By default, these definitions are stored in the config/filter-type directory.  These definitions identify the Java classes that should be used to read Filter Instances (rfml*.properties) and the Java classes that implement named Filter Types (*-filters.properties).  Filter Types are established at system initialization.

 

Filter Instances define the filters available for use by the system.  By default, these definitions are stored in the config/filter-instance directory.  These definitions, written in RFML, identify the Filter Types that should be combined in order to implement a filter.  Filter Instances can be established at runtime.

 

Some example Filter Instances are provided.  As you think of useful Filter Instances, simply define a new one in this directory (or another directory) and either restart the system or re-load the filters through the user interface.

 

Please propagate generally useful filters back to this open source project so that others can benefit from them.

Sorter configuration

An installation includes a set of Sorter Types and a set of Sorter Instances.  You should not need to configure the Sorter Types.  Sorter Instances are stored in Requirements Sorter Markup Language (RSML) files.  You may or may not need to change or add Sorter Instances.

 

Sorter Types define the sorting algorithm implementations and the "orderers" that they use.  By default, these definitions are stored in the config/sorter-type directory.  These definitions identify the Java classes that should be used to read Sorter Instances (rsml*.properties) and the Java classes that implement named Sorter Types (sorters.properties and orderers.properties).  Sorter Types are established at system initialization.

 

Sorter Instances define the sorters available for use by the system.  By default, these definitions are stored in the config/sorter-instance directory.  These definitions, written in RSML, identify the Sorter Types that should be combined in order to implement a sorter.  Sorter Instances can be established at runtime.

 

Some example Sorter Instances are provided.  As you think of useful Sorter Instances, simply define a new one in this directory (or another directory) and either restart the system or re-load the Sorters through the user interface.

 

Please propagate generally useful filters back to this open source project so that others can benefit from them.

Main Project Pages