My experience has been that users generally do not have a very clear idea of what they want. What they DO know is what doesn't work for them in what they have now. The users will often have some (maybe even mutually contradictory) ideas about what they do not, but when you sit down with the users to look at this all systematically more issues will arise, and they may even conclude that what they initially requested isn't quite what they want, after all. Establishing functional requirements is usually a process, requiring significant input from both users and engineers.
--- Aylesworth Marc A Ctr AFRL/IFSE <[EMAIL PROTECTED]> wrote: > You should not get programming specs from a customer but should get > general > functionality that is desired. The customer should say I want to have > remote > clients that can do the same thing as local clients, or that I can > enter all > the information for a patient from a remote station, then we the > programmers > turn those general statements into specifications that are realistic > in > terms of what they want in the time frame that it is desired. Usually > doing > this in small increments makes both the customer and the programmer > happy. > > Thanks > > Marc Aylesworth > > C3I Associates > > AFRL/IFSE > > Joint Battlespace Infosphere Team > > 525 Brooks Rd > > Rome, NY 13441-4505 > > Tel:315.330.2422 > > Fax:315.330.7009 > > Email: [EMAIL PROTECTED] > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ruben > Safir > Sent: Wednesday, August 24, 2005 9:36 AM > To: [email protected] > Subject: RE: [Hardhats-members] MUMPS and VistA ( more M read > questions) > > On Wed, 2005-08-24 at 09:12, Aylesworth Marc A Ctr AFRL/IFSE wrote: > > I believe that what he means is that we actually talk to someone > who is > > going to use Vista, get the wish list then decide what is feasible > in the > > given time and then do the work. > > I understand that, and that is exactly what is not a good idea. > > > > I believe that we need user involvement to > > ensure that we have something that actually does what is needed and > to > > foster the feeling that users have a say in what a product does. A > well > > thought out program is useless if it does not do what the user > wants. > > > > Have you ever tried to get a programming spec from a customer. They > have no idea what they want, no idea what they need and no idea what > can > be done (which is usually more than they ever imagined). > > What they are, however, is completely confused and snowed over by > cheap > marketing jargon from vendors playing word games to skew the market > under the disguise of computer science and technological advances. > > That's why it is absolutely critical for a design team to vet user > input. > > Ruben > > > Thanks > > > > Marc Aylesworth > > > > C3I Associates > > > > AFRL/IFSE > > > > Joint Battlespace Infosphere Team > > > > 525 Brooks Rd > > > > Rome, NY 13441-4505 > > > > Tel:315.330.2422 > > > > Fax:315.330.7009 > > > > Email: [EMAIL PROTECTED] > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > Ruben > > Safir > > Sent: Tuesday, August 23, 2005 2:24 PM > > To: [email protected] > > Subject: Re: [Hardhats-members] MUMPS and VistA ( more M read > questions) > > > > On Tue, 2005-08-23 at 09:55 -0700, A. Forrey wrote: > > > If the VistA Community is going to reach the rest of > > > the world it needs to tell them how it will deal with this > problem > > > and > > > then get on with it. > > > > Free Software projects just adapt to needs as developers precieve > them, > > which is frankly, a better idea than having development driven by > > healthcare providers who are working under many misconceptions > about the > > limitations and capabilities of software. > > > > It is important to have a map. It is important to have a group and > a > > leader to vet out reasonable requests from the user community. > > Ultimately, the satisfaction of healthcare providers based on the > > performance of the WorldViSTA and Mumps products will be what > swings > > things. But letting the providers create the software map, that > might > > not be the best idea. > > > > Ruben > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Design quality doesn't ensure success, but design failure can ensure failure." --Kent Beck ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
