ENGENHARIA DE

REQUISITOS

Professor: Amadeu Anderlin Neto

amadeu.neto@ifam.edu.br
 ESPECIFICAÇÃO DE REQUISITOS
 Processo
de escrever os requisitos de usuário e de sistema em
um documento de requisitos
 Informaçõescoletadas durante a atividade de elicitação e análise
são colocadas em um documento que define o conjunto de
requisitos
O documento de requisitos não deve se preocupar com a forma
como o sistema deve ser projetado ou implementado

2
 ESPECIFICAÇÃO DE REQUISITOS
 Idealmente,
requisitos de usuário e de sistema devem ser claros,
não-ambíguos, fáceis de entender, completos e consistentes
 Difícilde se conseguir, pois os stakeholders possuem visões
diferentes, causando conflitos e inconsistências
O documento de requisitos pode ser usado como parte do contrato
para a implementação do sistema e deve conter uma especificação
completa do sistema

3
 ALTERNATIVAS PARA ESPECIFICAÇÃO
 Documento de requisitos pode ser:
 Documento escrito (textos)
 Modelo gráfico (diagramas)
 Modelo matemático formal (autômatos)
 Cenários de casos de uso (em geral, para sistemas menores)

 Casos de uso são mais utilizados em métodos orientados a plano

 User stories são mais utilizadas nos métodos ágeis
 Protótipos de tela são sempre um bom complemento para as
especificações 4
 CASOS DE USO
 Descreve um conjunto particular de funcionalidades do
sistema
 Modelao diálogo que uma entidade externa (ator) realiza com o
sistema
 Quando combinados, os casos de uso constituem todas as formas
de uso do sistema
 Casosde uso fornecem uma visão do sistema focada na
funcionalidade
5
 CASOS DE USO
 Possibilitam um formato de apresentação compreensível que
pode ser utilizado para aprimorar a comunicação
 Especialmente entre projetistas e clientes

 Sãoúteis também para fases posteriores do ciclo de vida, ajudando

na identificação de objetos, desenvolvimento de planos de teste e
documentação

6
 CASOS DE USO
 Utilizado para representar as funcionalidades do sistema
 Representa o que o sistema faz e não como

7
 CASOS DE USO: ATORES
 Entidades do meio ambiente (externas ao sistema)
que interagem com o sistema para obter alguma
funcionalidade
 Podem ser: humanos, outros sistemas, organizações,
dispositivos externos, etc.
 Alguns atores dão início a eventos, enquanto outros
interagem com o sistema em decorrência do resultado
de outros eventos
8
CASOS DE USO

9
 EXEMPLO DE ATOR E CASO DE USO
 Cliente de um banco pode usar um caixa eletrônico para:
 Sacar ou transferir dinheiro
 Consultar o saldo da conta

 Ator?
 Cliente

 Casos de uso?
 Sacar dinheiro
 Transferir dinheiro
 Consultar saldo 10
CASOS DE USO

11
 PRINCIPAIS TIPOS DE RELACIONAMENTOS
 Associação

 Inclusão

 Extensão

 Generalização

 Representam as interações entre:

 Atores e casos de uso
 Dois ou mais casos de uso
12
 Dois ou mais atores
 ASSOCIAÇÃO
 Demonstra que o ator utiliza a função do sistema representada
pelo caso de uso
 Requisitando a execução da função
 Recebendo o resultado produzido pela função

 Representada por uma reta ligando o ator ao caso de uso

 Direcionada ou não

13
 INCLUSÃO
 Inclusão(<<include>>): o caso de uso base incorpora o
comportamento do caso de uso incluído
 Sempre que o caso de uso base for executado, o caso de uso
incluído também será
 Ou seja, indica obrigatoriedade: a execução do primeiro obriga a
execução do segundo
A direção do relacionamento é do caso de uso base para o caso de
uso incluído
 Representado por uma seta tracejada
14
 A seta aponta para o caso de uso incluído
 INCLUSÃO

 No exemplo:
 “Realizar venda” inclui “Verificar estoque”
 Ao “Realizar venda” sempre haverá a necessidade de verificar o
15

estoque para saber se o produto está disponível

 EXTENSÃO
 Extensão(<<extend>>): o caso de uso base incorpora o
comportamento de um outro caso de uso em local especificado
 Quandoo caso de uso base for executado, o caso de uso extensor
poderá ser executado também
É utilizado em funcionalidades opcionais
 Cenários que somente acontecerão em uma situação específica

 Pode ser usado para:

 Simplificar fluxos de eventos complexos
16

 Representar comportamentos opcionais

 EXTENSÃO

 No exemplo:
 “Comprar produto” estende “Realizar venda”
17
 Ao “Realizar venda”, caso não exista o produto em estoque (após
consultar no estoque) poderá ser solicitada a compra do produto
 GENERALIZAÇÃO
 Generalização/especialização (<<generalization>>): um caso de uso
generaliza outro(s)
 Permite modelar comportamento de estruturas de aplicação em
comum
 Acontece quando dois ou mais casos de uso possuem
características semelhantes
 Foco em reutilização

O caso de uso geral descreve as características compartilhadas

18

 As especializações definem as características específicas

 GENERALIZAÇÃO

 No exemplo:
 “Emitir pedido de compra” generaliza “Comprar produto”
 “Comprar produto” especifica como se realiza o pedido de compra no
setor de vendas, processo que ocorre em qualquer área do negócio 19
 Reaproveitamento do que já está pronto
RELACIONAMENTOS ENTRE CASOS DE USO

20
CASOS DE USO: EXEMPLO

21
 EXERCÍCIO
 Dados os requisitos funcionais abaixo, elabore o diagrama de casos de uso
para o sistema de controle acadêmico.

RF01 – O sistema deve permitir à secretaria cadastrar cursos.

RF02 – O sistema deve permitir à secretaria cadastrar disciplinas de cursos.
RF03 – O sistema deve permitir à secretaria cadastrar alunos.
RF04 – O sistema deve permitir ao departamento de recursos humanos (RH)
cadastrar professores.
RF05 – O sistema deve permitir à secretaria cadastrar turmas de disciplinas de
cursos.
RF06 – O sistema deve permitir aos coordenadores de curso alocar professores
a determinadas turmas.
RF07 – O sistema deve permitir à secretaria matricular alunos em turmas. 22
 ENGENHARIA DE
REQUISITOS

Professor: Amadeu Anderlin Neto

amadeu.neto@ifam.edu.br