Author Archives: Tony Heap

About Tony Heap

Tony Heap is a freelance Business Analyst Designer based in the UK. Having worked on a variety of projects both large and small, he feels like he has a few experiences to share. He is particularly interested in agile approaches and how they apply to business analysis.

BA Sketchbook Stencil for Visio

This article describes a Visio stencil I have created to help BAs produce “sketches” in Visio. The BA Sketchbook stencil for Visio contains various shapes (symbols/icons) and connectors with a hand-drawn style that can be incorporated into all sorts of diagrams – such as business process diagrams, flowcharts or boxes-and-arrows diagrams. it has been reported that the resulting diagrams are well-received – especially by non-technical business people, who can sometimes feel intimidated by more formal diagrams.

Continue reading

How to Prioritize Requirements

On software development projects, requirements prioritization is a well-established practice, and there is a wealth of information, both in books and on the Internet, describing the various techniques you can use to do it.

But in my experience, there are two key points that nobody ever seems to emphasize enough:

  1. Prioritization is really important
  2. Prioritization is really difficult

In this article I’m going to explain why I think this is the case, and why we therefore need to be absolutely ruthless about prioritization if we want our projects to succeed.
Continue reading

Behaviour Driven Development – Use Cases Re-Invented

I’m hearing of more and more agile teams using Behaviour Driven Development (BDD) as a way to specify the acceptance criteria for user stories. I hadn’t realised how widespread it was getting until I attended two separate talks on it at BA2014 this week (in particular, at the BBC and Aviva).

With each new technique comes a learning curve, both for individuals and for the industry as a whole. The technique matures as people work out how best to apply it.

But there’s good news for anyone learning to use BDD. The technique is already mature, and there’s a body of knowledge out there on how to write BDD scenarios. It’s just that people weren’t calling them BDD scenarios. They were calling them Use Cases.
Continue reading

Requirements are really Desirements

A colleague of mine invented a new word recently.

Every time we had a meeting, and he mentioned requirements, I would point out that, of course, there is no such thing as a requirement – it’s all design. He took my point (or at least he humoured me), but was struggling to let go of the word “requirements” because he was so used to it.

And so he came up with a new word – “desirements”.

It started out as a contraction: design-requirements became “des-irements”. But I quite like the alternative interpretation. Desirements are what stakeholders desire. What they want. Not what they necessarily need. Not necessarily the best thing for them. They are ideas, suggestions, proposals.

This term helps me out of a hole. I’ve been trying for some time now to avoid using the word requirements (walking the talk, as it were) but it’s actually quite hard in an environment where it’s a de-facto standard. Desirements gives me the perfect get-out. People will know what I mean, and will also instantly get that I have an alternative view on requirements, without me having to pause the conversation to present by 5 minute monologue on why there’s no such thing as a requirement.

I’m going to try using the term and see where it gets me. I don’t suppose it will catch on but you never know.

Business Analyst Designer Method

I recently announced that I’m not a Business Analyst, I’m a Business Analyst Designer. A job title is all very well, but it’s not much use without a job description. I have already waxed philosophical about the designer mindset – there’s no such thing as a requirement and it’s all design. But I haven’t said explicitly what a Business Analyst Designer actually does.

In this article I introduce the Business Analyst Designer Method – the method I follow as a Business Analyst Designer. I’ve been evolving it over the past few years, and it’s now stable enough to be worth sharing.

Continue reading

There’s No Such Thing as a Regulatory Requirement

There's No Such Thing as a Regulatory Requirement: Let Me OutI recently gave a short talk at a seminar for my local IIBA local chapter, in which I argued, as usual, that there’s no such thing as a requirement.

In the Q&A, one audience member commented that he works in banking, and is often subject to regulatory requirements which, if not implemented, could be considered a criminal offence, and could theoretically land the company directors in jail. Therefore, in certain circumstances, he argued, there is such thing as a requirement.

Continue reading