I just read a great post by Thomas LaRock...  http://thomaslarock.com/2009/12/those-four-little-words/

It really hit home because getting requirements within my organization is sometimes like attempting to pull ones own teeth (see the movie "The Hangover" for a good example of the outcome). 

We're currently in "phase two" of building a data warehouse and we do have a BA whom I thought would be responsible for writing requirements but it turned out our BA either (1) didn't know how to write them or (2) didn't want to write them or (3) didn't feel it was their responsibility.  Either one, they probably felt overwhelmed and there was little communication on the issue probably for the reasons stated in Larock's blog.  Meanwhile milestones were approaching and our ETL person was doing other things while waiting for requirements.  I ended up writing the requirements just to get the ball rolling and have maintained them since first published.  (I'm responsible for the SSAS side).

So how are requirements handled in your organization?  Who responsible?  Is there a sign off process?  Is there a methodology that's followed?

Thanks

Ed,

 I'm currently working on an article on this very topic. Stay tuned!

Adam

Hi Ed and Adam,

Adam,  I'm very interested to see your article when it is available.

Ed, Here is my two cents.  We use an Agile methodology that iteratively gathers requirements as the the system is developed and users understand the the capabilities of the system.  The Agile SDLC diagram in this link does a pretty good job of describing the project flow. http://www.agiledata.org/essays/dataWarehousingBestPractices.html

As you know a traditional waterfall model doesn't work well for BI because it depends on front-loaded requirements.  We have to accept that requirements will change as the power of the new system is realized. 

We interview a sample of business users with the help of the BA and interview the source system applications folks, typically also the BA, to determine if the data exists to meet the user requirements.  We then summarize the interviews and meet with a core team of business users with authority to gavel down on the first iteration of the requirements and data definitions (Dimensions, Measures, other metadata).  This core team is brought back at each iteration for typically no longer than an hour week per iteration.  This core team is brought back for a meeting lasting no more than an hour after each development iteration (typically every one to two weeks).  This, of course, requires a committed business sponsor.

Something I'm interested in is "What questions do you use to gather requirements?". 

Here is a sample of mine.

1) How do you define success in what you do?
2) How do you measure your success?
3) Who are your customers, both internal and external, that ask you questions? What are they asking for?
4) Imagine as you drink your morning coffee, you could look at a report that has three pieces of information that answer, "Are we winning?" or "Are we losing?" what would those three things be?

Regards,
Luke