LEVANTAMENTO DE REQUISITOS E
MODELAGEM DE USE CASES
QUEREMOS TRATAR LOGO DO LEVANTAMENTO DE
REQUISITOS DO ESTUDO DE CASO PARA QUE VOCÊ POSSA INICIAR SEU
PROJETO :-)
FAZER SOFTWARE DE QUALIDADE SIGNIFICA
FAZER O SOFTWARE CORRETO, NOS PRAZOS ESTABELECIDOS E COM
UM NÍVEL ACEITÁVEL DE DEFEITOS
A EXPERIÊNCIA MOSTRA QUE O MAIOR
PROBLEMA (FONTE DE FRACASSO) DE FAZER SOFTWARE É FAZER O SOFTWARE ERRADO!
LEVANTAR REQUISITOS É FAZER CORTES NO ESPAÇO DE SOLUÇÃO PARA DELIMITAR SOLUÇÕES ACEITÁVEIS
A QUALIDADE É MEDIDA PELA
SATISFAÇÃO DO CLIENTE: ENVOLVER O CLIENTE É A CHAVE PARA OBTER REQUISITOS
SÓLIDOS
MUITOS TIPOS DE REQUISITOS PODEM
SER LEVANTADOS
REQUISITOS
FUNCIONAIS SÃO OS MAIS
ÓBVIOS, MAS TEM TAMBÉM:
FACILIDADE DE USO
HARDWARE E AMBIENTE ALVOS PARA
O PRODUTO
QUALIDADE
DESEMPENHO
SEGURANÇA
COMPATIBILIDADE E NECESSIDADES
DE MIGRAÇÃO
INTERNACIONALIZAÇÃO
SUPORTE
PREÇO
DOCUMENTAÇÃO
US DE PADRÕES
ASPECTOS LEGAIS
INTEGRAÇÃO COM OUTROS
PRODUTOS
PACKAGING
RISCOS ACEITÁVEIS
SÓ FALAREMOS DO LEVANTAMENTO DE
REQUISITOS FUNCIONAIS AQUI
TÉCNICA BÁSICA: USE CASES (CASOS DE
USO, CENÁRIOS, ...)
MODELAGEM USE CASE: PROCESSO ITERATIVO ENVOLVENDO DISCUSSÕES
ENTRE TÉCNICOS E CLIENTES (OU USUÁRIOS FINAIS) PARA
LEVANTAR REQUISITOS
ELEMENTOS PRIMÁRIOS DA MODELAGEM USE
CASE
SISTEMA: O QUE ESTÁ INCLUÍDO SOB
RESPONSABILIDADE DO PROJETO. SÓ A FUNCIONALIDADE
INTERNA AO SISTEMA É CONSIDERADA
ATORES: ENTIDADES EXTERNAS AO SISTEMA COM
INTERESSE EM INTERAGIR COM O SISTEMA
USE CASES: UM
CONJUNTO DE AÇÕES QUE UM SISTEMA FAZ E QUE
PRODUZ UM RESULTADO OBSERVÁVEL IMPORTANTE PARA
UM ATOR INTERESSADO
VÁRIOS USE CASES
REPRESENTAM A FUNCIONALIDADE DO SISTEMA
O MOTIVO DE USAR USE CASES:
PARA DECIDIR E DESCREVER A FUNCIONALIDADE DE COMUM ACORDO COM O CLIENTE
SERVE COMO DOCUMENTO BÁSICO
DE REFERÊNCIA DURANTE TODO O PROCESSO SOBRE O QUE FOI
PROMETIDO
SERVE COMO BASE PARA ELABORAR TESTES FUNCIONAIS DO SISTEMA FINAL
PARA PODER RASTREAR REQUISITOS FUNCIONAIS DENTRO DOS
MODELOS DE ANÁLISE, PROJETO E IMPLEMENTAÇÃO
(SABEMOS QUE REQUISITOS CAUSARAM O APARECIMENTO
DE DETERMIANADAS SOLUÇÕES)
AS ETAPAS DE MODELAGEM USE CASE
DEFINIR O SISTEMA
ACHAR OS ATORES
ACHAR OS USE CASES
DESCREVER OS USE CASES
DEFINIR O RELACIONAMENTO ENTRE
USE CASES
VALIDAÇÃO DO MODELO
GARANTIR QUE O SISTEMA
É O QUE O USUÁRIO REALMENTE NECESSITA
OS INTERESSADOS NOS USE CASES
O CLIENTE E/OU
USUÁRIOS FINAIS
OS USE
CASES USAM A TERMINOLOGIA DO DOMÍNIO DO
PROBLEMA
DESENVOLVEDORES
INTEGRADORES E
TESTADORES
O PRODUTORES
DE DOCUMENTAÇÃO
MARKETING E
VENDAS
DIAGRAMAS USE CASE
UM MODELO USE
CASE PODE CONSISTIR DE VÁRIOS DIAGRAMAS USE CASE
(E OUTROS DIAGRAMAS)
ALÉM DO DIAGRAMA VISUAL, CADA
USE CASE DEVE SER DESCRITO (COM TEXTO)
MAIS SOBRE ATORES
ENTIDADE
EXTERNA QUE INTERAGE COM O SISTEMA
SÃO OS ATORES QUE
"FAZEM" OS USE CASES
PODE SER HUMANO OU OUTRO SISTEMA
UM ATOR É UMA CLASSE, NÃO UMA
INSTÂNCIA
REPRESENTA UM PAPEL, NÃO UM
USUÁRIO ESPECÍFICO
COMO ACHAR ATORES
ESTABELEÇA AS ENTIDADES
INTERESSADAS EM USAR O SISTEMA
FAÇA AS SEGUINTES PERGUNTAS SOBRE O SISTEMA:
QUEM VAI USAR A
FUNCIONALIDADE PRINCIPAL DO SISTEMA
(ATORES PRINCIPAIS)?
QUEM VAI PRECISAR DO
SUPORTE DO SISTEMA PARA DESEMPENHAR SUA
TAREFAS DO DIA-A-DIA?
QUEM DEVERÁ MANTER E
ADMINISTRAR O SISTEMA (ATORES
SECUNDÁRIOS)?
QUE DISPOSITIVOS DE
HARDWARE O SISTEMA PRECISA MANUSEAR (SÃO
ATORES TAMBÉM)
COM QUE OUTROS SISTEMAS
ESTE INTERAGE?
QUEM OU O QUE TEM
INTERESSE NOS RESULTADOS (VALORES
PRODUZIDOS) DO SISTEMA?
LEMBRE QUE NÃO SÃO APENAS
PESSOAS QUE SENTAM NA FRENTE DE UM TERMINAL (A
INTERAÇÃO PODE SER INDIRETA)
PARA TER CERTEZA QUE CADA ATOR
DESCOBERTO EXISTE DE FATO TENTE ACHAR UMA OU DUAS
INSTÂNCIAS PARA CADA ATOR (O ATOR É UM NOME
PARA UM PAPEL)
ATORES EM UML SÃO REPRESENTADOS POR UM STICKMAN:
RELACIONAMENTOS
ENTRE ATORES PODEM EXISTIR:
CARACTERÍSTICAS DE USE CASES
UM USE CASE SEMPRE É INICIADO A PARTIR DO
ESTÍMULO DE UM ATOR
PODE SER UM ESTÍMULO
DIRETO OU INDIRETO
O ATOR PODE ATÉ NEM
SABER QUE ELE CAUSOU O ESTÍMULO
MAS É O ATOR QUE INICIA
TUDO PORQUE É EM PROL DELE QUE OS USE
CASES OCORREM
UM USE CASE PROVÊ ALGUM VALOR TANGÍVEL (NO
SENTIDO DE SER VALOROSO, IMPORTANTE) PARA UM ATOR
UM USE CASE É COMPLETO
UM USE CASE NÃO ESTÁ
COMPLETO QTÉ QUE O VALOR FINAL TENHA
SIDO PRODUZIDO (MESMO QUE ENVOLVA, POR
EXEMPLO, VÁRIOS DIALOG BOXES, ETC.)
DESCREVE ALGUMA FUNÇÃO
COMO UM TODO, INCLUINDO ALTERNATIVAS,
TRATAMENTO DE ERROS, ETC.
UM USE CASE É UMA CLASSE, NÃO UMA
INSTÂNCIA
COMO ACHAR USE
CASES
FAÇA AS SEGUINTES PERGUNTAS SOBRE CADA ATOR
QUAIS FUNÇÕES O ATOR
REQUER DO SISTEMA? O QUE O ATOR PRECISA
FAZER?
O ATOR PRECISA LER,
CRIAR, DESTRUIR, MODIFICAR OU ARMAZENAR
ALGUM TIPO DE INFORMAÇÃO NO SISTEMA?
O ATOR PRECISA SER
NOTIFICADO DE EVENTOS DO SISTEMA OU ELE
PRECISA NOTIFICAR O SISTEMA SOBRE ALGO? o
QUE TAIS EVENTOS REPRESENTAM EM TERMOS DE
FUNCIONALIDADE?
O DIA-A-DIA DO ATOR
PODERIA SER SIMPLIFICADO ATRAVÉS DE
NOVAS FUNÇÕES DO SISTEMA?
OUTRAS PERGUNTAS A FAZER (DEPOIS
ACHA OS ATORES ENVOLVIDOS)
QUE ENTRADAS E SAÍDAS O
SISTEMA PRECISA/PRODUZ? DE ONDE VEM E
PARA ONDE VAI?
QUAIS SÃO OS MAIORES
PROBLEMAS COM A UTILIZAÇÃO DO SISTEMA
ATUAL?
A GRANULARIDADE
A USAR VARIA DE PESSOA PARA PESSOA
JACOBSON (QUE INVENTOU
USE CASES) DIZ QUE UM SISTEMA NÃO PODE
TER MAIS DO QUE 10 A 20 USE CASES
MUITA GENTE ACHA ISSO
POUCO E GERAM CENTENAS DE USE CASES
MINHA OPINIÃO: O ESTUDO
DE CASO CAPTURA BEM A GRANULARIDADE (VIDE
ADIANTE)
EM UML, USE CASES SÃO REPRESENTADOS COM
OVAIS
RELAÇÕES
ENTRE USE CASES
EXTENDS:
UM CASO ESTENDE OUTRO PELA ADIÇÃO DE
OPERAÇÕES ESPECIAIS
O USE CASE NOVO PODE
USAR PARTE DO USE CASE SENDO ESTENDIDO
USES:
UM CASO USA OUTRO CASO COMPLETAMENTE E NÃO
QUEREMOS REPETIR A DESCRIÇÃO
EM AMBOS OS CASOS, TEMOS UMA
REUTILIZAÇÃO DE COMPORTAMENTO, MAS A INTENÇÃO
É DIFERENTE
EXTENDS É USADO QUANDO ESTÁ
DESCREVENDO UMA VARIAÇÃO
DO COMPORTAMENTO NORMAL
USE É USADO QUANDO ESTÁ REPETINDO DESCRIÇÕES EM
DOIS USE CASES DIFERENTES
A DESCRIÇÃO
TEXTUAL DE UM USE CASE DEVE CONTER:
O OBJETIVO DO USE CASE (O QUE
ESTÁ TENTANDO FAZER OU ATINGIR)
COMO O USE CASE É INICIADO
O FLUXO DE MENSAGENS ENTRE
ATORES E O USE CASE, INCLUINDO QUAIS ENTIDADES
SÃO USADAS E/OU MODIFICADAS
FLUXO ALTERNATIVO EM CASO DE
ERRO OU EXCEÇÃO (MAS SEM EXAGERAR NOS DETALHES)
COMO O USE CASE TERMINAR E O
TIPO DE VALOR DADO AO USUÁRIO
O LINGUAJAR USADO DEVE SER
SEMPRE DO DOMÍNIO DO PROBLEMA
UM USE CASE COM PASSOS MAIS COMPLEXOS PODE DESCREVER AS
SITUAÇÕES ESPECIAIS USANDO:
DIAGRAMAS DE ATIVIDADE (TIPOS DE
FLUXOGRAMA)
DIAGRAMAS DE ESTADO (MÁQUINA DE
ESTADOS FINITA)
DIAGRAMAS DE SEQUÊNCIA (MOSTRA O
DINAMISMO EM FUNÇÃO DE TEMPO)
EXEMPLO DE UM DIAGRAMA DE SEQUÊNCIA
(EMPRESTAR ITEM)
A VALIDAÇÃO
DO MODELO DE USE CASE É FEITA ASSIM QUE ELE ESTIVER
TERMINADO
JUNTO COM OS CLIENTES, PARA QUE
SE CERTIFIQUEM DE QUE O MODELO SATISFAZ SEUS
REQUISITOS
DESCRIÇÃO INICIAL
É UM SISTEMA DE SUPORTE PARA UMA BIBLIOTECA
UMA BIBLIOTECA EMPRESTA LIVROS E REVISTAS A
CLIENTES. CLIENTES, LIVROS E REVISTAS SÃO
CADASTRADOS NO SISTEMA
UMA BIBLIOTECA TRATA DA AQUISIÇÃO DE NOVAS
OBRAS (UM "TITLE" EM INGLÊS). VÁRIAS
CÓPIAS DE OBRAS POPULARES PODEM SER COMPRADAS.
LIVROS E REVISTAS VELHOS SÃO REMOVIDOS QUANDO
ESTÃO EM CONDIÇÕES POBRES OU OBSOLETOS
UM BIBLIOTECÁRIO É UM EMPREGADO DA
BIBLIOTECA QUE INTERAGE COM OS CLIENTES E CUJP
TRABALHO É APOIADO PELO SISTEMA
UM CLIENTE PODE RESERVAR UM LIVRO OU REVISTA
QUE NÃO ESTEJA CORRENTEMENTE DISPONÍVEL NA
BIBLIOTECA DE FORMA A SER AVISADO QUANDO FOR
DEVOLVIDO OU COMPRADO. A RESERVA É CANCELADA
QUANDO O CLIENTE FAZ O EMPRÉSTIMO OU ATRAVÉS DE
UM PROCEDIMENTO EXPLÍCITO DE CANCELAMENTO
A BIBLIOTECA PODE CRIAR, MODIFICAR E REMOVER
INFORMAÇÃO SOBRE AS OBRAS, CLIENTES,
EMPRÉSTIMOS E RESERVAS
O SISTEMA DEVE RODAR EM TODAS AS PLATAFORMAS
POPULARES (UNIX, WINDOWS, ETC.)
O SISTEMA DEVE SER SIMPLES DE ESTENDER EM
FUNCIONALIDADE
A PRIMEIRA VERSÃO DO SISTEMA NÃO PRECISA
TRATAR DAS MENSAGENS DE NOTIFICAÇÃO AOS
CLIENTES SOBRE RESERVAS QUE CHEGAM, NEM PRECISA
VERIFICAR QUE UM ITEM (UMA CÓPIA DE UMA OBRA)
ESTÁ ATRASADO
VOCABULÁRIO
CLIENTE (BORROWER)
BIBLIOTECÁRIO (LIBRARIAN)
OBRA (TITLE)
ITEM (ITEM)
RESERVA (RESERVATION)
OS ATORES
CLIENTES E BIBLIOTECÁRIOS
BIBLIOTECÁRIOS SÃO OS ÚNICOS
USUÁRIOS DIRETOS DO SISTEMA
(JÁ, JÁ VAI PINTAR UM NOVO
REQUISITO DE COLOCAR TUDO NA WEB)
OS USE CASES
EMPRESTA ITEM
RETORNA ITEM
FAZ RESERVA
REMOVE RESERVA
ADICIONA TÍTULO
MODIFICA OU REMOVE TÍTULO
ADICIONA ITEM
REMOVE ITEM
ADICIONA CLIENTE
MODIFICA OU REMOVE CLIENTE
MANUTENÇÃO (UMA COMBINAÇÃO DE VÁRIOS
OUTROS USE CASES)
SÓ USADO PARA DEIXAR CLARO QUE UM
ATOR TEM QUE TRATAR DE TUDO ISSO
O DIAGRAMA USE CASE
EXEMPLO DE
DESCRIÇÃO TEXTUAL: O ATOR BIBLIOTECÁRIO
The actor who actually works
with the computer system. The librarian maintains
the system by adding and deleting titles, items
and borrowers, and also performs the key
functions such as lending and returning items,
reserving titles, and giving out information
about the data stored in the system. The
functions are performed on behalf of the borrower
actor.
EXEMPLO DE DESCRIÇÃO TEXTUAL:
EMPRESTAR ITEM
IF THE BORROWER HAS NO
RESERVATION
A TITLE IS IDENTIFIED
AN AVAILABLE ITEM OF THE
TITLE IS IDENTIFIED
THE BORROWER IS
IDENTIFIED
THE LIBRARY LENDS THE
ITEM TO THE BORROWER
A NEW LOAN IS REGISTERED
IF THE BORROWER HAS NO
RESERVATION
A TITLE IS IDENTIFIED
AN AVAILABLE ITEM OF THE
TITLE IS IDENTIFIED
THE BORROWER IS
IDENTIFIED
THE LIBRARY LENDS THE
ITEM TO THE BORROWER
A NEW LOAN IS REGISTERED
THE RESERVATION IS
REMOVED (SEE USE CASE REMOVE RESERVATION)
UM EXEMPLO DE DOIS
DIAGRAMAS DE SEQUÊNCIA PARA O USE CASE
EMPRESTAR ITEM COM RESERVA
O MODELO COMPLETO DE USE CASE ESTÁ NO
MATERIAL DO ESTUDO DE CASO DISPONÍVEL AQUI
E DEVE SER ESTUDADO POR
INTEIRO
SEU PROJETO VAI DEVE TER O MESMO FORMATO
usecase1.htm programa