Requirements Compiler

[ShaunR]

For a while now I've been mulling over a gap in what I see as software in general. This has nothing to do with LabVIEW, per se, but it is the reason we need CLAs and System Engineers to translate what the customer wants into what the customer gets.

 

A good example of this is the CLA exam. There, we have a well written, detailed requirements specification and a human has to translate that into some "stuff" that another engineer will then code. So why do we need an engineer to translate what amounts to pseudo code in to LabVIEW code?

 

Maybe 10-15 years ago (before scripting was a twinkle in the milkman's eye), I had a tool that would scan word documents and output a text file with function names, parameters and comments and this would be the basis for the detailed design specification. I would create requirements for the customer with meetings and conversations and generate a requirements specification that they could sign off in Microsoft Word. Unbeknownst to the customer, it had some rather precise formatting and terminology. It required prose such as "boolean control" and "Enumerated Indicator"  It also had bold and italic items that had specific meaning - bold was a control/indicator name. Italic was a function or state . It was basically pseudo code with compiler directives hidden in the text.

 

Roll forward a few years and people were fastidious about getting CLD and CLA status. Not being one of those I looked at the CLD exam and saw that a big proportion of the scoring was non functional. By that I mean making sure hints and descriptions are filled in etc - you know, the stuff we don't actually do in real life. So I wrote a script that read the exam paper (after exporting to text), pulled out all the descriptions and filled in all the hints, labels and descriptions. It would probably take 5-10 minutes recreating it in an exam but ensure 100% of the score for that part of the test (this later became Passa Mak, by the way).

 

So that got me thinking, once again, about the CLA exam and the gap in technology between specification and code. I have a script that takes a text file and modifies some properties and methods. It's not a great leap to actually scripting the "stuff" instead of modifying its properties. I don't have the Word code anymore, but  should be able to recreate it and instead of spitting out functions, I could actually script the code. We could compile a requirements specification! If not to a fully working program, at least so that an engineer could code the details. Doesn't that describe the CLA exam?

 

So I looked at an example CLA exam.

 

Woohoo. Precise formatting already

 

.......to be continued.

Edited September 18, 2015 by ShaunR

[hooovahh]

The problem is the people customers.  You must know that a requirements document, or rather a text document from a customer that very loosely describes what they want the software to do, is going to vary in format, wording, and technical level from customer to customer.

 

I've seen plenty of documents that were supposed to describe the software a customer wanted, but was more of a stream of consciousness, describing what they wanted, including but not limited to things like "the operator won't get bored using the software".  Good luck getting them to use a word like Boolean, or Enum.  This is hardly pseudo code, and requires some amount of magic and hand waving when it comes to bidding on project with this type of specifications.

 

For me the real meat of what needs to happen is a sit down conversation with the end user, asking what they want it to do.  Flush out what they really need, and what they want.  Understand priorities, and try to think of all the pit falls, technical limitations, and dead locks where they ask for something in one place and contradict it elsewhere.

 

I'm not saying it can't be improved, but I'm trying to say in my world why so much effort is put in translating this document to an output like software.

 

That being said I agree that you can fail CLD/CLA simply based on not understanding what it wants.  I remember hearing someone take the CLD coffee maker exam having never drank coffee, or knowing what it was.  If it were me in real life I'd sat down with the customer and discuss what they really want and how they want it to work.

 

By that I mean making sure hints and descriptions are filled in etc - you know, the stuff we don't actually do in real life. 

I do.

[ShaunR]

The problem is the people customers.  You must know that a requirements document, or rather a text document from a customer that very loosely describes what they want the software to do, is going to vary in format, wording, and technical level from customer to customer.

 

I've seen plenty of documents that were supposed to describe the software a customer wanted, but was more of a stream of consciousness, describing what they wanted, including but not limited to things like "the operator won't get bored using the software".  Good luck getting them to use a word like Boolean, or Enum.  This is hardly pseudo code, and requires some amount of magic and hand waving when it comes to bidding on project with this type of specifications.

 

For me the real meat of what needs to happen is a sit down conversation with the end user, asking what they want it to do.  Flush out what they really need, and what they want.  Understand priorities, and try to think of all the pit falls, technical limitations, and dead locks where they ask for something in one place and contradict it elsewhere.

 

I'm not saying it can't be improved, but I'm trying to say in my world why so much effort is put in translating this document to an output like software.

 

That being said I agree that you can fail CLD/CLA simply based on not understanding what it wants.  I remember hearing someone take the CLD coffee maker exam having never drank coffee, or knowing what it was.  If it were me in real life I'd sat down with the customer and discuss what they really want and how they want it to work.

 

I do.

 

You are in the wrong stage of the process.

 

If you are at the bidding stage, then you will be creating a proposal. That proposal becomes the specification after some back and forth and sit-down meetings. The supplier always wins the terms and conditions war as well as the final specification document. You obviously haven't gotten to the trick of making them adopt your specification by marking and amending your proposal.

 

Anyway. This is all somewhat relevant but a distraction.. We are talking, at this stage, of taking a precise, well defined document and doing what they do in the exams. If we produce a method of translating all NI CLA specifications into exam results (which I have sort of done already,  so know it is possible) We can discuss natural language heuristics later for general use cases.

 

Don't throw the baby out with the bathwater.

Edited September 18, 2015 by ShaunR

[hooovahh]

Don't throw the baby out with the bathwater.

Either you misunderstood what I said, or you misunderstand what that expression means.

[Val Brown]

FWIW, this thread so far confirms its original premise, reveals what "the baby" is and what "the bathwater" is.