Login | Register
My pages Projects Community openCollabNet

RAVE features

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.
    1. Subject nouns in the sentences are placed into a list of tentative actors.
    2. Predicates are placed into a list of tentative use cases.
    3. All nouns are placed into a list of tentative objects.
    4. All entities are placed into a dictionary for definition.
    5. Any relationships derived from sentence structure are stored.
    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.
  • 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 process diagrams.
  • RAVE has version control, and all entries are autosaved.
  • RAVE has accountability. It is a centralized, server-based system. 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.
    • 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 functional grouping.
    Access (read, read/write, none) can be controlled at the level of individual or group.
  • 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 development.
  • 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.