Shortcomings in Requirements Engineering (RE) are known to be the prime source of software development project failures. Better education can help improve this situation, but a critical prerequisite is adequate (and a ordable) tooling for modeling and working with requirements speci cations. The author has been teaching a major Requirements Engineering class at the Technical University of Denmark (DTU) for six years, and the need of tool support to do practical case-study work is quite obvious. We had prior experience with commercial tools (DOORS, RequisitePro, and JIRA), and we have tried di erent approaches to tooling in the course, including the \pragmatic" solution (spreadsheets and text documents), an open source RE tool (OSRMT, with massive customization), and a UML tool (MagicDraw, with extensions). Neither of them proved to be helpful.1 Among their disadvantages are their high cost (licenses, customization, learning), vendor lock-in, a hard-wired development approach, eclectic coverage of requirements concepts, and inconsistent terminology. In a nutshell, existing tools are focused on practical software production and speci c customers while the concerns of education are less important. So, eventually, we decided to build our own tool, the Requirements Editor (RED). RED is speci cally created to address the needs of students and teachers, but it has matured beyond a mere academic prototype: based on personal experience with RE tools in large development projects, we believe it outperforms many existing commercial products.
Previous versions of RED already provided a rich set of requirements editing
capabilities, including classic textual requirements, stakeholders, goals, glossaries,
sketch-style UML model fragments, and so on. Also, major tools like reporting,
search, logging/status information, inspection support, and user-de ned views
were provided. Finally, all the usual qualities and UI capabilities of an Eclipse
RCP application were available, which made RED a stable and easy to use tool
from the start. However, the new version 3.0 of RED signi cantly extends the
previous version [
{ Use Case Modeling: RED now provides fully edged Use Case modeling
capabilities, focusing on the tabular view, which Dobing and Parsons
describe as the most common form of use cases [
RED strives to be open in every sense, thus we allow to include any kind of documents into a RED project, acknowledging the fact that the most widely used requirements tools (in particular in the early phases), are Word, Excel, and PowerPoint. This kind of document can be stored in a RED project, and opened from within RED (as far as the respective tools are available). 3
Faced with these requirements, we decided to create RED using the Eclipse Rich Client Platform (ERCP). Since 2011, seven students have contributed to RED through their MSc-thesis projects, and three more are currently on-going, adding up to almost 300 ECTS points worth. A student programmer is employed to coordinate and integrate the contributions, x bugs, and add small features not tting into the larger projects.
A rst version was deployed in September 2012 and since then, we have used RED continuously in our RE courses.2 By now, RED has been used by students for several thousand hours. The feedback received there was used to improve the tool, and while initial reactions were mixed, they have gradually improved. Students now use RED without problems.
The latest version has not been eld tested yet, but developer tests suggests no decrease in stability or usability, while the feature set has expanded considerably. We believe that RED is now relatively close to commercial solutions with regards to capabilities and qualities. 4
RED has been created using the latest Eclipse platform available at the time (Eclipse 3.7 \Indigo"). RED is organized in a set of components (\features" in Eclipse terminology, see Fig. 2), each providing speci c bundles of concepts and capabilities: the Core module provides the main UI of the application and the back-bone of the meta-model. It supports a number of feature-modules, such as Glossary, Speci cationElements and Help. We have also reused a number of third-party plug-ins, including EPF RichText and AgileGrid, that increased the code reuse ratio.
The main rationale behind for using Eclipse is its proven ability to create rich, cross-platform applications. Due to its plug-in-architecture, signi cant leverage through reuse was achieved. Adopting a popular framework, we also ensured maintainability and long-term development.
One particular highlight in the release currently under development are the visual editors. They will present an easy to use front-end for specifying many of those elements of a requirements speci cation that we have come to expect as being primarily visual, e.g., use case and goal models. They will supplement the existing tabular and form-based editors. Adding a visual front end will allow both faster modeling and more e ective communication of speci cations. 2 In this course, there are 50-60 students per year, working in groups of 4-6 for 13 weeks, spending approximately 25 hours per week for the course.
CD RED Meta-Model
Another highlight is the Dynamic Online Extension Connector which is a
novel feature allowing to seamlessly integrate features at run-time via
webservices. This is useful to provide features which are di cult to integrate for
technical reasons (e.g., they are based on a di erent technology), that require
more resources than are readily available on a standard client desktop, that must
be deployed late, or that must be maintained and updated independently. It is
also a way to allow a wide spectrum of extensions to be provided by third parties,
avoiding IP issues. One example of such a service is Hypersonic [
We currently focus on providing a few missing features such as visual editors, connectors for other formats such as ReqIF, and a teamwork server to support distributed work, easy to use version control, and controlled natural language checking facilities. Also, the recent set of additions prompts us to consolidate the meta model and software architecture of RED once more. Further features are currently postponed due to resource shortage, including support for star-card based approaches as used for \agile" requirements.
We are working on legal issues which, when resolved, will allow us to release RED under a liberal licensing scheme. Clearly, this is the cornerstone both to attracting outside contributions to further evolve RED, and to allow its usage in industrial projects where it will realize its true potential.