In the last couple of weeks, I have been working on an open source project called REL - Requirements Engineering Language. Its core is a domain specific language, which enables requirements engineers to define a so called requirements model. The model contains type definitions and enumerations, which are then used to formally describe the actual “content”, i.e. the requirements written by developers. All data resides in text files, which can be committed into a git repository. Besides the DSL, the REL framework contains a (partially completed) implementation of the language server protocol, to get IDE support for the language, and python integration. For more technical details about the framework, have a look at the README.md on Github or the still growing developer’s guide.

Requirements engineering in software projects always consists of three parts:

  1. The actual content, which means the requirements that describe the resulting product and the metadata like attributes, links, comments to the requirements etc.
  2. The tooling to manage the requirements (like DOORS or, yes, as usual, the multi-purpose powertool Excel)
  3. The processes, that define how requirements work is done in the project, e.g. collaboration with partners, quality metrics, tracing of requirements towards tests and others.

2 and 3 are ideally covered by the requirements manager(s) of the project, whose role cover establishing processes and tools for requirements work within the project. Processes and tools, well documented and supporting an agile workflow, are the enabler for #1: All project members have to contribute to the “content”, as in most projects, the knowledge about the product is distributed among all team members. Based on my experience, projects often neglect the efforts to establish solid processes and tools for requirements engineering, which are ideally available right at the beginning of the project! If this is not the case, developers don’t know where to put their requirements, and in worst case, gradually loose track on this fundamental part of their (software) development work.

To address this challenge, I created the REL framework, whose purpose is already well described in the developers guide, therefore I quote it here again:

In a nutshell, the REL framework shall enable requirements engineers to define a requirements model and the corresponding processes, which helps the whole team to focus on the actual work of writing valuable requirements. With the domain specific language as core element, well-known agile processes can be applied. The tooling provided in the framework is focusing on clear usecases, and always provides hooks for project-specific extensions. In an ideal world, requirements engineers use the REL framework to define tooling and processes upfront, so that developers can then focus on the creative work of writing requirements.