Background
Teaching (and learning) requirements engineering is very difficult. It is inherently difficulty as it covers a very wide range of topics, from hard to soft. It is also one of those topics that require first-hand experience to really appreciate it, something students often lack. But apart from that, RE is a truly wicked discipline, as it may appear trivial at first sight. Even Dijkstra dismissed it as "the pleasantness problem", and flat out denied that it part of CS.
We at DTU believe that learning is best done in a practical, hands-on way, and this is particularly true of RE. This asks for two things: realistic settings and realistic cases. It is easy enough to organize teamwork and realistic case studies, but a realistic setting will also require using one or more tools. Also, realim in case studies implies non-trivial size, so that tool usage is inevitable. But that is actually a major problem.
In practice, the most used RE tool is office software, mostly word processors and presentation tools. So in order to be totally realistic, we would have to use that. Clearly, students will spend a disproportionate amount of time on manually doing trivial consistency checking tasks. Not only will they not like it very much, they do not learn much from it and will come to regard RE lowly.
We tried out several existing RE tools in teaching. none of them worked in a satisfactory way. Here are some of the drawbacks we encountered.
- The good tools are expensive, and universities are perpetually underfinanced. The cheap/free tools, on the other hand, are not so good. Even the expensive tools are not actually good, and all tools seem to ignore much of RE research.
- All tools have their own special approach and idiosyncratic concepts and terminology. Using any one of them will force me to adopt some strange jargon, explain it to be the "right one" against better knowledge, or to utterly confuse many a student.
- Probably the worst problem is that every tool specialises on some kind of industry or system type. Optimized for any such market niche, the tools perform poorly in other settings. This results in either a narrow specialisation of the course ("RE for embedded systems" or some such), or using severl tools which results in even more teaching time being devoted to learning a given tool rather than engineering.
- Free: The tool should not cost universities anything to use it. In fact, with a view to improving RE industrial practice, it should not cost businesses anything to use it.
- Comprehensive: The tool should allow most if not all relevant methods and concept of RE so that engineers choose concepts and approaches according to what is needed, not by what the tool offers.
- Method Agnostic: Commercial tools automate methodological choices for a given market segment. Students must learn about the options, so they need the freedom to choose for themselves, allowing them to make poor choices.
- Transparent: The concepts provided should be named clearly, consistently, and systematically at the expense of violating bad habits. Any concept or fetaure appearing in the tool should appear under the same name in lecture material.
The latter goal has an interesting and, at the time, unpredicted side effect: introducing a concept in the lecture alone leads to poorer learning result than reiterating it many times over in using a tool practically. Lanugage barriers and misunderstandings, missing a lecure or being absent minded, and many other real life phenomena in academic teaching can be mitigated by aligning lecture material and teaching tool. In the end of the day, it doesn't matter how students learn as long as they learn.
The RED family of tools
The RED family of tools (RED, REDO, and RedCloud) is comprehensive and method-agnostic: we offer a broad range of perspectives, from Interaction Design, via Goal Modeling and classic Textual Requirements to UML analysis-level modeling. Every one of these is considered useful in its place and for a given type of projects, and every one of them is addressed in some tool. But only RED offers them all together, without preference. They all integrate in the common conceptual framework and terminology of RED to achieve unique synergies and allow consistent tracing through all phases.
The RED family of tools is informed by academic developments but focuses on practical utility. We’re offering some advanced features found nowhere else, but we always stay pragmatic and focus on the practically relevant features and capabilities. So apart from the “exciting” features like UseCasePoint estimation or model weaving, we offer plenty of the bread-and-butter of project work: reporting, version control, inspection support, online team collaboration, Excel-integration, and so on.
RED has been developed since 2009 and is used regularly for RE teaching at graduate and undergraduate level. In those years, the terminology and tool have been reengineered and polished again and again. The meta-model, the software architecture, and user interface have been tested by scores of students – and students can be a really tough audience… If it has worked for all of them, it can work for you.
Our visual modeling approach in the RED desktop solution is unique by giving equal space to diagrams and visual elements on the one hand, and specifications and conceptual elements on the other. Both parts can be specified separately or together, and the connections between them can be established and severed at any time.
Last but not least, all RED tools are free and open source. They are created and distributed under the Apache 2.0 license, so that you can use it for academic, pro bono, and commercial work alike. You can contribute bug fixes and feature additions, and you can even create your very own requirements toolset based on the currently three members of the RED family, RED, REDO, or RedCloud.
RED is a stand-alone desktop application. It is our flagship and constitutes the workstation of the requirements engineer. All modeling concepts are availabel here first, advanced features will only be provided in RED.
REDO is a reimplementation of the major conceptual editing parts of RED. REDO is fully browser based and allows online collaboration through bidirectional synchronization almost in real-time. Is is also responsive to be usable on mobile devices. This is particularly suited for distributed teams in the early phases of specification, or for distributed validation and read-only access. There is currently no integration between RED and REDO.
RedCloud is a cloud based platform to pland and document specifiation projects and their progress over time. It is particularly suited to provide advanced tracing, workflow planning and visualization, and version control of RED specifications. Unlike REDO, RedCloud follows a more classic checkin/checkout mode of synchronization to allow for structured and controlled interactions.
