First Things First
Introdução
A priorização de requisitos é fundamental para garantir que funcionalidades críticas sejam desenvolvidas primeiro. No projeto Celular Seguro, utilizamos a técnica First Things First para organizar e priorizar os requisitos com base em benefício, penalidade, custo e risco. Essa abordagem ajuda a alinhar o desenvolvimento com os objetivos de segurança, usabilidade e acessibilidade do aplicativo.
Metodologia
As pessoas que participaram da aplicação da técnica First Things First (FTF) estão listadas na Tabela 1.
- Mediador – Conduz a sessão e apresenta os requisitos.
- Cliente – Atribui notas de benefício e penalidade.
- Desenvolvedor – Atribui notas de custo e risco.
Tabela 1: Participantes da técnica First Things First.
| Nome | Função |
|---|---|
| Arthur Carvalho | Mediador |
| Leticia Figueiredo | Cliente |
| Gabriel Lima | Desenvolvedor |
Legenda:
Nome – participante da técnica.
Função – papel desempenhado na priorização.
A aplicação do FTF seguiu os passos:
- Listagem e filtragem dos requisitos independentes.
- Atribuição de notas de benefício e penalidade (escala 1 – 9) pelo Cliente.
- Atribuição de notas de custo e risco (1 – 9) pelo Desenvolvedor.
- Cálculo do valor total = Benefício × 2 + Penalidade × 1.
- Normalização dos valores e cálculo da prioridade:
prioridade = valor(%) / (Custo (%) × Custo Relativo) + (Risco (%) × Risco Relativo)
- Ordenação dos requisitos em ordem decrescente de prioridade.
Pesos relativos
- Benefício: 2
- Penalidade: 1
- Custo: 1
- Risco: 1
Resultado da Priorização
Tabela 2: Resultado da priorização dos requisitos.
| Funcionalidade | Benefício Relativo | Penalidade Relativa | Valor total | Valor (%) | Custo Relativo | Custo (%) | Risco Relativo | Risco (%) | Prioridade |
|---|---|---|---|---|---|---|---|---|---|
| Q01 | 9 | 9 | 27 | 4,98 | 1 | 1,35 | 1 | 1,16 | 1,984 |
| Q02 | 9 | 9 | 27 | 4,98 | 1 | 1,35 | 1 | 1,16 | 1,984 |
| OBS06 | 9 | 9 | 27 | 4,98 | 1 | 1,35 | 1 | 1,16 | 1,984 |
| OBS15 | 8 | 9 | 25 | 4,61 | 1 | 1,35 | 1 | 1,16 | 1,836 |
| OBS10 | 8 | 7 | 22 | 4,05 | 1 | 1,35 | 1 | 1,16 | 1,613 |
| OBS09 | 9 | 9 | 27 | 4,98 | 1 | 1,35 | 3 | 3,49 | 1,031 |
| BS15 | 8 | 9 | 25 | 4,61 | 2 | 2,70 | 2 | 2,33 | 0,458 |
| Q09 | 8 | 5 | 21 | 3,87 | 2 | 2,70 | 2 | 2,33 | 0,384 |
| BS08 | 7 | 6 | 20 | 3,69 | 2 | 2,70 | 2 | 2,33 | 0,366 |
| BS23 | 6 | 7 | 19 | 3,50 | 2 | 2,70 | 2 | 2,33 | 0,347 |
| BS17 | 6 | 7 | 19 | 3,50 | 2 | 2,70 | 2 | 2,33 | 0,347 |
| BS02 | 9 | 7 | 25 | 4,61 | 2 | 2,70 | 4 | 4,65 | 0,192 |
| BS37 | 8 | 7 | 23 | 4,24 | 3 | 4,05 | 3 | 3,49 | 0,170 |
| OBS18 | 6 | 8 | 20 | 3,69 | 3 | 4,05 | 3 | 3,49 | 0,163 |
| Q06 | 6 | 5 | 17 | 3,13 | 3 | 4,05 | 3 | 3,49 | 0,138 |
| BS52 | 9 | 9 | 27 | 4,98 | 4 | 5,41 | 4 | 4,65 | 0,123 |
| BS50 | 8 | 9 | 25 | 4,61 | 4 | 5,41 | 4 | 4,65 | 0,114 |
| BS48 | 6 | 7 | 19 | 3,50 | 4 | 5,41 | 4 | 4,65 | 0,086 |
| BS60 | 8 | 9 | 25 | 4,61 | 5 | 6,76 | 5 | 5,81 | 0,073 |
| OBS03 | 4 | 9 | 17 | 3,13 | 5 | 6,76 | 5 | 5,81 | 0,049 |
| OBS21 | 7 | 5 | 19 | 3,50 | 5 | 6,76 | 6 | 6,98 | 0,046 |
| OBS16 | 4 | 3 | 11 | 2,02 | 2 | 2,70 | 6 | 6,98 | 0,042 |
| Q19 | 6 | 3 | 15 | 2,76 | 5 | 6,76 | 6 | 6,98 | 0,036 |
| BS54 | 9 | 9 | 27 | 4,98 | 7 | 9,46 | 9 | 10,47 | 0,031 |
| BS56 | 5 | 3 | 13 | 2,39 | 6 | 8,11 | 6 | 6,98 | 0,026 |
| TOTAL | 542 | 74 | 100 | 86 | 100 |
Legenda:
Funcionalidade – código do requisito priorizado (RFx para funcionais, RNFx para não funcionais).
Benefício Relativo e Penalidade Relativa – notas (1 – 9) atribuídas pelo Cliente.
Valor total – Benefício × 2 + Penalidade × 1.
Valor (%) – valor total normalizado.
Custo Relativo e Risco Relativo – notas (1 – 9) atribuídas pelo Desenvolvedor.
Custo (%) e Risco (%) – valores normalizados.
Prioridade – razão entre Valor (%) e o esforço ((Custo (%) × Custo Relativo) + (Risco (%) × Risco Relativo)).
Requisitos Funcionais
Tabela 3: Requisitos Funcionais identificados para o Celular Seguro.
| ID (RFx) | Descrição do Requisito Funcional |
|---|---|
| Q01 | O aplicativo deve permitir localizar o celular perdido. |
| Q02 | O aplicativo deve tornar visível e acessível a opção de registro de boletim de ocorrência. |
| Q06 | O aplicativo deve notificar o usuário em caso de atividade suspeita relacionada ao dispositivo. |
| OBS03 | Existe a funcionalidade de redefinir a senha via e-mail. |
| OBS06 | O sistema disponibiliza uma aba que te leva a um pdf com um tutorial do aplicativo. |
| OBS09 | Ao tentar emitir um alerta de roubo, o sistema exibe uma janela pop-up solicitando a confirmação do usuário antes de prosseguir com a ação. |
| OBS10 | Pelo MEI do aparelho, é possível consultar o status do celular e saber se ele se encontra como um celular roubado, furtado, etc ( irregular). |
| BS02 | Apagar todos os dados do dispositivo |
| BS08 | Bloquear chip por integração direta com a operadora |
| BS15 | Botão de “bloqueio rápido” sempre acessível na tela principal. |
| BS17 | Efetuar backup automático de contatos, fotos e mensagens antes do bloqueio remoto. |
| BS23 | Definir “dispositivo de confiança” para controle remoto secundário. |
Legenda:
ID (RFx) – identificador sequencial de Requisito Funcional.
Descrição – definição concisa da funcionalidade exigida.
Requisitos Não Funcionais
Tabela 4: Requisitos Não Funcionais identificados para o Celular Seguro.
| ID (RNFx) | Descrição do Requisito Não Funcional |
|---|---|
| OBS15 | O aplicativo apresenta uma interface amigável e intuitiva, com ícones bem definidos e menus acessíveis. |
| OBS16 | As páginas carregam em até 2 segundos em conexões padrão 4G. |
| OBS18 | O aplicativo é acessível para pessoas com deficiência visual (uso de leitor de tela, contraste, tamanho da fonte). |
| OBS21 | O aplicativo está disponível 24/7, com raras quedas detectadas durante a observação. |
| Q09 | O aplicativo deve funcionar de maneira estável e confiável em momentos de emergência. |
| Q19 | O aplicativo deve oferecer um modo escuro (dark mode) para maior conforto visual. |
| BS37 | Linguagem simples sem jargões técnicos |
| BS48 | Autenticação multifator (2 FA) com fallback via SMS. |
| BS50 | Política de privacidade clara e facilmente acessível dentro do app |
| BS52 | Central de ajuda acessível offline e online |
| BS54 | Monitoramento de tentativas de acesso não autorizado com alertas automáticos. |
| BS56 | Sincronização de estado entre app e portal em menos de 5 segundos |
| BS60 | Atualizações automáticas de segurança e correções de vulnerabilidades em até 24 horas. |
Legenda:
ID (RNFx) – identificador sequencial de Requisito Não Funcional.
Descrição – detalhamento do critério de qualidade ou restrição.
Legenda Geral
- RF – Requisito Funcional: descreve o que o sistema deve fazer para atender às necessidades do usuário ou do negócio.
- RNF – Requisito Não Funcional: descreve como o sistema deve se comportar ou quais restrições de qualidade deve obedecer (usabilidade, desempenho, segurança, etc.).
Gravação
Fonte: Gabriel Lima.
Bibliografia
FIRST things first: Setting requirement priorities. In: WIEGERS, K. E.; BEATTY, J. Software Requirements. 3. ed. Microsoft Press, 2013. cap. 16, p. 313‑329.
Histórico de Versões
| Versão | Data de Produção | Descrição da Alteração | Autor(es) | Revisor(es) | Data de Revisão |
|---|---|---|---|---|---|
| 1.0 | 01/05/2025 | Criação do documento FTF para Celular Seguro | Leonardo de Melo | Arthur Carvalho | 01/05/2025 |
| 1.1 | 04/05/2025 | Análise de valores de custo, valor e risco | Gabriel Lima | Arthur Carvalho | 04/05/2025 |
| 1.2 | 08/05/2025 | Padronização do Histórico de Versões | Arthur Carvalho | Arthur Carvalho | 08/05/2025 |
| 2.0 | 28/06/2025 | Inserção do video de entrevista na tecnica FTF | Gabriel Lima | Arthur Carvalho | 28/06/2025 |