Hi all,

I’m Daniel Sweeney, and I’m Senior Business Analyst at LibLime. Galen and the Coders have written a lot of the posts on this blog, while I’ve been staying in the background. If you’re a LibLime customer who’s interested in custom development, though, you’ve probably heard from me. I thought I’d write up a quick post about how the analysis process works at LibLime.

As a business analyst, I’m responsible for writing up specifications for new functionality in Koha that libraries are interested in sponsoring. The general idea is that the specification should be something that both the staff at the library and the programmers at LibLime can understand and agree on. That way LibLime knows that what we’re building matches what the library wants, and the library knows what’s going to arrive when LibLime delivers.

I should mention, the title “Business Analyst” makes it sound like I rate bonds or something. A better title might be “Library Analyst,” but the BA title is pretty standard in the IT industry, so we kept it at LibLime.

I usually start the process off with a conference call with staff from the library who do the work that Koha supports. My usual tactic is to make believe that I’ve never worked in a library, gone to library school, or ever talked to anyone in the library community at all. (None of those things are true, but playing dumb can really work for  you.)

I tend to talk a lot, but the call is really an opportunity for me to listen. I want to find out what the library is doing, and what the context is for the changes we want to make in Koha. I usually try to find out about things that sound like they’re incidental to the change that the library wants, but can show me how people are doing their jobs. That’s valuable when writing up a functional specification that will affect how people at the library do their jobs.

Once that call is done, I write up a preliminary specification. I usually try to do this right away so that things are fresh in my mind. The preliminary specification is always subject to revision–what I really want is to get a good set of ideas down on paper so that I can talk to both the development staff here about the ideas and to the library again. Sometimes I completely rewrite that spec multiple times, either because something is not clear, or because we develop some of the ideas better as we talk about them.

Finally I reach a point where the spec makes sense to the library and matches what they wanted in the first place. It’s harder than it sounds to turn a simple idea that sounds like common sense into a detailed document that describes how it will fit into Koha.

Once the library understands what the spec says, and accepts that it’s right, then the programming side takes over, and reviews the spec to get a detailed idea how long it will take to actually do. This estimate drives the quoting process. The specification is part of the quote that goes to the library that sponsors development, and we need to get the details right so that we know how much work it will be.

In a lot of ways the Business Analyst is the bridge between the library and the programmers. I hope that gives people at Koha libraries who’ve never sponsored any development an idea of how the process works. I do subscribe to the comments to the blog, so feel free to ask questions there about the process.