Introdução à gestão de requisitos: um guia passo a passo

É sexta-feira à noite e você está prestes a pedir pizza. Você tem o telefone em uma mão e uma lista de pedidos dos seus amigos na outra. Mas, primeiro, você precisa organizar as preferências de todos e decidir que tipo de pizza pedir. Calabresa? Queijo? Vegetariana?

Pedir pizza está começando a parecer estranhamente como gerir os requisitos para o seu mais recente lançamento de produto. Assim como na situação acima, a gestão de requisitos consiste em ouvir as partes interessadas e entender a melhor forma de atender às suas necessidades. 

O que é a gestão de requisitos?

A gestão de requisitos é uma maneira de garantir que os entregáveis finais do projeto atendam às necessidades dos clientes e das partes interessadas internas. Nesse caso, um requisito é algo que as partes interessadas precisam ou querem do seu produto. As partes interessadas podem ser internas (como parceiros interdisciplinares) ou externas (como clientes). 

A gestão de requisitos é mais frequentemente usada por equipes de desenvolvimento que trabalham em produtos e recursos de software, mas também pode ser aplicada de forma mais geral à gestão de projetos. Por exemplo, um requisito pode ser uma funcionalidade que permita aos clientes usar o seu produto com sucesso, ou um aspecto do seu produto que ajude os parceiros interdisciplinares a atingir as suas metas de Business. 

Antes de começar a trabalhar em um produto, é necessário concordar com os requisitos exatos para garantir que você esteja dando às partes interessadas o que elas precisam. A gestão de requisitos ajuda a documentar e priorizar os requisitos, acompanhar as mudanças e manter o alinhamento com as partes interessadas durante todo o ciclo de vida do projeto. Ela também ajuda a gerir os requisitos em constante mudança e a garantir que o projeto permaneça dentro do escopo. 

O que é um requisito? 

Um requisito é um componente que você precisa implementar para concluir uma funcionalidade ou produto. Em outras palavras, é algo que o seu produto precisa ter ou fazer para atender às necessidades das partes interessadas. Os produtos de software podem ter centenas de requisitos. Mas, independentemente de quantos requisitos o seu produto tenha, todos eles devem ser: 

• Necessários: você precisa desse requisito para atingir as metas do seu negócio ou produto. 

• Específico: o requisito é detalhado e tem um propósito claro. 

• Compreensível: o requisito está claramente escrito e é fácil de compreender. 

• Precisos: o requisito tem informações precisas suficientes sobre o desafio ou a necessidade que está abordando. Isso significa que, em vez de apenas descrever o que precisa ser feito, você também deve esclarecer por que o requisito é importante. 

• Viável: você deve pesquisar o requisito para ter certeza de que pode implementá-lo com a sua pilha de tecnologia e infraestrutura de código atuais.

• Testável: você deve ser capaz de testar o requisito por meio de testes de usuário, testes A/B ou outro método. 

Vejamos um exemplo. Imagine que você está criando um aplicativo e um dos seus requisitos é que ele seja traduzido para inglês, chinês, japonês e francês, porque esses idiomas se alinham aos seus principais mercados de negócios.

• Este requisito é necessário para lançar o aplicativo nos principais mercados da empresa e atingir os objetivos de business. 

• É específico porque você descreve quais idiomas precisa e que todo o aplicativo precisa ser traduzido. 

• É compreensível porque não entra em detalhes técnicos, mas foi escrito de uma forma que os membros da equipe e as partes interessadas interdisciplinares podem entender. 

• É preciso porque você descreveu claramente por que o requisito é importante: inglês, chinês, japonês e francês se alinham aos principais mercados da sua empresa. 

• É viável porque você já criou protótipos e casos de teste em outros idiomas, portanto sabe que a localização é possível e funcionará conforme o esperado. 

• É testável porque você tem um sistema para testar e confirmar a precisão de cada versão traduzida. 

Por que a gestão de requisitos é importante? 

Para criar um ótimo produto, você precisa da gestão de requisitos. Veja por quê: 

• Entregar as funcionalidades certas. O processo de gestão de requisitos ajuda a definir o que os seus usuários precisam, entendendo como eles interagem com o produto. Isso ajuda a alinhar os seus entregáveis, em primeiro lugar, com as necessidades essenciais dos seus clientes. 

• Alinhar-se às metas de negócios. Ao documentar e priorizar os requisitos, certifique-se de que cada um deles esteja alinhado às suas metas gerais de negócios. Por exemplo, um requisito para traduzir o seu aplicativo para 12 idiomas apoiaria uma meta de negócios de expansão para mercados internacionais. Se um requisito não contribui para as metas de negócios, isso provavelmente significa que você deve investir recursos em outro lugar, ou ter uma boa razão para a importância desse requisito. 

• Evitar desvios de escopo. Os requisitos definidos funcionam como um escopo do projeto: eles estabelecem limites e definem exatamente as metas e os entregáveis para os quais você trabalhará. Definir os requisitos com antecedência ajuda a identificar possíveis obstáculos e a reagir quando as partes interessadas tentam adicionar requisitos adicionais.

• Evitar obstáculos. Criar um produto é complexo: há desenvolvimento de software, design e testes, sem mencionar as pilhas de código e os sistemas de engenharia complexos. A gestão de requisitos ajuda a planejar como desenvolver um produto dentro das restrições da sua pilha de código e a monitorar o que você precisa realizar em cada estágio do processo de desenvolvimento do produto.

Quem é responsável pela gestão de requisitos? 

A pessoa responsável pela gestão de requisitos depende do seu projeto ou equipe. Dito isso, os proprietários ou gestores de produto normalmente gerenciam os requisitos para as equipes de desenvolvimento. Essas duas funções são semelhantes, exceto que os proprietários de produto são uma função padrão nas equipes Scrum, enquanto os gerentes de produto são uma função mais universal, independentemente de a equipe usar uma metodologia ágil. Se você estiver trabalhando em um projeto mais geral em vez de desenvolver um produto, o gestor de projeto é responsável pela gestão de requisitos. 

A gestão de requisitos exige colaboração interdisciplinar entre a equipe e as partes interessadas do projeto. Você precisa coletar feedback das partes interessadas, trabalhar com elas para entender cada requisito e ajudar a equipe a planejar como atender a cada necessidade. Isso significa que a pessoa que gerencia os requisitos do seu projeto deve ter fortes habilidades de colaboração e se destacar na comunicação interdisciplinar, porque ela estará no centro de tudo.

Quais são os diferentes tipos de requisitos? 

Há três tipos principais de requisitos: requisitos de negócios, requisitos do usuário e requisitos de sistemas. É importante definir os diferentes tipos de requisitos antes do início do trabalho, porque isso geralmente determina as partes interessadas com as quais você precisa colaborar. 

Aqui está uma visão geral dos diferentes tipos de requisitos: 

Requisitos de Business

Os requisitos de negócio são as metas ou métricas gerais de negócio que o seu produto atende. Não são necessariamente algo que o produto precisa fazer, mas sim coisas que o seu negócio precisa fazer para satisfazer as partes interessadas internas e externas. 

Por exemplo, imagine que você trabalha para uma empresa de varejo on-line e a sua equipe de vendas usa um sistema de gestão de conteúdo para criar e atualizar as páginas dos produtos no seu site. Para lidar com o inventário crescente, a equipe de produto está aprimorando a funcionalidade de busca no sistema de gestão de conteúdo.

O projeto da equipe de produto atende ao seguinte requisito de negócios: aumentar o inventário de produtos em 50 % no primeiro trimestre. Para registrar requisitos como esses em um formato único e organizado, tente usar um modelo de documento de requisitos de negócio.

Requisitos do usuário

Os requisitos do usuário definem o que os usuários precisam do seu produto e como eles interagirão com ele. Eles descrevem um ponto problemático ou uma ação que o cliente deseja realizar, além de como o produto deve aliviar esse ponto problemático ou ajudar o cliente a realizar a ação desejada.  

As equipes ágeis normalmente formatam os requisitos do usuário como histórias de usuário, que são explicações informais de um recurso de software escrito a partir da perspectiva de um usuário final. As histórias de usuário seguem este formato: “Como [persona], eu quero [meta do software] para alcançar [resultado]”. 

Voltemos ao exemplo do CMS que descrevemos acima. Aqui está um exemplo de história de usuário escrita a partir da perspectiva do usuário final, neste caso, um associado de vendas que usa o CMS para desempenhar suas funções. 

“Como representante de vendas, quero pesquisar e encontrar facilmente listas de produtos específicas no nosso CMS para poder atualizar e gerir o nosso crescente inventário on-line.” 

Requisitos de sistemas

Os requisitos de sistema definem o que o produto fará. Pense desta forma: enquanto os requisitos do usuário descrevem o “porquê” e o “o quê” das funcionalidades do produto do ponto de vista do usuário, os requisitos de sistema definem o “como” da construção dessa funcionalidade do ponto de vista da equipe de engenharia. 

Os requisitos de sistemas são frequentemente divididos em requisitos funcionais e requisitos não funcionais. Os requisitos funcionais definem o que o produto fará, enquanto os requisitos não funcionais definem o quão bem o produto desempenha as suas funções. Isso significa que os requisitos não funcionais normalmente têm a ver com segurança, desempenho e confiabilidade. 

Por exemplo, veja como uma equipe de engenharia pode dividir o requisito de usuário do CMS acima em requisitos de sistema: 

Requisitos funcionais

• Cada listagem de produto armazena as seguintes informações: tipo de produto, data de criação, autor, URL e status de publicação.

• Novos produtos não podem ser criados a menos que os autores selecionem um tipo de produto em um menu suspenso. 

• A barra de pesquisa inclui uma opção para aplicar os seguintes filtros adicionais: tipo de produto, data de criação, autor, URL e status de publicação. 

• É possível selecionar vários filtros ao mesmo tempo. 

Requisitos não funcionais

• Os resultados da busca são exibidos em menos de cinco segundos. 

• Os resultados da busca são 100 % precisos. 

As sete etapas do processo de gestão de requisitos

A gestão de requisitos não precisa ser algo avassalador. Se você criar um processo padronizado para a sua equipe, poderá seguir sempre as mesmas etapas, em vez de se preocupar com quais partes interessadas devem ser incluídas e quando. 

Para começar, simplificamos o processo em sete etapas. Depois de experimentar e descobrir o que funciona para a sua equipe, você pode adaptar o processo de gestão de requisitos conforme necessário. 

Etapa 1: desenvolva um plano de gestão de requisitos

Comece o seu projeto criando um plano de gestão de requisitos (RMP, na sigla em inglês). Este plano é o seu roteiro para lidar com os requisitos durante todo o ciclo de vida do projeto. No seu RMP, defina:

• Quem participará da coleta de requisitos?

• Como você coletará e documentará os requisitos?

• Qual é o seu processo para acompanhar as alterações nos requisitos?

• Como você garantirá o sucesso do projeto em relação às metas?

Um bom plano de gestão de requisitos ajuda a equipe do projeto a se manter organizada e alinhada durante todo o ciclo de desenvolvimento.

Etapa 2: levantamento e definição dos requisitos

A elicitação envolve a coleta e a definição dos requisitos do projeto. É uma etapa essencial na qual você se conecta com as partes interessadas e os clientes para entender as necessidades de ponta a ponta.

Obtenção de requisitos

• Interaja com as partes interessadas: reúna-se pessoalmente ou comunique-se de forma assíncrona com as partes interessadas. Apresente o produto, a funcionalidade ou a iniciativa que você está criando e pergunte o que eles precisam para ajudar os clientes ou atingir as metas de negócios.

• Reúna os requisitos do usuário final: se possível, realize testes com os usuários. No mínimo, consulte a equipe de desenvolvimento para obter insights.

• Gerencie as expectativas: explique que nem todos os requisitos solicitados serão necessariamente implementados. Esclareça que esta é uma etapa de coleta de informações.

Definição de requisitos

Definir os requisitos ajuda a delinear todos os componentes que a equipe de desenvolvimento precisa realizar para concluir a iniciativa ou o produto. 

• Escreva requisitos claros e específicos com base nas informações coletadas.

• Crie casos de uso para mostrar como os usuários interagirão com o produto final.

• Certifique-se de que cada requisito descreva uma necessidade ou funcionalidade específica.

Você também pode criar histórias de usuário para cada requisito, a fim de articular o que os usuários precisam e como eles interagirão com o seu produto ou funcionalidade.

Em seguida, você pode dividir esses requisitos do usuário em requisitos de sistema mais específicos. À medida que avança, talvez seja necessário coletar informações adicionais das partes interessadas para garantir que você tenha contexto suficiente para concluir cada requisito.

Lembre-se de que, nesta etapa do fluxo de trabalho de gestão de requisitos, você está coletando necessidades e requisitos potenciais. A sua equipe priorizará e selecionará os mais importantes para prosseguir mais tarde no processo de gestão de requisitos.

Etapa 3: análise e validação dos requisitos

Agora é hora de classificar todo esse feedback e decidir quais requisitos se alinham às suas metas de produto e de negócios. Em última análise, cada requisito deve contribuir para uma meta geral de Business, como aumentar a receita, expandir para novos mercados ou melhorar a satisfação do cliente. 

A validação de requisitos inclui:

• Verificar se todos os requisitos técnicos são necessários, viáveis e não se contradizem.

• Confirmar que os requisitos técnicos estão alinhados com as metas do projeto.

Em seguida, validar os requisitos com as partes interessadas. Isso significa verificar se os requisitos refletem verdadeiramente as necessidades de ponta a ponta das partes interessadas.

Etapa 4: estabeleça a linha de base dos requisitos

Depois que os requisitos forem validados, estabeleça uma linha de base. A documentação nesta fase fornece um instantâneo de todos os requisitos aprovados e oferece:

• Um ponto de partida para a sua solução de gestão de requisitos

• Uma referência para futuras tomadas de decisão e mensuração de mudanças.

Não há uma maneira definida de documentar e monitorar os requisitos. A sua equipe de produto pode ter usado anteriormente uma especificação de requisitos de software (SRS), um documento de requisitos de produto (PRD) ou uma matriz de rastreabilidade de requisitos (RTM). 

Mas, para garantir que a sua equipe tenha informações em tempo real sobre todos os requisitos do projeto, experimente usar uma ferramenta de gestão de projetos como a Asana. Isso significa que não haverá mais planilhas desatualizadas para auditar os requisitos. Em vez disso, tanto a equipe quanto as partes interessadas podem ver as descrições mais atualizadas de cada requisito. Você também pode acompanhar o status de cada requisito enquanto trabalha no projeto e até mesmo configurar automatizações para alertar as partes interessadas quando houver progresso.  

Você também pode integrar a Asana a aplicativos e ferramentas de gestão de requisitos mais especializados, como Jira e GitHub. Isso é especialmente útil se você trabalha com partes interessadas que não têm permissão para acessar ferramentas de desenvolvimento. 

Etapa 5: priorização e mapeamento de dependências

Agora que você tem o seu conjunto de requisitos anotados, trabalhe com a equipe para priorizar e planejar como você os abordará. Essa priorização permite que você lide com as tarefas mais importantes primeiro, especialmente se elas estiverem bloqueando outras tarefas no futuro.

Nesta etapa, identifique como os requisitos se relacionam entre si. Esse processo, muitas vezes chamado de rastreabilidade, envolve:

• Vincular os requisitos relacionados.

• Conectar os requisitos a outros elementos do projeto, como documentos de design e casos de teste

Se a sua equipe usa a metodologia Agile, adicione os requisitos ao backlog do produto e, em seguida, organize uma sessão de planejamento do sprint para decidir quais tarefas incluir no próximo sprint. Se você não trabalha em sprints, tudo bem: você pode criar um cronograma do projeto para definir quando cada requisito deve ser concluído e se há dependências. 

Etapa 6: gestão de mudanças, controle de versões e análise de impacto

A gestão de requisitos não se trata apenas de planejar os requisitos antes do início do projeto, mas também de lidar com as mudanças nos requisitos durante o andamento do projeto. Isso significa que você deve planejar como incorporar tarefas adicionais que afetarão o escopo do projeto. 

À medida que o projeto avança, os requisitos podem mudar. Gerencie essas alterações da seguinte forma:

1. Defina um processo para enviar e revisar solicitações de mudança.

2. Analise como cada mudança proposta pode afetar outros requisitos e elementos do projeto.

3. Atualize a linha de base se as alterações forem aprovadas.

Use o mapa de dependências para realizar a análise de impacto. Isso ajuda a entender o impacto total das mudanças antes de decidir implementá-las.

Outra opção é criar um processo de controle de mudanças. Isso permite que as partes interessadas enviem novos requisitos que afetarão o escopo do projeto, além de determinar quem deve aprovar ou negar essas solicitações.

Um processo de gestão de mudanças bem definido ajuda a entender como gerir os requisitos de forma eficaz, mantendo o controle das mudanças. 

Etapa 7: verificação e validação do sistema

Na etapa final, verifique se o produto finalizado atende a todos os requisitos técnicos:

• Verificação: teste cada funcionalidade para garantir que ela funcione conforme especificado nos requisitos.

• Validação: verifique com as partes interessadas se o produto atende às suas necessidades e expectativas.

Esta etapa ajuda a detectar quaisquer problemas antes de finalizar o produto, o que reduz a necessidade de retrabalho dispendioso mais tarde.

Ao longo deste processo, considere usar um software de gestão de requisitos como a Asana. Ele pode servir como um núcleo de referência, ajudando a gerir os requisitos, monitorar as alterações e gerar relatórios e painéis para uma melhor supervisão do projeto.

Ferramentas para agilizar a gestão de requisitos

A gestão de requisitos tem muitas partes móveis, mas não precisa parecer fora de controle. Com as ferramentas certas, você pode configurar um processo repetível que estabeleça exatamente com quem falar, quando fazê-lo e como documentar e organizar os requisitos ao longo do ciclo de vida do projeto. 

Se você monitora os requisitos na Asana, pode criar um modelo padronizado para ajudar a gerir os requisitos de cada projeto. Isso significa que, em vez de começar o processo do zero a cada vez, você pode reutilizar um fluxo de trabalho predefinido e ficar tranquilo sabendo que não está esquecendo nenhuma parte essencial. 

Perguntas frequentes: gestão de requisitos

O que se entende por gestão de requisitos? A gestão de requisitos é o processo de definir, monitorar e controlar os requisitos do projeto ao longo do ciclo de desenvolvimento. Ela garante que todas as partes interessadas entendam e concordem com as necessidades do projeto.

O que é um plano de gestão de requisitos? Um plano de gestão de requisitos descreve como os requisitos serão coletados, monitorados e geridos durante um projeto. Ele serve como guia para lidar com mudanças, documentação e comunicação.

Quais são as principais funções do processo de gestão de requisitos? As principais funções do processo de gestão de requisitos incluem a coleta de requisitos, a análise e validação deles, o acompanhamento das alterações e a garantia de que o produto final atenda aos requisitos acordados.

Como é um bom requisito? Um bom requisito é claro, específico e mensurável. Ele deve ser facilmente compreendido, testável e alinhado às metas gerais do projeto.