Future work
In the following directions, we would like to extend our work.
- Templates and query language First of all, the document generator should be made more dynamic. The current prototype implementation does allow for two different types of documents to be generated, but which information to select from the repository and in which chapter to include the information currently hard-coded. We would like to be able to define templates, one for each type of document according to a certain documentation standard (e.g. J-STD-016). These templates should be written using some sort of query language in order to dynamically select information artefacts from the repository and place them in the desired chapter or the document being generated. A suggestion about what the templates might look like was done in the author's thesis.
- Extensions Several extensions have been thought of already, as explained next.
- Meta model
- Domain specific plug-ins for model checker
- Include testing in the tracing process
- Name spacing
- Change management
- Reverse engineering As resulted from our second case study, the Forest approach is suitable to assist in a reverse engineering process. However, since this was not intended from the beginning of the project, more research is needed to define the role of the Forest approach in such a process more clearly.
- Professional tooling The case studies described were performed using a prototype implementation of the tools mentioned and yielded positive results. However, the prototype implementation is not suitable for documenting an industry scale project. Reasons for this are performance, design decisions, and some user interface issues. Hence, professional tools that are easy to use and well-integrated in the development environment need to be created.
Although the case studies performed showed no major insufficiencies, it is expected that for larger cases a more extensive meta model needed. For example, where the Forest meta model only provides one motivation artefact, the Griffin project provides more than 20 artefacts for storing design rationales. Furthermore, the current meta model has very limited support to express relations between systems. Research should be done to investigate to what extent the Forest meta model should be extended. This is related to the work of the Quadread project as well.
The current model checker implementation is only capable of verifying the existence of files in the file system that are referenced by atoms. However, in a Java implementation for example, atoms could refer to classes or even methods. The model checker could then verify their existence inside source files.
Currently, no support for managing test artefacts is available. A simple first extension could be to add a test case artefact to the meta model consisting of a title, a description, and a reference into the file system. Then, requirements tracing can be extended to include these test case artefacts.
Currently, the repository requires any identifiers used to be globally unique. For larger systems this might be a restriction, which might be solved by introducing name spaces.
As envisioned from the start of the research project, it should be possible to support change management. Change management allows for so-called impact analysis: which parts of the system are affected when certain requirement or design artefacts change.
Website last updated: July 11, 2007