http://marylaine.com/exlibris/xlib293.html

Ex Libris: an E-Zine for Librarians sponsored by my bulk
mail provider,

WillCo

#293, December 15, 2006



SUBJECT INDEX to Past Issues

http://marylaine.com/
exlibris/archive.html

* * *

Neat New Stuff I Found This Week

* * *

My resume

http://marylaine.com/
resume.html
Or why you might want to hire me for speaking engagements or workshops. To see outlines for previous presentations I've done, click on Handouts

* * *

My Writings

http://marylaine.com/
resume2.html
A bibliography of my published articles and columns, with links to those available online.

* * *

Order My Books

Net Effects: How Librarians Can Manage the Unintended Consequences of the Internet, and The Quintessential Searcher: the Wit and Wisdom of Barbara Quint.

* * *

What IS Ex Libris?

http://marylaine.com/
exlibris/purpose.html

The purpose and intended scope of this e-zine

* * *

E-Mail Subscription?

For a combined subscription to Neat New Stuff and ExLibris, please click HERE, complete the form, and click on "subscribe." To unsubscribe, use the same form but click on "unsubscribe." To change addresses for an existing subscription, unsubscribe from that form and return to the page to enter the new address.

* * *

Highlights from Previous Issues:


My Rules of Information

  1. Go where it is
  2. Corollary: Who Cares?
  3. The answer depends on the question
  4. Research is a multi-stage process
  5. Ask a Librarian
  6. Information is meaningless until queried by human intelligence
  7. Information can be true and still wrong
  8. Pay attention to the jokes

* * *

Guru Interviews

  1. Tara Calishain
  2. Jenny Levine, part I
  3. Jenny Levine, Part II
  4. Reva Basch
  5. Sue Feldman
  6. Jessamyn West
  7. Debbie Abilock
  8. Kathy Schrock
  9. Greg Notess
  10. William Hann
  11. Chris Sherman
  12. Gary Price
  13. Barbara Quint
  14. Rory Litwin
  15. John Guscott
  16. Brian Smith
  17. Darlene Fichter
  18. Brenda Bailey-Hainer
  19. Walt Crawford
  20. Molly Williams
  21. Genie Tyburski
  22. Patrice McDermott
  23. Carrie Bickner
  24. Karen G. Schneider
  25. Roddy MacLeod, Part I
  26. Roddy MacLeod, Part II
  27. John Hubbard
  28. Micki McIntyre
  29. Péter Jacsó
  30. the "It's All Good" bloggers
  31. the "It's All Good" bloggers, part 2

* * *

Cool Quotes

The collected quotes from all previous issues are at http://marylaine.com/
exlibris/cool.html

* * *

When and How To Search the Net

* * *

Wanna See Your Name in Lights?

Or at least on this page, anyway? I'd like to print here your contributions as well as mine. As you've noticed, articles are brief, somewhere between 750 and 1000 words -- something to jog people's minds and get their own good ideas flowing. I'd also be happy to run other people's contributions to the regular features like Favorite Sites on _____. I'll pay you the same rate I pay me: nothing.

* * *

Drop me a Line

Want to comment, ask questions, submit articles, or invite me to speak or do some training? Write me at: marylaine at netexpress.net




Visit My Other Sites


BookBytes

http://marylaine.com/
bookbyte/index.html
My page on all things book-related.

* * *

How To Find Out of Print Books

http://marylaine.com/
bookbyte/getbooks.html
Suggested strategies, resources, and finding tools.

* * *

Best Information on the Net

http://library.sau.edu/
bestinfo/default.htmThe directory I built for O'Keefe Library, St. Ambrose University, still my favorite pit stop on the information highway.

* * *

My Word's Worth

http://marylaine.com/
myword/index.html
an occasional column on books, words, libraries, American culture, and whatever happens to interest me.

* * *

Book Proposal

Land of Why Not: an Appreciation of America. Proposal for an anthology of some of my best writing. An outline and sample columns are available here.

* * *

My personal page

http://marylaine.com/
personal.html



CREATING A FUNCTIONAL SPECIFICATION

By Stephanie Taylor.

A functional specification is a very powerful tool for anyone involved in buying or commissioning any kind of software. A well crafted functional spec can make demos a breeze and fine-tune your question and answer sessions with software companies. It helps you focus on what your new technology must do, what you'd like it to do and highlights what you can live without, too. Don't confuse it with a technical specification. That is the details and technical document that developers use to scope and plan their work. No, this is about what something does from the user point of view, not about how it does it under the hood. To write one, you need to be able to question people so you coax out their needs, give a balanced view of several sources of information and have a sharp eye for detail. In short, a set of skills honed to perfection by library and information professionals!

Start by asking some basic questions yourself. What do you want the technology to do? Try to keep this simple and distil your needs down to one sentence: "I want a system to automate our inter-lending process", "I want something that can manage my e-journal subscriptions", " I want to pull all the library resources into one place online" are all good starting points. It can be tricky to come up with the sentence, but persevere. This is your overview and encapsulates what is at the heart of your requirements. When you've got your sentence, you're ready to start filling in the detail.

This is the point when you need to start talking! First, identify all the people who will need to use the technology. If there are too many to talk to, identify key groups of users and talk to a representatives. Then, hit them with your sentence and get them to tell you what they want and why. Make sure you get the why too - that's very important. We'll come back to that later.

Your questions should focus on the way people are currently carrying out the work that the technology will help them with, and then expand into what they would like to be able to do. You are looking for answers like " I want to email journal publishers from the same place I keep our subscription details", "I need to be able to send a specific code to this ILL supplier on every request we make". It might take time to get people talking, so be prepared to start off by sharing your own ideas. And don't let anyone get sidetracked into describing the actual technology. You don't want to know if someone prefers Linux, you want to know what tasks they do now and what they need to help them. Keep focussed on the workflow. Once you have this information, start to write it up. You are looking for specific tasks and functionality here, stuff like "ability to email from within the system",and "needs to print out for sending reminders by mail as well as email". Then do some categorising, based on whether this is essential, useful if possible or optional. Your functional spec is taking shape.

Next up is to talk to your local technical/systems people. Here, you are looking to establish some ground rules for bringing new technology onto the network. Explain what you are wanting to do and find out any requirements that need to be met for your particular network and systems situation. You will probably need to keep talking as you actually start to shop for your solution, so be prepared to start a dialogue rather than b done in one meeting. It's well worth making friends with this team as you want to make sure your new technology will work within your organisation. Add their requirements, suggestions and questions to your functional spec. It is worth keeping this in a new section so that once you start talking to software companies, you can ask someone to look at this section and maybe liaise directly with your systems people. This can avoid the confusion of a non-technical person trying to translate between two groups of techies!

Your functional spec is almost there. But before you launch yourself into the purchasing process, spend some time researching the industry standards and protocols for the kind of technology you want. Standards and protocols are devised to help easy communications between either human beings, technologies, or both. They can be specifically library-focused (e.g. Dublin Core, MARC, ISO10161) or have a broader application (e.g. W3C web standards, XML). You need to identify the ones that matter to your software. Look at the websites of the main software players in the field as well as to the library and technology communities. The application of standards and protocols can be a tricky business - not all are as standard as the name might suggest - so it is a good idea to talk to colleagues who have already got experience of implementing them if you are not familiar with the practical side. Feed this final set of information into your functional specification and you're done.

You now have a comprehensive list of wants and needs covering workflow, network/system needs and standards/protocols. These should all be graded according to their importance, clearly showing you what you must have, what you would like and where you might compromise. This is a firm foundation to use when talking to vendors. Remember as you start the purchasing process that your functional spec is a living document and you can adjust it. If things change, take it back to your original groups of users to discuss further. You might discover some needs are difficult to meet or too costly to buy, or that some things are just not possible. So talk again, feed the new information into the functional spec and you'll make a good purchase.


Stephanie Taylor has extensive experience in the United Kingdom's higher education library and information sector, developing global document delivery and information management solutions. As founder of Critical Eye Communications <http://www.criticaleyecommunications.co.uk> Stephanie is now a consultant and trainer, offering courses in the effective use of communication technologies in the project environment, and preparing Library and Information workers for the changing nature of their roles. Stephanie can be contacted at: [email protected]

* * * * *

COOL QUOTE:

Google doesn't try to force things to happen their way. They try to figure out what's going to happen, and arrange to be standing there when it does. That's the way to approach technology-- and as business includes an ever larger technological component, the right way to do business.

Paul Graham. "Web 2.0." November, 2005. http://www.paulgraham.com/web20.html

* * *

You are welcome to copy and forward any of my own articles (but not those by my guest writers) for noncommercial purposes as long as you credit ExLibris and cite the permanent URL for the article. Please do NOT copy and post my articles to your own web sites, however. Instead, please copy a brief excerpt and link to the URL for the remainder of the article.

Ex Libris: an E-Zine for Librarians and Other Information Junkies.
http://marylaine.com/exlibris/
Copyright, Marylaine Block, 1999-2006.

[Publishers may license the content for a reasonable fee.]