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.]
