O Analista de Requisitos é o profissional responsável por entrevistar os stakeholders de um projeto ou demanda e mapear requisitos funcionais, requisitos não funcionais, regras de negócio e etc. O Analista de Requisitos é o responsável direto pela qualidade do que será desenvolvido e entregue ao cliente. É o ponto focal da equipe de desenvolvimento para dúvidas e esclarecimentos.
Quando uma demanda ou projeto se inicia, o Analista de Requisitos é o responsável por levantar as necessidades do cliente ou solicitante. O profissional agenda reuniões, elabora atas de reunião, identifica se o escopo está fechado e cria as documentações necessárias para o andamento da demanda ou projeto. Iniciar um projeto com o escopo ainda a ser definido é um grande e perigoso problema. Na maioria dos casos, é dado um tempo a mais para o cliente finalizar o escopo e só depois disso, o Analista de Requisitos é acionado para atuar naquele projeto.
Em alguns casos, o Analista de Requisitos desempenha, em parte, o papel de Product Owner e participa de todo o ciclo de desenvolvimento de um projeto. O Analista pode participar ainda na fase de priorização, gerenciando o backlog junto ao cliente. Pode participar na fase de homologação e por fim, manter o cliente atualizado entregando o Status Report da demanda ou projeto. O Analista de Requisitos pode e deve participar de todo o Ciclo de Vida de Desenvolvimento de Sistemas ou em inglês Systems Development Life Cycle (SDLC).
A quantidade de documentos escritos e quão extenso ou aprofundado serão escritos, pode variar de acordo com as necessidades e/ou processos e metodologias utilizadas.
Já participei de projetos em que o cliente pedia documentação extensa e seguindo a UML. Confeccionando muitos artefatos como diagrama de caso de uso, documento de caso de uso, fluxos de atividade ou sequência e protótipos. CMMI é um bom exemplo disso.
Em algumas empresas, demandas internas são tratadas por documentos com informação necessária apenas para o entendimento da equipe de desenvolvimento e stakeholders. O documento não pode ser técnico e também não pode ser tão superficial acarretando indas e vindas de um desenvolvedor até sua mesa.
Quando o assunto é “ser ágil”, estes documentos são praticamente “extintos” e os requisitos são escritos no próprio código fonte do programa.
Quais seriam as qualidades que um profissional de requisitos deve ter?
- Capacidade de comunicação;
- Capacidade de abstração;
- Ser um bom ouvinte;
- Ter conhecimento técnico;
- Ser objetivo nas reuniões;
- Ter uma boa escrita;
- Capacidade de identificar problemas e impactos;
- Conhecer os sistemas alvos de alteração.
Alguns profissionais criticam a ideia de que o profissional tenha que ter conhecimentos de programação ou algum conhecimento técnico. A presença de um profissional da equipe de desenvolvimento durante a reunião de levantamento de requisitos, neste caso supriria a falta de conhecimento técnico do Analista de Requisitos. Já no início do levantamento, ao verificar que o solicitado não é viável tecnicamente de ser desenvolvido, o Analista de Requisitos não perde tempo elaborando toda a documentação necessária.
Portanto, escrever um documento sem verificar a viabilidade técnica, pode acarretar um problema quando a equipe de desenvolvimento começar a ler a documentação e identificar a não viabilidade técnica.
Conhecer os sistemas que serão abordados nas demandas e projetos é um facilitador para que o Analista de Requisitos consiga identificar possíveis impactados em outros sistemas. É claro que não é o Analista de Requisitos que terá responsabilidade final de verificar quais sistemas serão impactados por uma mudança. Essa análise é feita no momento da viabilidade técnica ou no momento em que a equipe de desenvolvimento estima as alterações sugeridas na documentação.
E quais seriam as qualificações técnicas de um Analista de Requisitos? Qual formação, cursos e conhecimentos de ferramentas? Vou elencar algumas abaixo:
- Formação na área de TI e afins;
- Curso de Engenharia de Requisitos;
- Pós-graduação em Inovação;
- Conhecimento de UML;
- Conhecimento em ferramentas de gerenciamento de requisitos, tais como:
No próximo artigo, abordaremos o tema “Certificações na área de Requisitos”.
Obrigado!
“For every complex problem there is an answer that is clear, simple, and wrong.”
H. L. Mencken
Olá Bruno,
ótimo post, claro e objetivo. Parabéns!
Mas fiquei com uma dúvida. Qual a diferença, claro se existir, entre um Analista Funcional que executa atividades de Business Partner junto as áreas de negócio e um Analista de Requisitos? Podemos dizer que esse Funcional é um Analista de Requisitos também? Como diferenciar as duas carreiras?
Faço essas perguntas pois sou Analista Funcional, mas desempenho muito no meu dia a dia essas atividades descritas no post, seja em projetos pontuais ou apenas melhorias de processos.
Obrigado,
Diego Gomes
Diego,
O Analista Funcional é um profissional mais técnico. Tem que possuir profundo conhecimento técnico para elaborar a documentação funcional.
Diferente do Analista de Requisitos, o profissional não precisa ser técnico. Na verdade, existe uma equipe técnica que faz a verificação se aquele estudo de viabilidade escrito pelo analista é viável ou não.
Já o Analista Funcional geralmente é um desenvolvedor. Ele escreve a documentação funcional sabendo se aquilo é possível ou não.
Outra diferença, e acredito ser a maior, é que o Analista Funcional tende a ser um profissional especialista em um determinado sistema. É comum ver por aí, Analista Funcional SAP, Analista Funcional Oracle, Analista Funcional SalesForce e etc. São profissionais com profundo conhecimento técnico de um ou mais módulos de CRM, por exemplo.
Me arrisco a dizer que o Analista de Requisitos é um profissional “Generalista” enquanto que o Analista Funcional é um profissional “Especialista”. Mas, entendo que as atividades do Analista Funcional e do Analista de Requisitos são as mesmas ou bem próximas.
Me adicione no Linkedin: https://br.linkedin.com/in/brunoreisamaral
Abraço e obrigado!
Bruno Amaral