All Entries Tagged With: "Elicitation"
Classic Business Analysis Articles
I was sorting through some of my bookmarks and articles I’ve accumulated over time via the Web, and found that there are a few articles that I seem to refer back to time and again.
Communication: Are you the king, or a guard?
In this scene from Monty Python and the Holy Grail, the king is giving the guards orders to keep an eye on his son, and not to let him leave the room. Sounds simple enough, right?
Escalation and Infinite Regression
Fancy words for pretty common ways simple projects can quickly morph into gargantuan ones.
Could requirements analysis be automated?
Could systems and software be used to take the place of the requirements analyst?
Google Wave for Business Analysis
The social web is abuzz with news on the upcoming Google offering, Google Wave.
Requirements Elicitation: “Most Valuable” Questions
A few of my favorite requirements elicitation interview questions, and an idea for cataloging them.
IT’s Interest in Business/IT Alignment
Bob Lambert says IT should take the initiative in solving problems of business/IT misalignment, and thinks the requirements process can be an effective vehicle for reaching out. I agree.
I could come up with a number of reasons why IT has an interest in being the one to reach out, but one reason in particular occurred to me as I was reading through Lambert’s post….
Requisite Pro + Doors = ?
What does IBM’s acquisition of Telelogic (Doors) mean to the future of both products? What does it mean for their users? I thought I’d share a recent article I came across that shows that IBM has made some progress in determining how they’ll leverage both products.
A Few Quick Links – 12/18/08
New idea for requirements collaboration, lots of project management terms, more evidence on the link between poor requirements and project failure, and, for Heaven’s sake, we don’t “gather” requirements!
The Echo, The Lie and The UML Guy
“Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge.”
The Business Analysis “Artist” and the Requirement Tools of the Trade
Understanding the limitations of requirements management tools, and the importance of analysis skills.
Is the Solution Animal? Vegetable? Mineral?
Ever taken a “20 questions” approach to requirements elicitation? According to The Bitter Project Manager, there are good reasons for doing so. Querying the user/customer in 20 questions fashion helps to determine s/he wants by eliminating the things s/he doesn’t.
Preparing Questions for a Great Customer Interview
Good questions lead to good requirements.
The “Requirements Workbench” Concept
The idea of a “requirements workbench” is one that the guys over at Requirements.net have been consistently socializing over the past few months, and one that I have been following with interest.
Requirements.net has recently posted a Business Analyst Workbench Whitepaper and a Workbench Buyer’s Guide. To give the general gist of the workbench without stealing Req.net’s thunder, the workbench concept includes requirements management capabilities, but then goes beyond that to support the analyst through elicitation, elaboration and communication and validation activities.
How hard could it be to design the stop sign?
I recently stumbled upon this video, got a kick out of it and thoughts I’d share. It is basically a video parody for the process of designing the stop sign if the project were kicked off in 2008. There have definitely been times in my career as a BA where I’ve felt like the poor chap trying to design to the customers’ specs.
Oh.. and for geeks like me who saw this and then wondered when we really did get the stop sign, here’s an interesting link.
Good Requirements Are More Than Just Accurate
The business analyst’s job is not complete if the requirements are documented and accurate but lack precision.
Requirements Elicitation: Are You the Artist, or the Order-Taker?
Requirements elicitation is an art. Watching a solid business analyst efficiently identify and document business need by using a careful mix of questions is much like watching the work of any other type of artist.
Is “Requirements Engineering” a Misnomer?
When you think of an engineer, hard skills such as the various science and technology disciplines come first to mind. It’s easy to see where one could question whether the BA has a place in the engineering tent, and I actually see that as a positive. In fact, I think that anything that chips away at the conception of business analysis as exclusively IT work is probably a good thing for the future of the BA role.