Questionário detalhado para subsidiar rodadas de levantamento de requisitos de sistema com gestores e usuários.
A elicitação de requisitos é considerada uma das atividades mais críticas — e mais propensas a falhas — da engenharia de software. Segundo Sommerville (2011), erros na compreensão dos requisitos respondem por até 56% dos defeitos em sistemas entregues. Este questionário foi elaborado para que estudantes de engenharia de software conduzam uma entrevista única, profunda e estruturada com o cliente-gestor, extraindo em uma só sessão todas as informações necessárias para compor a base de conhecimento do projeto: perfil organizacional, análise SWOT, perfil de usuários e stakeholders, dores, expectativas, cenários de uso, além dos requisitos funcionais e não-funcionais completos.
O roteiro a seguir está organizado em dez blocos temáticos progressivos, partindo do contexto organizacional amplo até as especificações técnicas mais granulares, seguindo as recomendações do BABOK® Guide (IIBA, 2015) e do padrão ISO/IEC/IEEE 29148 (ISO, 2018). O princípio norteador é que o entrevistado detém conhecimento total sobre o domínio, de modo que o questionário busca esgotar cada tema, minimizando a necessidade de retornos posteriores (Zowghi; Coulin, 2005).
BLOCO 1 — PERFIL DA ORGANIZAÇÃO E CONTEXTO ESTRATÉGICO
Este bloco mapeia a identidade organizacional e o ambiente no qual o sistema será inserido, fornecendo subsídios para a análise SWOT e o alinhamento estratégico do projeto (Pressman; Maxim, 2021).
1.1 Identidade organizacional
- Qual é a razão social e o nome fantasia da organização?
- Qual o CNPJ, porte (MEI, ME, EPP, médio, grande) e regime tributário?
- Em que ano a organização foi fundada e qual a sua forma jurídica (SA, LTDA, EIRELI, associação, órgão público etc.)?
- Qual a missão, a visão e os valores declarados da organização?
- Descreva o organograma atual: quantos níveis hierárquicos existem? Quais são os departamentos ou setores?
- Quantos colaboradores a organização possui atualmente (total e por setor)?
- A organização possui filiais, franquias ou unidades remotas? Onde estão localizadas?
- Qual o faturamento médio anual ou faixa de receita (se aplicável)?
1.2 Segmento de atuação e mercado
- Em qual setor econômico e nicho de mercado a organização atua (CNAE principal)?
- Quem são os principais concorrentes diretos e indiretos?
- Qual a participação estimada de mercado (market share) da organização?
- Quais são os principais produtos ou serviços oferecidos e suas respectivas proporções na receita?
- Quem é o público-alvo primário e o secundário da organização?
- Há sazonalidades ou ciclos que impactam significativamente a operação (picos, períodos de baixa)?
1.3 Análise SWOT — Forças, Fraquezas, Oportunidades e Ameaças
- Quais são as principais forças (strengths) da organização em relação ao mercado? (por exemplo: marca forte, equipe qualificada, localização privilegiada, base de clientes fiel etc.)
- Quais são as fraquezas (weaknesses) internas mais relevantes? (por exemplo: processos manuais, tecnologia obsoleta, alta rotatividade, dependência de fornecedor único etc.)
- Quais oportunidades (opportunities) externas a organização identifica atualmente? (por exemplo: mudança regulatória favorável, novos mercados, tendência tecnológica etc.)
- Quais são as ameaças (threats) externas mais preocupantes? (por exemplo: entrada de novos concorrentes, mudança legislativa desfavorável, crises econômicas etc.)
- Dentro da análise SWOT, qual fraqueza interna mais diretamente motivou a busca por este sistema?
BLOCO 2 — O PROBLEMA, AS DORES E AS NECESSIDADES
Este bloco investiga as motivações reais para o desenvolvimento do sistema, identificando dores operacionais, estratégicas e humanas (Robertson; Robertson, 2012).
2.1 Diagnóstico do cenário atual
- Descreva detalhadamente o(s) processo(s) de negócio atual(is) que o sistema deverá apoiar ou substituir. Se possível, descreva passo a passo, do início ao fim, com os atores envolvidos em cada etapa.
- Esses processos são executados de forma manual, semiautomatizada ou já possuem algum sistema? Qual?
- Quais ferramentas, planilhas, cadernos, sistemas legados ou plataformas são usados atualmente para executar esses processos?
- Qual o volume médio de operações (transações, atendimentos, registros) por dia, semana e mês em cada processo?
- Quanto tempo médio cada processo leva para ser concluído do início ao fim?
- Quantas pessoas estão envolvidas na execução de cada processo?
2.2 Dores e pontos de falha
- Quais são as três maiores dores ou frustrações dos colaboradores com o processo atual?
- Quais são as três maiores dores ou frustrações dos clientes finais (se aplicável) com o serviço ou produto oferecido?
- Quais erros, falhas ou retrabalhos acontecem com mais frequência? Com que frequência ocorrem?
- Há gargalos identificados (etapas que travam o fluxo)? Onde exatamente?
- Já houve perdas financeiras, contratuais, legais ou de reputação decorrentes dessas falhas? Pode exemplificar?
- Quais informações ou dados são perdidos, duplicados ou inconsistentes atualmente?
- Existem tarefas repetitivas que consomem tempo excessivo dos colaboradores? Quais?
- Há reclamações recorrentes de clientes ou parceiros? Sobre quais aspectos?
2.3 Necessidades e expectativas de melhoria
- O que o sistema precisa obrigatoriamente resolver ou melhorar para que o projeto seja considerado bem-sucedido?
- Quais resultados mensuráveis são esperados com a implantação do sistema? (por exemplo: redução de X% no tempo de atendimento, eliminação de Y retrabalhos/mês, aumento de Z% na satisfação do cliente)
- Há algum indicador-chave de desempenho (KPI) que o sistema deverá monitorar ou impactar diretamente? Qual(is)?
- Quais benefícios intangíveis são esperados (por exemplo: maior confiança do cliente, melhoria na cultura organizacional, transparência)?
- Existe uma priorização já definida entre as necessidades (o que é mais urgente versus o que pode esperar)?
BLOCO 3 — PERFIL DOS STAKEHOLDERS E PAPÉIS
A identificação completa dos stakeholders e seus interesses é fundamental para a gestão de expectativas e a priorização dos requisitos (IIBA, 2015).
- Quem é o patrocinador (sponsor) do projeto? Qual seu cargo, departamento e nível de autoridade sobre decisões do projeto?
- Quem são os decisores que aprovarão requisitos, escopo e entregas? Liste nome, cargo e área.
- Quem será o ponto focal (ou Product Owner) para esclarecer dúvidas durante o desenvolvimento?
- Liste todos os grupos de usuários que interagirão diretamente com o sistema. Para cada grupo, informe: (a) denominação do grupo; (b) quantidade estimada de pessoas; (c) função/cargo típico; (d) nível de familiaridade com tecnologia (básico, intermediário, avançado); (e) frequência de uso prevista (diária, semanal, eventual).
- Existem usuários indiretos (que não operam o sistema, mas consomem seus resultados — ex.: gestores que leem relatórios, auditores)? Quem são?
- Há partes externas interessadas no sistema (órgãos reguladores, parceiros comerciais, fornecedores, clientes finais)? Quem são e qual seu interesse?
- Existe algum stakeholder que possa ser um potencial resistente ou opositor ao sistema? Por quê?
- Quais expectativas cada grupo de stakeholders tem especificamente em relação ao sistema?
BLOCO 4 — PERFIL DOS USUÁRIOS E ACESSIBILIDADE
O entendimento profundo do perfil de quem usará o sistema define a experiência do usuário e a arquitetura de permissões (Wiegers; Beatty, 2013).
- Qual a faixa etária predominante dos usuários do sistema?
- Qual o nível de escolaridade predominante dos usuários?
- Os usuários possuem experiência prévia com sistemas similares? Quais?
- Em quais dispositivos os usuários acessarão o sistema (desktop, notebook, tablet, smartphone)? Há predominância de algum?
- Os usuários trabalham em ambiente fixo (escritório) ou móvel (campo, visitas externas, home office)?
- Há usuários com necessidades de acessibilidade (deficiência visual, auditiva, motora, cognitiva)? Quais adaptações seriam necessárias?
- Qual o idioma principal dos usuários? Há necessidade de suporte multilíngue?
- Os usuários terão acesso à internet de forma constante e estável ou há cenários de conectividade limitada/offline?
- Quantos usuários simultâneos são esperados em horários de pico?
- Que tipo de treinamento será viável (presencial, online, manual, tutoriais embutidos no sistema)?
BLOCO 5 — REQUISITOS FUNCIONAIS — DETALHAMENTO DE FUNCIONALIDADES
Os requisitos funcionais descrevem "o que" o sistema deve fazer. A técnica de decomposição por funcionalidades é recomendada pela ISO/IEC/IEEE 29148 (ISO, 2018) e por Sommerville (2011).
5.1 Cadastros e entidades de dados
- Quais entidades (cadastros) o sistema deverá gerenciar? (ex.: clientes, produtos, fornecedores, colaboradores, serviços, equipamentos, contratos etc.) Liste todas.
- Para cada entidade listada, quais campos/atributos são necessários? Indique quais são obrigatórios e quais são opcionais.
- Quais campos possuem regras de formatação ou validação (CPF, CNPJ, e-mail, telefone, CEP, valores monetários, datas)?
- Há campos que devem ser preenchidos automaticamente pelo sistema (data de criação, código sequencial, campo calculado)? Quais?
- Quais entidades possuem relacionamentos entre si? (ex.: um cliente pode ter muitos pedidos; um produto pertence a uma categoria) Descreva os relacionamentos e suas cardinalidades (1:1, 1:N, N:M).
- Há necessidade de histórico de alterações nos cadastros (auditoria de quem alterou o quê e quando)?
- Existem cadastros que precisam de aprovação antes de serem efetivados? Qual o fluxo de aprovação?
- É necessário importar dados de cadastros existentes (migração de dados)? De quais fontes e em quais formatos (CSV, Excel, banco de dados, API)?
5.2 Processos e fluxos de trabalho (workflows)
- Quais são os processos de negócio completos que o sistema deverá automatizar ou apoiar? Descreva cada um passo a passo, incluindo: (a) evento que inicia o processo; (b) cada etapa e seu responsável; (c) decisões/condições que alteram o fluxo; (d) resultado final esperado.
- Para cada processo, quais são as regras de negócio que regem cada etapa? (ex.: desconto só pode ser dado com aprovação gerencial se acima de 15%; pedido só avança se estoque disponível; prazo máximo de resposta é 48h)
- Há processos que envolvem múltiplos departamentos ou atores? Descreva as transições e as dependências entre eles.
- Existem processos com etapas que podem ser executadas em paralelo? Quais?
- Quais processos possuem prazos (SLAs) a serem controlados? Quais são esses prazos e o que deve acontecer em caso de descumprimento (alerta, escalonamento, penalidade)?
- Há necessidade de assinatura digital ou eletrônica em algum ponto do fluxo?
- Existem processos que geram documentos (contratos, notas, ordens, recibos, laudos)? Descreva cada tipo de documento, seus campos e seu formato esperado.
5.3 Consultas, filtros e relatórios
- Quais consultas e pesquisas os usuários precisarão realizar com frequência? Por quais campos/critérios?
- Quais relatórios o sistema deve gerar? Para cada relatório, descreva: (a) nome/título; (b) dados apresentados; (c) filtros disponíveis; (d) formato de saída (tela, PDF, Excel); (e) periodicidade (sob demanda, diário, semanal, mensal); (f) quem terá acesso.
- Há necessidade de dashboards ou painéis de indicadores? Quais indicadores devem ser exibidos e para quem?
- Os relatórios ou dashboards precisam exibir dados em tempo real ou atualizações periódicas são suficientes? Qual a frequência aceitável?
- Há necessidade de exportação de dados (CSV, Excel, PDF, XML, JSON) para uso externo?
5.4 Comunicação e notificações
- O sistema deverá enviar notificações aos usuários? Em quais situações (alertas de prazo, confirmações, atualizações de status, lembretes)?
- Quais canais de notificação devem ser suportados (e-mail, SMS, push notification, WhatsApp, notificação interna no sistema)?
- Há necessidade de comunicação interna entre usuários dentro do sistema (chat, comentários, anotações em registros)?
- O sistema deverá enviar comunicações em massa (mala direta, campanhas, avisos em lote)?
5.5 Autenticação, autorização e controle de acesso
- Quais perfis de acesso (papéis) devem existir no sistema? (ex.: administrador, gestor, operador, consultor, auditor, cliente) Liste todos.
- Para cada perfil, quais funcionalidades e dados devem estar acessíveis e quais devem ser restritos?
- Um mesmo usuário pode acumular mais de um perfil?
- Há campos ou registros que devem ser visíveis apenas para determinados perfis (ex.: dados financeiros apenas para a diretoria)?
- Como será feito o login? (credenciais próprias, integração com Active Directory/LDAP, login social, SSO — Single Sign-On)?
- Há exigência de autenticação multifator (MFA)?
- Qual a política de senhas desejada (tamanho mínimo, complexidade, expiração, bloqueio após tentativas)?
BLOCO 6 — REQUISITOS NÃO-FUNCIONAIS
Os requisitos não-funcionais definem qualidades sistêmicas e restrições transversais. A classificação segue a norma ISO/IEC 25010 (ISO, 2023) e Bass, Clements e Kazman (2021).
6.1 Desempenho e escalabilidade
- Qual o tempo máximo de resposta aceitável para operações típicas (abrir tela, salvar registro, gerar relatório)?
- Qual o número máximo de usuários simultâneos que o sistema deve suportar sem degradação perceptível?
- Qual o volume máximo de dados projetado para os próximos 3 a 5 anos (número de registros, tamanho em GB)?
- Há expectativa de crescimento abrupto de uso em determinados períodos (campanhas, sazonalidade, expansão)?
- Há funcionalidades que exigem processamento em tempo real (ex.: rastreamento, IoT, chat ao vivo)?
6.2 Disponibilidade e confiabilidade
- Qual o nível de disponibilidade exigido (ex.: 99%, 99,9%, 24/7)?
- Há janelas de manutenção aceitáveis (horários em que o sistema pode ficar indisponível)?
- Qual o tempo máximo aceitável de indisponibilidade (RTO — Recovery Time Objective) em caso de falha?
- Qual o volume máximo de dados que pode ser perdido (RPO — Recovery Point Objective) em caso de falha?
- É necessário um plano de contingência ou disaster recovery? Quais cenários devem ser cobertos?
6.3 Segurança e privacidade
- O sistema manipulará dados pessoais (nome, CPF, endereço, dados de saúde, dados financeiros)?
- Há necessidade de conformidade com a LGPD (Lei Geral de Proteção de Dados) ou algum regulamento setorial específico (HIPAA, PCI-DSS, Bacen etc.)?
- Quais dados devem ser criptografados em trânsito e/ou em repouso?
- Há necessidade de logs de auditoria para todas as ações dos usuários? Por quanto tempo devem ser mantidos?
- O sistema precisará atender a auditorias externas? Quais padrões ou certificações são necessários?
- Quais são os requisitos de consentimento e gestão de dados do titular (portabilidade, exclusão, retificação)?
6.4 Usabilidade e experiência do usuário (UX)
- Há uma identidade visual (manual de marca, paleta de cores, logotipos) que o sistema deverá seguir?
- Existe preferência por estilo de interface (minimalista, rico em informações, tipo dashboard, tipo formulário)?
- O sistema deve ser responsivo (adaptar-se a diferentes tamanhos de tela)?
- Há benchmarks de tempo de aprendizado desejado (ex.: usuário deve conseguir realizar tarefa X em menos de Y minutos na primeira tentativa)?
- O sistema deve seguir diretrizes de acessibilidade (WCAG 2.1, e-MAG)?
- Há funcionalidades que exigem operação por voz, leitura de tela, atalhos de teclado ou alto contraste?
6.5 Portabilidade e compatibilidade
- O sistema será web, desktop, mobile nativo ou híbrido?
- Quais navegadores e versões mínimas devem ser suportados (se web)?
- Quais sistemas operacionais devem ser suportados (Windows, macOS, Linux, Android, iOS)?
- Há restrições quanto ao hardware mínimo dos usuários (ex.: PCs antigos, dispositivos de baixo custo)?
6.6 Manutenibilidade e evolução
- O sistema será mantido por equipe interna ou terceirizada? Qual o perfil técnico dessa equipe?
- Há preferência ou restrição quanto a tecnologias, linguagens de programação, frameworks ou bancos de dados?
- O código-fonte deve ser entregue? Sob qual licença?
- É desejável uma arquitetura modular que permita adicionar funcionalidades futuras sem grande impacto?
- Quais funcionalidades são previstas para fases futuras (roadmap)?
BLOCO 7 — INTEGRAÇÕES E ECOSSISTEMA TÉCNICO
A interoperabilidade é um dos fatores mais subestimados em projetos de software, respondendo por atrasos significativos quando não mapeada previamente (Bass; Clements; Kazman, 2021).
- O sistema deverá se integrar com quais sistemas internos existentes? (ERP, CRM, BI, folha de pagamento, contabilidade, e-commerce etc.) Para cada integração, descreva: (a) nome do sistema; (b) fornecedor/versão; (c) dados a serem trocados; (d) sentido do fluxo (envio, recebimento ou bidirecional); (e) frequência (tempo real, batch, sob demanda); (f) tecnologia de integração disponível (API REST, SOAP, arquivo CSV, banco compartilhado, webhook).
- O sistema deverá se integrar com serviços externos ou APIs de terceiros? (ex.: gateways de pagamento, serviços de CEP, consulta de CPF/CNPJ, serviços de e-mail, SMS, mapas, redes sociais, governo eletrônico) Descreva com o mesmo detalhamento da questão anterior.
- Há necessidade de integração com hardware ou dispositivos (impressoras, leitores de código de barras, balanças, catracas, sensores, câmeras)?
- O sistema deverá disponibilizar API própria para consumo por outros sistemas ou parceiros?
- Há requisitos de integração com plataformas de autenticação federada (OAuth 2.0, OpenID Connect, SAML)?
BLOCO 8 — CENÁRIOS DE USO E CASOS CRÍTICOS
Os cenários de uso conectam requisitos abstratos a situações concretas do cotidiano, sendo essenciais para a validação do entendimento (Cockburn, 2001).
- Descreva o cenário de uso mais comum (o "caminho feliz") do sistema, do ponto de vista do usuário principal, desde o login até a conclusão da tarefa mais frequente.
- Descreva pelo menos três cenários alternativos ou de exceção: (a) o que acontece quando o sistema detecta um dado inválido; (b) o que acontece quando o usuário não tem permissão; (c) o que acontece em falha de comunicação ou indisponibilidade de serviço integrado.
- Há cenários críticos de negócio em que uma falha do sistema teria consequências graves (perda financeira, risco à saúde, descumprimento legal)? Descreva-os detalhadamente.
- Há cenários de uso sazonais ou esporádicos que são diferentes do dia a dia (fechamento mensal, inventário anual, auditorias, eventos especiais)?
- Existe um cenário de migração ou primeiro uso (carga inicial de dados, configuração, onboarding) que requer fluxo específico?
BLOCO 9 — RESTRIÇÕES, PREMISSAS E RISCOS DO PROJETO
A explicitação de restrições e premissas evita o scope creep e alinha expectativas desde o início (PMI, 2021).
9.1 Restrições
- Qual o orçamento disponível para o projeto (desenvolvimento, infraestrutura, licenças)?
- Qual o prazo esperado ou obrigatório para entrega (parcial e total)? Há datas-limite inegociáveis?
- Há restrições legais, regulatórias ou contratuais que o sistema deve atender?
- Há restrições de infraestrutura (servidor local obrigatório, proibição de nuvem pública, limitação de largura de banda)?
- Há restrições relacionadas a propriedade intelectual (uso obrigatório de software livre, proibição de determinada tecnologia proprietária)?
9.2 Premissas
- Quais são as premissas que a equipe de desenvolvimento pode assumir como verdadeiras? (ex.: "todos os usuários terão acesso à internet"; "a base de dados legada será fornecida em formato CSV limpo"; "haverá um ponto focal disponível durante todo o projeto")
- Há alguma dependência de terceiros (fornecedores, prestadores de serviço, órgãos) para que o projeto avance?
9.3 Riscos conhecidos
- Quais riscos a organização já identifica para o sucesso do projeto? (ex.: resistência à mudança, falta de tempo dos usuários para testes, dependência de sistema legado sem documentação)
- Já houve tentativas anteriores de implantar um sistema similar que não foram bem-sucedidas? O que deu errado?
- Quais estratégias de mitigação a organização está disposta a adotar para os riscos identificados?
BLOCO 10 — CRITÉRIOS DE ACEITAÇÃO, IMPLANTAÇÃO E PÓS-ENTREGA
Critérios claros de aceitação definem a fronteira entre "feito" e "não feito" e são parte essencial da validação de requisitos (Wiegers; Beatty, 2013).
- Quais são os critérios mínimos de aceitação para que o sistema seja considerado pronto para uso? (ex.: todas as funcionalidades do escopo testadas e aprovadas; tempo de resposta inferior a 3 segundos; zero bugs críticos abertos)
- Quem realizará os testes de aceitação (UAT — User Acceptance Testing)? Haverá um grupo de usuários-piloto?
- Qual a estratégia de implantação desejada (big bang, migração gradual por módulos, paralelo com o sistema antigo por um período)?
- Há necessidade de treinamento pré-implantação? Para quantas pessoas e em qual formato?
- Quem será responsável pela operação e suporte técnico após a entrega (help desk, suporte N1/N2/N3)?
- Qual o período de garantia esperado após a entrega para correção de defeitos?
- Há expectativa de contrato de manutenção (evolutiva, corretiva, adaptativa) após a entrega?
- Existem critérios para o encerramento formal do projeto (documento de aceite, homologação)?
BLOCO COMPLEMENTAR — PERGUNTAS ABERTAS E CONSOLIDAÇÃO
- Existe algum aspecto, funcionalidade, restrição ou preocupação que não foi abordado neste questionário e que você considera relevante?
- Se pudesse resumir em uma frase, qual é o principal objetivo deste sistema?
- Como você imagina o dia a dia dos usuários após a implantação bem-sucedida do sistema? Descreva o cenário ideal.
- Há alguma referência de sistema (concorrente, de outro setor ou de outra empresa do grupo) que você considera um bom modelo a ser seguido? Qual e por quê?
Referências
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software architecture in practice. 4. ed. Boston: Addison-Wesley, 2021.
COCKBURN, A. Writing effective use cases. Boston: Addison-Wesley, 2001.
INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS (IIBA). A guide to the Business Analysis Body of Knowledge (BABOK® Guide). Version 3. Toronto: IIBA, 2015.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO/IEC 25010:2023 — Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model. Geneva: ISO, 2023.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018.
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the Project Management Body of Knowledge (PMBOK® Guide). 7. ed. Newtown Square: PMI, 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.
ROBERTSON, S.; ROBERTSON, J. Mastering the requirements process: getting requirements right. 3. ed. Upper Saddle River: Addison-Wesley, 2012.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
ZOWGHI, D.; COULIN, C. Requirements elicitation: a survey of techniques, approaches, and tools. In: AURUM, A.; WOHLIN, C. (ed.). Engineering and managing software requirements. Berlin: Springer, 2005. p. 19-46.
Fonte:
Visto no Brasil Acadêmico
Comentários