É o processo de descobrir, analisar, documentar e validar os requisitos de um sistema. Um levantamento de requisitos bem-executado garante que o produto final atenda às necessidades e expectativas dos stakeholders, enquanto um processo falho pode levar a projetos fracassados, custos extras e insatisfação do cliente.
📑 Índice
📚 Um Pouco de História
A Engenharia de Requisitos, como disciplina, começou a tomar forma na década de 1970, a partir da necessidade de formalizar o processo de desenvolvimento de software e evitar os problemas recorrentes de projetos que não atendiam às expectativas. Antes disso, o desenvolvimento de software era uma atividade muito mais artesanal e menos estruturada. Com o aumento da complexidade dos sistemas, tornou-se evidente a necessidade de um processo mais rigoroso para a definição do que o software deveria fazer.
O primeiro simpósio internacional sobre o tema, o International Symposium on Requirements Engineering, em 1993, marcou a consolidação da área como um campo de pesquisa e prática fundamental na Engenharia de Software [1]. Desde então, a Engenharia de Requisitos evoluiu significativamente, incorporando novas técnicas, metodologias e ferramentas que refletem as mudanças no desenvolvimento de software, desde abordagens tradicionais até metodologias ágeis.
🔍 Técnicas de Elicitação de Requisitos
A elicitação de requisitos é o processo de obter os requisitos dos stakeholders. Existem diversas técnicas para isso, cada uma com suas vantagens e desvantagens. A escolha da técnica ideal depende do contexto do projeto, do perfil dos stakeholders e dos tipos de requisitos a serem levantados. Apresentamos aqui três das técnicas mais comuns e eficazes:
💬 Entrevistas
A entrevista é uma das técnicas mais tradicionais e eficazes para a elicitação de requisitos. Consiste em uma conversa, que pode ser estruturada, semiestruturada ou não estruturada, entre o analista de requisitos e o stakeholder. O objetivo é coletar informações detalhadas sobre as necessidades e expectativas do stakeholder em relação ao sistema.
As entrevistas permitem um aprofundamento nas questões e a identificação de requisitos que talvez não fossem percebidos em outras técnicas [2]. Além disso, elas facilitam o esclarecimento de ambiguidades e a construção de uma relação de confiança entre o analista e o stakeholder, elementos essenciais para o sucesso do projeto.
Tipos de entrevistas:
Estruturadas: Baseadas em um conjunto fixo de perguntas predefinidas, permitindo comparações entre respostas de diferentes stakeholders.
Semiestruturadas: Combinam perguntas predefinidas com questões abertas, oferecendo flexibilidade para explorar tópicos emergentes.
Não estruturadas: Conversacionais por natureza, ideais para compreender o contexto e os problemas do ambiente de trabalho.
📋 Questionários
Os questionários são uma forma de coletar informações de um grande número de pessoas de forma rápida e eficiente. Eles podem ser compostos por perguntas abertas ou fechadas e são úteis para obter dados quantitativos e validar requisitos já identificados.
No entanto, os questionários não permitem o mesmo nível de aprofundamento que as entrevistas e podem gerar respostas superficiais se não forem bem elaborados [3]. A efetividade dos questionários depende muito da clareza das perguntas, da estrutura lógica do documento e da capacidade de motivar os respondentes a participarem com seriedade.
Vantagens dos questionários:
Alcance de um grande número de stakeholders simultaneamente.
Redução de custos comparado a entrevistas individuais.
Facilidade de análise de dados quando bem estruturados.
Possibilidade de coleta de dados em diferentes localizações geográficas.
👁️ Observação (Etnografia)
A observação, ou etnografia, é uma técnica em que o analista de requisitos se insere no ambiente de trabalho do stakeholder para observar suas atividades diárias. Essa técnica é particularmente útil para descobrir requisitos implícitos, ou seja, aqueles que o stakeholder não consegue articular verbalmente, mas que são essenciais para a execução de suas tarefas [4].
A observação permite entender o contexto de uso do sistema e identificar problemas e oportunidades de melhoria que não seriam percebidos de outra forma. Além disso, ela revela as práticas reais de trabalho, que frequentemente diferem dos processos formais documentados nas organizações.
Fases da observação:
Preparação: Identificar áreas a observar, obter aprovações e explicar o propósito do estudo.
Condução: Observar atividades, documentar procedimentos e coletar dados sobre frequência e duração das tarefas.
Consolidação: Documentar descobertas e revisar resultados com os observados e seus superiores.
🎭 Personas no Desenvolvimento de Software
A técnica de criação de Personas é uma das ferramentas mais poderosas e amplamente utilizadas no design de produtos, engenharia de software e experiência do usuário. Ela serve para "humanizar" dados de pesquisa e gerar empatia, garantindo que o produto seja criado para resolver problemas de pessoas reais, e não para satisfazer as suposições da equipe técnica.
O que é uma Persona?
Uma Persona não é um usuário real e não é sinônimo de "público-alvo". O público-alvo é uma definição ampla e puramente demográfica, enquanto a persona é um arquétipo semifictício focado em comportamento, dores e contexto [6]. A persona é "fictícia" porque ganha um nome e um rosto inventados, mas deve ser rigorosamente construída com base em dados reais coletados através de pesquisas.
Processo de Criação:
Pesquisa: A equipe realiza entrevistas qualitativas, aplica questionários e observa usuários reais para coletar dados autênticos.
Identificação de Padrões: Os pesquisadores analisam os dados para encontrar semelhanças de comportamento, frustrações e objetivos entre os entrevistados.
Construção do Arquétipo: O grupo comportamental ganha vida em um documento visual que contém nome fictício, foto, citação, objetivos, dores/frustrações e contexto de uso.
Aplicação Prática: A persona é impressa ou fixada no mural da equipe, orientando decisões de design e desenvolvimento.
História e Origem:
A criação da técnica de Personas aplicadas a software é atribuída a Alan Cooper, um renomado designer e programador americano, frequentemente chamado de "Pai da linguagem Visual Basic" [7]. Em 1983, Cooper estava desenvolvendo um software de gerenciamento de projetos chamado Plan*It e, durante o processo, criou intuitivamente a primeira persona ao fazer role-play mental, simulando como uma colega chamada Kathy reagiria a cada elemento da interface.
Anos depois, Cooper notou um problema crônico na engenharia de software: os programadores projetavam para o que ele chamou de "Usuário Elástico", um termo tão vago que a equipe técnica o esticava ou encolhia conforme a própria conveniência [8]. As Personas nasceram para "matar" o usuário elástico, ao dar um nome e limites humanos rígidos ao personagem, forçando a equipe a ter empatia e foco.
Aplicação em Metodologias Modernas:
A Persona é uma ferramenta central em várias disciplinas modernas, incluindo Design Centrado no Usuário (UCD), UX Design, Design Thinking e Metodologias Ágeis [9]. 

Uma ferramenta online para criação de persona é o Make My Persona.

No mundo Ágil, os requisitos são escritos no formato de Histórias de Usuário (User Stories), que ganham precisão quando se usa a persona. Em vez do genérico "Como usuário, eu quero...", escreve-se "Como Marina, eu quero exportar o relatório em 1 clique para não me atrasar para buscar meu filho".
👥 Análise de Stakeholders
Stakeholders são todas as partes interessadas em um projeto, ou seja, qualquer pessoa ou grupo que possa ser afetado pelo sistema ou que possa influenciar seu desenvolvimento. Isso inclui usuários finais, gerentes, desenvolvedores, clientes, fornecedores e até mesmo órgãos reguladores.
A análise de stakeholders é o processo de identificar quem são os stakeholders, quais são seus interesses e como eles podem impactar o projeto [5]. Uma análise de stakeholders bem-feita é fundamental para garantir que todos os requisitos relevantes sejam considerados e para gerenciar as expectativas e os conflitos que possam surgir ao longo do projeto.
Etapas da análise de stakeholders:
Identificação: Listar todos os possíveis stakeholders do projeto.
Análise: Compreender seus interesses, influência e importância para o projeto.
Categorização: Classificar stakeholders por nível de poder e interesse (matriz de poder/interesse).
Engajamento: Definir estratégias de comunicação e envolvimento para cada grupo de stakeholders.
Monitoramento: Acompanhar mudanças nas posições e interesses dos stakeholders ao longo do projeto.
A identificação correta dos stakeholders e a compreensão de suas necessidades são essenciais para evitar retrabalho, atrasos e custos adicionais no desenvolvimento do software. Um stakeholder esquecido ou mal compreendido pode levar a requisitos incompletos ou conflitantes que comprometem o sucesso do projeto.