Requirements often play second ddle in software development projects. The tools for managing requirements are only loosely integrated with the tools used for implementing the system. Furthermore, while implementation tools are based on a rich syntax and wellunderstood semantics (the programing language itself), requirements tools are often only aware of weakly structured text. This leads to accidental complexity in integrating requirements with each other and with implementation artifacts. In this paper we describe an approach based on language engineering technologies that results in integrated development environments where both requirements and the code are treated as rst class entities. Parts of requirements can be used directly as the implementation, and they are managed with the same tools that are used for the implementation. The approach is illustrated by an extension of the mbeddr system, a comprehensive IDE for embedded software development, with functionality for managing requirements.
Collecting, organizing and managing requirements is essential in the embedded software development. Complete con guration management and traceability from the code to requirements is required by safety standards such as IEC61508. Still, it is often a cumbersome activity which either is relentlessly executed with major e ort (typically if the process requires it) or it is mainly overlooked, leading to poorly structured and maintained requirements.
One major problem with the traditional ways of collecting and maintaining
requirements is the inadequacy of the supporting tools [
The study in [
In this paper we present an approach to use language engineering and
projectional editors to deeply integrate requirements into software development tools.
Requirements are captured using an extensible language speci c to the
"requirements domain", just as other artifacts are expressed with languages speci c to
their particular domains (C code, state machines, data ow blocks). We have
implemented this approach based on the JetBrains MPS language workbench
and the mbeddr stack for implementing embedded software (discussed in the
next section). The approach leads to four main bene ts:
{ Rich and extensible requirements language: By using the language
modularization and composition features supported by language workbenches,
requirements can have a rich structure, domain-speci c extensions to (generic)
requirements can be de ned, and custom traces or consistency checks can
be seamlessly integrated. The need to extend requirements engineering tools
in order to to properly express requirements was pointed out already almost
forty years ago in [
mbeddr and MPS at a Glance
mbeddr4 is an open source project supporting embedded software development
based on incremental, modular domain-speci c extension of C. It also supports
other languages, which is what we exploit in this paper. Fig. 1 shows an overview,
details are discussed in [
represented as a sequence of characters which are transformed into an abstract syntax tree (AST) by a parser. Instead, a user's editing actions lead directly to changes in the AST. Projection rules render a concrete syntax from the AST. Consequently, MPS supports non-textual notations such as tables or mathematical symbols, and it also supports wide-ranging language composition and extension { no parser ambiguities can ever occur when combining languages.
mbeddr comes with an extensible implementation of the C99 programming
language. On top of that, mbeddr ships with a library of reusable extensions
relevant to embedded software. As a user writes a program, he can import language
extensions from the library and use them in his program. The main extensions
include test cases, interfaces and components, state machines, decision tables and
data types with physical units. For many of these extensions, mbeddr provides
an integration with static veri cation tools [
In this section we describe a set of challenges in requirements engineering as well as our approach to solving them in mbeddr. While not all of the solutions are unique to mbeddr, the combination of features and their exible extensibility is. 3.1
Challenge Traditionally, requirements are stored in a tool-speci c database. Other development artifacts are instead typically stored in version control systems (VCS) such as git, SVN or ClearCase. This leads to problems when trying to keep requirements in sync with the implementation.
Solution In mbeddr, requirements are treated like any other artifact and stored in MPS models (represented as XML les on the les system). This way, requirements and implementation artifacts are stored in the same VCS. Di /merge is supported for requirements in the same way as for any other artifact (see Fig. 2). mbeddr is not the only tool that uses this approach: Requality6 and Yakindu7 use this approach as well.
To represent requirements, mbeddr provides a special language. Each requirement has an ID, a short description, an optional longer prose and additional attributes. Requirements can also be nested. An example is shown in Fig. 4. 3.2
Challenge Tracing can be used to express the relationship between
implementation artifacts and requirements: a program element has a pointer to one or
more requirements, expressing that this particular element is somehow related to
a requirement. By using di erent trace kinds, the nature of "somehow related"
can be quali ed. Trace kinds typically include implements or tests. Tracing is
supported by several requirements tools. For example, Reqtify8 supports tracing
into SCADE models and Yakindu supports tracing into various Eclipse-based
artifacts, requiring speci c tool adapters for each of them. Consistent element-level
tracing becomes a challenge, however, when working with di erent
implementation languages, techniques and tools. The empirical study in [
1. The trace is not an independent program element that is just "geographically close" to the program element it traces. Instead, the trace is a child of the traced element. This means that, if you move, copy, cut or paste the element, the trace moves with it. 2. Since MPS is a projectional editor, the program can also be shown without the traces, if the user so desires. 3. The requirements trace is a well-typed program element that can be used in analyses. For example, it is possible to nd all program elements that have traces to a particular requirement using MPS' generic Find Usages facility. 4. The tracing facility is completely independent of the traced language. Program elements de ned in any (MPS-based) language can be traced. Userde ned languages with automatically work with the tracing mechanism. Our tracing framework still requires users to manually establish and maintain the traces according to the actual relationship between programs and requirements (except in cases where artifacts are generated from higher-level artifacts, in which case traces can be added automatically). However, the approach does solve the technical challenges associated with ubiquitous tracing support. In particular, the fact that referential integrity is automatically checked and that arbitrary analyses can be built on top of the program/requirement/trace data, eases the work of the developer. 3.3
Challenge In today's practice, there is a big gap between requirements and
implementation artifacts: requirements are prose text, and developers are
expected to understand the text and write implementation code that is faithful
to the requirements. This is ine cient, tedious and error prone. In many cases,
aspects of a system's requirements are known to domain experts and
requirements engineers in a structured/formal way. Examples include price calculations,
legal rules or control algorithms. It would be useful a tool were available that
is able to incorporate such structured/formal aspects into requirements { with
IDE support for the languages used to express these structured/formal aspects.
With today's tools, this is hard to achieve, and the study in [
Solution mbeddr supports embedding structured/formal parts of the business logic into requirements, and then use these parts directly in the implementation. Fig. 4 shows two requirements. The rst one de nes a constant BASE POINTS with the type int8 and the value 10. The second requirement de nes a calculation PointsForATrackpoint. A calculation has a name, parameters, and a result expression, which, in this case, uses a decision table (a representation of nested if-statements). The calculation also references the BASE POINTS constant. Using constants and calculations, business users can formally specify some important business data and rules, while not having to deal with the actual implementation of the overall system. To help with getting these data and rules correct, calculations also include test cases. These are evaluated directly in the IDE, using an interpreter: users can directly "play" with the calculations.
To increase the usefulness of the constants and calculations speci ed by business users in requirements, these calculations should make their way into the code directly. Fig. 5 shows a component, expressed in mbeddr's component extension to C that invokes a calculation (the green code). When this code is translated to C, the expression in the calculation is translated into C and inlined.
The constants and the calculations are just examples of possible "plug in" languages into mbeddr's requirements system. Any DSL, using a wide range of business user-friendly notations, can be plugged into requirements. Challenge For each functional requirement there should be a suite of tests to verify it. The functional coverage represents the degree to which all functional requirements are covered through veri cation activities. Making sure that all requirements are veri ed in the code is usually a manual process. Solution The solution to this challenge combines language extensibility and tracing. Language extensions that express test cases and domain-speci c formal veri cations are available, and traces (with suitable kinds) are used to tie tests and veri cations back to the tested and veri ed requirements (Fig. 6, Fig. 7). The deep integration of requirements and code also helps to identify inconsistencies or underspeci cations in requirements. This way, requirements can be implemented, tested and veri ed iteratively, checked automatically and continuously. Challenge To answer questions like "how many requirements were implemented", "what are the quality assurance tasks for a certain requirement", or "how much e ort has been spent on each requirement" one needs today to use various di erent tools, because answering these questions often requires access to the requirements, the traces as well as the implementation artifacts. This makes answering these questions expensive, preventing team members from getting an overview over the state of the project.
Solution mbeddr's assessments provide a exible way of answering questions
like the ones mentioned above. An assessment is a query over the integrated
model. The results are presented in a query-speci c way. Users can navigate
from the result entries to various linked elements. A color code highlights results
that have been added in the most recent update. Fig. 8 shows an example.
As mentioned in the introduction, Winkler and von Pilgrim [
In [
Favaro et al. [
Discussion The tooling described in this paper solves some important challenges in requirements engineering. However, it is assumed that all artifacts reside in MPS, which limits the applicability of the approach (an import/export facility for requirements is provided, though). On the other hand, mbeddr demonstrates the bene ts of building tool suites on top of a language workbench like MPS. In our opinion, this trade-o is worthwhile.
mbeddr allows us to scale the level of sophistication of the language used to
express requirements to the needs of the project. This way, small projects can
use a basic version of the language to express requirements in a very lightweight
form. For more demanding contexts, for example the development of complex
embedded systems, the tooling permits to plug-in domain-speci c extensions of
the requirements language. The e orts of extending the requirements language
is limited (language extension e orts are discussed in [
Since the mbeddr requirements tool looks like a "programming IDE", it may
appear to appeal mostly to programmers. However, in a recent project, the
product manager has expressed that he is very happy using it. Also, we are
currently in the process of introducing a similar tool to business users in the
insurance domain. In both cases, the ability to use domain-speci c abstractions
and notations such as tables or formulas were cited as a major advantage.
Conclusion mbeddr's core idea is discussed in [
Future Work There are two main areas for future work. First, we will add
reporting functionality, targeting requirements documents in HTML and
Latex. The reports will include the diagrams, as well as trace reports. Second, a
colleague of ours is currently working on an MPS editor component that
supports mixing free text (with text-like editing support) and instances of language
concepts. Integrating this editor with the requirements management tooling
discussed in this paper will be extremely useful: for example, one could reference
other requirements from within the prose description of a particular requirement,
while making sure that this reference would take part in refactorings. In addition
we may experiment with integrating information retrieval techniques to suggest
possible traces between requirements and development artifacts, as suggested by
Hayes et al. in [
Acknowledgements We thank the mbeddr and MPS teams for creating a powerful platform that can accommodate the things described in this paper.