LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to collect/organize user requirements?

Hello everyone,

I have been a self taught LV programmer for years now, who never focused much on the UI design process, at the beginning of a big LV project. Now, I am about to embark on a big project, as a team leader, I have started thinking about the methods my fellow LV developers use to collect/organize and evaluate the end-users needs/requirements in a big LV project. I would really appreciate if anyone could point me towards some reading materials or your input on how to approach this phase of a LV project. Specifically, I would like to know about the methods that have worked for you before and how you have approached this design process of a LV project.
Message 1 of 3
(3,651 Views)
I can think of 2 sources I know which discuss this - the LabVIEW style guide and Damien Gray's presentation on the topic. For some reason (NI replaced their search engine a couple of months ago and it's surprisingly bad), I couldn't find the link to the presentation, so I'll just upload it.

Message Edited by tst on 05-03-2005 12:56 PM


___________________
Try to take over the world!
0 Kudos
Message 2 of 3
(3,622 Views)
I can not cite any written material of the top of my head. I will drop some ideas.

1) Ask for the "Elevator Speach". The "Elevator Speach" is the answer you would give if you suddenly found yourself alone on an elevator with the president of your company and they ask "So what does that application do?" The elevator speach should just one or two sentances. Once you get the speach write it down and keep it in mind throught the life of the application development. It helps to constrain scope and in the end the application has to do what is in the speach or it is useless.

2) Ask about some of the "dreams" and "nice to have" functionality and also the "core functionality" (this is a technical version of the elevator speach). Keep seperate lists and share these with your customer so they know up front that they are not going to see the "dreams" until after the core is done.

3) Avoid asking the user how they think things should be done. Decide for yourself what is the best way, then present your ideas to the user. That way you can design things so that you can take advantage of the software environment.

4) When presenting your ideas, leave a small obvious flaw in the demo so the user can give you some constructive feed-back. They often feel that they are doing their job if they do not offer feed-back. Make their job easier. If you present a perfect app, they will have to work very hard to find something for you to change and it will probably complicate your life.

5) Once you find the person that knows of the technical stuff associated with the application, have them go through a "game" of pretending the application is done, and let them tell you what they plan on doing and what they expect. These will be you "use cases".

OK done for now, gotta get to work!

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 3
(3,588 Views)