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
Leave a Comment