UML for Business Analysts - Series Intro
April 25th, 2007There are several tools that a business analyst has to document and communicate requirements. Some of the most used formats are use cases and requirements specifications. These documents are very useful and certainly have a place in a business analyst’s toolbox, however they do have some limitations. One of the biggest limitations is that these documents are written in standard english, which increases the likelihood of ambiguity being incorporated into the requirements. Even the best written requirements will include a certain amount of ambiguity, it is the nature of structured language. Of course ambiguity can be limited with more complete documents and fuller specifications; this of course results in longer documents which reduces the amount of people who will read them. It is a bit of a catch-22 for the business analyst, how to write a document that adequately and unambiguously captures the business requirements and logic while not creating an unwieldily large document that no one will read anyway. Enter UML…
The BA Handbook – A BA Wiki
April 18th, 2007I stumbled across this wiki entitled The BA Handbook the other day. The BA Handbook is run by Craig Brown of Better Projects. It looks like Craig beat me to the party, I was going to set up a BA wiki once my hosting provider upgraded to PHP 5 so I could run MediaWiki But such is life…
Not Everything Is a Use Case
April 5th, 2007Use cases are great tools, just as I can’t imagine building a house without a hammer, I can’t imagine building a system without use cases. (Well frankly my carpenter skills aren’t much to write home about so I can’t really imagine building a house period.) However, in building that house, I could certainly imagine laying the foundation or painting it without a hammer. Just as I don’t apply paint with a hammer, I don’t use a use case to document an API. And yet, I continually see use cases being used to document this type of functionality.
So let me say it again: NOT EVERYTHING IS A USE CASE. Sorry, I don’t mean to yell, I just get frustrated sometimes.
Presentation from BA World Toronto
March 30th, 2007Kevin Brennan over at Business Analyst Insight, the Vice President of the IIBA Body of Knowledge (BABoK), posted his presentation that he gave at BA World in Toronto. The presentation covers three topics:
- Understanding why mere translation between the business and IT isn’t enough
- Identifying gaps in your BA toolkit
- Understanding how to build stakeholder requirements into something that adds value
In addition, Kevin presents the Zachman framework as a tool for conducting enterprise analysis.
How to Hang Easel Sized Post-It Notes
March 27th, 2007The easel size pads of paper can be a business analyst’s best friend. They’re great for mocking up UIs, making parking lots, capturing notes plus they’re much more permanent than a whiteboard. I never facilitate a meeting without one handy. There’s only one problem with them, sometimes they can be a real pain to hang up on the wall. Even the super sticky post-it note types can be difficult. After many a wrestling match with the paper posters, I’ve found the absolute best way to hang them up. And it is pretty much the simplest method. Maybe Occam was onto something…
What Type of App Are You Working On?
March 20th, 2007Creating Passionate Users has a hilarious post entitled Is you app an ass-kisser? The post is work checking out for a good laugh. Right now I’m working to rehab a combination brilliant but temperamental and show-off guy. Not too long ago I finished up with and overhaul of an undecider… I’m glad that’s over.
What’s your current project like?
Creating Mockups
March 8th, 2007I like using wireframes and mockups as part of the requirements elicitation process. I think that having something tangible as a starting point helps a lot of stakeholders become involved in the process. I know that time is valuable and my SME’s and stakeholders aren’t going to take the time to read a long, dry document that I’ve written. Plus it seems that people are suffering from more and more from CPA induced by their email, blackberry, ipod, IM and flickr stream, so even if they read it they won’t be focused. Another reason I like mockups and wireframes is that they are something different. It is fun to break out of the word processor and spreadsheet realm and really start rock’n with Visio or Powerpoint. Bust a little creativity out now and again.
Onion Diagrams
March 6th, 2007There is a great post entitled Peeling the Onion at requirements defined this week. I’ve used the onion diagram before to identify stakeholders and found it to be very powerful. It was also very easy to use as a straw man with stakeholders because it required very little explanation; stakeholders “got it” very quickly. The visual aspect of the onion diagram is also nice because it is very easy to post on a wall, glance at, and also to draw interdependencies between stakeholders. Finally the onion diagram is very easy to get started on and build out. Often the most difficult part of a project is figuring out where to start, and this diagram provides an easy way to get the ball rolling.
Why a Project Needs Both a PM and a BA
March 2nd, 2007I ran across this article a few weeks ago and have been meaning to write a bit about it. The article does a very good job of articulating why a project needs both a project manager and a business analyst and why those roles should be filled by two discrete resources.