Continuing the Requirements Discussion

[JosephLloyd]

Thank you, Chris, for your great presentation last night.  For those not there, Chris presented the concept of adding a static block to your block diagram to keep track of requirements alongside the code itself.  This allows you easy access to information about what requirements your code might satisfy and other metrics, such as maturity.

I wanted to continue that discussion some.  A static block diagram element, such as the array of clusters that Chris used, can be tricky.  While the traversal code that searches for block diagram comments that was shown can display the contents of block diagram elements, I don't think it has the capability of editing them programatically.  If anyone knows a way to do this, let us know!  If editable, then you can run code for unit tests or requirements checking that can automatically update this dataset with last tested dates, pass/fail/coverage info, etc. without doing it by hand.

A front panel object is more accessible programmatically, though less elequent since its not next to the code itself.  But it too can be tricky depending on what you want to do.  If you include an output reference to your front panel cluster array of requirements on all your VIs, you have the ability to read the contents of the cluster array and edit it, but only after the VI finishes executing.  Once edited, you can set the new values to default programmatically with VI server (see here), thus keeping the information stored alongside the VI itself.

If you need to get access to the requirements cluster array while the code is running, this can be very difficult.  You can't get the output, since the VI isn't done executing, and any input you wire over-writes the existing content, defeating the purpose of the requirements tracking scheme.  However, there is a way around this.  If you create a cluster containing only a reference to the requirements array of clusters, my IMS Cluster Tools has a function that can populate this reference with the actual run-time reference of the local only requirements array of clusters.  Of course, in order to get access to this cluster while the VI is running, you can't use the output of a cluster of a reference, instead you need a reference to a cluster of a reference to the requirements array of clusters.  Confused?  So am I, but I've attached an example (LV2011+).  Note that this is a deliberate violation of dataflow; hence my recommendation to not use Cluster Tools unless you know you really need to.

If you unzip the files in the example, open ReqCheckTool.vi.  This calls Chris's Static Example.vi, which I have modified to include both a reference output to the requirements and an input for a reference to a cluster of blah blah thingy using my Cluster Tools' register references tool.  I've also added a wait.  If you run ReqCheckTool you'll see the reference output populate and the current value of the requirements show up after the Static Example finishes executation.  If you have my cluster tools installed, you'll see the reference and current value populate after a short delay while the VI is still running.  I then call a VI from the application note I linked to above to save the default values so they're stored with the file.

This programmatic access to requirements data allows us to continue along the lines of Chris' presentation to implement even more thorough requirements tracking.  I think there's other interesting ways to take this further as well, for example with an Xcontrol which I'll try playing with when I have some time.

[JosephLloyd]

I've designed an XControl that allows you to perform requirements management directly in any of your VIs.  Its like one button to rule them all.

Simply place the control on your front panel.  No additional code needed.  Click on the glyph and the control displays requirements and information about your code.  Add some comments, or new requirements and the control defaults itself to the new values.  This utilizes the Make Current Values invoke for all controls.  If you're uncomfortable with other controls in your VI changing default values, there's a setting to disable it so you can manually set to default.  When you run your code, the control minimizes and becomes transparent, so its out of the way.

Since its a control, it can be scanned and its contents edited remotely by automated routines.  It's quite possibly the easiest way to now do requirements in LabView.  I plan to put together an exe that manages and reports on projects using this free control.  If you have any features you want me to add, let me know.  This seems pretty useful so I think I'll add it to the NI Tools Network for everyone to freely download.  Though I'll need to create an example.  Any ideas?

[jdebuhr]

Where is the control? I would like to check it out

[JosephLloyd]

Ahh, good question, I have the moderately annoying habit of placing control pallettes in the Modern group because it is the default installed display group.  Look for RXX.  For some reason JKI's VIPM installer wants to show the functions pallete when you click "show palletes" which produces a weird labview error since there are no block diagram functions associated with this install.

[jdebuhr]

oh so the control is int he IMS Cluster Package then, I misunderstood as I read it

[JosephLloyd]

Uh, no, its attached to my 2nd post in this thread on the NI CUGM forum, the file ims_lib_rxx-1.0.0.11.vip, a JKI VIPM installer.  I don't think attachements show up in the email transcripts if you're seeing this message there.  If you can't find the attachment let me know!

[jdebuhr]

nope the attachments are this:

https://decibel.ni.com/content/servlet/JiveServlet/download/48584-29513/socialgroup_image_small

Tried Firefox and Chrome.. although it looks like something else is going on as many posts have changes to the user name now being "restapi"

[JosephLloyd]

Here, I built a version with an example integrated into the example finder.  I put in on our website here.