Levantamento de Requisitos: Uma abordagem simples

Por que se estressar tanto com esse negócio de Levantamento de Requisitos? pensou um Analista começando na área, meio perdido, enquanto justamente rabiscava uns requisitos numa planilha. “Será só um protocolo? formalidade?” Por querer entender melhor o que estava fazendo e achar um incentivo pra continuar, pesquisou bastante, anotou, entendeu, exercitou, compartilhou e aqui está o que ele descobriu.

A verdade é que o Levantamento de Requisitos é como o alicerce de uma casa. Você pode ter a melhor arquitetura, os melhroes materiais, mas se a base não estiver sólida, tudo pode desmoronar. Essa fase inicial do processo de desenvolvimento de software é super importante para garantir que o produto final atenda às expectativas e necessidades do cliente, ou até mesmo as suas como desenvolvedor.

Para quem não sabe para onde vai, qualquer caminho serve

Lewis Carroll

Essa citação do Lewis Carrol já da uma dica. Imagine construir uma casa sem ter uma ideia clara do que o cliente deseja. Você poderia acabar com uma casa com cinco quartos quando o cliente queria dois, ou com uma cozinha gourmet quando o que ele realmente queria era bancada rústica e uma grelha. O Levantamento de Requisitos é tipo o arquiteto da construção, sendo pago para que cada funcionalidade, cada detalhe, seja cuidadosamente planejado e alinhado com as expectativas do cliente ou do usuário. A diferença é que para o cliente final não é “qualquer caminho que serve”, muito pelo contrário, então temos que saber exatamente “para onde se vai”.

Falando no contexto de Desenvolvimento de Softwares, o levantamento de requisitos pode ser definido como o processo de compreensão e identificação das necessidades que o cliente espera que sejam abordadas pelo sistema a ser desenvolvido. Esse processo define as funcionalidades e limitações que o software precisará atender para chegar ao objetivo desejado.

Quem participa do Levantamento de Requisitos? Basicamente todas as partes interessadas – incluindo clientes, vendedores, especialistas do setor, desenvolvedores de software, analistas de negócios, gerentes e gestores, todos podem colaborar para juntar as informações necessárias sobre o que será construído.

Analisando esse fluxo super didático que cita as etapas de Desenvolvimento de Sotfware, se você leu da esquerda para a direita, nota-se que a Análise de Requisitos é a primeiro passo no processo, e há motivos para isso.

Pense no seguinte cenário, você ou sua equipe, aceitam desenvolver um software para o cliente e acham que possuem um entendimento suficiente sobre tudo o que ele quer, quando nem mesmo o cliente tem esse entendimento completo. Então, de alguma forma, fazem uma estimativa de esforço para o desenvolvimento e vendem o pacote. Tempo depois, durante o desenvolvimento começam a perceber várias funcionalidades que não tinham previsto anteriormente, parece que todo dia alguém acorda com uma nova ideia na cabeça, uma nova funcionalidade, uma nova demanda. Porém, provavelmente nenhuma dessas “novas” demandas que apareceram são novas de fato, apenas não foram mapeadas anteriormente, o quê pode levar a retrabalho, replanejamento e novas especificações. Esse é um possível resultado de não fazer um Levantamento de requisitos no processo de desenvolvimento do software.

Para entender um pouco mais sobre como fazer uma análise de requisitos em si, vale a pena definiir primeiramente os tipos de requisitos que existem. Cada tipo tem um papel importante em definir as funcionalidades, restrições e regras. Requisitos podem ser classificados como Requisitos Funcionais, Requisitos Não Funcionais e Regras de Negócio.

Requisitos Funcionais

Os requisitos funcionais são nada mais do que as funcionalidades que o sistema deve oferecer para atender às necessidades do usuário. Eles definem o que o sistema deve fazer e são geralmente declarados em termos de entradas, processos e saídas. Exemplos de requisitos funcionais:

• Cadastro de Usuário: O sistema deve permitir que os usuários se cadastrem fornecendo informações como nome, e-mail e senha.
• Funcionalidade de Pesquisa: O sistema deve fornecer uma função de pesquisa que permita aos usuários buscar informações no banco de dados.

Requisitos Não Funcionais

Os requisitos não funcionais definem as características do sistema que não estão relacionadas diretamente às funcionalidades, mas afetam a eficácia, usabilidade e o desempenho do sistema. Eles podem incluir requisitos de desempenho, segurança, usabilidade, entre outros. Exemplos de requisitos não funcionais são:

• Desempenho: O sistema deve ser capaz de processar 1000 transações por segundo sem comprometer o desempenho.
• Segurança: O sistema deve garantir a proteção dos dados do usuário por meio de criptografia SSL.

Regras de Negócio

As regras de negócio são condições ou restrições que se aplicam ao negócio e ao sistema. Elas definem o comportamento esperado do sistema em relação aos processos de negócios. Exemplos de regras de negócio incluem:

• Clubinho fidelidade: Se um cliente fizer mais de cinco compras, ele recebe automaticamente um desconto de 10% em sua próxima compra.
• Restrições de Estoque: Um produto não pode ser vendido se o estoque estiver abaixo de 20 unidades.

Mas qual é o resultado de uma análise de requisitos? O resultado de uma análise de requisitos no contexto do desenvolvimento de software é um documento detalhado e que define as necessidades, expectativas e funcionalidades esperadas para o sistema a ser construído.

Esse documento, muitas vezes chamado de especificação de requisitos, serve como uma base para a equipe de desenvolvimento entender o que precisa ser implementado. Ele inclui informações como requisitos funcionais e não funcionais, critérios de aceitação, restrições e prioridades. O produto final dessa análise é, portanto, um guia abrangente que orienta todas próximas etapas do desenvolvimento de software, garantindo que o sistema seja construído de acordo com as expectativas do cliente e do time de desenvolvimento.

Resumindo, o resultado pode ser a famosa planilha em Excel, embora também possa ter outros formatos, sendo a planilha uma escolha comum devido apraticidade e facilidade de compartilhamento de informações entre os membros da equipe e os demais envolvidos.

Porém não basta encher uma planilha com funcionalidades e esperar que alguém entenda alguma coisa. Durante o processo de levantamento de requisitos, assim que o time vai adquirindo uma visão mais detalhada sobre o software a ser desenvolvido e tem conversas com o cliente, a planilha crescre muito rapido e por isso é importante classificar, organizar e categorizar os requisitos levantados. Formas de fazer isso são separar em tipos, categorias, criticidade, objetivos de negócio e etc. Abaixo um exemplo simples de uma Planilha de Requisitos de um aplicativo de tarefas.

A planilha exemplificada acima é uma ferramenta prática para organizar os requisitos levantados durante o processo de especificação de software. Cada requisito é atribuído a um número identificador (Nº) para facilitar referências e rastreamento. Os tipos de requisitos (Funcional ou Não Funcional), níveis de criticidade, categorias e descrições detalhadas fornecem uma visão abrangente de diferentes aspectos dos requisitos.

Por exemplo, o requisito R-01, marcado como Funcional e de alta criticidade, aborda a capacidade do sistema de permitir a criação de novas tarefas. Já o requisito R-03, classificado como Não Funcional e de baixa criticidade, trata da responsividade da interface do usuário em dispositivos móveis.

A categorização por tipos e níveis de criticidade auxilia na priorização e destaque dos requisitos mais cruciais para o sucesso do sistema. Além disso, a inclusão de informações sobre compatibilidade, desempenho, segurança e usabilidade reflete a abordagem abrangente do levantamento de requisitos, considerando não apenas as funcionalidades específicas, mas também aspectos essenciais para a qualidade global do software. Essa planilha serve como uma referência para a equipe de desenvolvimento, proporcionando uma compreensão clara e estruturada das necessidades do cliente.

É importante deixar claro que o exemplo apresentado é uma versão simplificada de uma planilha de requisitos, e a realidade pode(e deve) ser mais complexa, variando de acordo com o escopo do projeto. Em cenários mais amplos, as informações contidas na planilha podem abranger uma gama ainda maior de requisitos, detalhes e interações específicas do sistema. O processo de levantamento de requisitos é bastante adaptável e, consequentemente, a documentação resultante reflete o contexto de cada projeto. Portanto, equipes de desenvolvimento podem ajustar e personalizar formatos de documentação de requisitos para atender às necessidades específicas dos projetos.

Vantagens do Levantamento de Requisitos

O entendimento aprofundado do escopo do software durante o levantamento de requisitos é importante para o sucesso do projeto, pois fornece uma visão clara das expectativas e necessidades dos usuários. Esse entendimento prévio permite que a equipe de desenvolvimento evite ambiguidades, garantindo uma definição precisa das funcionalidades essenciais do sistema.

As estimativas de custos e prazos mais precisas são outra vantagem do levantamento de requisitos. Ao realizar uma análise detalhada nessa fase, as equipes podem calcular o esforço de desenvolvimento de forma mais precisa, o que contribui para uma gestão eficiente dos recursos financeiros e temporais do projeto, evitando surpresas desagradáveis no decorrer do desenvolvimento.

A categorização de funcionalidades, parte integrante do levantamento de requisitos, não apenas facilita o desenvolvimento posterior, mas também proporciona uma compreensão mais clara das inter-relações entre diferentes partes do sistema. Isso resulta em uma arquitetura mais coesa e adaptável, simplificando a manutenção e as futuras melhorias no software.

A facilitação do planejamento é outra vantagem. O levantamento de requisitos oferece uma base estruturada para o planejamento do projeto, permitindo uma alocação eficiente de recursos, a definição de marcos importantes e a criação de um cronograma realista. Isso contribui para uma execução suave do projeto, minimizando riscos e assegurando a entrega dentro dos prazos estipulados.

Metodologias para Realizar a Análise de Requisitos

Várias técnicas podem ser utilizadas para coletar, analisar e documentar as necessidades dos usuários e do sistema. Aqui estão algumas metodologias comuns de levantamento de requisitos.

Entrevista: A técnica de entrevistas no levantamento de requisitos é uma maneira direta de coletar informações importantes para o desenvolvimento de um software. Durante uma entrevista, um membro da equipe conversa com os usuários ou stakeholders para entender suas necessidades e expectativas. Por exemplo, ao criar um aplicativo de planejamento financeiro, o analista pode entrevistar potenciais usuários para descobrir quais recursos são mais importantes, como a capacidade de rastrear despesas mensais ou receber alertas para pagamentos pendentes.

Observação: A técnica de observação no levantamento de requisitos envolve simplesmente observar como as pessoas realizam suas tarefas no ambiente real de trabalho. Por exemplo, ao desenvolver um aplicativo de gerenciamento de estoque para um supermercado, os analistas podem observar os funcionários registrando as entregas, reabastecendo prateleiras e registrando vendas. Essa observação direta oferece insights sobre os processos diários. Ao observar as atividades em tempo real, os analistas podem entender melhor as necessidades do usuário e garantir que o software seja projetado de maneira a otimizar e simplificar as operações cotidianas.

Brainstorming: O brainstorming é uma técnica colaborativa de levantamento de requisitos que estimula a geração livre e rápida de ideias. Durante uma sessão de brainstorming, membros da equipe se reúnem para contribuir com pensamentos e sugestões relacionadas ao projeto. Por exemplo, ao desenvolver um aplicativo de planejamento de viagens, uma sessão de brainstorming pode envolver a equipe gerando ideias sobre funcionalidades, como a capacidade de criar itinerários personalizados, compartilhar dicas de viagem e receber alertas sobre condições meteorológicas. Este méotodo promove a criatividade, permite que diversas perspectivas sejam consideradas e ajuda a identificar soluções para atender às necessidades do usuário.

Análise de documentação existente: A técnica de análise de documentação existente no levantamento de requisitos envolve a revisão de documentos já disponíveis para coletar informações relevantes. Por exemplo, ao desenvolver um sistema de gestão de recursos humanos, os analistas podem analisar manuais de procedimentos internos, políticas de RH existentes e registros de treinamento. Através dessa revisão, a equipe pode identificar requisitos específicos relacionados à gestão de folhas de pagamento, processos de recrutamento ou requisitos de conformidade legal. A análise de documentação existente é eficaz para aproveitar informações já documentadas, economizando tempo e proporcionando insights sobre as práticas e procedimentos atuais da organização. Essa técnica é particularmente útil quando se busca compreender processos internos e requisitos específicos já estabelecidos.

A técnica de JAD, ou Desenvolvimento de Aplicações em Grupo, é uma técnica colaborativa no levantamento de requisitos, envolvendo a participação ativa de stakeholders(pessoas ou grupos envolvidos em um projeto, sendo afetados por suas ações e resultados), usuários e membros da equipe em sessões estruturadas de trabalho conjunto. Por exemplo, ao criar um sistema de gerenciamento de projetos, uma sessão JAD poderia reunir gerentes de projeto, membros da equipe técnica e usuários finais para discutir funcionalidades essenciais, fluxos de trabalho e critérios de sucesso. Essas sessões ajudam na comunicação direta, esclarecem dúvidas imediatamente e ajudam a alinhar as expectativas de todas as partes interessadas.

Storyboarding: A técnica de Storyboarding usa uma metodologia visual no levantamento de requisitos, envolvendo a criação de sequências de imagens ou esboços para representar a interação do usuário com o software. Por exemplo, ao desenvolver um aplicativo de compras online, a equipe pode criar storyboards que ilustram o fluxo desde a seleção de produtos até o checkout. Essas imagens ajudam a visualizar como os usuários irão interagir com o sistema, mstrando possíveis pontos de melhoria na interface do usuário e identificando requisitos específicos para aprimorar a experiência do usuário.

Análise de Casos de Uso: A técnica de Análise de Casos de Uso é uma abordagem no levantamento de requisitos que se concentra em descrever situações específicas em que o sistema será utilizado. Por exemplo, ao desenvolver um aplicativo de gerenciamento de tarefas, um caso de uso pode ser a criação de uma nova tarefa, descrevendo passo a passo como o usuário interage com o sistema para adicionar uma tarefa à lista. Cada caso de uso destaca as ações dos usuários e as respostas esperadas do sistema, proporcionando uma compreensão clara dos requisitos funcionais. Essa técnica é valiosa para identificar fluxos de trabalho e interações fundamentais, garantindo que o software atenda adequadamente às necessidades específicas do usuário em diferentes cenários.

Posts mais recentes

Bruno Kappi

Analista de Sistemas e Desenvolvedor Web, formado em Analise e Desenvolvimento de Sistemas, Processos Gerencias e Técnico em Eletrônica