Eel873 Requisitos

10/09/2018
EEL873
Engenharia de Software
ENGENHARIA DE REQUISITOS E CASOS DE USO

Guilherme H. Travassos
Programa de Engenharia de Sistemas e Computação
ght@cos.ufrj.br
http://www.cos.ufrj.br/~ght
Material evoluído dos originais preparados por Tayana Uchoa Conte e Talita Vieira Ribeiro para edições
anteriores deste curso
1
10/09/2018
Introdução
• Causas de falhas em projetos:
Fatores %
1. Requisitos incompletos 13,1
2. Falta de envolvimento dos usuários 12,4
3. Falta de recursos 10,6
4. Expectativas irreais 9,9
5. Falta de apoio executivo 9,3
6. Mudança nos requisitos 8,7
7. Falta de planejamento 8,1
8. Sistema não mais necessário 7,5
Mas o que é um Requisito?

• Para o IEEE Software Engineering Standards (1987):
– (1) Uma condição ou capacidade necessária para um usuário resolver um
problema ou alcançar um objetivo
– (2) Uma condição ou uma capacidade que deve ser alcançada ou estar
presente num sistema para satisfazer um contrato, padrão, especificação ou
outro documento formalmente imposto...
• Um requisito é uma característica do sistema ou a descrição de algo que o sistema

é capaz de realizar, para atingir os seus objetivos (Pfleeger, 2004)
• Um requisito é descrito como uma propriedade que o software deve exibir para
resolver algum problema no mundo real (SWEBOK, 2004)
• Requisitos de um sistema são descrições dos serviços que devem ser fornecidos
por esse sistema e as suas restrições operacionais. (Sommerville, 2007)
2
10/09/2018
Classificação de Requisitos
• Existem diferentes variações de classificação de requisitos,
porém uma classificação amplamente aceita divide os
requisitos em...
Funcionais Não
Funcionais
– Estão diretamente ligados às
funcionalidades do produto, ou seja, Funcionais
descrevem as funções que o Não
produto deve desempenhar. Funcionais
– Um requisito funcional descreve uma interação entre o
sistema e o seu ambiente (PFLEEGER, 2004), podendo
descrever, ainda, como o sistema deve reagir a entradas
específicas, como o sistema deve se comportar em
situações específicas e o que o sistema não deve fazer
(SOMMERVILLE, 2007).
3
10/09/2018
– Exemplos:
• "O sistema deve disponibilizar Funcionais Não
para os funcionários CLT um
formulário para solicitação de
Funcionais
férias"
• "O sistema deve permitir que os pacientes
remarquem suas consultas"
• "O sistema deve fornecer semanalmente aos
interessados um relatório de acompanhamento
dos processos de indenização (via email)"
– Exemplos:
Funcionais Não • "As consultas devem ser
realizadas usando o protocolo
Funcionais HTTPS"
• "As consultas on-line devem ser
respondidas em no máximo 3
segundos"
• "As senhas dos usuários devem
ser armazenadas criptografadas"
4
10/09/2018
Perspectivas para Explicitação dos

Requisitos
• Durante o processo de desenvolvimento de um sistema,
existem diversos interessados (stakeholders) nos requisitos:
Usuário
Gerente
Analista
Desenvolvedora
Cliente
e cada um deles tem expectativas diferentes.
Perspectivas
para
Explicitação
dos
Requisitos
5
10/09/2018
Como Escrever Requisitos?

• O sistema [não] deve + [verbo + objeto | frase verbal] +
[agente] + [condições]
• Como + [agente] + eu quero + [verbo + objeto | frase

verbal] + [condições] + para + [objetivo pretendido com
a ação]
Verbo é um verbo simples que expressa a funcionalidade daquele requisito. Dependendo do
tipo do verbo, objeto pode ser um objeto direto ou um objeto direto seguido de um objeto
indireto.
Frase verbal é uma frase que expressa a funcionalidade do requisito.
Agente é a identificação de um agente relacionado com o requisito. Esse complemento pode
ser descrito por um objeto indireto. Agente pode ser uma pessoa, uma instituição, um grupo ou
um dispositivo físico externo ao software.
Condições são sentenças que estabelecem situações específicas nas quais o requisito é válido.
Como Escrever Requisitos?

• Exemplos:
 O sistema deve emitir o documento de cobrança para o cliente no
último dia útil do mês.
 O sistema deve possibilitar que o usuário realize a inscrição no
processo seletivo dos cursos oferecidos.
 O sistema deve possibilitar o cadastramento de clientes.
 O sistema deve alterar o estado do DVD de disponível para
emprestado, quando o DVD for alugado.
 O sistema deve registrar a data e hora nas operações de empréstimo e
retorno de livros.
 O sistema deve solicitar, obrigatoriamente, CPF, nome e endereço do
cliente ao realizar o cadastramento.
6
10/09/2018
Engenharia de Requisitos
• Na Engenharia de Software, existe uma área que cuida
somente de requisitos chamada de Engenharia de
Requisitos.
• Pressupõe a adoção de métodos e técnicas para a
obtenção de requisitos do sistema.
• Objetiva:
• Entender o que o cliente deseja
• Avaliar a viabilidade
• Negociar condições razoáveis
• Especificar os requisitos do software com qualidade
• Gerenciar requisitos
• Processo de Engenharia de Requisitos: (adaptado de KOTONYA e
SOMMERVILLE, 1998):
7
10/09/2018
Engenharia de Requisitos –
Elicitação (Levantamento)
SOMMERVILLE, 1998):
LEVANTAMENTO
 Meta: descobrir tanto o conhecimento
explícito quanto o tácito que sejam
importantes para o entendimento do
problema e a proposta da solução.
• Envolve atividades que se preocupam em
definir quais são as fontes de informação
(incluindo os stakeholders) para obtenção
dos requisitos e como estes podem ser
obtidos.
• Também é nesta fase que os canais de
comunicação e o relacionamento dos
desenvolvedores com os stakeholders são
estabelecidos.
8
10/09/2018
• Durante o levantamento de requisitos, devem ser
considerados (KOTONYA & SOMMERVILLE, 1998):
– Entendimento do domínio da aplicação
– Entendimento do problema
– Entendimento do negócio
– Entendimento das necessidades e das restrições dos
interessados
• Técnicas para o levantamento dos requisitos:
• Entrevistas;
• Questionários;
• Observação;
• Análise de Documentos
• Cenários
• Brainstorm
• Prototipação
9
10/09/2018
• Entrevistas:
– Tipos:
• Estruturadas (ou fechadas)
• Não estruturadas (ou abertas)
• Semi-estruturadas
• Questionários:
– Contato indireto
• Observação:
– Acompanhamento no ambiente real do domínio
do problema: pretende-se observar as pessoas na
sua rotina de trabalho, sem interferência direta.
10
10/09/2018
• Análise de Documentos:
– Investigação da estrutura e fluxo das informações
e procedimentos da organização
• Cenários:
– Simulações de possíveis situações reais
11
10/09/2018
• Brainstorming:
– Reunião para definição do problema e proposta
de solução:
• Liberdade para expressão
de opinião
• Não há críticas prévias
• São válidas as observações
por impulso
• Prototipação:
– Auxilia na comunicação e validação do
entendimento dos requisitos
12
10/09/2018
• Qual técnica escolher?
– Análise as possibilidades e restrições do projeto:
• Tempo disponível dos stakeholders
• Tempo para execução do projeto
• Acesso aos usuários, ambiente de trabalho e aos
documentos
Documento de Requisitos
• Lembrar do 5W1H!
1. Why: porque é assim ? (justificativa)
2. What: o que é isso ? (conceitos)
3. Where: onde é feito ? (local)
4. When: quando é feito ? (tempo, pré-condições, eventos)
5. Who: por quem é feito ? (responsabilidade)
6. How: como é feito (método, técnica ou ferramenta)
13
10/09/2018
"A cafeteira deve ser feita de aço"
• "Por que a cafeteria deve ser feita de aço ?"

• "Qual a razão para ser feita com esse material ?"
• "Existe uma explicação para isso ?"
A ideia é tentar fazer o usuário verbalizar o que há por trás dessa demanda.
"Porque se for de vidro ela quebra"
• Qual o requisito real aqui ?
14
10/09/2018
"A cafeteira deve ser feita de material inquebrável"
• Pode ser: plástico, aço, etc.
"A cafeteira deve ser feita de material inquebrável"
• Pode ser: plástico, aço, etc. Requisito ou

necessidade
Possíveis
soluções
15
10/09/2018
SOMMERVILLE, 1998):
ANÁLISE e
NEGOCIAÇÃO
Engenharia de Requisitos – Análise

 Meta: prover visão funcional, comportamental e informacional;
detectar problemas, incompletudes, omissões e redundâncias nos
requisitos.
• Nessa fase também são desenvolvidos

modelos conceituais que ajudam a
entender o problema
• Por quê?
Representação
Organização
Armazenamento
Comunicação
16
10/09/2018
Engenharia de Requisitos – Análise

• Técnicas para a análise dos requisitos:
• DFD – Diagrama de Fluxo de Dados
• Tabelas de Decisão
• Máquinas de Estado (StateChart)
• SADT
• Modelo Entidade-Relacionamento
• Diagramas UML: Casos de Uso (descrição e diagrama), Diagrama
de Atividade, Classes...
Engenharia de
Requisitos – Diagrama
de Casos de
Análise Uso
DFD
Diagrama de Estados
17
10/09/2018
Engenharia de
Requisitos –
Análise
Diagrama de Entidade-
Relacionamento
Diagrama de Classes
Negociação
 Meta: resolver conflitos de interesses entre stakeholders; priorizar e
identificar os riscos dos requisitos; eliminar, combinar ou modificar os
requisitos; chegar a um consenso sobre a lista final de requisitos
priorizada.
– É comum o cliente pedir:

– Mais do que possa ser conseguido por desconhecer de software
Conflitos comuns (entre clientes):

• Requisitos contraditórios;
• Prioridades;
Conflitos comuns (clientes-equipe de
desenvolvimento):
• Prazo;
• Custo
18
10/09/2018
SOMMERVILLE, 1998):
DOCUMENTAÇÃO
Especificação (Documentação)
 Meta: detalhar e documentar os requisitos.
• Facilita a comunicação dos requisitos
• Reduz trabalho resultante de erros
• Fornece uma base realística para estimativas, verificação e
validação
• Serve como manual para futuros usuários
• É útil para futuras manutenções ou incremento de funcionalidades
Documento de
Especificação de Requisitos
19
10/09/2018
SOMMERVILLE, 1998):
AVALIAÇÃO
Avaliação
• Nesta fase, o documento de requisitos é alvo de verificações
com o objetivo de assegurar que os requisitos são
compreensíveis, consistentes e completos.
• Nesta mesma fase, o documento de requisitos é alvo de

validações, com o objetivo de assegurar que o desenvolvedor
entendeu os requisitos, ou seja, o documento de requisitos
reflete as necessidades dos stakeholders.
20
10/09/2018
Avaliação
• Verificação:
– Os requisitos foram especificados de maneira correta e
consistente?
• Validação:
– Os requisitos corretos foram especificados?
Avaliação
• Técnicas para a avaliação dos requisitos:
• Revisão ad-hoc;
• Técnicas de Inspeção;
• Checklists;
• Prototipação (validação)
21
10/09/2018
SOMMERVILLE, 1998):
GERÊNCIA: Controle de Mudança e Rastreabilidade
Engenharia de Requisitos – Controle

de Mudança
• Define os procedimentos, processos e padrões que devem ser
utilizados para gerenciar as alterações de requisitos,
assegurando que qualquer proposta de mudança seja
analisada conforme os critérios estabelecidos pela
organização.
• Envolve a análise do impacto da mudança e a sua estimativa

de custo.
22
10/09/2018
Rastreabilidade
• É o conceito que define uma rede de ligações, de forma que
um requisito possa estar associado a outros requisitos, a
outros elementos do software ou, até mesmo, a elementos
do processo de desenvolvimento.
• Através da rastreabilidade é possível avaliar como uma

mudança impacta no software.
• Importância da Especificação de Requisitos
– Após a elicitação de requisitos, é essencial especificá-
los
– Ao modelar os requisitos de um sistema, estes ficam
registrados:
• Podem ser consultados por qualquer pessoa da equipe;
• O registro não “apaga” com o tempo – como a memória
• O usuário pode validá-los
23
10/09/2018
• Requisitos:
– Funcionais
– Não funcionais
• Portabilidade, eficiência de execução, tolerância a falha,
confiabilidade, ...
• Para detalhar a especificação dos requisitos é
possível utilizar várias técnicas:
– Uma técnica comumente adotada é a modelagem de
Casos de Uso (Use Cases)
Funcionais
• Razões para utilizar Casos de Uso [Lima 2005] :
– O modelo de Casos de Uso é de fácil compreensão pelo
cliente
• Um caso de uso bem escrito é fácil de ler
• O modelo pode ser a base de discussão entre as partes
interessadas e um meio para acompanhar o progresso dos
trabalhos
– O foco do caso de uso é o problema e não a solução
informatizada
– A finalidade dos casos de uso é somente registrar o que
de fato o sistema deve fazer
24
10/09/2018
Elementos do Modelo de Casos de

Uso
• Atores
– Ator: representa o papel executado por uma entidade que
interage com o sistema em questão
– Um ator modela algo fora da fronteira do sistema que precise
trocar informações com o sistema, tais como usuários, outros
sistemas, dispositivos, coisas, dentre outros
– Uma instância da entidade pode executar o papel de vários
atores diferentes e um determinado ator pode ser
representado por várias instâncias da entidade
Ator
• Representação gráfica
– Ator: o ícone estereótipo padrão para um ator é a figura
de um “stick man”, contendo seu nome abaixo da figura
– Outra representação consiste num retângulo de classe,
com o estereótipo <<actor>>
25
10/09/2018
Ator
• Lembre: Ator não é o mesmo que usuário!
– Um ator representa um papel exercido por uma
entidade do ambiente que interage com um
determinado caso de uso
– Uma mesma entidade (incluindo usuários) pode
desempenhar mais de um papel junto ao sistema
Ator
• Tipos de Atores [Lima 2005]
– Ator primário – acessa o sistema para obter
diretamente um serviço
• Exemplo: balconista que acessa o sistema em nome do
cliente
– Ator secundário (ou Ator de suporte) - provê um
serviço ao sistema, mas não diretamente
• Exemplos: uma impressora, um serviço web
• Atores secundários são úteis para identificar o que o sistema
deverá prover em termos de formatos de dados e interfaces
externas, etc.
26
10/09/2018
Ator
• Categorias comuns para Atores [Lima 2005]:
– Usuários: usuários finais-alvo, administradores, gerentes;
– Aplicações (processos individuais e sistemas de software);
– Dispositivos (atuadores e sensores);
– Eventos externos (como um controlador de tempo – “Cron”)
Ator
• Relacionamentos entre Atores
– O relacionamento padrão entre os atores é a
Generalização
• É considerado quando temos dois atores semelhantes, mas
com um deles realizando algo a mais ou apresentando
características de importância para o sistema
27
10/09/2018
Ator
• Exemplo de Generalização de Atores [Lima 2005]
Elementos do Modelo de Casos de

Uso
• Caso de Uso (Use Case):
– Representa um conjunto de sequências de ações, cada uma
indicando a interação das entidades externas (atores) com o
sistema e vice-versa (diálogo ator-sistema)
– Cada caso de uso trata (captura) um ou mais requisitos
funcionais do sistema
– O caso de uso captura uma funcionalidade/facilidade que
deve ser oferecida pelo sistema
– Fornece a visão externa do sistema – importante para o
stakeholder validar!
• Descreve O QUÊ o sistema faz, mas não especifica COMO é feito
28
10/09/2018
Casos de Uso
• Representação gráfica
– Caso de Uso: seu ícone é uma elipse contendo seu
nome. O nome também pode vir abaixo da elipse
Calcular pagamento
dos funcionários
Gerenciar Contas a
Pagar
Diagramas de Casos de Uso
• Objetivo
– São utilizados para expressar a fronteira do sistema e/ou
modelar os requisitos do mesmo
– Mostram a visão estática do caso de uso
• A visão dinâmica do caso de uso é especificada através da
descrição dos cenários
– Por serem representações gráficas, diagramas de caso de
uso permitem uma visão geral dos relacionamentos entre
casos de uso e atores de um sistema
– Podem conter também notas, restrições e pacotes
29
10/09/2018

• Relacionamento entre atores e casos de uso -
Associação
– A associação representa a existência de interação entre o ator
e o caso de uso, por meio de envio e recebimento de
mensagens
– Associações são representadas por uma linha sólida, ligando o
ator ao caso de uso
– Se o ator inicia um caso de uso, o caso de uso pode se
comunicar com vários atores depois
• As associações servem para mostrar quais atores se comunicam com o
caso de uso em questão

• Relacionamento entre atores e casos de uso -
Associação
Matricular
aluno
Secretaria Aluno
30
10/09/2018
Características da Associação entre

Atores e Casos de Uso
• Multiplicidade:
– A multiplicidade da associação mostra quantas instâncias de
um ator podem se comunicar com uma instância de caso de
uso simultaneamente
– A multiplicidade é representada por uma expressão de texto
no diagrama:
• Um único inteiro
• Uma lista separada por vírgulas de uma faixa inteira (ex.: 0:1)
• * - indica 0 ou mais
Características da Associação entre

Atores e Casos de Uso
• Direção:
– Cada papel de uma associação tem uma propriedade de
navegabilidade, que indica quem inicia a comunicação na
interação
– A direção é representada no diagrama por uma seta:
• Se a seta apontar para um caso de uso – o ator inicia a interação
• Se a seta apontar para o ator – o sistema inicia a interação
– A navegabilidade de duas direções é mostrada por uma linha
sem setas
• Também é possível usar setas bidirecionais
31
10/09/2018
Associação entre Atores e Casos de

Uso
• Exemplo de Associação com Multiplicidade e
Direção:

• Representação da fronteira do sistema
– O diagrama de casos de uso pode ainda mostrar a
fronteira do sistema que é representada com um
retângulo envolvendo os casos de uso
• Os atores ficam externos ao retângulo
32
10/09/2018

• Exemplo de diagrama de caso de uso com representação da
fronteira do sistema [Bezerra, 2002]:
Sistema de Vendas de
Livros por Correio
Vendedor
Realizar Pedido
Cliente
Empresa Transportadora
Casos de Uso
• Modelando com Casos de Uso:
– Separe as funcionalidades do sistema
– Cada funcionalidade deve corresponder a um conjunto de
ações que tenham um objetivo bem definido – o caso de uso
– Cenário: é uma sequência específica de ações que ilustra um

comportamento do caso de uso
• Geralmente um caso de uso tem várias maneiras de ser realizado
• O cenário é a descrição de uma dessas maneiras (instância de um caso
de uso)
33
10/09/2018
Casos de Uso
• Descrevendo Cenários [Bezerra 2002]
– Fluxo principal – descreve uma sequência de ações que será
executada considerando que nada de errado acontecerá durante
sua execução
• Descreve o que normalmente acontece quando o caso de uso é realizado
(modo normal e correto de operação)
– Fluxos Alternativos – descrevem o que acontece quando o ator

faz uma escolha alternativa, diferente da descrita no fluxo
principal, para alcançar seu objetivo
• Podem descrever escolhas exclusivas entre si
– Fluxos de Exceção – correspondem à descrição das situações de

exceção
• Descrevem o que acontece quando algo inesperado ocorre na interação
entre o ator e o caso de uso (ex.: ator realiza ação inválida)
Casos de Uso
• Descrevendo Cenários [Bezerra 2002]
– Pré-condição – define as condições que devem ser obedecidas
(satisfeitas) para que o caso de uso tenha início
• Deve ser usada em casos de uso cuja realização não faz sentido em
qualquer momento, mas somente quando o sistema está em um
determinado estado com certas propriedades estabelecidas
• Ex.: O gerente deve estar habilitado no sistema
– Pós-condição – estado que o sistema alcança (e deve ser

garantido) após o caso de uso ter sido realizado
• Não precisa declarar como esse estado foi alcançado
• Ex.: A atualização do Registro do Funcionário foi realizada
34
10/09/2018
Casos de Uso
• Representações para Casos de Uso:
– Descrições textuais contínuas
– Descrições formais (com pré e pós-condições, fluxo principal,
alternativos e de exceção)
– Tabelas Ator x Sistema
• ATENÇÃO!
– Não descrever casos de uso como algoritmos: casos de uso
definem o quê e não como.
– Não definir ou referenciar os elementos/componentes da
interface Humano-Computador no diálogo.
Casos de Uso
• Exemplo de descrição textual contínua:
• O Cliente chega ao caixa eletrônico e insere seu cartão. O

Sistema requisita a senha do Cliente. Após o Cliente
fornecer sua senha e esta ser validada, o Sistema exibe as
opções de operações possíveis. O Cliente opta por
realizar um saque. Então o Sistema requisita o total a ser
sacado. O Sistema fornece a quantia desejada e imprime
o recibo para o Cliente.
35
10/09/2018
Casos de Uso
• Exemplo de descrição de fluxo principal:
1. Cliente insere seu cartão no caixa eletrônico.

2. Sistema apresenta solicitação de senha.
3. Cliente digita senha.
4. Sistema exibe menu de operações disponíveis.
5. Cliente indica que deseja realizar um saque.
6. Sistema requisita quantia a ser sacada.
7. Cliente retira a quantia e recibo.
Casos de Uso
• Exemplo de Tabela Ator x Sistema:
Cliente Sistema
Insere seu cartão no caixa eletrônico.
Apresenta solicitação de senha.
Digita senha.
Exibe operações disponíveis.
Solicita realização de saque.
Requisita quantia a ser sacada.
Retira a quantia e o recibo.
36
10/09/2018
Template para descrição de Casos de

Uso
1. Descrição – sumário da funcionalidade do caso de uso
2. Atores – tabela com os atores que interagem com o caso de uso
3. Pré-condições - condições pertinentes que devem valer antes da
realização do caso de uso
4. Fluxos
1. Básico (principal) - apresenta a descrição para o evento que dispara o caso de
uso, e a descrição para os demais eventos que compõem o fluxo básico
(principal, ou “normal”)
2. Fluxos Alternativos (opcional) - descrevem os eventos que compõem os fluxos
alternativos de execução.
3. Fluxos de Exceção (opcional) - descrevem os eventos que compõem os fluxos
de exceção do caso de uso.
5. Pós-condições - descrevem as condições pertinentes que devem valer
após a realização do caso de uso.
6. Regras de Negócio (opcional) - listam as regras de negócio
implementadas no caso de uso.
Exemplo de Caso descrito conforme

template [Bezerra, 2002]
• Caso de Uso “Realizar Inscrição” (1)

– Descrição: Aluno realiza inscrição em disciplinas
– Atores:
• Aluno
• Sistema de Faturamento
– Precondições: o aluno está identificado pelo sistema
37
10/09/2018

– Fluxo Principal:
1. O Aluno solicita a realização de inscrição
2. O sistema apresenta as disciplinas disponíveis para o semestre
corrente e para as quais o aluno tem pré-requisitos
3. O Aluno seleciona as disciplinas desejadas e as submete para inscrição
4. Para cada disciplina selecionada, o sistema aloca o aluno em uma
turma que apresente uma oferta para tal disciplina. O sistema informa
as turmas nas quais o Aluno foi alocado.
5. O aluno confere as informações recebidas
6. O sistema envia os dados sobre a inscrição do aluno para o Sistema de
faturamento e o caso de uso termina.

– Fluxo Alternativo (4): Inclusão em lista de espera
a. Se não há oferta disponível para alguma disciplina selecionada pelo
aluno, o sistema reporta o fato e fornece a possibilidade de inserir o
aluno em uma lista de espera.
b. Se o Aluno aceitar, o sistema o insere na lista de espera e apresenta a
posição na qual o aluno foi inserido na lista. O caso de uso retorna ao
passo 4.
c. Se o Aluno não aceitar, o caso de uso prossegue no passo 4.
– Fluxo de Exceção (3): Aluno sem inscrição
a. Se o Aluno atingiu a quantidade máxima de inscrições (RN01), o sistema
informa ao aluno a quantidade de disciplinas que ele pode selecionar, e o
caso de uso retorna ao passo 2.
– Pós-condições: o Aluno foi inscrito em uma das turmas de cada uma
das disciplinas desejadas, ou foi adicionado a uma ou mais listas de
espera.
38
10/09/2018
Casos de Uso
• Especificação de Casos de Uso
– Todo caso de uso deve possuir um nome que o
diferencie dos demais (único no seu escopo)
– Os atores que interagem com o caso de uso devem
ser listados
– Os cenários devem incluir como e quando o caso de
uso inicia e termina
• A apresentação do fluxo principal é obrigatória
• Fluxos alternativos e de exceção devem ser descritos caso
existam
Casos de Uso
• Caso de Uso: Reserva em Restaurante
– Ator: Atendimento ao Cliente
– Fluxo principal:
1. O cliente informa ao atendente a data da reserva, que é
repassada ao sistema.
2. O sistema mostra o mapa do salão do restaurante, indicando as
mesas já reservadas e as que estão livres. O sistema calcula e
exibe o número de reservas disponíveis.
3. Um ou vários lugares disponíveis são escolhidos.
4. O sistema solicita o CPF do cliente, p/ identificação do mesmo
no sistema. O sistema pesquisa o cliente e mostra nome e
telefone para confirmação
5. Após confirmação, a reserva é efetuada para o cliente
39
10/09/2018
Casos de Uso
• Fluxos Alternativo e de Exceção para Reserva
Restaurante
– Alternativa: Reservas esgotadas
• 2a) O sistema verifica se para o dia informado as
reservas estão esgotadas. O sistema deve possibilitar
que seja informada nova data ou que se encerre a
solicitação de reserva
– Exceção: Cliente não cadastrado
• 4e) Se o cliente não for cadastrado: Extend Cadastrar
Cliente de Reserva

• Relacionamento entre casos de uso – Extensão
<<extend>>
– Um relacionamento de extensão entre casos de uso indica
que um deles terá seu procedimento acrescido, em um
ponto de extensão, de outro caso de uso, identificado
como base
• Um ponto de extensão é uma referência a um local dentro do caso
de uso no qual podem ser inseridas ações de outros casos de uso
– É usado quando se tem um caso de uso que é similar a
outro, mas faz alguma coisa a mais
40
10/09/2018

• Usos do relacionamento de Extensão
– Expressar rotinas de exceção ou para expressar o
desmembramento de um caso de uso
• Quando um fluxo alternativo possui um grande conjunto de eventos
ou que mereça uma atenção especial
– Separar um comportamento obrigatório de outro opcional
– Separar um trecho do caso de uso que será utilizado apenas
em determinadas condições
– Separar trechos que dependam da interação com
determinado ator

• Representação gráfica do relacionamento de
Extensão
– É representado graficamente por uma seta
tracejada com a ponta aberta, que parte do caso de
uso estendido e contém o estereótipo <<extend>>
• A condição do relacionamento pode ser apresentada
opcionalmente perto da palavra-chave <<extend>>
41
10/09/2018

• Representação gráfica do relacionamento de
Extensão
Fazer
ligação
Usuário Celular
Fazer
ligação em
conferência

• Exemplo de relacionamento de Extensão [Bezerra, 2002]:
«estende» Substituir Texto
Editar Documento
«estende»
Escritor
Corrigir Ortografia
42
10/09/2018

• Relacionamento entre casos de uso – Inclusão
<<include>> (ou <<uses>>)
– Indica que um caso de uso terá seu procedimento inserido
num local especificado no outro caso de uso, identificado
como base
– Ocorre quando há uma porção de comportamento que é
similar ao longo de um ou mais casos de uso e não se deseja
repetir a sua descrição
– Ou seja, quando existem cenários cujas ações servem a mais
de um caso de uso

• Representação gráfica do relacionamento de Inclusão
– É representado graficamente por uma seta tracejada com a
ponta aberta, que parte do caso de uso base e contém o
estereótipo <<include>>
Fazer
pedido
Validar
Localizar cliente
pedido
43
10/09/2018

• Exemplo de relacionamento de Inclusão [Bezerra, 2002]:
Obter Extrato
«inclui»
«inclui»
Fornecer
Realizar Saque
Identificação
«inclui»
Cliente
Realizar
Transferência

• Modelando requisitos com casos de uso
– Inicia-se a modelagem com a descoberta dos atores ou dos casos
de uso do sistema
– A partir dos atores, examinam-se suas necessidades para
determinar os casos de uso
– Ou a partir dos casos de uso, determina-se quem deve interagir
com os mesmos para chegar aos atores
– Para cada caso de uso, deve-se descrever os cenários principais e
os alternativos relevantes
44
10/09/2018

• Modelando requisitos com casos de uso - continuação
– É durante a descrição de cenários principais e alternativos que são
percebidos:
• As exceções extensas ou muito importantes que geram os casos de uso de
extensão (variações do curso normal)
• Os fluxos comuns a vários casos de uso que geram os casos de uso de
inclusão
– A descrição dos cenários deve ser complementada com a visão
geral proporcionada pelo diagrama de casos de uso

• Identificando atores:
– Fontes e os destinos das informações a serem
processadas são atores em potencial.
• uma vez que um ator é todo elemento externo que
interage com o sistema.
– O analista deve identificar:
• as áreas da empresa que serão afetadas ou utilizarão o
sistema.
• fontes de informações a serem processadas e os destinos
das informações geradas pelo sistema
45
10/09/2018
• Identificando atores – Perguntas úteis [Bezerra, 2002]:

– Que órgãos, empresas ou pessoas irão utilizar o sistema?
– Que outros sistemas irão se comunicar com o sistema a ser
construído?
– Alguém deve ser informado de alguma ocorrência no sistema?
– Quem está interessado em um certo requisito funcional do
sistema?
Identificando casos de uso [Falbo, 2003]
• Ponto de partida: objetivos do usuário.

• Um bom caso de uso compreende uma
sequência de ações que produz um resultado
identificável útil para um ator.
Importante para não se obter casos de

uso grandes demais.
Importante para não se obter casos de uso pequenos demais.

Cuidado: um caso de uso não deve ser apenas um passo de um processo.
46
10/09/2018
Modelando casos de uso [Falbo, 2003]
• Várias ações descritas em um único caso de

uso.
Incluir Novo Cliente
X Alterar Dados Cliente
Cadastrar Cliente
Funcionário
Funcionário
Consultar Cliente
Excluir Cliente
Exemplo: Locadora de Vídeo

[Falbo, 2003]
Efetuar Reserva
Cadastrar Classe
<<inclui>>
Efetuar Devolução
<<inclui>>
Efetuar Pagamento
Cadastrar Fita Funcionário
Efetuar Locação
Cadastrar Distribuidor
Cadastrar Título Cadastrar Cliente Consultar Título Cliente
47
10/09/2018
Identificação de Subsistemas [Falbo,

2003]
• Objetivos:
– Definir uma representação concisa capaz de orientar a leitura
de um modelo complexo.
– Útil para a organização de grupos de trabalho em projetos
extensos.
• Base: complexidade do problema
• Bom critério para organização da documentação
• UML: diagrama de pacotes
Exemplo: Locadora de Vídeo

[Falbo, 2003]
Atendimento Controle
Cliente Acervo
48
10/09/2018
Controle de Acervo [Falbo, 2003]
Cadastrar Título
Cadastrar Fita
Funcionário
Cadastrar Classe
Cadastrar Distribuidor
Atendimento a Cliente [Falbo, 2003]
Cadastrar Cliente Consultar Cliente

Título
Efetuar Reserva
Funcionário <<inclui>>
Efetuar Locação
<<inclui>> Efetuar
Pagamento
Efetuar Devolução
49
10/09/2018

• Tipos de Casos de Uso:
– Primário: representa os objetivos dos atores
– Secundário: aquele que não traz benefício direto
para os atores, mas que é necessário para que o
sistema funcione adequadamente
• Manutenção de usuários
• Manutenção de informações provenientes de outros
sistemas
Documentação associada aos

Casos de Uso
• Documentação de Requisitos
– O modelo de casos de uso força o desenvolvedor a pensar
em como os agentes externos interagem como o sistema
• No entanto, este modelo corresponde somente aos requisitos
funcionais.
– Outros tipos de requisitos (desempenho, interface,
segurança, regras do negócio, ...) também fazem parte do
documento de requisitos
50
10/09/2018

Casos de Uso
• Regras de Negócio
– São políticas, condições ou restrições que devem ser
consideradas na execução dos processos existentes em
uma organização
– Descrevem a maneira pela qual a organização funciona
– Estas regras devem ser identificadas e podem ser
documentadas no chamado modelo de regras do negócio
• Uma vez identificadas, devem ser referenciadas na especificação
de casos de uso

Casos de Uso
• Alguns exemplos de regras do negócio:
– O valor total de um pedido é igual à soma dos totais dos
itens do pedido acrescido de 10% de taxa de entrega
– Um professor só pode estar lecionando disciplinas para as
quais esteja habilitado
– Um cliente do banco não pode retirar mais de R$ 1.000
por dia de sua conta
– O valor da remuneração de férias é calculado da seguinte
forma: 1/3 * (Valor da remuneração contratual + valor do
acréscimo de férias)
51
10/09/2018

Casos de Uso
• Requisitos de Desempenho
– Pode haver uma conexão de casos de uso com requisitos de
desempenho [Bezerra, 2002]:
Identificador Freqüência Tempo ...

do caso de da utilização máximo
uso esperado
CSU01 5/mês Interativo …
CSU02 15/dia 1 segundo …
CSU03 60/dia Interativo …
CSU07 500/dia durante 10 segundos ...
10 dias
seguidos.

Casos de Uso
• Casos de Uso e outras atividades de desenvolvimento
– Planejamento e gerenciamento do projeto
• Uma ferramenta fundamental para o gerente de um projeto no
planejamento e controle de um processo de desenvolvimento
incremental e iterativo
– Testes do sistema
• Os casos de uso e seus cenários oferecem casos de teste.
– Documentação do usuário
• manuais e guias do usuário podem ser construídos com base nos
casos de uso
52
10/09/2018
Bibliografia
• BEZERRA, E. “Princípios de Análise e Projeto de Sistemas com
UML” Editora Campus, 2002.
• BOOCH, G. et al. “UML, guia do usuário” Campus, 2000.
• FALBO, R. “Modelagem de Objetos usando UML”. Mini-Curso XVII
SBES, Manaus, 2003.
• LIMA, A. S., “UML 2.0 Do Requisito à Solução”, Editora Érica, 2005.
• MELO, A. C. “Desenvolvendo aplicações com UML” Brasport, 2002.
• LARMAN, C. “Applying UML and Patterns” Prentice Hall, 1997.
53

Eel873 Requisitos

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Eel873 Requisitos

Enviado por

Direitos autorais:

10/09/2018

ENGENHARIA DE REQUISITOS E CASOS DE USO

Mas o que é um Requisito?

• Um requisito é uma característica do sistema ou a descrição de algo que o sistema

Perspectivas para Explicitação dos

e cada um deles tem expectativas diferentes.

Como Escrever Requisitos?

• Como + [agente] + eu quero + [verbo + objeto | frase

Como Escrever Requisitos?

• "Por que a cafeteria deve ser feita de aço ?"

• Qual o requisito real aqui ?

• Qual o requisito real aqui ?

"A cafeteira deve ser feita de material inquebrável"

• Pode ser: plástico, aço, etc.

• Qual o requisito real aqui ?

"A cafeteira deve ser feita de material inquebrável"

• Pode ser: plástico, aço, etc. Requisito ou

Engenharia de Requisitos – Análise

• Nessa fase também são desenvolvidos

Engenharia de Requisitos – Análise

– É comum o cliente pedir:

Conflitos comuns (entre clientes):

• Nesta mesma fase, o documento de requisitos é alvo de

GERÊNCIA: Controle de Mudança e Rastreabilidade

Engenharia de Requisitos – Controle

• Envolve a análise do impacto da mudança e a sua estimativa

• Através da rastreabilidade é possível avaliar como uma

Elementos do Modelo de Casos de

Elementos do Modelo de Casos de

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Características da Associação entre

Características da Associação entre

Associação entre Atores e Casos de

Diagramas de Casos de Uso

Diagramas de Casos de Uso

– Cenário: é uma sequência específica de ações que ilustra um

– Fluxos Alternativos – descrevem o que acontece quando o ator

– Fluxos de Exceção – correspondem à descrição das situações de

– Pós-condição – estado que o sistema alcança (e deve ser

• O Cliente chega ao caixa eletrônico e insere seu cartão. O

1. Cliente insere seu cartão no caixa eletrônico.

Retira a quantia e o recibo.

Template para descrição de Casos de

Exemplo de Caso descrito conforme

• Caso de Uso “Realizar Inscrição” (1)

Exemplo de Caso descrito conforme

Exemplo de Caso descrito conforme

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

«estende» Substituir Texto

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

Diagramas de Casos de Uso

• Identificando atores – Perguntas úteis [Bezerra, 2002]:

Identificando casos de uso [Falbo, 2003]

• Ponto de partida: objetivos do usuário.