I’m doing a short (10 minute) presentation at the above event – more details here. IIBA members and non-members alike are welcome. Should be interesting as I have 24 slides in my deck, so that’s 2.4 slides per minute or one slide every 24 seconds!
My presentation is largely based on the article There’s No Such Thing as a Requirement, but does include a new case study/example that I haven’t described before.
The slides for my presentation can be downloaded here:
Feedback welcome as usual, whether or not you will be/were at the meeting!
In my first ever article on this site, I wrote the following:
Hi there. My name is Tony. I live in Leeds, England and I’m an Agile Business Analyst.
That was two and a half years ago, and things have changed since then. Over that time, I’ve slowly come to realise that I’m not a Business Analyst. I’m a Business Analyst Designer. It’s a job title I’ve invented because I couldn’t find any existing job title that quite fits the bill. In this article I’m going to explain what it means.
A couple of years ago I had an extension built on my house. It was an interesting process – mostly satisfying but not without its difficulties.
It has been said that building software is very different from building houses, and that it isn’t useful to compare the two. Nevertheless, I think there are some interesting parallels, and in this article I am going to discuss them.
The life of a business analyst appears to revolve around requirements. Every working day we go about eliciting, analysing, prioritizing and communicating requirements.
So it might come as a bit of a shock to discover something:
There’s no such thing as a requirement.
At least, not in my view. Let me explain why.
One evening last week I collapsed onto the sofa and asked myself a question:
Why am I so tired?
I’d had a normal day at work. It had been a typical day – I’d spent the vast majority of the time sitting down, in a comfortable seat, in a modern temperature-controlled office. I had been to two or three meetings which involved walking a total of a few hundred metres. The office canteen is about 30 seconds’ walk from my desk. The only other physical exercise I’d had that day was making a few cups of tea and eating my lunch.
This is a story about how my relationship with a “difficult person” was improved considerably and unexpectedly by a very simple change.
If you have read any of my previous articles, you will know that I like to experiment. And in particular, I have a bit of a thing about functional specifications and looking at alternative ways of presenting them. As well as the traditional ‘words and pictures’ document approach, I’ve tried a format that consists of a spreadsheet and an HTML prototype and, more recently, a graphical format.
In this article I’d like to explore another approach. This time I’m going out on a limb – it’s not something I have actually tried and tested, so it’s more of a suggestion than a recommendation, and I’d be interested to hear what you all think about it.
In Part 1 of this article, I discussed some of the general principles I apply when creating a graphical functional specification. I talked about my dislike for UML models and formal modelling tools. I talked about my love of informal, anything-goes diagrams. And I espoused the benefits of simple drawing tools like Microsoft Visio and OpenOffice Draw.
In Part 2, I’m going to walk you through the specific diagrams I include in my graphical functional specifications and explain how going graphical has changed my life. OK, that might be a bit strong, but I do think it’s helped.
In one of my previous articles, What Actually Goes in a Functional Specification?, I mentioned that there are many different ways to present a functional specification, including a whole host of alternatives to the “traditional” text-and-diagrams document. One approach I have used successfully in the past consists solely of a spreadsheet and an HTML prototype. In this article I’m going to describe another approach I’ve been using recently – in which the specification is entirely graphical. The format has been well-received by business stakeholders and developers alike, so it seems like it’s worth sharing.
If you know even a little about Agile, you’ll have heard of the idea of using index cards for managing requirements. It might seem like a trivial concept, but I’ve had some unexpected successes with index cards recently, so I thought I’d share them with you.