31
jan
2011

Carreiras em TI - O que faz um Analista de Requisitos

Um Analista de Requisitos trabalha para levantar, analisar, documentar e validar as necessidades do cliente dentro de um projeto de software. Essas necessidades são inicialmente ouvidas do cliente como funcionalidades - ou seja, idéias ou desejos de como o sistema deve funcionar - e normalmente são transformadas em requisitos funcionais e não-funcionais.

Podemos dizer que um requisito funcional é uma funcionalidade reescrita para ter três características: clareza de conteúdo, ausência de ambiguidade e em linguagem mais formal. Em outras palavras, um requisito deve ser claro, formal e não-ambíguo.

Vamos supor que o cliente diga “Quero que o sistema gere um relatório de vendas por período”. Veja a diferença abaixo:

  • Funcionalidade: “Gerar relatório de vendas por período”
  • Requisito funcional: “Dentro do módulo de Relatórios, o sistema deve permitir a geração de um relatório com todas as vendas ocorridas entre duas datas informadas pelo usuário. Como datas default, o sistema deve sugerir o primeiro dia do mês corrente e a data atual.”

Mas o cliente também pode falar “Por falar nisso, nós não usamos Windows por aqui. Todo mundo vai usar Linux nas máquinas que acessam o sistema”. Nessa hora, o Analista de Requisitos ouve um *DING* e percebe que apesar de não estarem ligados às funcionalidades (telas, formulários, relatórios) do sistema, essas informações também são requisitos para o projeto. Então ele:

  1. Anota um requisito não-funcional (RNF) “O sistema será hospedado em servidores Linux”
  2. Descobre um pouco mais e anota outro RNF “Mesmo não tendo sido definido o SGBD para o sistema, o cliente já possui pessoal especializado em MySQL.”
  3. Pergunta ao cliente “Que browsers vocês costumam usar? E qual versão? Existe alguma perspectiva disso mudar?” e com a resposta escreve mais um RNF: “O sistema deve ser acessível a partir do browser Firefox 1.5 ou superior”.

Se você é um Analista de Requisitos e quer garantir que um requisito está bem escrito, leia-o novamente como se OUTRA pessoa o estivesse vendo pela primeira vez. Tente ver se alguém além de você consegue captar 100% do texto, sem duplo-sentido ou interpretações diferentes. Se isso acontecer, pode pular para o próximo requisito.

Em projetos usando RUP ou processos adaptados, sugere-se também modelar casos de uso, de forma a estruturar as funcionalidades e atores do sistema usando notação UML. Segundo o RUP, isso contribui com mais um passo na direção do software mais robusto: os requisitos são expandidos e pensa-se tanto na sequência de ações e respostas do sistema (fluxo principal) quanto em potenciais situações adversas (fluxos alternativos).

Gestão do escopo

O conjunto de requisitos - funcionais e não-funcionais - irá determinar o escopo do projeto. O escopo é tudo que o software deve implementar, e será a referência para todo o time de desenvolvimento. E aí vem o segundo trabalho do Analista de Requisitos, que é a gestão de requisitos ao longo de todo o projeto.

Inicialmente, ele participa do processo de estimativa. Consultando arquitetos, analistas e desenvolvedores, ele deve estimar o esforço para implementar cada requisito definido. Isso será a base do planejamento de prazos e custos do projeto! Além disso, se um requisito mudar, ele pode ter impacto em diversas coisas: custos, prazo e qualidade. Para garantir que isso acontece de forma controlada, estabelece-se alguma forma de medir a rastreabilidade dos requisitos - ou seja, rastrear como eles se relacionam entre si e com o restante dos itens de projeto (código, casos de teste, defeitos, entre outros). Por isso, o Analista de Requisitos deve sempre participar de reuniões de mudanças em projetos, e suas recomendações sempre devem ser respeitadas para aceitar ou não uma mudança no escopo.

Conclusões

Metodologias como o XP - Extreme Programming - têm práticas diferentes para lidar com o problema dos requisitos, criando user stories ao invés de grandes documentos de especificação com requisitos e casos de uso. Elas estão no meio do caminho entre funcionalidades e a formalidade dos requisitos, dado que são escritas pelos próprios usuários do sistema tentando explicitar ao máximo o que precisam.

Para ser um bom Analista de Requisitos, é preciso ser organizado e às vezes até metódico. Para ser um excelente Analista de Requisitos, é preciso saber ouvir e escrever bem. Essa é uma das especialidades mais recomendadas na área de TI para mulheres, e os motivos são vários:

  • Elas sabem ouvir melhor do que os homens
  • São mais empáticas e percebem melhor as sutilezas do comportamento humano
  • Costumam ter mais horas de leitura (tanto revistas quanto livros) e também costumam ter maior experiência em escrever (quantos garotos de 12 anos você já viu escrevendo diariamente no “querido diário”?)
  • Têm um talento natural para conversar sem precisar ir direto ao ponto, facilitando a comunicação e envolvendo os outros participantes da reunião.

Não é necessário um curso de Ciência da Computação, Sistemas da Informação ou similar para ser um bom Analista de Requisitos. Até mesmo pessoas da área de Comunicação podem desempenhar esse papel, contanto que entendam o mínimo de UML ou técnicas similares para registrar seu trabalho. Até mesmo usuários mais experientes podem se tornar excelentes especialistas em Requisitos na área de conhecimento das empresas em que atuam.

Não são muitas as empresas que contratam especificamente Analistas de Requisitos. Esse papel é normalmente acumulado por um Desenvolvedor ou Analista de Sistemas, dando origem aos famosos “Analistas Desenvolvedores”. Mesmo assim, o mercado procura cada vez mais esse tipo de profissional.

Fonte: Infoblogs