LabVIEW
How granular do you get with your functional requirements?
On a site note, be careful if you specify a "communication failure error".
The error made it to the DCS system's punch list. The only way to raise the flag was to break communication, but this wouldn't be visible on the DCS system (because there was no communication).
I had to re-write my software to simulate the error...
It is also really silly to loop test signals from my 'flow computer' to DCS system at 0%, 20%, 40%, 60%, 80% and 100% when these signals where communicated through modbus... And also the ranges where software defined, so basically arbitrary.
Of course when done loop testing, someone finds a list with new ranges, and you have to start loop testing again...
Careful what you wish to test for...
Search LabVIEW like a graph! 
@Hoovah, well you did say " I would often run through test procedures and fail things as they were written, when others would pass based on their interpretation." thus i'd taken your first attempt as a strict instruction. 🙂
Your 2nd revision is more open ended and a better way or writing it.
We have people here that works with those things full time, maybe i should ask them. 😄
@Yamaeda wrote:
@Hoovah, well you did say " I would often run through test procedures and fail things as they were written, when others would pass based on their interpretation." thus i'd taken your first attempt as a strict instruction.
I threatened to fail a line of devices because the test procedure stated a requirement as "Must survive a 10MS power outage." 10 Megaseconds!? So we need ~1/2 a year to do this test. I was yelled at for being contrarian stating "they obviously meant 10 milliseconds." To which I replied "Then fix the procedure."
@crossrulz wrote:
@Yamaeda wrote:
@Hoovah, well you did say " I would often run through test procedures and fail things as they were written, when others would pass based on their interpretation." thus i'd taken your first attempt as a strict instruction.
I threatened to fail a line of devices because the test procedure stated a requirement as "Must survive a 10MS power outage." 10 Megaseconds!? So we need ~1/2 a year to do this test. I was yelled at for being contrarian stating "they obviously meant 10 milliseconds." To which I replied "Then fix the procedure."
LOL! My first thought was 10 Mega Sievert ... i don't think it would survive that either!
@crossrulz wrote:
I threatened to fail a line of devices because the test procedure stated a requirement as "Must survive a 10MS power outage." 10 Megaseconds!? So we need ~1/2 a year to do this test. I was yelled at for being contrarian stating "they obviously meant 10 milliseconds." To which I replied "Then fix the procedure."
Oh yes this is why I'd fail most tests, because I ran it the way it was written. Another requirement I had was "The test software shall be stable and not crash after running continuously for one year" I was like uh, okay well it will take one year to dry run this requirement, one year to run the SAT, and one year to run the FAT. But the customer had already signed off on these requirements by the time I was tasked with writing the test procedure for it. We obviously had to go back and explain to them why these requirements were written poorly.
@jcarmody wrote:
Yeah probably. But words have meaning. If we signed up to say we will do one year of testing for a factor acceptance test, and a site acceptance test, and then don't do it, that is breach of our contract. My obligation is to tell the program manager that the requirements were written in a way that it will mean either not testing our own requirements which we agreed to do, or taking 3+ extra years to deliver. They can make the call on which they want to do.
I love you (even more) for saying "words have meaning." But, there's got to be a middle ground. I imagine something like this:
Glen is a former coworker who'd maliciously misinterpret a requirement because "it doesn't say I can't do it this way".
I should have mentioned this earlier as it's probably important: our requirements are 100% internal. We're writing them for ourselves so we can build test equipment that we're going to use.
@jcarmody wrote:
I should have mentioned this earlier as it's probably important: our requirements are 100% internal. We're writing them for ourselves so we can build test equipment that we're going to use.
Oh yeah that changes things quite a bit in my opinion. For "The test software shall be written in LabVIEW 2020" I'd just be like, yup I've seen the source code, I know it is I'll sign off on it. But when writing a test procedure that is part of the deliverables to a customer, things are given more scrutiny.
