Wednesday, May 23, 2012

   Quick Links:   Articles     MA Blog     Community Blog     Templates     Books     BA Humor     Events     Jobs     Interview Questions         RSS Feeds

Business Analyst Articles: Business Analysis & Systems Analysis

Resources



Articles and White Papers
Minimize


Current Articles | Search | Subscribe (RSS)

» The Creative Business Analyst - Part 1

Statistics:Article Rating (3897 Views) (3 Comments) Print
Posted: Friday, October 31, 2008
Categories: Analytical and Problem Solving Skills

Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.

We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.

To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.

Author: Jan Kusiak

Read More ...

Rating
Comments
I completely disagree with the statement that Business Analysis has always been about 'gathering' requirements and converting them into specifications and only it i changing....

Business Analysis has always been about understanding business problem and designing a solution. As part of the process we 'elicit' requirements from users (which can be done only after we understand the problem 'as is')
Being a BA with formal education and experience in Business Process Re-Engineering, I do not like the use of the term 'gathering' which implies the requirements all there ready with the users, and all we do is 'gather' them.
We really have to 'elicit' requirements using good techniques and smart questions, which again can be done only after we understand the problem.

posted @ Saturday, November 01, 2008 10:15 PM by joel32


Joel is completely correct as the second paragraph in the paper tries to state. As a training provide we see 2 types of analysts, those in more junior roles who quite literally just document requirements and the more senior ones who actively work to change the business. The paper's objective is to broaden the horizons of the more junior ba's. Elicit is not a word much used by us antipodeans although it's meaning is 100% applicable in this context...Jan Kusiak

posted @ Tuesday, November 04, 2008 4:52 PM by Jank88


@ Jan K this is Lakshmin and am relatively a kid inside the BA world. I concur to JanK's point.

@ Joel --> I believe as a Industry BA people define "Requirements gathering" where they use "Elicitation techniques". Most of the BA's do unfortunately serve as interface between busines and IT potentially with or without the systems knowledge or rather not at a detailed level which allows them to think outta box solutions to ask "why this and why not this way?"

I am sure both of you peers agree to the statement that doing a BA role is not guidelined, as we guys tend to wear multiple hats during a project activity and its one's own passion as a BA to create the value addition. The "Role" gets well defined when there is passion for what you do....

posted @ Monday, February 22, 2010 11:15 AM by lakshmin


Only registered users may post comments.
  

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



 

Privacy Statement  |  Terms Of Use
Copyright 2006-2011 by Modern Analyst Media LLC