All Entries Tagged With: "Elicitation"
Don’t Forget the Constraints!
In addition to eliciting and specifying the requirements, an important part of the analyst’s value-add lies in helping business stakeholders and delivery teams identify and understand the constraints that will apply for the solution.
Begin with what you HAVE to do
The simple fact is, you can’t know all the details upfront. You can and should, however, be able to work with your stakeholders to identify the broader range of necessary capabilities and constraints, or “placeholders for conversations”.
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.