Pay for report development

Mike or Penny Novack stepbystepfarm at mtdata.com
Tue Mar 29 15:18:36 EDT 2011


>My recommendation is to come up with a full set of functional
>requirements for your report:
>
>* what will it be reporting
>* over what accounts
>* performing what computations
>* with what filtering
>* how should it be displayed?  (giving examples is good)
>
>...  as much detail as you can.
>
>Perhaps do this in a wiki page on the gnucash wiki?  And then send your
>request to -devel with your offer(s).  If nothing else, thinking about
>the problem thoroughly and laying out the requirements for the report
>can help you clear your mind on what it needs to do, and perhaps help
>the developers understand what you need and in what form.
>
>Good Luck,
>  
>
And maybe I can help? (besides being a retired senior systems analyst 
also "business analyst")

In a real world project usually something like 20% of the time is spent 
getting the "requirements" straight. Far from trivial as usually at the 
start the "users" only have a general idea of what they want and aren't 
taking ANY of the "unusual situation" possibilities into account. What 
the analyst does isn't supply the answers but the questions for the user 
group along the lines of "and in THIS situation would want what to 
happen?".

Without very clear requirements the results are bound to be 
disappointing. After all, if it hasn't been defined WHAT a program 
should do in some situation or other then anything it does is "correct" 
(if it doesn't hang or loop).

So --- IF a "user team" comes together to try to come up with the 
"requirements" for this feel free to ask me to sit in with you. Please 
-- I won't bother if the user team isn't willing to make the effort. It 
isn't the software designers of programmers who decide what a program 
SHOULD do.

Michael D Novack, FLMI


More information about the gnucash-user mailing list