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?
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:
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
PSM I, PACC, SFC, ISMF, SMAC, IPOF, STMAC, ITILv3 e MCTS. Possuo 20 anos de experiência em TI com background em desenvolvimento. Desde 2008 a liderar equipas de performance. Desde 2010 a trabalhar com Scrum, Kanban e XP. Desde 2017 a desempenhar papel de Scrum Master e Agile Coach. Desde 2018 a escrever artigos sobre Scrum, Equipas de Performance e Metodologias Ágeis.
You must be logged in to post a comment.
12:00:04 pm
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
2:12:05 pm
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