REQUISITOS
Requisitos de são as descrições de tudo o que um sistema deve fazer e como deve operar.
Eles respondem a duas perguntas fundamentais:
• “O que o sistema deve fazer?” (requisitos funcionais)
• “Como o sistema deve fazer isso?” (requisitos não funcionais).
Requisitos Funcionais:
• Definição: Descrevem funcionalidades específicas do sistema.
• Exemplo:
• “O sistema deve permitir que os usuários façam login com nome de usuário e
senha.”
• “O sistema deve calcular o frete baseado na localização do cliente.”
Requisitos Não Funcionais
• Definição: Descrevem propriedades do sistema, como desempenho,
segurança e usabilidade.
• Exemplo:
• “O sistema deve carregar páginas em até 2 segundos.”
• “A plataforma deve estar disponível 24 horas por dia, 7 dias por semana.”
• “Os dados do cliente devem ser criptografados durante o transporte.”
Brainstorming
Uma sessão colaborativa para gerar ideias e identificar requisitos.
• Projeto: “Criar um aplicativo de entregas.”
• Pergunta para o grupo: “Quais são as funcionalidades mais importantes para
um cliente de aplicativo de entregas?”
• Ideias geradas: “Rastreio de pedido, pagamento via cartão, avaliações de
entregadores.”
Escrita Formal de Requisitos
Identificador: RF01
Descrição: O sistema deve permitir que o usuário faça login com e-mail e senha.
Prioridade: Alta
Critérios de Aceitação:
1. O usuário deve inserir um e-mail e senha válidos para acessar o sistema.
2. Se as credenciais forem incorretas, o sistema deve exibir uma mensagem de
erro.
3. O usuário deve ser redirecionado para a página principal após o login
bem-sucedido.
Prototipação
Criar modelos visuais para representar os requisitos. Alta e baixa fidelidade.
Escritas de requisito
• Necessário: O requisito deve ser essencial para o funcionamento do sistema,
sem o qual o objetivo não pode ser alcançado.
• Claro: A linguagem deve ser precisa e sem ambiguidades.
Exemplo: “O sistema deve ser rápido” (não) “O sistema deve processas pedidos em até dois
segundos” (sim)
• Verificável: O requisito precisa ser passível de ser testado ou validado, de
forma que seja possível confirmar se foi atendido corretamente.
• Atingível: O requisito deve ser realista, considerando as restrições de tempo,
recursos e tecnologia disponível para ser implementado.
Casos de Uso
Descrevem cenários em que um usuário interage com o sistema para alcançar um objetivo
específico.
Obs: (Fluxo alternativo: Situações fora do padrão (ex.: falha de login))
Caso de Uso: Desconectar
Ator: Professor, Aluno
Pré-condição: estar logado
Fluxo Básico:
1. Inicia quando ator seleciona a opção desconectar
2. Sistema finaliza seção
3. Sistema exibe interface de login
Fluxo Alternativo: -
Pós-condição: ator não está logado no sistema
Diagrama de casos de uso
<<extend>>: opcional, quando um caso de uso pode chamar o outro mas é não obrigatório,
extende um comportamento adicional.
<<include>>: quando um usuário precisa chamar o outro para concluir sua tarefa, ele vai
incluir outro caso de uso para fazer parte do processo. Sempre deve ser chamado.
Agrupamento e Priorização
Eles organizam requisitos em três categorias:
• Essenciais: indispensáveis para o funcionamento.
• Importantes: necessárias, mas podem ser adiadas.
• Desejáveis: agregam valor, mas não são críticas.
Descrição de Caso de Uso:
• Ideia das Funcionalidades:
Define o comportamento do sistema e as ações que os usuários podem realizar. Descreve
as interações entre os usuários (atores) e o sistema.
• Documento ou Texto Explicativo:
Geralmente apresentado como um documento que detalha como cada funcionalidade deve
ser executada, fornecendo informações claras sobre os passos necessários para alcançar o
objetivo.
• Utilização pela Equipe de Desenvolvimento:
A equipe usa a descrição para entender os requisitos e o comportamento esperado do
sistema, ajudando a guiar o desenvolvimento e os testes das funcionalidades.
Histórias de Usuário
São descrições simples de funcionalidades do ponto de vista do usuário final.
Estrutura:
“Como um [tipo de usuário], eu quero [ação] para [benefício].”
Exemplo:
“Como um cliente, eu quero rastrear meu pedido para saber a hora de chegada.”
Critérios de Aceite:
São as condições específicas que definem quando uma funcionalidade ou história de
usuário está considerada pronta e pode ser entregue. Eles são essenciais para garantir que
o sistema atenda aos requisitos esperados, ajudando a equipe a saber exatamente o que
precisa ser feito e testado. Definem como saberemos que a história está pronta.
Exemplo: Se a história do usuário fala sobre “realizar o login”, os critérios de aceitação
podem ser:
• O sistema deve aceitar um nome de usuário e senha válidos.
• O sistema deve exibir uma mensagem de erro se as credenciais forem
incorretas.
• Preciso:
Sem essa história o projeto/produto não tem sentido
• Quero:
História importante, porém negociável
• Desejo:
Seria bom se fosse possível, mas se não der, tudo bem.
• Como um usuário não cadastrado, eu preciso realizar o cadastro para que
eu possa acessar as funcionalidades do aplicativo.
• Como um usuário não cadastrado, eu quero realizar o cadastro para que eu
possa acessar as funcionalidades do aplicativo.
• Como um usuário não cadastrado, eu desejo realizar o cadastro para que
eu possa acessar as funcionalidades do aplicativo.
• Como cliente, eu quero sacar dinheiro no caixa eletrônico para evitar a fila
do banco.
• Critérios de aceite:
⁃ O cliente com saldo suficiente consegue sacar dinheiro da sua conta.
⁃ O cliente sem saldo suficiente não consegue sacar dinheiro da sua conta.
⁃ O cliente com saldo suficiente não consegue sacar dinheiro da sua conta se
o caixa eletrônico não tiver dinheiro suficiente para isso
