ETL Requirement Gathering Details

ETL Requirements Gathering:

A requirement gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.

Stakeholders need to be taken thru a set of requirements starting from the product capabilities, quality and the ability to be embedded into the existing enterprise infrastructure. As for base lining of the gathered requirements, well, the only high-level requirements are stable, more granular requirements will become stable after having the product design completed. Here it is possible to get the full support of stakeholders and their sign-off.

Once we understand that what we will be doing should always be business value driven, it should become obvious that we need to talk to the business, to learn what actually adds the most business value.

The primary purpose of business requirements gathering is to understand what the business is trying to accomplish. It is the most critical step in data warehousing, as this is when we learn through conversations with the business what we need to build for them to achieve the business goals.

With the agile approach I am promoting, requirements gathering is an ongoing process unlike most conventional project management methodologies. In a conventional approach a requirement gathering is often seen as a (lengthy) one time step that will determine what will be done in the next many months.

With today’s volatile business environment, we simply cannot afford to effectively tell the business that “you are only allowed to come up with requirements every six months, because we have already decided what we are doing for the rest of this project”. The answer is to work in short iterations and build our data warehouses incrementally.

Incremental requirements gathering

What we should be doing, and what is fortunately being done more and more, is using some of the key elements from agile methodologies like SCRUM and XP.

As you will learn from subsequent posts, I highly recommend using user stories to capture business requirements. User stories are written by the business itself, thus you as an organization can easily capture new requirements concurrently with building a data warehouse increment.

User stories will be prioritized by business value and the data warehouse built in time-boxed increments of 1-2 weeks duration called sprints. As the business requirements that goes into a sprint is decided before every sprint, it is a very good way to ensure that you will constantly consider what makes the most value to the business right now.

User stories are placeholders for business requirements and contain just enough text to serve as planning and to remember what the story is about. With this approach you do not have to spend a lot of time with detailed analysis of the requirements, until the business decides that is now one of the current priorities for an upcoming sprint.

Requirement gathering is part of Business Analysis and goes through the following stages:

- Requirements Gathering
- Requirements Elicitation
- Requirements Management Plan
- Requirements Analysis
- Requirements Traceability
- Change Control

Your requirements approach and requirements will be defined during the initiation phase with the following pm artifacts feeding into it:

- Project Approach
- Business Case
- Communications Plan

The requirements feed into the following pm artifacts used during the execution phase:

- Work Packages
- Configuration Items
- Product Description
- Product Flow Diagram

The requirements analysis might be carried out by the Project Manager or for larger projects by a Business Analyst.