There’s a lot of information on the Interweb about how to write a functional specification (FS for short, aka software requirements specification, system specification, product specification.

What I have struggled to find, though, is a good, detailed description of what should actually go in an FS and, in particular, to what level of detail. When asked this question, most BAs answer, “it depends”. Whilst this is true, I think we can improve on it by drawing some clear boundaries around how much detail is allowed, and how much is too much.

Therefore, I present a specification for a functional specification. This my own view and by no means an industry standard, but it works for me. 🙂

Continue reading →

So here’s a topic that you don’t see discussed very often. Document version numbers might seem like a trivial concept – a subject upon which there is little to be said – but they are a real bug bear for me. Let me explain why.

Continue reading →

An article titled Design and requirements? Pshaw! was published recently on Bridging The Gap. It discusses whether or not it is good practice to include ‘designs’ within a requirements document. I’ve seen this debate before, in various guises, and I’m always a little bemused and confused by it. And here’s the reason:

To me, it’s all design.

Now that’s going to take a little explaining, so bear with me.

Continue reading →

In my previous post I described my experience as a business analyst on an agile project.

One of the key artifacts I produced on the project was the functional specification (FS). In this post I’m going to get right under the covers of the FS and explain exactly what it was and how it worked. My intention is to provide enough detail so that others could actually try it out on their own projects. So you’ll have to excuse me if I go on a bit – I’m sharing some love here. 🙂 I’m not saying it’s perfect, but it worked for me!

Continue reading →

In my previous article I described my first ever agile project as a Java developer. I highlighted some of the challenges that we faced in terms of the requirements gathering and analysis work.

In this article I’m going to talk about my first agile project as a business analyst, and how I took on some of the learning from the previous project.

Continue reading →

In my previous article, How I Became an Agile Business Analyst, I talked about my passage from the world of good old fashioned ‘write it all up and get it signed off’ business analysis into the uncharted territories of agile.

In this article I’m going to describe my first experience on an agile project. I should explain that I joined this project not as a BA but as a developer, in particular to bolster the team’s Java skills. So whilst I taught them a little Java, they taught me a little agile.

Continue reading →

Hi there. My name is Tony. I live in Leeds, England and I’m an Agile Business Analyst.

Oh dear, that sounds more like a confession at an Alcoholics Anonymous meeting than my first ever online article. It’s also not true and, so some people say, an oxymoron.

Actually, what I really am is a regular Business Analyst who has recently been experimenting with some agile practices and has a few experiences to share.

Continue reading →