Example Code

Example Veristand Requirements Management with Requirements Gateway

Code and Documents

Attachment

Download All

Requirements Gateway is a great tool for managing and reporting on code coverage based on a requirements document.

Whilst Requirements Gateway 2012 is capable of dealing out of the box with LabVIEW, TestStand, Doors, Word and many others, there isn't a conversion tool to handle direct communication with Veristand.

Since all the files for a Veristand project (the Project, the screen workspace, the calibration and the system definition file) are all XML based, then a new type can be created to allow connection to Veristand projects.

Attached is an example (pretty empty) starting point for doing this. It is by no means complete but should serve as a roadmap for showing how to implement new sections for display in Requirements Gateway, as well as presenting a simple [Covers: xyz] reference item for pasting in to the Description field.

Assuming a basic understanding of setting up a project in Requirements Gateway...(for more information, start here http://www.ni.com/white-paper/8330/en/)

When you unpack the two .zip files, place them side by side in the same directory as shown,

Directory.PNG

otherwise you will need to re-point the Requirements Gateway project at the place where you've set up Veristand 2013 project in to.

Your project should look like (note the files are relative to the Requirements Gateway project) :

RqGwy Project.PNG

The example requirements sit in the Word document int he Veristand Project zip file. This uses the Requirements ID style as normal for Requirements Gateway.

The elements under a type in the Types List define how Requirements Gateway identifies traceability information in a text or XML intermediate file. Type elements use regular expressions to specify patterns in the text of the intermediate file for Requirements Gateway to identify instances of an element. Types that use XML intermediate files also specify the structure of the XML data to identify traceability information.

Requirements Gateway stores custom types in a .types file, with the same filename as the name of the project file, in the same directory as a current project.

You can place custom types in the public folder in the Types List on the Types pane to make the types available for all projects. Requirements Gateway stores the type definitions for the public folder in <Requirements Gateway Public>\Config\types\public\public.types.

Refer to Chapter 5, Customizing Types, of the Getting Started with NI Requirements Gateway manual for a tutorial on creating a new custom type and using the type in a project.

For the Veristand type in the included example, the main 3 points are the type of type is XML, the file extension list incorporates the 4 file extensions used in Veristand and the reference (since we're using Veristand to cover a requirement, not hold requirements) uses a simple tag to match any Description field.

ReqGwy Types.PNG

Personally I use Notepad++ (download here http://notepad-plus-plus.org/ ) for reading xml files since you can select a style that allows you to manage the tags as twisties by changing the language of the opened file. Since Veristand is not a supported Edit Tool, then we will not be able to open in to Veristand from the Requirements Gateway 2012 project.

If we look at the Veristand Project itself, there are several places you can right click and select properties. This will allow you to enter text in to the Description fields.

Veristand Project.PNG

Right clicking on the nivsscreen and selecting properties for instance yields :

nivsscreen properties.PNG

Since we've already created the Description reference in Veristand and the project has the linkage between the Veristand type and the Word document with the requirements in, then you can right click in Requirements Gateway on a project and copy for.... to get the correct nomenclature to paste in to the Description field.

In this example, I've placed covering requirements text in the Workspace, the Calibration, the System Definition File item inside the project and inside of a user channel inside the System Definition File itself

If we open up the project file in Notepad++ and find one of the lines where the description field has text in it, then we can see that near the middle is a tag marked <Description>[Covers: Req3]</Description>

VS Porject in XML.PNG

Based on the fact that this is XML and knowing the layout and the tag names, creating the reference is pretty straight forward. (Note this is not done in chronological order - earlier I mentioned being able to right click and copy for... but that doesn't exist until after we have the reference created so I used the layout we have for LabVIEW)

The reference tag (target) regular expression is ^\[Covers:[ \t]*([^\]]+)\]

In other words, once inside the tag, we start immediately with a [Covers: and then multiple tabs or spaces until we get to text that doesn't include a ] and then expect to close off with the ].

Note also the Display is set as [Covers: $i]   where the $i refers to the requirements ID we're using.

Reference.PNG

With just the reference in place and the file extensions, it's possible to just manage the "here's a Veristand project and it covers xyz requirements".

What's nicer is to include sections where we can get a better idea in Requirements Gateway just where the coverage lives.

To do that, we need to look closer at the XML layout for the Veristand files.

Fundamentally, every low level item is marked by a <Section> tag in the files. Unfortunately this means that the path to each "Section" is not unique.

Every file starts with a <Root> tag, so we can use that as our Requirements Gateway section starting point.

Root Section.PNG

The Name attribute is what we'll use for the display in Requirements Gateway, so that's marked as the Label.

Under that, we have Target Sections - this is specific to the Systems Definition file, so we need to make sure that it's an "if you see this" then show that. This is why it's going down through the tree to show it from a parent perspective (i.e. rules checking, TargetSections should only ever be found under a Root tag). Since we can also limit the Target Sections to a specific Name, we can fixate on that as being totally valid using a condition :

Target Section.PNG

Note the fixed "Display:" text used at the top.

Under that we should have Targets, and under that Sections.

The challenge is that the Sections tag can appear in multiple places, but we only want to use it as a section here if it's got the right parenting in the tree, so we have to mark this final section as the reference item, and show the <Target> tag above it again. Otherwise it will get confused with any other <Section> tags found in different places.

Target Section Section.PNG

To make that <Section> tag the reference (see the green pointer) you need to right click on it to bring up the sub menu nd set it in there.

Other <Section> tags such as Aliases are set specifically again using the Name attribute with a matching condition.

Aliases Section.PNG

Armed with the above, it should be possible to navigate the XML file formats and extend this example to include other areas.

Note the use of the GUID type throughout - there may be cases where a GUID is not actually unique (I came across one when dealing with CAN interfaces) and this may cause a rules check warning.

Any thoughts or requests to extend, please feel free to leave me a comment below

Thanks and good luck.

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Contributors