Levantamento, Análise e Gestão
Requisitos
Aula 08
Agenda

Elaboração dos Principais Artefatos:
●
Visão
●
Especificação de Requisitos
●
Glossário
●
Especificação suplementar
●
Diagrama de Casa de Uso
●
Verificação (Check Lists)
●
Guias (do RUP)
Visão
Princípios de uma boa especificação
1. Separar a funcionalidade de implementação
2. Abranger o sistema do qual o software é um
componente
3. Abranger o ambiente no qual o sistema opera
4. Ser um modelo cognitivo
5. Ser operacional
6. Ser tolerante com não ser completa e ser
expansível
7. Ser localizada e fracamente acoplada
Especificação
Documentar e formalizar os resultados da elicitação e
da análise
●
Usar templates específicos de documentos para cada
tipo de requisito
●
Formato da Especificação de Requisitos
Introdução - declara as metas e os
objetivos do software, descrevendo-os
no contexto do sistema baseado em
computador
Visão Geral do Produto - descrição
detalhada do problema que o software
deve resolver
Premissas e Restrições
Requisitos Funcionais
Requisitos Não funcionais
01_ModeloDocumentoDeRequisitos.doc
Regras de Negócio
Introdução – descrever a finalidade,
escopo, referência e abreviaturas
Regras de Negócio do Sistema –
descrição detalhada de cada uma das
regras que compõe o sistema
Aprovação – acerto com o cliente
02_RegrasDeNegocio.doc
Especificação
Registrar os vários tipos de informações dos requisitos
visa facilitar a comunicação entre os stakeholders do
Projeto:
Documentações em linguagem natural
Modelos gráficos de análise
Armazenar as informações dos requisitos
Ferramentas de gerenciamento comercial
 Utilizando documentos padrões
●
Documento de Visão e Escopo
Introdução
●
Finalidade
●
Escopo
●
Descrição Geral
●
Requisitos Específicos
●
Relatórios dos Casos de Uso
●
Papéis e Responsabilidade
●
Usuários
●
Modelos de Equipe
●
Cronograma Inicial
●
03_ModeloDeVisaoEscopo.doc
Importância da Especificação Correta
Completa Compreensão
●
Reduz o custo e o retrabalho
●
Referência para Validação Final
●
Base de Concordância Cliente e Fornecedor
●
Não importa quão bem projetado ou codificado está um
programa, se ele for mal analisado e especificado
desapontará o usuário e trará aborrecimentos ao
desenvolvedor
●
Documento por tipo de requisito
Não-funcional
Funcional
Requisitos de
negócio
Documento de visão e escopo
Regras de
negócio
Requisitos de
usuário
Atributos de
qualidade
Documento de caso de uso
Interfaces
externas
Requisitos
funcionais
Requisitos de
sistema
Especificação dos
requisitos de software
Restrições
Artefatos Utilizados
Onde o problema é definido?
Onde os stakeholders e usuários são listados?
Onde os ambientes e plataformas são identificadas?
Onde os requisitos não funcionais
estão localizados?
Onde os casos de uso são mantidos?
Onde o vocabulário comum está descrito?
Necessidades e Requisições
dos stakeholders são capturadas?
Visão
Especificação
Suplementar
Especificações de
Caso de uso
Glossário
Requisições do
Stakeholder
Descrever Steakholders no Documento de Visão
Stakeholder:
Representante:
Descrição:
Tipo:
Responsabilidade:
Critério de
Sucesso:
Envolvimento:
Entregas:
Comentários /
Preocupações:
Digitador
João das Couves
Usuário
O digitador é tipicamente um técnico com conhecimentos em
informática. O digitador é treinado e experiente no uso do atual
sistema batch de registro
O digitador é responsável por administrar o cadastro de cursos para
cada período letivo. Isto inclui a supervisão administrativa e de
permissão de acesso aos dados
Conseguir manter o banco de dados de estudantes e professores, e
abrir/fechar cursos para matrícula
A responsabilidade primária dos digitadores será manter o banco de
dados de estudantes e professores, e abrir/fechar cursos para
matrícula
Também será requerido da área de matrícula
Gestor de Revisão – especialmente nas funcionalidades requisitadas
pela área de Matrículas
Nenhum
Descrever o problema no Documento de Visão
Requisições do
Stakeholder
Definição do
Problema
Documento de
Visão
Modelo de
Caso de Uso
Especificações de
Design
Especificação
Suplementar
Especificações de
Manual do Usuário
Documento de Visão
• As mesmas informações devem conhecer a
gerência, o marketing e a equipe de projeto
• Fornecer um feedback inicial do cliente
• Promover uma única compreensão
• Definir o escopo e a prioridade em alto nível
das requisições do stakeholder e suas
características
• Um documento de sistema que descreve o
“que” e “porquê”
Visão
Documento de Visão
Introdução
●
Posicionamento
●
Descrição dos Envolvidos
●
Necessidade dos Envolvidos
●
Visão Geral do Produto
●
Características do Produto
●
Restrições
●
Outros Requisitos do Produto
●
Aprovação
●
04_ModeloDeVisao.doc
Obtendo o Entendimento do Problema
O problema de
(descreva o problema)
afeta
(os stakeholders afetados pelo
problema)
O impacto disto é (qual o impacto do problema)
que
Uma solução de
sucesso seria
(listar vários benefícios-chave de
negócio para uma solução de
sucesso)
Descrição do Problema
Visão
Identificar as Restrições
De ambiente
Políticas
Técnicas
Econômicas
Viabilidade
Sistêmicas
Identificar as Melhores Soluções de Negócio
Identificar as Melhores Soluções de Negócio
• Identificar as várias soluções para os problemas
principais
– Técnico, não-técnico, ou ambos
• Escolher a que:
– Melhor resolve as causas-raiz
– Suporta os objetivos de negócio
• Obter os requisitos que permitem implementar a
solução
Ciclo de Vida do Caso de Uso
Descoberto
Descrever
brevemente
Rabiscado
Totalmente
Descrito
Fechar Matrícula
Descrição Breve: Este caso de uso permite ao Digitador
fechar o processo de matrículas. Ofertas de curso que
não possuírem alunos serão canceladas. O sistema de
Cobrança é notificado com todos os dados de matrícula
para assim efetuar as devidas cobranças.
Resumo do Fechar Matrículas
-Fluxo de Eventos
-Passo-a-Passo
Fechar Matrículas Especificação de Caso de Uso
- Fluxo de Eventos detalhado
- Requisitos Especiais
- Condições Pré/Pós
Atores e Papéis
Manoel: Professor de Matemática e é
aluno de Economia
Joaquim: É um aluno de
Ciências
Matricular
em Curso
Manoel e Joaquim agem
como estudantes
Estudante
Manoel age também
como Professor
Submeter grades
Professor
Comunicação – Associação
Ator 1
Caso de Uso
Ator 2
Ator 3
• Um canal de comunicação entre um ator
e um Caso de Uso.
• Uma linha é usada para representar uma
associação de comunicação.
– Uma flecha indica quem inicia cada
interação
– Uma linha sem flecha indica que o caso de
uso ou o ator podem iniciar a interação
Convenções das Setas e Linhas
Sensor passivo
Monitorar
Alarmes
Sensor ativo
Supervisor
Sensor híbrido
Sensor passivo
Monitorar
Alarmes
Sensor ativo
Supervisor
Sensor híbrido
Cada Associação de Comunicação é o Diálogo completo
O estudante acessa o sistema
O sistema autentica o usuário
Estudante requisita dados do
curso
Estudante
Sistema apresenta a lista de cursos
Estudante seleciona curso
Sistema apresenta a agenda do curso
Matricular em
Curso
Sistema de
Cadastro de
Cursos
O sistema transmite a requisição
O sistema retorna os dados do curso
Um cenário de uma instância de Caso de Uso
Estudante
Matricular em
Curso
Cenário 1
Autenticar no sistema
Aprova o login
Digitar o assunto
Obter lista de cursos
Apresentar lista de cursos
Selecionar Cursos
Confirmar Disponibilidade
Mostrar grade final
Sistema de
Cadastro de Cursos
Cenário 2
Autenticar no sistema
Aprova o login
Digitar o assunto
Assunto inválido
Entra novamente assunto
Obter lista de cursos
Apresentar lista de cursos
Selecionar Cursos
Confirmar Disponibilidade
Mostrar grade final
Diagrama de Caso de Uso
Como deve ser o nome do Caso de Uso
•
•
•
•
Indicar o significado ou objetivo
Usar a forma ativa: começar com verbo
Imaginar uma lista de tarefas
Teste de Variação de Nomes:
– Matricular cursos
– Matriculado em curso
– Confirmar matrícula
– Matrícula em curso
– Usar sistema de matrícula
Que variações tem maior significado para o usuário?
Quais não tem?
Que nome de caso de uso você escolhe? Por que?
Passos para Criar o Diagrama de Caso de Uso
1. Procurar atores e suas ações
– Descrever brevemente os atores
– Descreva brevemente as ações realizadas
2. Escrever os casos de uso
– Desenhar todos os casos de uso
– Priorizar os fluxos de casos de uso
Identificar o Caso de Uso
Quais objetivos desejo alcançar
utilizando o sistema?
Objetivo 1
Ator
Objetivo 2
Identificar o Caso de Uso
• Quais são os objetivos de cada ator?
– Porque o ator quer utilizar o sistema?
– O ator irá criar, guardar, mudar, remover, ou ler
dados no sistema? Se sim, porque?
– O ator precisa informar ao sistema sobre mudanças
ou eventos externos?
– O ator precisará ser informado sobre certas
circunstâncias do sistema?
• O sistema atende ao negócio com o comportamento
correto?
Descrição do Caso de Uso
Nome
Matricular em curso
Descrição Breve
O estudante seleciona os
cursos que deseja para o
próximo semestre. Uma grade
dos cursos primários e
alternativos são gerados.
Relacionamento
com atores
Matricular em curso
Estudante
Check-points para o Caso de Uso
• Verificar o comportamento do sistema – com ele é
fácil de entender o que o sistema faz ao revisar o
modelo
• Todos foram identificados – o caso de uso conta com
todos os comportamentos esperados pelo ator com o
qual interage
• Todas as características estão mapeadas – para pelo
menos um caso de uso
• Não contêm comportamento supérfluo – todos os
casos de uso podem ser justificados ao rastreá-los de
volta para os requisitos funcionais
• Todos os casos de uso CRUD foram removidos:
– Create, Report, Update, Delete
Relacionamento entre Caso de Uso e Ator
Para relacionamentos de casos de uso,entre si, temos os
tipos: generalização,extensão e inclusão
Para relacionamentos de atores,entre si, temos um único tipo
que é o relacionamento de generalização
Para relacionamentos entre atores e casos de uso
temos apenas a associação
Relacionamento entre Caso de Uso e Ator
Associação (Association)
Interação do ator com o caso de
uso por meio do envio e
recebimento de mensagens
binárias -> envolvem apenas
dois elementos
Por exemplo: O ator Correntista
envia e recebe mensagens do
Caso de Uso Calcular
Empréstimo Pessoal, por um
relacionamento de associação
Relacionamento entre Caso de Uso e Ator
Generalização (Generalization)
Ocorre entre Casos de uso OU entre atores
Dois elementos semelhantes, mas com um deles realizando
algo mais
Por exemplo:podemos criar um ator genérico
Aluno e especializá-lo nos atores Aluno Matriculado e
Aluno Ouvinte
Relacionamento entre Casos de Uso
Extensão (Extend)
Indica que um deles terá seu procedimento acrescido, em um
ponto de extensão, de outro caso de uso, identificado como base
Podemos ter diversos pontos de extensão num mesmo caso de
uso, inclusive repetir um mesmo ponto de extensão
Utilização
• Expressar rotinas de exceção ou para expressar o
desmembramento de um caso de uso (quando o cenário
alternativo possui um fluxo grande demais)
• Separar um comportamento obrigatório de outro opcional
• Separar um trecho do caso de uso que será executado apenas em
determinadas condições
Relacionamento entre Casos de Uso
Extensão (Extend)
Separar um comportamento obrigatório de outro opcional
Separar um trecho do caso de uso que será executado apenas em
determinadas condições
Separar trechos que dependam da interação com um determinado
ator
Exemplo:
No cadastro de uma venda, a rotina de desconto só pode ser
executada pelo gerente. Essa rotina pode ser transferida para um
caso de uso de extensão
Relacionamento entre Casos de Uso
Inclusão (Include)
• Indica que um deles terá seu procedimento copiado num
local especificado no outro caso de uso identificado como
base
• Quando uso? Quando existem cenários cujas ações servem
a mais de um caso de uso
Exemplo validar matrícula é útil para casos de uso como
renovar matrícula de aluno, emitir histórico escolar, lançar
notas de provas, entre outros
Textualmente, um relacionamento de inclusão, dentro da
descrição de um caso de uso base, é representado com o
termo Include seguido do seu nome
Relacionamento entre Casos de Uso
Inclusão (Include)
Cenário Principal
1 . O aluno digita sua matrícula. O sistema verifica se a matrícula é
válida e ativa
Include (Validar Matrícula)
Evitar a cópia de trechos idênticos, ganhamos tempo na
modelagem e na implementação sem falar na manutenção
Modelando Caso de Uso com o Auxílio de Pacotes
• Representar vários casos de uso em um único
diagrama é uma tarefa impossível
• Podemos agrupar casos de uso considerando uma
mesma abordagem conceitual, podemos trabalhar com
pacotes
• Agrupamento de qualquer elemento de modelo, como
casos de uso, classe, estados, outros pacotes
Nomenclatura <nome do pacote>seguido de :: e <nome
do elemento>
pacote::elemento
Exemplo: Controle Acadêmico::Cadastrar Aluno
Evoluir o Caso de Uso
Matricular
em Curso
Estudante
Sistema de Matrícula
em Curso
+ Descrição Breve
Matricular Online em Curso
+ Fluxo de eventos rabiscado
• Passos de alto nível
Especificação de Caso de Uso
do Matricular para Curso
+ Fluxo de Eventos detalhado
• Passo a Passo
+ Requisitos Especiais
+ Condições Pré/Pós
Validação
Processo de verificar os requisitos quanto a sua
validade, consistência, completeza, realismo e sua
facilidade de verificação
●
Se os requisitos demonstram o que cliente realmente
quer
●
Verificações
O sistema fornece as melhores funções para atender as
necessidades de cliente?
●
Soluções conciliatórias com os usuários funções
adicionais ou diferentes que são exigidas
●
Existem requisitos em conflito?
●
Descrições diferentes para uma mesma função do
sistema ou restrições contraditórias
●
Todas as funções solicitadas e exigidas pelo cliente estão
incluídas?
●
Os requisitos implementados estão dentro do orçamento, prazo
e da tecnologia existente?
●
Os requisitos podem ser verificados?
●
Modelo de Caso de Uso
Nome do Caso de Uso
●
Atores
●
Pré-condições
●
Fluxo de Eventos
●
Pós-condições
●
Pontos de Extensão
●
Referências
●
Observações
●
Aprovação
●
05_ModeloDeCasoDeUso.doc
RUP
É extremamente importante para o sucesso de um projeto que o
processo seja adequado e que o nível de cerimônia seja ajustado,
pois documentação em excesso não trará produtividade e
documentação superficial trará problemas de comunicação
Guias (do RUP)
Abordagem Interativa
Em uma
iteração,
você passa
por todas as
disciplinas
Disciplinas
agrupam
atividades
logicamente
Disciplinas
RUP tem disciplinas
Artefatos são desenvolvidos em
cada disciplina através de um
processo iterativo
Disciplinas produzem e compartilham modelos
Várias disciplinas
produzem modelos…
Modelagem
Negócio
Requisitos
Implementação
Análise &
Design
Entrada para
Realizado por
B
B
B
B
Business
Analysis Model
Automatizado
por
Modelo de
Design
Verificado por
…cada modelo é
averiguado.
por
Modelo de
Caso de Uso
Modelo de
Negócio
Modelo de
Implementação
Validado por
Teste
Entrega
Realizado
Por
Implementado
Papéis e artefatos
Fonte: IBM Rational Unified Process
Quando usar o RUP?
O RUP pode ser usado desde o início até as fases de manutenção do
projeto. O RUP pode ser customizado para suas necessidades, mas
seguindo as considerações abaixo:
• Ciclo de Vida do
Software (nº de
iterações, tamanho das
fases e do projeto)
• Objetivos de negócio do
projeto, visão, escopo e
risco
• Tamanho e
complexidade do esforço
de desenvolvimento
Dúvidas? Agradecimentos
Home Page
http://fernandoans.site50.net
Blog
http://fernandoanselmo.blogspot.com
X25 Home Page
http://www.x25.com.br
Fernando Anselmo
[email protected]