Calling all LV Architects and Developers: advice required on Build Specifications and Requirements

[testswan]

This is a call to all contractors, consultants, architects etc...

I have been asked to develop and automated test system...  

Long story short - can anyone offer me an example or two or copy of  a specification and requirements document given to them by a company that is in need of a labview system, which specifies what it needs to do, what it should look like, how the data should be stored etc...

The reason I ask is that I have not been given any spec.  And trying to build a system without one is non-sensicle to me.  I am fairly new to labview as well.

The way I see it is that if a job goes out to tender for quotes from different contractors, surely there must be some kind of spec document so that they can give their quotes and understand how to build the system from the ground up and plan ahead.

maybe it should include things like:

Including:

Types of tests

Things to be tested

Who will be using it? Testers/engineers/analysts?

Who will maintain it? What skills do they have?

What should it look like? Colours, menu’s test result feedback format(s)…

What features and functions do they want?

How much test modification control does it need?

Please feel free to add to this list

Hope you can help/advise.  all comments welcome.. Thanks all

[PiDi]

Let's get some things straight first:

• There are no companies in the world in need of "LabVIEW system". There are companies in need of automated test systems, for which LabVIEW is suitable choice. But this choice is mostly made by you, not by the client. If client explicitly asked you to do it in LabVIEW, he's still in need of test system, but one of the additional requirements might be LabVIEW ("We're standarized for NI hardware" or "Mr. Smith here knows LV, so you'll sell us codes and he'll be able to modify them", etc).
• Specifications given by clients are rare. In-depth specifications are unicorns. Most clients would just give you "hey, we want to measure this and check that". And that's just ok - they're not experts in automated test systems, you are. They're just their domain experts. That makes YOU responsible to gather requirements for their test system by cooperating with them. If they knew what exactly is needed to archieve their goals, they'd just do it without your help (or hire you as mindless coder).
• No one would probably just give you any specification here. At best such specification is company know-how, but most common it's just proprietary information.
• Requirements gathering is hard. Mainly because they're changing. And there are no silver bullets, no "template documentation" which you can just fill and everything would be clear.

Now, adding to your questions list:

• What do we automate? Why? What do we want to archieve?
• What will be measured? How? What are specifications of measurements (sampling rate, accuracy, etc)? What hardware do we need?
• What are the use cases for the system? (you can look up "use case" in internets; this is also closely connected to "Who will be using it?)
• How we'll decide that the system is complete and working (Will we have some functionality check list? Is there any calibration required? Do they have any procedures - MSA, etc? Should we provide training?)
• Would it be easier if you'd make some demo to show?
• ...and that's just the top of the ice berg 😉

[Norbert_B]

Well, just to clearify PiDis "realistic" post, i want to add:

- Not having a specification document is a HUGE disadvantage for both parties: client and contractor. To be more elaborate: Not having any specifications is plainly stupid.

- It is true that most of mankind is stupid. That means: The majority of projects are done without proper collection and discussion about specifications. That is one of the major reasons why so many projects fail.

While talking about specifications is a nice thing, the tools you select to implement those specifications (which become "requirements" for the project if following proper project management!) is the second important thing. Does your client request you to do this in LV? If not, what makes you think that LV is the best choice?

Honestly, i would go for TestStand as it already provides you the most imporant parts for automated test system control software without you having to implement a single line of code (or VI). Yes, you WILL have to implement things in C/C++, C# or LV (or other languages) when selecting TS, but that effort is way less compared to implement your own sequencer and reporting mechanism. And YES, you have to get familiar with TS to be effective.

Did you have the chance to attend any LV class? Is there a possibility for you to attend a TS class?

I think, these will give you some valuable information and "best practises" on how to approach, manage and implement software for tasks like automated test control.

Norbert

[testswan]

I agree, just making sure I was not the only one who struggles to find documentation.

I do however have experience in bespoke software developement, where even as the client there is some form of specification. If not how do we measure its success and level of completion, In line with a deadline date and I like your comment on functionality checklist. 

I will use the questions you mentioned and the more 'relevant questions' that can be answered.  I have learned from prevous projects and other peoples lessons learned that, lack of documented and agreed specs is a red hot candiate for an accessory to project failure.  Additionally,  though when designing a framework or archticture surly you begin with the end in mind.  otherwise changes made later the functionality may not have been accounted for; it and therefore it either does not get done or ithe framework has to be rebuilt from the ground up.  

I think I will as you say create a list of what 'I think' would be good to have, (functions and features wise) without digging myself a hole.  

Heard a quote the other day. "People dont know what they want unitl you show it to them".  

From you statement I gues there is requirements gathering checklist or need to know from the start or else...?

I have done the teststand course, and am certainly considering using it.  But was ages ago and will need to somehow work with it as I go. 

[Norbert_B]

I recommend you to look for IEEE specifications for software management. The most important IDs for this are:

- 830: Requirements Document

- 1058: Project Plan

- 829: Test Plan

- 1016: Design Document

- 1028: Reviews and Audit

Note that this list is incomplete and lists only the most important international recommendations and best practises on professional software project management. It is up to your discretion to follow this conventions or to try to re-invent the wheel.

Norbert

[testswan]

Are these documents and standards what you use?

[Norbert_B]

---

@testswan wrote:

Are these documents and standards what you use?

---

These are documents and standards everyone SHOULD use. Most companies use "sporadic subsets" of these items, but we all try to improve, right? So you don't need to use all these at once, but you have to be aware of these standards and successively try to adopt them in your project management.

Norbert

[testswan]

I am familier with some of the documents, or guidlines I as relate to them,  however, they are very generic and one size does not fit all. 

I suppose my main reason for this thread was to see what labview folk currently use for there projects what questions would they ask if little or no requirements are specified. There are many companies who create automated solutions using labview, but without an accurate specification how can they possibly give an accurate quotation and completion date? Surley they must have some idea upfront? They themselves you would think standardize something.

Come on peeps, 

[Norbert_B]

Well, most of project management is "experience". Without self-collected experience, it is very hard to answer the questions for yourself. On the other hand, all answers you receive from other developers/managers can be quite inaccurate for yourself as "the way of working" is different.

That being said, a generic recommendation of processes and documents is valuable. And this is exactly what IEEE provides.

You can expand your search as there are adoptions of IEEE to different "use cases". One buzzword i can throw at you in this regard is "Automotive SPICE". Looking into this, you will find quite some commonality to IEEE, but also slight differences.

It is your own task to select, try and work with recommendations and standards as it also your task to train your customers to also follow (international) recommendations.

Norbert

[jcarmody]

---

@testswan wrote:

I am familier with some of the documents, or guidlines I as relate to them,  however, they are very generic and one size does not fit all. 

I suppose my main reason for this thread was to see what labview folk currently use for there projects what questions would they ask if little or no requirements are specified. There are many companies who create automated solutions using labview, but without an accurate specification how can they possibly give an accurate quotation and completion date? Surley they must have some idea upfront? They themselves you would think standardize something.

Come on peeps, 

---

I've only worked at one company that wrote bullet-proof specifications.  We'd write the specification, the vendor would read it and submit a "statement of understanding" that we would then read and use to update our specification.  Wash, rinse, repeat until both parties are as sure as reasonably possible that we both understood each other.  That was a wonderful environment!

[Almost] nobody does that.

I worked for an NI Alliance partner and discussed this topic with the company's president.  He said the same thing - nobody does that.  You're the expert and they're paying you to tell them what they want.

I'm of the opinion that it'll take me longer to write a solid specification (that we can use to hold a vendor accountable) than it will take me to do the entire project myself.  My assumption is that possible ambiguities are handled in the huge price-tag.  If they're lucky, things will go reasonably well and they'll make a reasonable profit.  If not, well...  I'm with you, though.  I don't know how anybody can stay in business like that.  I wave my hands and say I want "this", they wave their hands and say they'll do "that" and we both go away hoping that we've made ourselves clear.  It's insane, but it seems to work.