Levantamento Ágil de Requisitos - Site Campus: A Escola do Novo GP

Levantamento Ágil de Requisitos

Levantamento Ágil de Requisitos

Entender o que o cliente quer nunca é fácil… Mas será que a culpa é dele? Qual o seu esforço para entender o que ele quer? Para lhe ajudar nós temos um recurso muito valioso: o Levantamento de Requisitos. Neste artigo abordamos o assunto com dicas, técnicas e informações úteis para esta etapa do projeto.

No artigo anterior ajudamos você à elaborar um plano de comunicação ágil e eficiente. Veja agora como usar técnicas de comunicação e trabalho em equipe para identificar melhor os requisitos do seu projeto.

Precisamos entender e identificar quais são os requisitos do projeto, inicialmente na visão do cliente mas também considerando a visão de quem entregará o projeto.

Você encontrará muita informação sobre isso no Google, além disso este tema é muito utilizado em cursos de tecnologia e de gestão de projetos. Apesar disso vamos passar algumas informações básicas para que você possa entender melhor os requisitos do seu projeto a partir de hoje.

Processos, Restrições, Premissas e Riscos.

Quando buscamos o entendimento dos requisitos, é comum que as partes interessadas forneçam informações que não são requisitos. Mesmo assim estas informações são importantes e devem ser classificadas e consideradas de alguma forma. Abaixo algumas delas:

  • Premissas
    • Pense naquilo que você acredita ser verdadeiro mas sem provas. Toda premissa tem um risco associado a ela ok?
      • Exemplo: Nosso fornecedor disponibilizará acesso completo ao seu ambiente de TI.
        • Você pode e deve incluir um risco associado, exemplo: “O fornecedor pode não autorizar o acesso às instalações durante a noite”.
  • Restrições
    • É tudo o que restringe algo no projeto. Da mesma forma como premissa, uma restrição pode virar um risco.
      • Exemplo: Temos apenas R$100.000,00 para o projeto.
        • Risco associado: O Dólar pode subir, inviabilizando o projeto caso ele ultrapasse R$100.000,00.
  • Riscos
    • Riscos são situações que podem prejudicar ou beneficiar o seu projeto. Você deve criar um plano de ação para cada um deles, podendo evitá-lo, aceitá-lo, mitigá-lo ou transferir este risco.
      • Exemplo: Temos a probabilidade de 50% de chover durante o período de construção do nosso projeto.
        • Ação: Antecipar os elementos da construção que não se prejudiquem durante as chuvas. (especificar claramente quais são estes elementos)
  • Processos
    • É comum que durante o levantamento de requisitos as pessoas peçam mudanças no processo em que elas trabalham. Considere estas informações, mesmo que não seja responsável por elas, pois elas podem se tornar um risco ou restrição no futuro.
      • Exemplo: Hoje todas as autorizações demoram 1 semana para serem aprovadas devido a burocracia do nosso sistema
        • Risco associado: Podemos ter 1 semana de atraso quando for necessário contratar mais material para o nosso projeto devido ao processo de autorização do cliente.

Procure incluir estas informações na sua TAP caso esteja no início do projeto. Caso contrário, registre em outro local. Lembre-se: Durante suas reuniões diárias, o foco deve ser sempre em verificar se algum Risco aconteceu ou se algum destes itens não é mais válido ou sofreu alteração.

Mudanças em processo são mais complicadas mas você pode sempre entrar em contato com seu cliente para buscar melhorias que ajudem no andamento do seu projeto.

Como Classificar os Requisitos

Podemos classificar de duas maneiras:

    • Requisitos Funcionais
      • São aqueles relacionados ao funcionamento do produto. Em caso de um software podem estar relacionado aos seus recursos, cálculos, saídas, processos, etc.
      • Você ainda pode dividir os requisitos funcionais de 3 maneiras:
  • Evidente: São os requisitos que o cliente tem plena ciência. Exemplo: Ao abrir o sistema aparece o login e ele tem que inserir usuário e senha.
  • Escondida: São os requisitos importantes mas ocultos do usuário. Exemplo: Manter uma tabela com log de acessos para consulta pelo administrador.
  • Friso: Em software são ações que não afetam as demais funções do sistema. Exemplo: Gerar um backup automático.
  • Requisitos Não Funcionais
    • São aqueles requisitos relacionados à utilização do produto. Estamos falando da disponibilidade, confiabilidade, tecnologias ou até mesmo segurança envolvida. É muito provável que um requisito não funcional gere alguma restrição ou risco em um requisito funcional.
      • Exemplo: Nosso sistema deve funcionar em qualquer celular com Android a partir da versão 7.  

Procure entender os requisitos iniciais do projeto mas não se preocupe em detalhar todos eles. No SCRUM temos o conceito de Backlog, que contém as estórias (requisitos) do dono do projeto porém só detalhamos os ítens prioritários. Os recursos mais distantes, menos importantes, vamos detalhar no futuro.

Comece pelo final

Comece por aquilo que realmente trará valor ao seu projeto. Não adianta querer desenvolver por exemplo um sistema de vendas começando pela parte contábil se você ainda não tem desenvolvido o processo de lançamento de pedidos e faturamento. Não adianta também focar em todas as telas de cadastro (cliente, fornecedor, produtos) se ele quer vender. Você pode mostrar o sistema de vendas em funcionamento, alimentando o banco de dados de cliente manualmente para ele simular e só depois se preocupar com as telas de cadastro.

Desta forma em pouco tempo você mostrará o sistema para ele, coletando feedback e ajustando seu desenvolvimento.

Validando os Requisitos

Você consegue validar os requisitos de 3 maneiras: Necessário, Verificável e Atingível.

  • (Verificável + Atingível) – Necessário (Desejável):
    • Pense: Se você não precisa, então não é requisito! Não misture os desejos com as necessidades reais do projeto.
  • (Necessário + Atingível) – Verificável (Fácil):
    • Se você quer validar, precisa de uma base, algo pra testar, demonstrar ou comprovar. Se o requisito é genérico, subjetivo demais, ele não é verificável, portanto você também elimina ou detalha mais.
  • (Verificável + Necessário) – Atingível: (Milagroso):
    • É aquele requisito que você até consegue comprovar porém é necessário um recurso absurdo (R$1 trilhão de reais por exemplo). Se ele está assim, então não é um requisito. Se você já sabe que não conseguirá atingi-lo, ele não é um requisito.

Parece simples? Saiba que na maioria dos projetos os requisitos são levantados da maneira correta. O que acontece? Um requisito definido incorretamente pode se tornar o motivo daquela famosa discussão: “Mas este recurso não estava incluso? Achei que sim!”. Requisito mal entendido ou detalhado pode se tornar um risco para o projeto, ou até mesmo acabar com ele.

Diferença entre Coleta de Requisitos X Elicitação de Requisitos

  • Coleta de Requisitos (Gathering)
    • Imagine que é como pegar conhas na Praia
    • Você pega somente o que você consegue ver.
    • Coleta reativa, não proativa.
  • Elicitação de Requisitos
    • Pense como na arqueologia
    • Você planeja uma busca, em um local de propósito
    • Muito mais proativo, menos reativo.

Percebeu como é muito melhor a Elicitação? É bem melhor você sentar em uma sala com toda a equipe do seu projeto, discutir o mesmo, apontar uma série de questões e perguntas para só então começar o trabalho. Parece ou não com a Reunião de Planejamento da Sprint?

Principais Técnicas

Abaixo relaciono as principais técnicas que podemos utilizar para elicitação dos requisitos:

  • Entrevistas
    • Técnica Direta:  Usamos para compreender os reais problemas e soluções na visão da parte interessada. Você pode receber uma demonstração de como a pessoa realiza o trabalho ou explicações sobre a real necessidade do produto do seu projeto.
  • Questionários
    • São perguntas específicas. Você apresneta uma lista de questões relevantes de acordo com o tipo de projeto ou processo no qual a pessoa está envolvida. Não esqueça de garantir o entendimento das questões e de preferência após a técnica direta. Lembre-se: Foque mais em compreender e ser compreendido do que apenas fornecer a lista de questões.
  • Casos de Uso
    • Converse com seu cliente para entender para que o produto será usado. Utilize artefatos visuais para identificar quem irá realmente interagir com o produto e suas conexões com outras necessidades da empresa.
  • Jogo de Funções
    • Aqui você assume o papel do cliente ou do usuário do produto, executando no lugar dele o processo. Assim você terá uma melhor visão das reais necessidades e dificuldades que ele enfrenta.
  • Brainstorming
    • Coloque em uma mesma sala os envolvidos no assunto que quer maiores explicações. Nesta sessão cada um apresenta o máximo de idéias possíveis ao redor de um tema. Aqui a imaginação deve fluir, não é o momento para críticas ou debates sobre as idéias apresentadas. Garanta que todos participem. Após isso, revise as idéias e as combine para conseguir extrair os requisitos.
  • Workshop de Requisitos
    • Quase igual ao Brainstorming. É uma reunião mais focada entre os participantes, conduzida com auxilio de um facilitador. Nesta reunião todos terão sua vez de falar e, ao final do workshop, você já terá a lista dos requisitos. Você pode inclusive aplivar outras técnicas em conjuto, incluindo as apresentadas acima (questionário, técnica direta, etc)

Se você pesquisar no Google encontrará dezenas de técnicas como prototipagem, observação, pesquisa de mercado, análise de documentos, entre outras. Pesquise e compreenda as técnicas e descubra quais serão úteis ao seu projeto.

Requisitos e o Manifesto Ágil

Olhando para o manifesto ágil, vamos ver como eles se relacionam ao levantamento de requisitos:

  • Indivíduos e interação entre eles mais que processos e ferramentas
      • Entenda como o produto do seu projeto será utilizado ou trabalhado com as partes interessantes. Não adianta você vender um sistema ERP perfeito, sem erros se as pessoas da empresa não conversam e não conseguem utilizar a ferramenta.
  • Software em funcionamento mais que documentação abrangente
      • Reveja os documentos do seu projeto. Não adianta detalhar todos os requisitos no começo. Você gastará tempo e não focará no que traz real valor. É o mesmo que você criar um manual perfeito de um produto que não funciona porque gastou mais tempo criando o manual do que desenvolvendo o sistema.
  • Colaboração com o cliente mais que negociação de contratos
      • Os requisitos podem mudar ao longo do projeto. Regras de negócio mudam, as necessidades mudam, principalmente em projetos longos. Aprenda a lidar com a mudança da melhor maneira possível. Existem modelos de contrato para projetos ágeis como o modelo guarda-chuva.
  • Responder a mudanças mais que seguir um plano
    • O que é melhor para o cliente? Ver o produto em 3 meses ou em 1 ano? Quanto antes mostrar, mais rápido você terá o feedback e melhor conseguirá responder aos ajustes. Trabalhe nos requisitos prioritários, entregue valor mais rápido!

Agora, a imagem clássica de um projeto cujo levantamento de requisitos não foi feito da maneira correta:

Escopo-do-Projeto

Assine a newsletter do prof. Frederico Aranha

#
Fale com o Site Campus

Tags:, , , ,