Aspiring Business Analyst
January 2, 2008 7:24 AM Subscribe
Help me become a great business analyst. I am slowly taking on more responsibilities as a business analyst and I am completely winging it. Does anyone out there gather requirements and do business modeling? Is that what a business analyst really does? I would like to here more about what makes a good business analyst. Can anyone recommend some good books, websites, techniques, and tools for jedi BA's? Should I learn more about UML? Interviewing techniques? Sharpen my general business understanding? Buy a fancy Monte Blanc pen? Is this job more about relationships than technology? Real life anecdotes appreciated.
What burnp3s is not true, I'm a BA and I use UML every day. If you read further on in the article, you see: UML is not restricted to modeling software. UML is also used for business process modeling, systems engineering modeling, and representing organizational structures.
A sound understanding of UML and different development methodologies will be very helpful. In reality, each project uses its own bastardized version of UML and RUP, but knowing what each is supposed to be can often give you the edge.
posted by sid at 8:04 AM on January 2, 2008
A sound understanding of UML and different development methodologies will be very helpful. In reality, each project uses its own bastardized version of UML and RUP, but knowing what each is supposed to be can often give you the edge.
posted by sid at 8:04 AM on January 2, 2008
I used to manage a team of business analysts. I recommend sharpening your general business understanding and building a rapport with your users. The most frequent feedback I received from users after a project was that they felt the BA didn't have a basic level of understanding about the business and how the system would ultimately be used. These were people with experience in formal BA methodologies, use cases, etc. However, their basic lack of business knowledge is what kept their requirements from being really good and comprehensive, allowing a building block for the next project.
posted by mamaquita at 8:13 AM on January 2, 2008
posted by mamaquita at 8:13 AM on January 2, 2008
I agree with mamaquita. Knowing what your users go through on a daily basis - how they use the system, what parts of the system makes their jobs easier or harder, etc. - will make you their hero. When they need a small change or something big and new, you'll know why they're asking for it and you'll be able to suggest tweaks that make everyone happier.
posted by loosemouth at 8:24 AM on January 2, 2008
posted by loosemouth at 8:24 AM on January 2, 2008
I'm a BA and I use UML every day
I stand corrected. A good introduction to UML is the book UML Distilled.
posted by burnmp3s at 8:25 AM on January 2, 2008
I stand corrected. A good introduction to UML is the book UML Distilled.
posted by burnmp3s at 8:25 AM on January 2, 2008
What mamaquita said: know the users and always remember that you are not one of them, so their opinions come first.
posted by yerfatma at 8:31 AM on January 2, 2008
posted by yerfatma at 8:31 AM on January 2, 2008
Interview and coaching techniques are very useful, as is the ability to ask pointy questions and to spot when you've been told different things by different people (kind of like interrogation, but without the torture elements...)
It's also worth bearing in mind that you'll want to be able to talk processes, checklists, data flows, etc. without even mentioning software. Work through existing process in diagrammatic form (data flow diagrams help, particularly the context diagram, although they often need to be simplified)
Never assume that you know something, or try to rely on something that you covered a month/6 months/year ago, as business areas change process more freuqently than most people change their socks; always go back to grass roots and work upwards.
People will always complain about processes, manual rework, bad systems, etc. - it's very easy to get into a situation where you've given the impression that things will be fixed, that the new shiny software will resolve all the problems, whereas in reality it ends up being too expensive and gets canned... making you look like a liar.
posted by Chunder at 8:52 AM on January 2, 2008
It's also worth bearing in mind that you'll want to be able to talk processes, checklists, data flows, etc. without even mentioning software. Work through existing process in diagrammatic form (data flow diagrams help, particularly the context diagram, although they often need to be simplified)
Never assume that you know something, or try to rely on something that you covered a month/6 months/year ago, as business areas change process more freuqently than most people change their socks; always go back to grass roots and work upwards.
People will always complain about processes, manual rework, bad systems, etc. - it's very easy to get into a situation where you've given the impression that things will be fixed, that the new shiny software will resolve all the problems, whereas in reality it ends up being too expensive and gets canned... making you look like a liar.
posted by Chunder at 8:52 AM on January 2, 2008
I recommend you look at the International Institute of Business Analysis. They have published the Business Analysis Body of Knowledge which you may find very helpful. I am studying this document with the other business analysts at my office. It's very helpful. The linked copy is version 1.6. Version 2 is to be released early in 2008, iirc.
For requirements writing, I've found the following two documents very helpful.
1. Writing a Software Requirements Document by Tanya Berezin
2. Writing Good Requirements by Ivy Hooks
Like sid, I'm a BA and I use UML all the time. Good luck.
posted by onhazier at 9:27 AM on January 2, 2008 [2 favorites]
For requirements writing, I've found the following two documents very helpful.
1. Writing a Software Requirements Document by Tanya Berezin
2. Writing Good Requirements by Ivy Hooks
Like sid, I'm a BA and I use UML all the time. Good luck.
posted by onhazier at 9:27 AM on January 2, 2008 [2 favorites]
This thread is closed to new comments.
I don't know anything about being a business analyst, but UML is used for modeling computer software systems, not businesses. Unless you will be implementing or designing software systems you will not need to learn UML.
posted by burnmp3s at 7:30 AM on January 2, 2008