Survey Results

<big>SOFTWARE SPECIFICATION AND DESIGN			CONSUMER CONSIDERATIONS</big><br />
S. Miller - First Draft: June 6, 2007, Second Draft:  June 11, 2007<br />
<br />
Converting the software needs of the consumer into an effective application is, as many of you have experienced, not without its difficulties.  These arise from a number of causes.  Amongst the commonest of these causes which both parties typically finger-point is that the users and developers have different understandings of the entire computer experience, and apparently don’t speak the same language.  That particular issue is not the one to be address here.<br />
<br />
Given carte-blanche for their software requirements, a user must give very careful consideration as to what their minimum requirements really are.  To take an extreme example, a specification such as "I need an application to enter my data" doesn’t help at all in design.  Going to the other extreme, and specifying an entry option for every piece of data that is generated by their work flow will, if implemented, generally come back to bite all involved.<br />
<br />
Both of these extremes scenarios, if brought to life, result in unusable software and a long, arduous, and frankly aggravating cycle of modifications . . . or even software that never gets used at all.<br />
<br />
The key to avoiding this is giving a long hard think about what it is you really need to do – not simply what you have always done.  To merely translate your manual tasks (or older applications) into a new version of the same fails to take advantage of the value-added potential of custom-designed software.<br />
 <br />
The following items ought to be given some consideration:<br />
<br />
The Medium:<br />
Although you me be comfortable, at present, with a certain style of input 	design (such as a spread-sheet), it may have only been initially chosen as an ad-hoc solution, or perhaps because it was the only game in town at the time.  At ATIC, the developers are rather well equipped to create exactly what is needed for any job.<br />
<br />
Work Flow:<br />
How can an application most smoothly match your true work-flow?  Try to take into account, as best you can, not only the perfect scenario, but how you’ll handle the most common errors.  <br />
<br />
Exceptions:<br />
We all make mistakes.  Some of these can be preempted with the software 	design, such as by using lists instead of type-in-text, for data entry. "Imaginative" data is prevented – but at the cost of flexibility.<br />
<br />
Data Selection:<br />
"What data do you want to collect?" vs. "What do you need to collect?"  This 		must take into account that someone has to actually enter this data.  The programmer slugs through a ton of entry fields just once:  you’ll have to do it all day, and every day.<br />
<br />
User Interface:<br />
An application should be eye-friendly.  By now, most of you have worked with applications which do it all in one place – and boast a small enough font to prove it.  Can your work be broken down into discreet segments, instead, which could be put on separate "tabs"?  Can these be arranged so the user can reach one or more stopping points (i.e., valid times to Save current work) along the way, reflecting their workflow?  Breaking down their unit of work to more easily digestible bites further allows for future division of labor when appropriate, or clean modifications to a specific work unit without impacting any of the others.<br />
<br />
Freedom:<br />
You should consider carefully how to seek a balance between flexibility, and the opportunities flexibility affords for ambiguity and user-errors.  What data must be entered, at a minimum prior to any type of save?<br />
<br />
Audit Trail:<br />
All work, particularly in a business such as ours, should maintain a chain of custody.  Normally, a programmer will create some degree of this via data logging.  This, however, can be their viewpoint of best practices for data management and rather hit-and-miss as to whether it meets your needs.  <br />
<br />
<br />
The above criteria, naturally, have varying degrees of applicability for your specific needs.  Their importance lies in getting you to think about what it will be like actually working with your new application.  Like swimming, simply writing about how you think it’s done will likely result in a future drowning.<br />
<br />
The goal, however elusive, is getting it right the first time.<br />
<br />
Sure – there is almost certainly going to be a short cycle of adjustment – but it can be reduced to a pleasant tune-up, and, after a break-in period, some tweaks.<br />
<br />
If you take into account the developer’s time, and even more so, the user-training cycle, born with the introduction of new software, it can be a costly enterprise.  It is done because, when done well, your work is easier and the product of is better – and all agree it is worthwhile.<br />
<br />
<br />
There’s a wise philosophy that seems to apply:<br />

Grimolfr wrote:

other departments as paying customers