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 ≤ 2\\ \text{s}, disponibilidade 99{,}9\%, armazenamento mínimo 500\\ \mathrm{GB}).
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 ≤ 3\\ \text{s}".
  • 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 ≥ 99{,}5\%".
  • 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é 1\\ \mathrm{GB} 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 n 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: 1\\ \mathrm{GB}, 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 1\\ \mathrm{GB} e vídeos, o RNF-A precisa ficar explícito: “o sistema deverá prover armazenamento mínimo de 5\\ \mathrm{TB} com retenção de 12 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 500\\ \mathrm{MB} 120\\ \text{s} usando conexão de 20\\ \mathrm{Mbps}". 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é 30\\ \text{s} após o upload e armazenados criptografados com chave gerenciada”.
  • Escalabilidade (RNF-D): se o curso tem 1000 alunos e prazos coincidentes, exige que o sistema suporte pelo menos 50 uploads simultâneos com performance degradando no máximo 20\%.
  • 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 40\% 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.
  • 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).
    1. 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.
    1. Forneça um exemplo curto e objetivo (usei RF1: upload até 1\\ \mathrm{GB}). 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).
    1. Explique como a prioridade muda (se RF é crítico, RNFs associados viram “Must”).
    1. 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.

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é 1\\ \mathrm{GB}), 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”).

Exercícios relacionados