- Project tools
- How do I...
|Over 500 more tools...
RAVE combines agility, formality, and ease of use, as well as integration
with other CASE tools. RAVE is specifically designed to assist the novice
in building a valid requirements statement.
A project with RAVE begins with a written, conversational overview of
the project which is entered into RAVE. RAVE processes this with a
lexical analyzer and extracts artifacts used by the engine.
This produces a baseline from which the requirements engineer can
start. The objects produced can be defined, modified, related, changed,
or flagged for omission, but the requirements engineer doesn't have
to start with an empty tool.
- Subject nouns in the sentences are placed into a list of
- Predicates are placed into a list of tentative use cases.
- All nouns are placed into a list of tentative objects.
- All entities are placed into a dictionary for definition.
- Any relationships derived from sentence structure are
RAVE has a repository which stores all of its information
in a format
that is, or can easily be converted to, common XML languages such as
XMI or BPEL. Thus, information can be displayed as a simple or
hierarchical list of requirements, as UML diagrams, or as business
- RAVE has version control, and all entries are autosaved.
RAVE has accountability. It is a centralized,
Each user has to log into RAVE individually, and his or her actions are
recorded and traceable. Changes generate a new version of a requirement,
and reasons must be given for changes.
No requirement is ever deleted, just flagged as
non-used with a reason for the exclusion.
RAVE has partitionability. The total set of requirements can
be partitioned in various ways.
Access (read, read/write, none) can be controlled at
the level of individual or group.
- Partitions may reflect implementation order. For example,
there may be a core functionality that is implemented first,
and the remainder of the project is divided into other
increments of functionality that are added at other times.
- Partitions may reflect specific teams or workgroups.
- Partitions may be time-dependent, for incremental
implementation by feature or improvement, rather than
- RAVE has deferrability. This means that a subset of requirements
can be partitioned out as a core functionality, or a particular feature set,
and completion and consistency be enforced on this subset without
requiring that other, deferred, requirements be completely defined.
Deferrability allows the application of formality to incremental
- RAVE contains outlines for nonfunctional requirements (security,
performance, etc) as a basis for defining project parameters.
RAVE entities can be viewed from different perspectives.
- Simple requirements list
- Hierarchical list showing dependencies
- List vs diagrammatic representation
- Requirements vs UML
- Traceability matrices with tests
- Object interrelationships
- Object relationships with actors
- Team developers' subsets
- Management high-level overview
- Others TBD
RAVE enforces consistency and completeness. Each functional
requirement must be associated with at least one object, actor,
use case, test. Requirements must have parent requirements
unless they are specifically designated as top-level (and
associated with a top-level use case). Consistency checking
can be run at any time; deferred requirements can be excluded
from the consistency checking.