Técnica de Priorização In or Out¶
Descrição¶
Essa técnica é utilizada na priorização e validação de requisitos de forma simplificada e objetiva. Após a elicitação e seleção de requisitos a serem trabalhados, os usuários finais do produto são convidados a avaliá-los e decidir se devem estar dentro do escopo (In) ou fora do escopo (Out) do sistema. Essa prática promove o alinhamento entre as expectativas dos usuários e a proposta do sistema, assegurando que as funcionalidades escolhidas reflitam as verdadeiras necessidades do público-alvo.
Objetivo¶
Junto com os usuários finais, validamos quais requisitos devem ser considerados no escopo inicial do sistema, garantindo que o produto atenda às principais demandas e evite funcionalidades desnecessárias.
Metodologia¶
Na metodologia, começão com a:
1. Preparação: reunir os requisitos levantados previamente durante a análise e elicitação.
2. Apresentação: A entrevistadora começa lendo o termo de consentimento e logo apresenta cada requisito aos usuários finais.
3. Decisão: os participantes indicam se cada requisito é In (essencial) ou Out (dispensável).
4.Registro: as respostas são colocadas na tabela abaixo, mostrando a evidência para definição de escopo.
Termo de Consentimento¶
Termo de Consentimento para Entrevista – Grupo de Requisitos (2025.2) Esta entrevista faz parte do projeto acadêmico do Grupo de Requisitos da disciplina de Engenharia de Software – semestre 2025.1. Ao participar, você deve estar ciente dos seguintes pontos: Autonomia: sua participação é voluntária e pode ser interrompida a qualquer momento, sem prejuízos.
Beneficência e Não Maleficência: a entrevista visa apoiar a pesquisa, sem causar riscos ou danos aos participantes.
Justiça e Equidade: todos os participantes serão tratados com respeito e igualdade.
Confidencialidade: as informações fornecidas serão utilizadas apenas para fins acadêmicos.
Declaro que fui informado(a) sobre os objetivos da entrevista e concordo em participar de forma voluntária.
Entrevista do In or Out¶
| Item | Pergunta | Referência | In or Out |
|---|---|---|---|
| 1 | Sistema deve permitir criação de conta com dados pessoais? | Análise Documentos RF1 + RF12 | In |
| 2 | Sistema deve verificar cadastros duplicados? | Análise Documentos RF2 | In |
| 3 | Sistema deve classificar usuários (casual/competitivo/investidor)? | Entrevista | Out |
| 4 | Sistema deve permitir apenas produtos Magic? | Análise Documentos RF4 | In |
| 5 | Sistema deve permitir catalogar cartas do usuário? | Glossário 5 | In |
| 6 | Sistema deve permitir criação de decks? | Glossário 4 | In |
| 7 | Sistema deve mostrar variação de preços entre lojas? | Entrevista | In |
| 8 | Sistema deve permitir troca de mensagens? | Análise Documentos RF9 | In |
| 9 | Sistema deve permitir posts e respostas? | Análise Documentos RF11 | In |
| 10 | Sistema deve disponibilizar contato entre usuários? | Análise Documentos RF7 | In |
| 11 | Sistema deve oferecer referência de preços? | Entrevista | In |
| 12 | Sistema deve permitir vendas por leilão? | Glossário 4 | In |
| 13 | Sistema deve manter lista de compras? | Glossário 7 | In |
| 14 | Sistema deve exibir dados completos das cartas? | Glossário 6 - 14 | In |
| 15 | Sistema deve funcionar em celular e desktop? | Entrevista | In |
| 16 | Sistema deve classificar por raridade? | Glossário 8 | In |
| 17 | Sistema deve diferenciar tipos de cartas? | Glossário 10-14 | In |
Fonte: Raissa, 2025.
Conclusão¶
Com a aplicação da técnica In or out, conseguimos validar os requisitos com base na percepção dos usuários finais, definimos de forma objetiva quais funcionalidades fazem parte do escopo do sistema.
Dos 17 requisitos avaliados, 16 foram classificados como In, eles são essenciais para a primeira versão, apenas 1 requisito ficou classificado como Out, classificar usuários como casual/competitivo/investidor.
Assim, concluímos que há um alinhamento consistente entre os documentos analisados, entrevistas e glossário, assegurando que o sistema está de fato desenvolvido com o foco nas necessidades prioritárias dos usuários.
Bibliografia¶
WIEGERS, Karl; BEATTY, Joy. First things first: Setting requirement priorities. In: WIEGERS, Karl; BEATTY, Joy. Software Requirements. 3. ed. [S.l.]: Microsoft Press, 2013. p. 313-326.
Nível de Contribuição dos Integrantes¶
| Nome | % de Contribuição |
|---|---|
| Raissa | 100% |
Histórico de versão¶
| Versão | Data | Descrição | Autor(es) | Revisor |
|---|---|---|---|---|
| 1.0 | 30/09/2025 | Criação e preenchimento do documento | Raissa | Vera |
| 1.1 | 02/09/2025 | Formatação e organização do documento | Samuel | - |