Análise de Sistemas: O Levantamento de Requisitos

A tarefa de levantamento de requisitos é árdua e complicada, envolve além da interpretação do sistema, a interpretação da regra de negócio.

Algo comum de acontecer no levantamento de requisitos é ocorrer a má interpretação no processo de negócio por parte do usuário e do analista, e isto pode levar o projeto ao insucesso. Todo processo que envolve pessoas torna-se complexo devido ao ponto de vista ser diferente, quando o usuário precisa expor todo o seu processo de negócio, ele pode se deparar com dois aspectos: o primeiro é o receio de ser substituído pelo sistema (existem pessoas assim) e o segundo ponto é “vou tentar ficar sem nada para fazer e transformar todas as minhas rotinas em sistema”.

Neste cenário o analista deve portar-se como intermediador e identificar com o usuário o que realmente pode ser atendido pela área de sistemas. Para tentar estreitar a relação entre analista e usuário algumas técnicas podem ser utilizadas, tais como:

Envio de questionário, contendo as principais questões relacionadas ao motivo da solicitação do novo sistema e/ou melhoria;
Entrevista com os usuários chave, assim poderá constatar que realmente existe uma necessidade sistêmica.

Após este primeiro contato, deve-se identificar e mapear o processo de negócio, assim, pode-se verificar a coerência da solicitação. Nesta fase cria-se uma padronização na forma de trabalhar e com o processo mapeado todos os envolvidos terão o mesmo entendimento ou estarão próximos do alinhamento.

Com o processo levantado, é chegada a hora de levantar os requisitos e finalmente definir quais solicitações serão acatadas pela equipe de desenvolvimento. Na fase de análise podemos começar criando as descrições dos requisitos de maneira simples e entendível ao usuário, após as escritas dos requisitos, devemos mostrar a interação que o sistema terá com o mundo externo e, para isto, geramos o documento de caso de uso.

Após validarmos os documentos, podemos gerar como última fase do levantamento os protótipos, desta forma todos os envolvidos estarão alinhados e consequentemente a chance de falha será menor.

Devemos entender que jamais uma análise de sistemas conseguirá contemplar 100% dos requisitos e que qualquer processo por melhor que seja estará sujeito a falhas e mudanças, é por este motivo que temos que ter a maturidade de entender que sempre podemos melhorar nossos processos. O mundo dos negócios vem sofrendo grandes e constantes alterações, nossa área é a que mais sofre com estes impactos, devemos ficar sempre atentos e prontos para estas mudanças.

Sigam-me no twitter: @ric_agostinho

6 Comentários

Marcelo Alberto Pinto maio 17, 2011 às 4:45 pm

O colega Ricardo abordou um ponto fundamentla para o desenvolvimento de um bom software. “O Processo de Negócio”. Não há software que resista sem uma sólida base de negócio. Geralmente vemos este importante item sendo deixado de lado, “porque onera o desenvolvimento”, entretanto, se a empresa não tem o processo definido, isto tem que entrar no custo do projeto, mas, enquanto as empresas/departamentos clientes não tiverem seus processos bem definidos, ou não quiser arcar com este custo, montar um software fica cada vez mais dificil. Já vi casos de processos tão indefinidos, que seria mais simples costurar uma gelatina do que construir um software.

Carlos Santana maio 18, 2011 às 11:46 am

Primeiro, parabéns pelo excelente texto, é realmente a tarefa requer muito conhecimento de todo o processo de desenvolvimento e as regras do negócio são essenciais para sua implementação, porém, acredito que serão poucas as empresas preparadas para seguir todos os passos, principalmente a fase da elaboração dos protótipos, visto que oneram e muito o custo do software !

Rogerio janeiro 23, 2013 às 10:05 am

Como dito na conclusão, se a área de TI é a que mais sofre com as grandes e constantes alterações, porque ainda há os que insistem em processos unificados – historicamente implementados como processos em cascata, que não funciona – e casos de uso? Certifiquei-me em RUP, mas nunca tive prazer em trabalhar com ele, dada tamanha prolixidade. Trabalhei com ágil e voltei a ver cor na vida. Funciona, atende as expectativas, não é mais caro, foca no resultado, é receptivo a mudança, é motivante e, por fim, trabalha o requisito com toda a equipe e o analista de requisito não está fora desse contexto, visto que equipes ágeis devem ser multidiciplinares.
Vejo que o artigo direciona, quando fala em caso de uso, para um processo unificado, exclusivamente, quando existem processos e tecnologias bem mais atuais, como dito, o ágil e até mesmo o BPM/BPMN.

Profissionais TI - Pra quem respira informação