Roi

Introdução

A técnica ROI (Return on Investment ou Retorno sobre Investimento) é uma abordagem que visa avaliar a relação entre o benefício esperado de um requisito e o custo estimado para sua implementação. No contexto do projeto de requisitos do eGDF, esta técnica nos ajudará a priorizar os requisitos que trarão maior valor aos usuários considerando os recursos necessários para implementá-los.

Metodologia

Para aplicar a técnica ROI, seguimos os seguintes passos:

Avaliação do Benefício (1-5):
1: Benefício muito baixo
2: Benefício baixo
3: Benefício moderado
4: Benefício alto
5: Benefício muito alto
Avaliação do Custo (1-5):
1: Custo muito baixo
2: Custo baixo
3: Custo moderado
4: Custo alto
5: Custo muito alto
Cálculo do ROI:
ROI = Benefício / Custo
Classificação da Prioridade:
Alta: ROI ≥ 2
Média: 1 < ROI < 2
Baixa: ROI ≤ 1

Link da gravação

Link para a gravação da reunião

Priorização dos Requisitos

Requisitos Funcionais

Tabela 1: Priorização dos Requisitos Funcionais

Requisitos	ID	Descrição	Benefício (1-5)	Custo (1-5)	ROI	Prioridade
RF01	BR01, AD01	O usuário deve conseguir realizar login de forma simples e rápida	5	2	2.5	Alta
RF02	BR02	O usuário deve conseguir acessar funcionalidades mesmo com pouca familiaridade com tecnologia	5	3	1.67	Média
RF03	BR03	O usuário deve poder receber notificações personalizadas com base em sua localização	4	3	1.33	Média
RF04	BR04	O usuário deve poder consultar agendamentos e serviços em um único local centralizado	5	2	2.5	Alta
RF05	BR05, AD05, INT13	O usuário deve ter acesso a um assistente virtual com acessibilidade por voz	4	4	1	Baixa
RF06	BR06	O usuário deve poder acessar tutoriais passo a passo sobre como usar o app	4	2	2	Alta
RF07	BR07, EN08, AD08	O usuário deve poder alterar o tamanho da fonte e o contraste de cores	4	2	2	Alta
RF08	BR08	O aplicativo deve permitir modo escuro	3	2	1.5	Média
RF09	BR10	O usuário deve poder acessar e visualizar notícias relevantes	3	2	1.5	Média
RF10	BR11	O usuário deve poder gerar relatórios e visualizar comprovantes de agendamentos	4	2	2	Alta
RF11	BR12	O aplicativo deve permitir a integração com serviços de saúde, educação e mobilidade	5	4	1.25	Média
RF12	BR13	O usuário deve poder alterar o idioma do aplicativo	3	3	1	Baixa
RF13	BR14	O usuário deve poder personalizar suas preferências e perfis para recomendações de serviços	4	3	1.33	Média
RF14	BR15	O aplicativo deve permitir o envio de mensagens curtas sobre vencimentos e lembretes importantes	4	2	2	Alta
RF15	BR16	O usuário deve poder acessar um menu com as principais funções logo na tela inicial	5	2	2.5	Alta
RF16	BR17	O usuário deve poder acessar informações de agendamento e reagendamento de forma centralizada	4	2	2	Alta
RF17	BR18	O usuário deve poder utilizar chatbot para tirar dúvidas	3	3	1	Baixa
RF18	BR19	O aplicativo deve permitir notificações por categorias como saúde, educação, transporte	4	2	2	Alta
RF19	BR20	O usuário deve conseguir compartilhar ou salvar informações importantes	4	2	2	Alta
RF20	EN01	O aplicativo permite a visualização da localização dos ônibus em tempo real	5	4	1.25	Média
RF21	EN02	O aplicativo fornece links para serviços externos de forma eficiente	3	2	1.5	Média
RF22	EN03, INT07	O aplicativo oferece funcionalidades para consulta de informações educacionais	4	3	1.33	Média
RF23	EN04	O aplicativo permite autenticação segura através da plataforma gov.br	5	3	1.67	Média
RF24	EN05	O aplicativo facilita o acesso a serviços relacionados a impostos	5	3	1.67	Média
RF25	EN06	O aplicativo implementa funcionalidades adicionais na área educacional	4	3	1.33	Média
RF26	EN09	O aplicativo deve permitir que usuários reportem problemas da cidade	4	3	1.33	Média
RF27	EN10, INT05	O aplicativo deve fornecer acesso a números de serviços de emergência	5	1	5	Alta
RF28	EN11	O aplicativo deve oferecer uma seção de suporte ao usuário	4	2	2	Alta
RF29	AD02	O sistema deve permitir que o usuário solicite serviços públicos	5	3	1.67	Média
RF30	AD03	O sistema deve permitir o usuário utilizar um mapa para localizar serviços	4	3	1.33	Média
RF31	AD04	O sistema deve permitir que o usuário visualize status das solicitações	4	2	2	Alta
RF32	AD06	O sistema deve permitir que o usuário confirme resolução de problemas	4	2	2	Alta
RF33	AD07	O sistema deve permitir que o usuário exclua seus dados	5	2	2.5	Alta
RF34	INT01	Permitir o registro de ocorrências de infraestrutura urbana	4	3	1.33	Média
RF35	INT02	Disponibilizar categorias pré-definidas para ocorrências	3	2	1.5	Média
RF36	INT03	Permitir selecionar tipo de serviço (implantação, limpeza ou reparo)	3	2	1.5	Média
RF37	INT04	Possibilitar adição de descrição, imagem e localização GPS	4	2	2	Alta
RF38	INT06	Disponibilizar agendamento de serviços de saúde pública	5	3	1.67	Média
RF39	INT08	Oferecer acesso a serviços de transporte público	5	3	1.67	Média
RF40	INT09	Permitir agendamentos em serviços sociais	4	3	1.33	Média
RF41	INT10	Disponibilizar emissão de tributos e documentos fiscais	5	3	1.67	Média
RF42	INT11	Fornecer histórico de interações do usuário	4	2	2	Alta
RF43	INT12	Apresentar feed de notícias atualizadas	3	2	1.5	Média
RF44	INT13	Integrar assistente virtual com respostas automáticas	4	4	1	Baixa
RF45	INT14	Fornecer mapa com localização de serviços públicos	4	3	1.33	Média

Fonte: Artur, 2025

Requisitos Não Funcionais

Tabela 2: Priorização dos Requisitos Não Funcionais

Requisitos	ID	Descrição	Benefício (1-5)	Custo (1-5)	ROI	Prioridade
RNF01	AD09	O sistema deve ser compatível com vários dispositivos como Android e iOS	5	4	1.25	Média
RNF02	AD10	O sistema deve estar em conformidade com a Lei Geral de Proteção de Dados (LGPD)	5	3	1.67	Média
RNF03	AD11	O sistema deve ter uma interface intuitiva	5	2	2.5	Alta
RNF04	BRN01	O sistema deve possuir uma interface simples, limpa e com ícones ilustrativos	4	2	2	Alta
RNF05	BRN02	O aplicativo deve permitir acessibilidade para pessoas idosas ou com deficiência visual	5	3	1.67	Média
RNF06	BRN04	O sistema deve funcionar em hardware limitado	4	3	1.33	Média
RNF07	BRN05	A navegação deve ser rápida e fluida	5	3	1.67	Média
RNF08	BRN06	O sistema deve ter carregamento otimizado	4	3	1.33	Média
RNF09	BRN07, INT22	O layout deve ser responsivo	4	3	1.33	Média
RNF10	BRN08	O sistema deve ter compatibilidade com leitores	5	3	1.67	Média
RNF11	BRN09	O app deve ter linguagem clara e acessível	5	2	2.5	Alta
RNF12	EN01	O aplicativo deve ser autoexplicativo	4	2	2	Alta
RNF13	EN02	As informações devem ser atualizadas e precisas	5	3	1.67	Média
RNF14	EN03	O aplicativo deve ter estabilidade	5	3	1.67	Média
RNF15	EN04	O aplicativo deve garantir proteção de dados	5	3	1.67	Média
RNF16	EN05	O processo de login deve ter boa performance	4	3	1.33	Média
RNF17	EN06	O design deve ser acessível para idosos	5	3	1.67	Média
RNF18	EN07, INT19	Deve ter recursos para daltônicos e deficientes	5	3	1.67	Média
RNF19	EN08	Deve ter aparência profissional e confiável	4	2	2	Alta
RNF20	INT15	Compatível com Android e iOS recentes	5	4	1.25	Média
RNF21	INT16	Resposta em máximo dois segundos	5	3	1.67	Média
RNF22	INT17	Interface simples e linguagem acessível	5	2	2.5	Alta
RNF23	INT18	Proteção com criptografia e autenticação	5	3	1.67	Média
RNF24	INT20	Funcionamento offline para consultas	4	4	1	Baixa
RNF25	INT21	Otimização de imagens para upload	3	2	1.5	Média

Fonte: Artur, 2025

Resultados

Com base na priorização realizada, podemos observar que:

Requisitos Funcionais:
Alta Prioridade: 16 requisitos (35.6%)
Média Prioridade: 24 requisitos (53.3%)
Baixa Prioridade: 5 requisitos (11.1%)
Requisitos Não Funcionais:
Alta Prioridade: 6 requisitos (24%)
Média Prioridade: 18 requisitos (72%)
Baixa Prioridade: 1 requisito (4%)

Analise das Informações:

A maioria dos requisitos funcionais e não funcionais tem prioridade média, indicando um bom equilíbrio entre benefício e custo.
Os requisitos de alta prioridade estão principalmente relacionados a:
Usabilidade básica (login, menu principal)
Funcionalidades essenciais (agendamentos, serviços de emergência)
Acessibilidade (fonte, contraste)
Interface do usuário (simplicidade, intuitividade)
Os requisitos de baixa prioridade geralmente envolvem:
Funcionalidades avançadas (assistente virtual, modo offline)
Recursos que requerem alto custo de implementação

Figura 1: Distribuição de Prioridades - Requisitos Funcionais

Distribuição de Prioridades - RFs
Alta (35.6%)	Média (53.3%)	Baixa (11.1%)

Figura 2: Distribuição de Prioridades - Requisitos Não Funcionais

Distribuição de Prioridades - RNFs
Alta (24%)	Média (72%)	Baixa (4%)

Fonte: Artur, 2025

Bibliografia

WIEGERS, Karl; BEATTY, Joy. "Software Requirements". Microsoft Press, 2013.

SOMMERVILLE, Ian. "Engenharia de Software". 9ª edição, Pearson, 2011.

The Standish Group. "CHAOS Report". 2020.

Histórico de Versão

Versão	Descrição	Autor(es)	Data	Revisor(es)	Data de Revisão
1.0	Criação da documentação do ROI	Artur Mendonça	04/05/2025	Lucas Mendonça	04/05/2025
1.1	Correção de nome	Artur Mendonça	04/05/2025	Lucas Mendonça	04/05/2025
2.0	Adição de hyperlinks de rastreabilidade nas tabelas de requisitos	Artur Mendonça	15/05/2025	Lucas Mendonça	16/05/2025