• Bookmark this page

    Post to del.icio.us Digg this!
  • Stats

    • Pages displayed : 73811
    • Unique visitors : 36696
    • Pages displayed in last 24 hours : 232
    • Unique visitors in last 24 hours : 89

Archive for February, 2008

Going to the Atlanta IIBA Chapter Meeting »

Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you’re new here, you may want to subscribe to my RSS feed. If you’d prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!I just RSVP’d to attend this coming Tuesday’s Atlanta IIBA [...]

Happy 1st Birthday, Blog! »

Actually, the true 1 year anniversary was on the 9th, but I thought I’d do as I do for most other birthdays, and forget it completely until a week or so has passed. So, we’ve been at it for a little over a year, and I think it is an appropriate time to thank all [...]

On Business Analysis in an Agile Setting »

 

I’ve noticed a recurring discussion around various business analysis-oriented websites of late concerning the relevance and value of the Business Analyst, especially in an agile environment. Some argue that with agile, “business analyst” responsibilities are carried out by software developers or technical architects, eliminating unneeded layers of communication (read; BA’s).
Karl Wiegers, one of my favorite [...]

Onshore vs. Offshore »

Matt Lockhart of Magenic Technologies, Inc. posted an excellent article at TechLinks a while back on things that need to be considered when determining whether development work should be done on or offshore.
Among others, Lockhart draws attention to topics such as budget, relationship management, onsite travel, CMM considerations, the risks of miscommunication, and economic [...]

With requirements, discussions matter most »

This post is based on a quote I read and liked from the article, “When Requirements Go Bad: Part II” by Kurt Bittner. The article is available from Dr. Dobb’s Requirements Development e-zine (free subscription required). According to Bittner:

We need to banish the practice of writing requirements that we can “throw over the wall” to developers or testers and instead pursue a more open, communicative approach. What is important to realize is that requirements are what motivate discussions, but it is the discussion that matters most.

Well said. While I’ve taken an occasionally rocky path to get there, my experience as a BA has led me to the same conclusion.