Neste artigo, vamos tratar da relação entre a Engenharia de Requisitos (EREQ) e as metodologias de desenvolvimento ágeis, em especial o SCRUM. Ou seja, vamos analisar a Engenharia de Requisitos no contexto ágil.
O que é a Engenharia de Requisitos
Inicialmente, pode-se definir a Engenharia de Requisitos como uma disciplina da Engenharia de Software. Ela consiste no uso sistemático e repetitivo de técnicas para cobrir atividades de levantamento, análise e gestão de requisitos para software. Finalmente, o objetivo é ter requisitos de software com qualidade e atendendo aos objetivos de negócio.
A Engenharia de Requisitos no contexto ágil
Dito isso e para melhor entendimento da proposta do artigo, vamos traçar uma diferença importante entre os dois contextos. Geralmente, no processo de desenvolvimento tradicional, cada papel na EREQ é desempenhado por uma pessoa distinta. E ela costuma ter um título como Analista de Requisitos, Engenheiro de Requisitos, etc. Por outro lado nas metodologias ágeis, a EREQ é de responsabilidade principal do Dono do Produto ou Product Owner. E ele delega parte dos requisitos; em especial o detalhamento de itens no escopo, à equipe de desenvolvimento. A equipe é multifuncional.
Por que o Dono do Produto (Product Owner)
Mas por que o Dono do Produto? Porque trata-se de quem melhor representa o interesse do usuário final e, portanto, tem a autoridade para dizer o que vai, ou não, fazer parte do produto final. É ele o encarregado de fazer o que chamamos de Backlog do produto, uma lista com os requisitos do produto desejado que vai ser construído.
Ciclos curtos de entrega e a Engenharia de Requisitos no contexto ágil
Uma metodologia ágil tem, também, outro diferencial importante em relação aos métodos tradicionais. São os ciclos curtos de entrega chamados de Sprint, um período de tempo fixo e pré-determinado dentro do qual a equipe completa conjuntos de itens do Backlog. Esse ciclo pode ser de duas a quatro semanas.
Vale destacar, ainda, outra característica importante do processo ágil. Nele, a EREQ restringe o esforço gasto para entender um requisito ao mínimo necessário para aquele momento, não sendo preciso refinar detalhes de todos os requisitos, com exceção, claro, de casos mais críticos ou complexos. Demanda, assim, um gasto mínimo necessário para ter uma visão do escopo e deixa para detalhar o requisito quando este estiver próximo ao desenvolvimento. Isso difere de uma metodologia tradicional, que busca definir todo o escopo de forma detalhada antes de seguir no desenvolvimento.
Visão dinâmica do produto e a Engenharia de Requisitos no contexto ágil
Ao contrário da metodologia tradicional, a visão inicial do produto não é estática no processo ágil: o conjunto de requisitos que se elabora no momento inicial dificilmente será o mesmo que o produto final vai ter. Ao longo das interações para o seu desenvolvimento, requisitos, histórias ou itens serão eliminados e outros serão acrescentados na medida em que a visão do produto é amadurecida, não só pela equipe de desenvolvimento, mas também pelo próprio cliente.
É importante frisar que, de forma geral, a visão do produto inicial representa um conjunto de requisitos que não é originado de uma única pessoa, mas sim de vários interessados, com demandas específicas. É preciso, então, que alguém execute as atividades da engenharia de requisitos: descobrir quem são essas pessoas e quais são as suas necessidades para refinar as histórias e priorizar as que serão desenvolvidas no próximo ciclo. Caso contrário, a equipe não conseguirá seguir à frente com o desenvolvimento do projeto.
A documentação da Engenharia de Requisitos no contexto ágil
Outro aspecto importante para mencionarmos sobre o processo ágil é a questão da documentação. Muita gente pensa que trabalhar requisitos demanda obrigatoriamente gerar documentação. Mas a verdade é que se existem documentos sem relação com as necessidades do cliente que devem ser satisfeitas, então esse trabalho de requisitos foi mal feito. Eles se tornam mera burocracia, pois não refletem os desejos para o produto final; só geram papel, sem benefícios e sem entregar valor.
Conclusões
Dito tudo isso, chegamos a algumas conclusões importantes. Em primeiro lugar, a EREQ é uma disciplina independente de qualquer tipo de processo de desenvolvi- mento, mas necessária a todos eles. Outro ponto é que o modo que se executa a EREQ em um processo tradicional não é igual ao de um processo ágil, e que, ainda que se troquem nomes de atividades, cargos de quem as executa, momentos em que estas são executadas e artefatos gerados, a EREQ está sempre presente. No final das contas, os dois conceitos são complementares: Ágil – entrega rápida de software funcionando; e EREQ – entrega do software correto. E, por fim, nunca esquecer que velocidade sem direção não vale nada!
Vale a pena assistir à entrevista entre Carlos Eduardo Vazquez e Guilherme Siqueira Simões sobre a medição funcional no desenvolvimento ágil realizada em Junho de 2020.
