by Angela & Tom Hathaway | Aug 5, 2008 | Requirements Gathering (aka Elicitation)
The difference between problems and opportunities is primarily one of perspective. Some people see problems in opportunities, others see opportunities as problems. What’s your take?
by Thomas Hathaway | Apr 18, 2008 | Business Analysis Overviews
The Agile Software Development Methodology has fundamentally changed how developers deliver working software to those who need it. This change has a ripple effect on how those who wear the business analysis hat need to work to support this evolving approach.
by Angela & Tom Hathaway | Mar 18, 2008 | Requirements Gathering (aka Elicitation)
Business requirements exist in the wilds of organizations around the world, The challenge is to capture, clarify and confirm them as early as possible.
by Angela & Tom Hathaway | Feb 5, 2008 | Requirements Gathering (aka Elicitation)
Many different roles are involved in delivering working IT soluitons. From the business community to the IT community, the players may wear many different hats throughout the project. It is important that each hat is a good fit to ensure project success.
by Thomas Hathaway | Jan 9, 2008 | Musings of a Mad BA
To be effective, business and stakeholder requirements need to contain minimal ambiguity and subjectiveiy. Misunderstood requiremetns are one of the major cuases of IT project failures.
by Angela & Tom Hathaway | Sep 10, 2007 | Process / Workflow Modeling
Confucius (or another one of the early Chinese geniuses) is credited with saying that a picture is worth a thousand words.
by Thomas Hathaway | Jul 19, 2007 | Musings of a Mad BA
Are user requirements really necessary? You probably did not define the requirements for most of the software you use on a daily basis, so why bother?
by Thomas Hathaway | Jun 27, 2007 | Musings of a Mad BA
Will Shakespeare has nothing on the intrepid business analyst.
by Thomas Hathaway | May 29, 2007 | Business Analysis Overviews
Requirements for Defining Requirements What are your requirements for your requirements definition process? Are they clearly defined? If not, why not? Should your requirements definition process be any different from any other business process? We don’t think so, so...