Requisitos funcionais se relacionam com os não funcionais de tal forma que um requisito funcional pode modificar a especificação de um não funcional, e a sua prioridade. Comente a afirmação e utilize um exemplo para ilustrar a sua resposta a partir do sistema especificado para a disciplina.
Passo 1
O que o enunciado pede e quais informações foram dadas.
- Pede um comentário sobre a afirmação: “Requisitos funcionais se relacionam com os não funcionais de tal forma que um requisito funcional pode modificar a especificação de um não funcional, e a sua prioridade.”
- Pede que seja usado um exemplo concreto a partir do sistema especificado para a disciplina.
- Informações implícitas que vou usar: existe um “sistema da disciplina” (plataforma para entregas, avaliações, materiais, fórum, etc.). Não foi dado mais detalhe, então vou assumir um sistema típico de disciplina e explicar passo a passo como um requisito funcional específico afeta requisitos não funcionais e suas prioridades.
Passo 2
O que são requisitos funcionais (RF) e não funcionais (RNF) — explicação didática e simples.
- Requisito funcional (RF): descreve uma função concreta que o sistema deve executar — algo que o usuário vê que o sistema faz (ex.: permitir que o estudante submeta um trabalho, corrigir uma prova, enviar notificações). Pense em RF como “o que o sistema faz”.
- Requisito não funcional (RNF): descreve como o sistema deve ser (qualidades ou restrições) — desempenho, segurança, usabilidade, disponibilidade, escalabilidade, capacidade de armazenamento, privacidade, etc. Pense em RNF como “qualidade do sistema”.
- Importante: RNF geralmente são cross-cutting (atravessam várias funcionalidades) e podem ser quantificados (ex.: tempo de resposta ≤
, disponibilidade , armazenamento mínimo ).
Explicação prática: RF = “aceitar upload de trabalho”; RNF = “tempo máximo de upload”, “arquivamento seguro”, “limite de tamanho”.
Passo 3
Por que e como um RF pode modificar a especificação de um RNF — princípios e mecanismos.
- Dependência natural: um RF pode introduzir novas exigências de qualidade ou ampliar as que já existem. Ex.: implementar streaming de vídeo (RF) exige alto throughput e mais armazenamento (RNF).
- Derivação de RNF: um RF pode gerar RNFs derivados. Por exemplo, RF “autenticar usuário” pode derivar RNF “senha criptografada em repouso” e RNF "tempo máximo para autenticação ≤
". - Alteração de especificação: quando um RF novo é detalhado, pode obrigar a especificar valores numéricos para RNFs que antes eram vagos. Ex.: antes se pedia “boa disponibilidade”; o RF “provas online sincronizadas” força a definir "disponibilidade ≥
". - Mudança de prioridade: se um RF é considerado crítico por stakeholders (professor, secretaria), então RNFs associados tornam-se prioritários para atender aquele RF. Ou seja, a importância de um RNF depende do conjunto de RFs que ele suporta e da criticidade desses RFs.
Passo 4
Apresentação do sistema da disciplina e listagem de RFs típicos (para usar no exemplo).
- Vamos assumir um sistema da disciplina com funções usuais:
- RF1: permitir que estudante submeta trabalhos (upload de arquivos).
- RF2: aplicar provas online com tempo cronometrado.
- RF3: disponibilizar vídeo-aulas ao vivo e gravadas.
- RF4: gerenciar notas e feedbacks.
- RF5: fórum de discussão.
- Esses RFs são a base; agora vou escolher um RF para mostrar o impacto sobre RNFs.
Passo 5
Escolha do RF para o exemplo e identificação dos RNFs afetados.
- Vou escolher RF1: “permitir que estudante submeta trabalhos (upload de arquivos)”. Suponha que o RF diga: arquivos de até
por entrega, múltiplos formatos aceitos, e possibilidade de anexar vídeos. - RNFs diretamente afetados por esse RF:
- RNF-A (capacidade/armazenamento): espaço em disco e política de backup.
- RNF-B (desempenho): tempo máximo aceitável para upload e processamento (por exemplo, tempo de resposta).
- RNF-C (segurança): verificação de vírus, controle de acesso, criptografia em repouso.
- RNF-D (escalabilidade/concorrência): suportar
uploads simultâneos sem degradar serviço. - RNF-E (usabilidade): feedback de progresso do upload (barra de progresso) e mensagens de erro claras.
- Note: já usei o número em TeX:
, conforme as regras.
Passo 6
Como o RF modifica a especificação dos RNFs — exemplos concretos de mudanças.
- Antes do RF detalhado podia existir um RNF vago: “o sistema deverá armazenar entregas dos alunos com segurança.” Após detalhar RF1 com
e vídeos, o RNF-A precisa ficar explícito: “o sistema deverá prover armazenamento mínimo de com retenção de meses e backup diário.” - Desempenho (RNF-B) vira quantitativo: antes era “rápido”; depois do RF torna-se "tempo máximo de upload para arquivo de
≤ usando conexão de ". Isso é especificar um cenário de qualidade. - Segurança (RNF-C): passar de “entradas devem ser seguras” para “todos os arquivos recebidos devem ser verificados por antivírus em até
após o upload e armazenados criptografados com chave gerenciada”. - Escalabilidade (RNF-D): se o curso tem
alunos e prazos coincidentes, exige que o sistema suporte pelo menos uploads simultâneos com performance degradando no máximo . - Usabilidade (RNF-E): passa a exigir UI com barra de progresso e re-tentativa automática em falha de rede.
- Em resumo: o RF força a transformar RNFs vagos em especificações mensuráveis e, muitas vezes, maiores em escala.
Passo 7
Como o RF altera a prioridade dos RNFs — mecanismo de priorização com exemplo prático.
- Stakeholders: professor, coordenador do curso, alunos, TI da universidade. Cada stakeholder atribui importância diferente a RFs e RNFs.
- Exemplo de priorização prática:
- Se professor declara “entregas valem
da nota e prazo é estrito”, então RF1 (upload de trabalhos) é crítico. Logo RNF-A (armazenamento), RNF-B (desempenho) e RNF-C (segurança) sobem para prioridade alta. - Se, no entanto, o curso é de laboratório onde arquivos são pequenos, talvez RNF-A tenha prioridade baixa. Portanto a prioridade de RNFs muda conforme a criticidade do RF.
- Se professor declara “entregas valem
- Métodos de priorização: usar MoSCoW (Must / Should / Could / Won’t) ou matriz de impacto × custo. No caso do RF1 crítico, RNF-A/B/C seriam “Must”, RNF-E talvez “Should”.
Passo 8
Riscos, trade-offs e como negociar mudanças entre RF e RNF.
- Trade-off típico: aumentar capacidade (RNF-A) custa dinheiro; melhorar antivírus (RNF-C) aumenta latência. Decisão: priorizar o que é crítico para RF.
- Estratégia prática: propor mitigação incremental — por exemplo, permitir uploads grandes mas com processamento assíncrono (aceitar o arquivo, devolver confirmação imediata, processar antivírus em background). Isso reduz impacto imediato em RNF-B ao custo de complexidade arquitetural.
- Documentar decisões: registrar rastreabilidade (traceability matrix) ligando RF1 aos RNFs que ela afeta e às decisões de prioridade. Isso facilita justificativas em prova e na prática.
Passo 9
Como responder à questão em prova (passo-a-passo prático e enxuto que você pode escrever).
-
- Diga se a afirmação é verdadeira e justifique com princípio: RF pode sim modificar RNF e prioridade porque RFs definem qualidades necessárias e sua criticidade determina prioridade.
-
- Forneça um exemplo curto e objetivo (usei RF1: upload até
). Liste 2–3 RNFs afetados e mostre como a especificação muda (armazenamento → valor numérico; desempenho → tempo máximo; segurança → antivírus/criptografia).
- Forneça um exemplo curto e objetivo (usei RF1: upload até
-
- Explique como a prioridade muda (se RF é crítico, RNFs associados viram “Must”).
-
- Conclua com uma frase sobre necessidade de rastreabilidade e negociação.
Essa estrutura ganha pontos porque mostra entendimento conceitual, exemplo concreto e aplicação prática.
- Conclua com uma frase sobre necessidade de rastreabilidade e negociação.
Passo 10
Resumo final e encorajamento — por que isso importa e dica rápida.
- Importa porque requisitos não funcionais são muitas vezes esquecidos até aparecerem problemas operacionais; entender que RFs trazem RNFs ajuda a evitar surpresas (sistema lento, sem espaço, inseguro).
- Dica rápida: sempre, ao escrever RFs na prova ou na prática, pergunte “que qualidades isso exige?” e escreva pelo menos um RNF mensurável ligado a cada RF crítico. Isso demonstra controle do problema e evita resposta genérica.
Resposta
Verdadeiro. Um requisito funcional pode alterar a especificação e a prioridade de requisitos não funcionais porque, ao detalhar uma função (por exemplo, permitir upload de arquivos de até
), surgem exigências mensuráveis de armazenamento, desempenho, segurança e escalabilidade (por exemplo, espaço mínimo em disco, tempo máximo de upload, verificação antivírus), e se esse RF for crítico para stakeholders esses RNFs tornam-se prioritários (passam a “Must”).