Archive

Posts Tagged ‘requirements’

RIF meets ReqIF

August 9, 2011 6 comments

ReqIF is the new OMG standard for requirements interchange. RIF is the predecessor to it and already supported by many tools like DOORS. RMF delivers both the standards as Ecore models. However, there are quite a few differences between the two standards making them type incompatible.

The main differences lies in,

1. Element naming.
For example, the element RIF is now called REQIF, SpecHierarchyRoot is now Specification and so on.

2. More specification types.
If you know the RIF model already, you would know the concept of SpecTypes. This element allows creation of new types. In RIF and ReqIF, SpecObjects (the instance values)  and SpecRelations (relations between instances) are typed. However, in RIF, both refer to the same SpecType element, where as ReqIF has different types called SpecObjectType for SpecObject, SpecRelationType for SpecRelation and some more new types.

3. More attribute definition and value types.
RIF had only a single attribute definition type called  AttributeDefinitionSimple. ReqIF extends this for different the different data types as AttributeDefinitionIntegerAttributeDefinitionRealAttributeDefinitionString etc. Same for values as AttributeValueIntegerAttributeValueRealAttributeValueString etc.

4. RIF XML uses no XML attributes where as ReqIF uses a lot of them.
For example, IDENTIFIER is an XML element in RIF whereas it is a XML attribute in ReqIF.

This brings us to the question – how do I convert my existing RIF files to the new ReqIF format? Considering the fact that there are a lot of industry samples in RIF format, we thought of writing a RIF to ReqIF converter. The transformer takes in a RIF file and transforms it into a ReqIF, retaining all its contents. You could also do an in-memory transformation between the two models.

This is how a RIF source than we passed to our converter looks like after transformation.

RIF Source

ReqIF Target

Advertisements

Formal Requirement Specification with Xtext & ProR

May 17, 2011 3 comments

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


Installation


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 {

	@Override
	public Injector getInjector() {
		return DomainmodelActivator.getInstance().
                               getInjector(getLanguage());
	}

}

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