Introdução
Como em qualquer projeto de desenvolvimento de software – inclusive para projetos de Business Intelligence e Data Warehouse – existe a fase de “levantamento de Requisito”. O que acontece com a maioria dos Gestores e não conhecedores do assunto é achar que as técnicas utilizadas no levantamento de requisitos, para desenvolvimento de softwares, devem ser aplicadas na construção de um DW. Esse é um erro básico que pode levar uma implementação de DW ao fracasso. “Não estou afirmando que não podemos adotar nenhuma técnica de Engenharia de Software”, temos que entender que são assuntos totalmente diferentes. Existem várias abordagens para reunir os requisitos de informação. Isso não significa que não há espaço para outras técnicas, tais como: brainstorming, questionários, prototipagem, observações, casos de uso e etc. Porém devemos ressaltar que nenhuma substitui a participação direta entre o analista, clientes (interno ou externo).
Requisitos de Negócio
Um fator determinante para o sucesso na sua gestão ou implementação é não criar frustrações com o seu stakeholder, afinal isso é um Data Warehouse. Só podemos carregar informação que existam nos sistemas legados, o que pode acontecer é “se” futuramente algo for implementado podemos implementar no nosso repositório. Na técnica usada para colher os dados, temos que realizar – nas primeiras reuniões – separando o gestor do seu subordinado. Isso mesmo, dependendo do gestor o subordinado “entra mudo e sai calado”, então vamos começar sempre com o gestor que é uma pessoa mais detalhista “Vende um fusca como se fosse uma Ferrari”, fala, fala, fala e fala! Anotamos as atividades que a área dele realiza o trabalho que eles exercem na manipulação dos dados. Depois vamos conversar com o seu subordinado, tente deixá-lo sempre a vontade e tentar absorver o máximo de suas atividades, caso ele esqueça de citar alguma atividade, cite que o gestor falou de algo que ele faz no relatório.
Características dos requisitos
Ao definir os requisitos precisamos reunir as características de cada um, definindo uma prioridade indicando se a necessidade é essencial, condicional ou opcional.
“MoSCoW Method“.
- MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
- SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
- COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
- WON’T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.
Entregas – Matriz de processos
A matriz de processos de negócios dá uma visão geral da combinação de todas as dimensões relevantes com todos os processos de negócios dentro de uma área de um determinado assunto.
A matriz de informação dá uma visão geral da combinação de todas as dimensões relevantes, com todos as fatos dentro de um processo de negócio.
