Home > Eclipse, EMF, Requirements Management, Xtext > Formal Requirement Specification with Xtext & ProR

Formal Requirement Specification with Xtext & ProR

Requirements engineering is a critical yet difficult part of software development. Although a lot has been said and written about using formal methods in Requirements engineering, it is often not practiced. Systems requirements are mostly couched in very high level terms and made comprehensible to end users.  “Formal” Requirement Specifications almost always remains a myth or a specialist thing. A good alternative here would be to use DSLs (Domain Specific Languages) for requirements specification. Or better mix DSLs with an standard requirements specification format like OMG ReqIF. A DSL offers the flexibility of fine tuning the specification language so that it is moderate enough for customers to understand and also for a specialist to process it.

To realize this and as a first step towards filling the void I was talking about last year, a open source toolset has been developed by itemis in collaboration with Düsseldorf University in the scope of VERDE project. The toolset consists of a OMG ReqIF based metamodel, a UI (named ProR) to edit requirements in a DOORS like table view manner and an Xtext extension to integrate DSLs. The tutorial talks about the Xtext extension to ProR editor.

To see the tool in action have a look at the screencast by Ömer Gürsoyhttp://www.guersoy.net/knowledge/crema

ProR with Xtext Integration


Creating a formal language

Please follow the  Xtext Userguide to learn how to create formal languages using Xtext

Integrating the formal language to ProR

  • Create a new Eclipse plugin Project
  • Add the following plug-in dependencies to the new project.

The last two dependencies are the newly generated plugins for your language by Xtext

  • Create a new extension for the extension point de.itemis.pror.presentation.xtext.configuration.
  • language is the id of the newly created language.
  • extension is the file extension of the newly created language

Please note that this is not the project/plugin id but the language id 

For injector, implement the interface de.itemis.pror.presentation.xtext.core.IXtextInjector or extend de.itemis.pror.presentation.xtext.core.AbstractXtextInjector. The getInjector() method should return the Google injector of your Xtext language UI project. For example,

public class DomainModelInjector extends AbstractXtextInjector {

	public Injector getInjector() {
		return DomainmodelActivator.getInstance().


Please note that it might be necessary to export the *.ui.internal package from the UI project to access the XXXActivator instance as above. We will improve this as soon as Xtext makes the injector public in a different way.

Running ProR with formal language integration

  • Launch the newly created plugins from your workspace which has ProR already in the target

Needless to say, build the newly created plugins and add them to the ProR target after testing

  • Create a new RIF file in ProR
  • Follow ProR documentation and create a datatype for the newly created language. In the example below we use an existing datatype in ProR, T_String32k
  • Create a new Presentation Configuration.
  • For Language enter the Language id of you new language as before

  • For Presentation Datatype, select an existing datatype. T_String32k in the example below

  • Double click on the requirement attribute which is linked to the new datatype in the ProR grid. Description in the example below.
  • A pop-up dialog opens up with a full-fledged editor for the newly created language. The editor supports most Xtext features like syntax highlighting, auto completion, error highlighting etc.

  • Enter your formal description in the editor
  • Click on a different cell to accept the new value
  • Save the file to persist the contents as usual
  1. Bernd Kolb
    May 17, 2011 at 4:45 pm

    Hi, some of the images are broken and link into an itemis-internal page


    • May 17, 2011 at 4:58 pm

      That explains how copy-paste of images into the WordPress editor worked (rather, appeared to be working). Thanks for pointing this out Bernd. Its fixed now

  2. May 27, 2011 at 4:08 pm

    I finally managed to try this out – works like charm. The next step will be to integrate the DSL with information taken from other parts of the model (I haven’t figured out how to do that yet, as I am new to Xtext). This will open many possibilities (e.g. defining a vocabulary in one part of the spec and using it in the requirements).

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: