• Home
• Concepts
• Current meta model (DTD)
• Example: Forest documented in Forest
• Prototype features
• Screenshots
• Future work
• Download prototype
• Trackers
• Master's Thesis (incl. literature references)
• Master's Thesis presentation



• Contact the project manager / developers

Prototype features

When working according to the proposed method (see here), a number of tools are useful. These tools are implemented in the current prototype and can be used via the command line interface (for checking the repository contents and for generating documents).
Furthermore, an plug-in was developed containing two different editors (requirements editor and a design editor) with an accompanying Outline view and a Trace view. The model checker is invoked after any structural change in the repository. Any warnings or errors generated by the model checker are written to the Problem view and decorators are used in the Outline view to indicate an issue with a certain artefact. Finally, the document generator can be called from within the Eclipse environment as well, displaying a preview of the rendered PDF file in the Eclipse editor area.

• The command line interface can be used to:
  • perform checks and various types of analysis on the contents of the repository
  • generate a requirements or a design specification document (PDF file)



• The editors and their accompanying outlines in the Eclipse plug-in have the following features:
  • Add / edit requirements, consisting of a title, description, type, stakeholder)
  • Translate, split, or join requirements
  • Add / edit systems (representing design artefacts), consisting of a title, description, motivation, status, etc.
  • Add / edit atoms (representing implementation artefacts), consisting of a title, description, motivation, etc.
  • Delegate requirements to subsystems
  • Delegate requirements to atoms
  • Link atoms to a concrete implementation (e.g. a source file in the file system)



• Additional features of the Eclipse plug-in are:
  • On any structural change, the model checker is invoked, results are written to problem view and decorators are used in the Outline view to indicate problems at the respective artefacts
  • A Trace view is available to trace requirements to their respective design and implementation artefacts
  • The document generator can be invoked



• The model checker currently contains the following checks:
  • AbstractSystemChecker: checks whether an extended system exists
  • ArtefactRequiredChecker: systems or atoms need at least one requirement pointing towards them (cost/benefit analysis)
  • AtomHasRefChecker: warns if the reference attribute of an atom is not used
  • DelegationChecker: verifies that all sources and targets exist
  • ExtensionChecker: verifies that an extending system provides concrete requirements, systems, and atoms
  • FileExistsChecker: warns if a file referred to does not exist in the file system
  • ImageChecker: checks image markers in description/motivation text
  • ImplementedRequirementExistChecker: checks whether all requirements implemented by an atom actually exist
  • RequirementImplOrDelChecker: verifies that for each system, all requirements are either implemented or delegated (coverage analysis)
  • SourceChecker: verifies that sources exist in the same subsystem they are delegated from
  • StandaloneChecker: verifies that the system does not contain any references to other systems (TODO)
  • TargetChecker: verifies that the target exists
  • UniqueNameChecker: verifies that names of artefacts are unique