This article describes Phase 3 of the Business Analyst Designer Method – Design.
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.
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:
- Prioritization is really important
- 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.
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.
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.
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.
I’ve been given a spot at BA Conference Europe 2014. It’s in London from 22nd to 24th September. My session is called There’s No Such Thing as a Business Need, and if you’ve read There’s No Such Thing as a Requirement, you’ll have a rough idea of the topic!
I’m looking forward to meeting people and sharing ideas. If you’re going to the conference, do give me a shout.
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.