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