Análise e Desenvolvimento de Sistemas

Sistemas para Internet

Engenharia de Software
Requisitos

Prof. Aldo Moura

aldo.moura@p.ficr.edu.br
 Entender a importância da etapa
de requisitos para o sucesso de
um projeto de software.

Objetivo da Aula
• Requisitos de Sistema
• Tipos de Requisitos
• Requisitos em Metodologias Ágeis

Roteiro
1. Coisa necessária e indispensável.
2. Condição indispensável; exigência.

Requisito
São as descrições do que o sistema:
✓ Deve fazer
✓ Os serviços que oferece
✓ As restrições a seu funcionamento

Refletem a necessidade dos clientes para um sistema que

serve a uma finalidade determinada, como:
✓ Controlar um dispositivo
✓ Colocar um pedido
✓ Encontrar informações
(Sommerville, 2011)

Requisito de Sistema de Software

Requisito de Usuário
Declarações, em uma linguagem natural com diagramas, de quais serviços o
sistema deve fornecer a seus usuários e as restrições com as quais este deve
operar.

Nível de Detalhamento
Requisito de Sistema
Descrições mais detalhadas das
funções, serviços e restrições
operacionais do sistema de
software.

Nível de Detalhamento
Dificuldade para Levantamento de Requisitos
Dificuldade para Levantamento de Requisitos
• Funcionais:
Descrevem os serviços que o sistema deve fornecer, como o sistema
deve reagir a entradas específicas e como o sistema deve ser comportar
em determinadas situações.

• Não Funcionais:
Descrevem as especificações técnicas de como melhor adequar o sistema
para atender às expectativas do cliente. Envolve:
• Limitações no produto: Como interface de usuário, confiabilidade,
desempenho, disponibilidade e segurança
• Limitações no processo de desenvolvimento: Como custo, tempo,
metodologia de desenvolvimento, componentes a serem utilizados e
padrões a serem aderidos.

Tipos de Requisitos
RF003: Manter exame: O sistema deverá permitir que o gerente realize a inclusão, consultar, alteração
e exclusão de exame. Cada exame é classificado por um tipo de exame. Os exames do tipo
“Verificação” precisa ter registrado a duração necessária, em minutos, para a realização do
exame.

RF007: Gerar agenda de consulta: O sistema deverá gerar a agenda de consulta de cada médico,
levando em consideração a disponibilidade do médico [RF006], a partir de um período
informado pelo gerente. Não deverá haver geração de agenda para as datas que estiverem
cadastradas como feriado. A agenda deverá prever consulta a cada 10 minutos e, quando for
permitido, prever as consultas de encaixe, na proporção de 1 consulta de encaixe para 1 hora
de serviço do médico. Todas as consultas geradas deverão ficar com o status de “Disponível”.

RF0014: Registrar confirmação de consulta: O sistema deverá permitir que a atendente registre a
chegada do paciente para ser atendido em uma consulta, alterando o status da consulta para
“Confirmada”. Para confirmação, a atendente informa o nome e a data de nascimento do
paciente e o sistema mostra a(s) consulta(s) agendadas para a data atual e a atendente
confirma a atendimento correspondente.

Requisitos Funcionais - Exemplos

RNF001: Hardware e Software: Para maior extensibilidade, reusabilidade e flexibilidade, deverá ser
adotado a linguagem de programação Java como linguagem principal, seguindo
cuidadosamente as técnicas de orientação a objetos. Outras linguagens também poderão ser
adotadas quando houverem recomendações técnicas. O uso da linguagem Java permite não
especificar qual será o sistema operacional e a máquina em que o programa irá executar. No
entanto, essa máquina deverá se comunicar com o SGBD MySQL.

RNF002: Prazo de entrega: O prazo de entrega da versão final do sistema não pode ultrapassar 6 (seis)
meses, devendo ser entregue em até 30 (trinta) dias antes do prazo de operação da clínica
(01/06/2020) para que os colaboradores possam ser treinados e o sistema alimentado com os
dados iniciais.

RNF003: Metodologia de desenvolvimento: O sistema deverá ser desenvolvido utilizando a

metodologia SCRUM para gerenciar o desenvolvimento do sistema, utilizado sprint de 15 dias.

RNF004: Disponibilidade: O sistema deverá ficar disponível 24x7 (24 horas 7 dias por semana).

Requisitos Não Funcionais - Exemplos

Por prioridades - exemplo:

• Essencial: Sistema não funciona sem ele

• Importante: Sistema funciona de forma não-satisfatória

• Desejável: Sistema funciona satisfatoriamente

Prioridade de Requisitos - Classificação

Em metodologias de desenvolvimento ágeis, normalmente utiliza-
se histórias do usuários para especificar os requisitos de um
sistema.

Requisitos Ágeis
As Histórias de Usuário comumente se baseiam no template:
COMO UM <USUARIO>
DESEJO <NECESSIDADE>
PARA QUE <OBJETIVO>.

Como um atendente desejo realizar um cadastro de aluno para

que possa ser realizado a sua matrícula.

História do Usuário
As histórias precisam ser criadas seguindo o conceito INVEST:
● Independent (Independente): pode ser implementada em qualquer ordem
● Negotiable (Negociável): pode ser removida a qualquer instante se
descobrir que não é útil
● Valuable (Valorosa): entregar valor
● Estimable (Estimável): capaz de ser estimada
● Small (Pequena): caber em uma Sprint
● Testable (Testável): possível de ser validada

História do Usuário
Lista de itens para verificar se a
história do usuário foi
implementada de acordo com o
que o PO queria e se atende aos
requisitos do usuário.

Serve de base para que equipe

escreva os testes de aceitação.

Critérios de Aceitação da Histórias do Usuário