Questionário para Entrevista de Elicitação de Requisitos em Projetos de Prototipagem de Software

Questionário detalhado para subsidiar rodadas de levantamento de requisitos de sistema com gestores e usuários.

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

1. Qual é a razão social e o nome fantasia da organização?
2. Qual o CNPJ, porte (MEI, ME, EPP, médio, grande) e regime tributário?
3. 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.)?
4. Qual a missão, a visão e os valores declarados da organização?
5. Descreva o organograma atual: quantos níveis hierárquicos existem? Quais são os departamentos ou setores?
6. Quantos colaboradores a organização possui atualmente (total e por setor)?
7. A organização possui filiais, franquias ou unidades remotas? Onde estão localizadas?
8. Qual o faturamento médio anual ou faixa de receita (se aplicável)?

1.2 Segmento de atuação e mercado

9. Em qual setor econômico e nicho de mercado a organização atua (CNAE principal)?
10. Quem são os principais concorrentes diretos e indiretos?
11. Qual a participação estimada de mercado (market share) da organização?
12. Quais são os principais produtos ou serviços oferecidos e suas respectivas proporções na receita?
13. Quem é o público-alvo primário e o secundário da organização?
14. 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

15. 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.)
16. Quais são as fraquezas (weaknesses) internas mais relevantes? (por exemplo: processos manuais, tecnologia obsoleta, alta rotatividade, dependência de fornecedor único etc.)
17. Quais oportunidades (opportunities) externas a organização identifica atualmente? (por exemplo: mudança regulatória favorável, novos mercados, tendência tecnológica etc.)
18. 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.)
19. 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

20. 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.
21. Esses processos são executados de forma manual, semiautomatizada ou já possuem algum sistema? Qual?
22. Quais ferramentas, planilhas, cadernos, sistemas legados ou plataformas são usados atualmente para executar esses processos?
23. Qual o volume médio de operações (transações, atendimentos, registros) por dia, semana e mês em cada processo?
24. Quanto tempo médio cada processo leva para ser concluído do início ao fim?
25. Quantas pessoas estão envolvidas na execução de cada processo?

2.2 Dores e pontos de falha

26. Quais são as três maiores dores ou frustrações dos colaboradores com o processo atual?
27. Quais são as três maiores dores ou frustrações dos clientes finais (se aplicável) com o serviço ou produto oferecido?
28. Quais erros, falhas ou retrabalhos acontecem com mais frequência? Com que frequência ocorrem?
29. Há gargalos identificados (etapas que travam o fluxo)? Onde exatamente?
30. Já houve perdas financeiras, contratuais, legais ou de reputação decorrentes dessas falhas? Pode exemplificar?
31. Quais informações ou dados são perdidos, duplicados ou inconsistentes atualmente?
32. Existem tarefas repetitivas que consomem tempo excessivo dos colaboradores? Quais?
33. Há reclamações recorrentes de clientes ou parceiros? Sobre quais aspectos?

2.3 Necessidades e expectativas de melhoria

34. O que o sistema precisa obrigatoriamente resolver ou melhorar para que o projeto seja considerado bem-sucedido?
35. 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)
36. Há algum indicador-chave de desempenho (KPI) que o sistema deverá monitorar ou impactar diretamente? Qual(is)?
37. Quais benefícios intangíveis são esperados (por exemplo: maior confiança do cliente, melhoria na cultura organizacional, transparência)?
38. 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).

39. Quem é o patrocinador (sponsor) do projeto? Qual seu cargo, departamento e nível de autoridade sobre decisões do projeto?
40. Quem são os decisores que aprovarão requisitos, escopo e entregas? Liste nome, cargo e área.
41. Quem será o ponto focal (ou Product Owner) para esclarecer dúvidas durante o desenvolvimento?
42. 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).
43. Existem usuários indiretos (que não operam o sistema, mas consomem seus resultados — ex.: gestores que leem relatórios, auditores)? Quem são?
44. Há partes externas interessadas no sistema (órgãos reguladores, parceiros comerciais, fornecedores, clientes finais)? Quem são e qual seu interesse?
45. Existe algum stakeholder que possa ser um potencial resistente ou opositor ao sistema? Por quê?
46. 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).

47. Qual a faixa etária predominante dos usuários do sistema?
48. Qual o nível de escolaridade predominante dos usuários?
49. Os usuários possuem experiência prévia com sistemas similares? Quais?
50. Em quais dispositivos os usuários acessarão o sistema (desktop, notebook, tablet, smartphone)? Há predominância de algum?
51. Os usuários trabalham em ambiente fixo (escritório) ou móvel (campo, visitas externas, home office)?
52. Há usuários com necessidades de acessibilidade (deficiência visual, auditiva, motora, cognitiva)? Quais adaptações seriam necessárias?
53. Qual o idioma principal dos usuários? Há necessidade de suporte multilíngue?
54. Os usuários terão acesso à internet de forma constante e estável ou há cenários de conectividade limitada/offline?
55. Quantos usuários simultâneos são esperados em horários de pico?
56. 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

57. Quais entidades (cadastros) o sistema deverá gerenciar? (ex.: clientes, produtos, fornecedores, colaboradores, serviços, equipamentos, contratos etc.) Liste todas.
58. Para cada entidade listada, quais campos/atributos são necessários? Indique quais são obrigatórios e quais são opcionais.
59. Quais campos possuem regras de formatação ou validação (CPF, CNPJ, e-mail, telefone, CEP, valores monetários, datas)?
60. Há campos que devem ser preenchidos automaticamente pelo sistema (data de criação, código sequencial, campo calculado)? Quais?
61. 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).
62. Há necessidade de histórico de alterações nos cadastros (auditoria de quem alterou o quê e quando)?
63. Existem cadastros que precisam de aprovação antes de serem efetivados? Qual o fluxo de aprovação?
64. É 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)

65. 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.
66. 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)
67. Há processos que envolvem múltiplas aprovações? Qual a sequência e quem são os aprovadores?
68. Existem processos com etapas que podem ser executadas em paralelo? Quais?
69. 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)?
70. Há necessidade de assinatura digital ou eletrônica em algum ponto do fluxo?
71. 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

72. Quais consultas e pesquisas os usuários precisarão realizar com frequência? Por quais campos/critérios?
73. 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.
74. Há necessidade de dashboards ou painéis de indicadores? Quais indicadores devem ser exibidos e para quem?
75. 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?
76. Há necessidade de exportação de dados (CSV, Excel, PDF, XML, JSON) para uso externo?

5.4 Comunicação e notificações

77. O sistema deverá enviar notificações aos usuários? Em quais situações (alertas de prazo, confirmações, atualizações de status, lembretes)?
78. Quais canais de notificação devem ser suportados (e-mail, SMS, push notification, WhatsApp, notificação interna no sistema)?
79. Há necessidade de comunicação interna entre usuários dentro do sistema (chat, comentários, anotações em registros)?
80. O sistema deverá enviar comunicações em massa (mala direta, campanhas, avisos em lote)?

5.5 Autenticação, autorização e controle de acesso

81. Quais perfis de acesso (papéis) devem existir no sistema? (ex.: administrador, gestor, operador, consultor, auditor, cliente) Liste todos.
82. Para cada perfil, quais funcionalidades e dados devem estar acessíveis e quais devem ser restritos?
83. Um mesmo usuário pode acumular mais de um perfil?
84. Há campos ou registros que devem ser visíveis apenas para determinados perfis (ex.: dados financeiros apenas para a diretoria)?
85. Como será feito o login? (credenciais próprias, integração com Active Directory/LDAP, login social, SSO — Single Sign-On)?
86. Há exigência de autenticação multifator (MFA)?
87. 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

88. Qual o tempo máximo de resposta aceitável para operações típicas (abrir tela, salvar registro, gerar relatório)?
89. Qual o número máximo de usuários simultâneos que o sistema deve suportar sem degradação perceptível?
90. Qual o volume máximo de dados projetado para os próximos 3 a 5 anos (número de registros, tamanho em GB)?
91. Há expectativa de crescimento abrupto de uso em determinados períodos (campanhas, sazonalidade, expansão)?
92. Há funcionalidades que exigem processamento em tempo real (ex.: rastreamento, IoT, chat ao vivo)?

6.2 Disponibilidade e confiabilidade

93. Qual o nível de disponibilidade exigido (ex.: 99%, 99,9%, 24/7)?
94. Há janelas de manutenção aceitáveis (horários em que o sistema pode ficar indisponível)?
95. Qual o tempo máximo aceitável de indisponibilidade (RTO — Recovery Time Objective) em caso de falha?
96. Qual o volume máximo de dados que pode ser perdido (RPO — Recovery Point Objective) em caso de falha?
97. É necessário um plano de contingência ou disaster recovery? Quais cenários devem ser cobertos?

6.3 Segurança e privacidade

98. O sistema manipulará dados pessoais (nome, CPF, endereço, dados de saúde, dados financeiros)?
99. 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.)?
100. Quais dados devem ser criptografados em trânsito e/ou em repouso?
101. Há necessidade de logs de auditoria para todas as ações dos usuários? Por quanto tempo devem ser mantidos?
102. O sistema precisará atender a auditorias externas? Quais padrões ou certificações são necessários?
103. 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)

104. Há uma identidade visual (manual de marca, paleta de cores, logotipos) que o sistema deverá seguir?
105. Existe preferência por estilo de interface (minimalista, rico em informações, tipo dashboard, tipo formulário)?
106. O sistema deve ser responsivo (adaptar-se a diferentes tamanhos de tela)?
107. Há benchmarks de tempo de aprendizado desejado (ex.: usuário deve conseguir realizar tarefa X em menos de Y minutos na primeira tentativa)?
108. O sistema deve seguir diretrizes de acessibilidade (WCAG 2.1, e-MAG)?
109. Há funcionalidades que exigem operação por voz, leitura de tela, atalhos de teclado ou alto contraste?

6.5 Portabilidade e compatibilidade

110. O sistema será web, desktop, mobile nativo ou híbrido?
111. Quais navegadores e versões mínimas devem ser suportados (se web)?
112. Quais sistemas operacionais devem ser suportados (Windows, macOS, Linux, Android, iOS)?
113. Há restrições quanto ao hardware mínimo dos usuários (ex.: PCs antigos, dispositivos de baixo custo)?

6.6 Manutenibilidade e evolução

114. O sistema será mantido por equipe interna ou terceirizada? Qual o perfil técnico dessa equipe?
115. Há preferência ou restrição quanto a tecnologias, linguagens de programação, frameworks ou bancos de dados?
116. O código-fonte deve ser entregue? Sob qual licença?
117. É desejável uma arquitetura modular que permita adicionar funcionalidades futuras sem grande impacto?
118. 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).

119. 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).
120. 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.
121. Há necessidade de integração com hardware ou dispositivos (impressoras, leitores de código de barras, balanças, catracas, sensores, câmeras)?
122. O sistema deverá disponibilizar API própria para consumo por outros sistemas ou parceiros?
123. 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).

124. 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.
125. 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.
126. 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.
127. 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)?
128. 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

129. Qual o orçamento disponível para o projeto (desenvolvimento, infraestrutura, licenças)?
130. Qual o prazo esperado ou obrigatório para entrega (parcial e total)? Há datas-limite inegociáveis?
131. Há restrições legais, regulatórias ou contratuais que o sistema deve atender?
132. Há restrições de infraestrutura (servidor local obrigatório, proibição de nuvem pública, limitação de largura de banda)?
133. Há restrições relacionadas a propriedade intelectual (uso obrigatório de software livre, proibição de determinada tecnologia proprietária)?

9.2 Premissas

134. 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")
135. Há alguma dependência de terceiros (fornecedores, prestadores de serviço, órgãos) para que o projeto avance?

9.3 Riscos conhecidos

136. 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)
137. Já houve tentativas anteriores de implantar um sistema similar que não foram bem-sucedidas? O que deu errado?
138. 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).

139. 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)
140. Quem realizará os testes de aceitação (UAT — User Acceptance Testing)? Haverá um grupo de usuários-piloto?
141. Qual a estratégia de implantação desejada (big bang, migração gradual, piloto)?
142. Há necessidade de treinamento pré-implantação? Para quantas pessoas e em qual formato?
143. Quem será responsável pela operação e suporte técnico após a entrega (help desk, suporte N1/N2/N3)?
144. Qual o período de garantia esperado após a entrega para correção de defeitos?
145. Há expectativa de contrato de manutenção (evolutiva, corretiva, adaptativa) após a entrega?
146. Existem critérios para o encerramento formal do projeto (documento de aceite, homologação)?

▶ 💭 BLOCO COMPLEMENTAR — PERGUNTAS ABERTAS E CONSOLIDAÇÃO

147. Existe algum aspecto, funcionalidade, restrição ou preocupação que não foi abordado neste questionário e que você considera relevante?
148. Se pudesse resumir em uma frase, qual é o principal objetivo deste sistema?
149. Como você imagina o dia a dia dos usuários após a implantação bem-sucedida do sistema? Descreva o cenário ideal.
150. 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