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:
stephanie.t@criticaleyecommunications.co.uk
* * * * *
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.]
