curso de requisitos módulo 03: requisitos de software requisitos de software, técnicas de...
TRANSCRIPT
Curso de RequisitosMódulo 03: Requisitos de Software
Requisitos de Software, Técnicas de Levantamento, Identificação dos Problemas,
Necessidades e Principais Artefatos
Introdução à Gerencia de Requisitos: Visão Geral
Sistema a ser
construído
Necessidades
Requisitos de Software
DesignProcedimentos de Teste
Docs do usuário
Características Domínio da Solução
Domínio do Problema
Rastreabilidade
ProblemProblema
Definições
• Requisitos–A condição ou capacidade que o sistema
deve possuir.
• Gerenciamento de Requisitos–Uma abordagem sistemática para:
• Detalhar, organizar, e documentar requisitos. • Estabelecer e manter acordos entre cliente/usuário
e equipe de projeto nas requisições de mudanças.
O que Requisitos de Software especificam?
Entradas Saídas
FunçõesRequisitos nãofuncionais(Ex.: Performance)
Restrições de Design
(Ex.: Ambientes)
Sistema
DefiniçõesRequisições do StakeholderUma expressão independente de solução de um estado desejado pelo stakeholder da solução ou sujeito ao domínio.
Requisitos de SoftwareRequisito FuncionalUm requisito que especifica, de uma perspectiva caixa-preta, como uma solução que interage com o mundo externo. Requisito não funcionalUm requisito que expressa, de uma perspectiva caixa-preta, os atributos de qualidade da solução.
RestriçãoUma limitação no design do sistema ou nos processos usados para construir o sistema.
CaracterísticaUm serviço externamente observável diretamente no sistema que atende a um ou mais requisições do stakeholder.
Exemplo de um Sistema de Registro em CursoRequisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas.
RestriçãoOpera no Main Frame DEC VAX da Universidade.
Requisito de SoftwareFuncionalO caso de uso começa quando o estudante seleciona o comando “register for course”. O sistema apresenta uma lista de cursos disponíveis…
Não-FuncionalDisponibilidade de 99% dos 24/7(3.65 dias off-line por ano)
CaracterísticaUma árvore de navegação de visualizar a grade de aulas, por semestre e por turma.
Caracterização das Definições
Based on Leffingwell & Widrig, 1999
Requisitos de Software
Restrições de Design
Requisitos Funcionais
Requisitos não funcionais
tipos de Requisitos
Requisições do Stakeholder
Características
O queComo
Necessidades do Stakeholder
Características do Produto ou Sistema
Requisitos de Software
Especificação de Design Procedimentos de Teste Planos de Documentação
Requisitos existem em vários níveis
O queComo
O queComo
Gerência de Requisitos Não é Fácil porque…
• Requisitos: –Nem sempre são óbvios.–Vem de várias fontes.–Nem sempre é fácil de expressar claramente em
palavras.–São interelacionados e relacionados a outras
entregas do processo de desenvolvimento de software.
–Tem propriedades únicas ou valores de propriedade.
–Mudam.–São difíceis de controlar quando em grande
número.
Gerenciamento Requer Estratégia
RUCS10:RM Plan
RM Plan
Gerenciamento de Requisitos efetivo
• Manter um claro estabelecimento dos requisitos requer: – Boa qualidade dos requisitos– Atributos aplicáveis para cada tipo de requisito– Rastreamento para outros requisitos e outros artefatos do
projeto
O OBJETIVO é entregar produtos de qualidade
No tempo e no orçamento
que atendam
As reais necessidades do usuário.
O que é um “Produto com Qualidade” ?
• Qualidade: Velhos Conceitos –Satisfaz os documentos de requisitos. –Passa nos testes de sistema.–Adere ao processo de desenvolvimento.
• Qualidade: Conceitos Modernos–Entende todas as necessidades do usuário. –Continuamente revisa todos os artefatos para
garantir que atendem às necessidades.
Paradigma baseado em atividades Paradigma baseado em atividades
Paradigma baseado em Resultados Paradigma baseado em Resultados
Dimensões de QualidadeComponentes do FURPS+
FFunctionality Conjunto de características, segurança, e requisitos em geral
UU sability Fatores humanos estéticos, consistência, documentação
RR eliabilityFrequência/severidade da falha, recuperabilidade, previsibilidade,
acurária, MTBF
PPerformance Velocidade, uso de recrusos, throughput, tempo de resposta
SS upportability
Testabilidade Extensível Adaptabilidade ManutenívelCompatibilidade Configurável
Disponibilidade InstalávelLocalizável Robustez
On Time and On Budget
Tempo
Quanto de trabalho nós
podemos fazer?
Recursos
Orçamento
ScopeScopeScope
Escopo
Atendendo as reais necessidades do cliente
Característica 1: O sistema deve...
Característica 2: O sistema deve
Característica 3: O sistema deve
Característica 4: O sistema deve
Característica 5: O sistema deve
Característica 6: O sistema deve
Característica 7: O sistema deve
Característica n: O sistema deve…
Como determinar prioridade?
O que é um baseline?
Como sabemos quais são as necessidades?
TempoData de Início
do ProjetoData-Alvo do Lançamento
Possibilitar um acordo entre os envolvidos
Objetivos de sistema
VerificaçãoRequisitos
ClienteGrupo de Usuários
Sistema a ser construído
Adapted from Al Davis
Requisitos
O Objetivo
Quais fatores contribuem para o sucesso do Projeto?
10. Outros aspectos9. Estimativas confiáveis8. Uso de métodos formais7. Requisitos básicos firmes
6. Infra de Software padronizada
5. Escopo controlado4. Objetivos Negociais claros
3. Gerente experiente
2. Envolvimento do Usuário
1. Suporte da Gerência Executiva
Os Dez Motivos
Standish Group, ‘01 (www.standishgroup.com)
28% dos projetos são completadosno orçamento e prazo. 49% dos projetos ultrapassam
as estimativas iniciais.- Tempo estoura em média 63%.- Custo ultrapassa em média 45%.
23% dos projetos são cancelados antes de sua conclusão.
Fatores de Sucesso
Tamanho é importante
0
10
20
30
40
50
60
Project Size ($)
less than $750K
$750K to $1.5M
$1.5M to $3M
$3M to $6M
$6M to $10M
Over $10M
Taxa deSucesso
(%)
Standish Group, ‘99 (www.standishgroup.com)
Sucesso pelo Tamanho do Projeto
O alto custo dos Requisitos Errados
Custo relativo para reparar erros: Quando Introduzidos X Quando reparados.
100
2.5
5
10
25
.5 - 1Em tempo de Requisitos
Design
Codificação
Teste Unitário
Teste de Aceitação
Manutenção
“All together, the results show as much as a 200:1
cost ratio between finding errors in the requirements and
maintenance stages of the software
lifecycle.”
Boehm 1988
A regra do 1-10-100
Ajuda para Projetos serem bem sucedidos
• Análise dos Problemas– Entender o Problema.– Obter o entendimento com os stakeholders.– Estabelecimento claro dos objetivos de negócio.
• Elicitação de Requisitos– Identificar quem utilizará o sistema (atores).– Elicitar como o sistema será usado (casos de uso).
• Gerenciamento de Requisitos– Especificar os requisitos de forma completa. – Gerenciar expectativas, mudanças, e erros.– Controlar quebra de escopo.– Listar todos os membros da equipe.
Envolvendo toda a Equipe com os Requisitos
• Desenvolvedores, Testadores, e Autores–Ajuda a desenvolveder as práticas de
gerenciamento de requisitos.–Monitora a aderência às boas práticas.–Verifica o processo de elicitação.–Documenta requisitos.–Participa das revisões sobre os requisitos.–Participa como membro do Comitê de Controle
de Mudanças (CCM).–Revisa as matrizes de rastreabilidade.–Verifica qualidade, testabilidade, e completude.
O resultado é pior quando a qualidade é baixa
??
?
?
Qualidades do Conjunto de requisitos de software• Correto
–É a descrição correta sobre o que o sistema deve fazer.
• Completo–Descreve todos os requisitos significantes para o
contexto do negócio e do usuário.
• Consistente–Não está em conflito com outros requisitos.
• Não ambíguo–Está sujeito a apenas UM entendimento.
Qualidades do Conjunto de Requisitos (cont.)
• Verificável– Pode ser testado sem grandes custos.
• Classificável por importância e estabilidade– Pode ser classificado por importância para o cliente e
estabilidade do requisito em si.• Modificável
– Mudanças não afetam a estrutura do todo.• Rastreável
– A origem de cada requisito pode ser apontada.• Claro
– Compreendido por usuários e desenvolvedores.
Leffingwell & Widrig (1999). IEEE 830-1993, § 4.3.2, 1994
IEEE 830-1993, § 4.3.2, 1994
- O sistema suporta acima de 1000 usuários simultâneos.- O sistema deve responder a qualquer consulta em 500ms.- A cor deve ser um agradável verde sombreado.- O sistema deve estar disponível em 24 x 7.-O sistema deve exportar visões dos dados em formato texto,
separado por vírgula de acordo com o IEEE.
Qualidades de um Requisito: Verificável• Um requisito é verificável se:
– É algo finito, em que uma pessoa ou máquina (com custo viável) pode checar se o produto atende ao requisito definido junto ao usuário.
Estes requisitos são verificáveis? Se não, qual o melhor modo de definí-los?
Qualidades de um requisito: Rastreável
Requisições do Stakeholder
Características
SuplementarCasos de Uso
ref - IEEE 830
“A deve ir de B para C”
“A deve ir de B para C”
“A deve ir de B para C”
Qualidades de um Requisito: Não ambíguo
• O requisito é não ambíguo se tiver apenas uma interpretação.
Requisito A
Como realizar os requisitos.O Modelo de Design espefica componentes de um sistema ou suas interfaces com outros sub-componentes.
Como saber se os requisitos estão sendo atendidos.
Um Test Suite contém um conjunto de scripts de teste e logs de teste.
Quando os requisitos atendem.O Plano de desenvolvimento de software especifica cronograma, planos de verificação e validação, e planos de gerenciamento de configuração.
Design
O que NÃO é um Requisito?
Verificação
Dados deProjeto
RUP: Um Framework para Gerência de Requisitos
Disciplina de Requisitos: Detalhes do Workflow
Papéis e Artefatos
Quais artefatos são usadosOnde o problema é definido?Onde os stakeholders e usuários são listados?Onde os ambientes e plataformas são identificadas?
Onde os casos de uso são mantidos?
Onde o vocabulário comum está descrito?
Visão
Especificações de Caso de uso
Glossário
Especificação Suplementar
Onde os requisitos não funcionais estão localizados?
Onde as Necessidades e Requisições dos stakeholders são capturadas?
Requisições do
Stakeholder
Onde estamos na disciplina de Requisitos?
Análise do Problema: Atividades e Artefatos
Análise do Problema• É o processo de entender os problemas
do mundo real, e como eles se relacionam com as necessidades dos stakeholders, e propor soluções para atender a estas necessidades.
• Qual o objetivo da Análise de Problemas?–Ter um melhor entendimento antes de
começar o desenvolvimento.–Identificar as causas-raiz.–Ajudar na identificação da solução.
• Evitar o: “Sim, mas…”–Minimizar o trabalho extra. Qual o problema
real?
Definição do ProblemaUm problema pode ser definido como uma
diferença entre as coisas como são percebidas e como são desejadas.
(Problema)
Percebido Desejado
Passos para a Análise do Problema
• Identificar os stakeholders.
• Entender as causas-raiz.
• Chegar a um entendimento sobre os problemas.
• Identificar as restrições do sistema e do projeto.
• Identificar e validar a solução em relação as causas-raiz.
• Definir a fronteira (escopo) do sistema.
Elicitar Requisitos
Expandir a lista de soluções do stakeholder.
Roadmap da Análise de Problemas
Escolher as melhores soluções para alcançar os
objetivos.
Melhor solução identificada
Problema validado/ajustado
Problema de Negócio Definido
Problema Atual identificado e definido
Identifique stakeholders para o problema.
Análise da Causa-Raiz.
Reavaliar qual é a melhor idéia de solução.
Entendimento dos Problemas no Contexto dos
Objetivos de Negócio.
Problema de
Negócio
Idéia de Solução ou
Oportunidade
Stakeholders: Definições
• Stakeholder –Um indivíduo que é materialmente afetados
por uma saída do sistema ou do projeto que está produzindo o sistema.
• Representante do Stakeholder–Um stakeholder representa um ou mais
stakeholders. Eles estão diretamente envolvidos na direção, concepção, e no escopo do projeto.
Identificar os Stakeholders• Cada grupo de stakeholders precisa de um
representante.
• Nem todos os grupos de stakeholders precisam ser consultados.–Vários irão fornecer os requisitos.
• Clientes, usuários, administradores do sistema
–Vários podem não fornecer requisitos.• Acionistas da empresa
Quem destes são stakeholders nos seus projetos?
Descrever Stakeholders no Documento de Visão
Stakeholder DigitadorRepresentante Kelly HansenDescrição UsuárioTipo O digitador é tipicamente um técnico com conhecimentos
em informática. O digitador é treinado e experiente no uso do atual sistema batch de registro.
Responsabilidades 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.
Critério de Sucesso
Conseguir manter o banco de dados de estudantes e professores, e abrir/fechar cursos para matrícula.
Envolvimento 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ículas….
Entregas Gestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matrículas.
Comentários/ Preocupações
Nenhum
Quais problemas estão por trás dos problemas?
Técnicas do Diagrama de Espinha de Peixe
Liste as causas que contribuem para o problema detectado.Continue perguntando “Por que?” (expanda cada raia).
Problema de negócio que foi
percebido.
Sem banco à noite
Morosidade
Quer privacidade
quando sacar
Clientes insatisfeitos com nossos serviços.
Banco
s nos
aer
opor
tos
Mais
pon
tos d
e
aten
dimen
to
Filas g
rand
es e
lent
as
nas f
iliais
Análise do Problema – Validando a soluçãoTécnicas do Diagrama de Espinha de Peixe
Liste as razões que justificam a solução.Continue perguntando “Por que?” (expanda cada raia).
Solução percebida para os problemas.
Sem banco à noite
Morosidade
Quer privacidade
quando sacar
Mais Máquinas de Auto
Atendimento.
Banco
s nos
aer
opor
tos
Mais
pon
tos d
e
aten
dimen
to
Filas g
rand
es e
lent
as
nas f
iliais
Ben
efíc
ioB
enef
ício
EsforçoEsforço20%20%
80%80%
Foco nos que mais contribuem – Lei de Pareto
Classifique por ordem. Use a regra do 80-20 para focar nas principais causas responsáveis pelas grandes porções de problema.
20% do esforço originam em 80%
de benefício.
20% do esforço originam em 80%
de benefício.
Compreender o contexto maior do problema
• A falta de entendimento do negócio e seus objetivos aumenta o risco.
• O problema está em algum componente do processo/empresa?
• A equipe entende qual o domínio do problema?
• A solução do problema cria oportunidades de melhoria do processo?
Disciplinas de Modelagem de Negócio e Requisitos
Modelagem de Negócio Requisitos
Modelos de Negócio• Modelo de Organização estrutural e dinâmico.
–Processos de Negócio–Estrutura Organizacional–Papéis e responsabilidades
• Visualize a organização e seus negócios.
• Ajude a entender os problemas atuais.
• Identifique potenciais melhorias.
• Derive e valide os requisitos de sistema necessários à Organização.
Produtos Entregas Eventos
Descrever o problema no Documento de Visão
Especificações de Manual do Usuário
Especificações de Design
Requisições do
Stakeholder
Documento de Visão
Especificação SuplementarModelo de
Caso de Uso
Definição do Problema
Documento de Visão• As mesmas informações para gerência,
marketing, e equipe de projeto.• Fornece o feedback inicial do cliente.• Promove uma compreensão única do produto. • Define escopo e prioridade em alto-nível das
requisições do stakeholder e suas características.
• Um documento em nível de sistema que descreve o “que” e “porquê” do produto.
Visão
Estrutura do Documento de Visão
1. Introdução2. Posicionamento3. Descrições do Stakeholder e Usuário4. Visão Geral do Produto5. Características do Produto6. Restrições 7. Faixas de Qualidade8. Precedência e Prioridade9. Outros Requisitos do Produto10. Requisitos de Documentação11. Anexo 1 – Atributos das Características
Obtendo o Entendimento do ProblemaDescrição do Problema
Visão
O problema de (descreva o problema)
afeta (os stakeholders afetados pelo problema)
O impacto disto é que
(qual o impacto do problema)
Uma solução de sucesso seria
(listar vários benefícios-chave de negócio para uma solução de sucesso)
Identificar as Restrições
Econômicas
Técnicas
De ambiente
Sistêmicas
Políticas
Viabilidade
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.
Definir a fronteira da solução de sistema
ManutençãoComunicações Relatórios
Novo Sistema
Outros sistemas
UsuáriosSistemasLegados
Atores ajudam a definir a fronteira do sistema
PC
Fronteira do sistema?
ServidorPC
PC
PC
Quem é o ator? Os módulos do sistema ou o usuário?
Servidor
Usuário
PC
Capturando o Vocabulário comum do sistema
• Definir os termos usados no projeto.
• Ajudar a previnir mal-entendidos.
Glossário
Capturar o Vocabulário Comum
• Começar o mais cedo possível.
• Continua durante todo o projeto.
Visualize o Glossário como um modelo de Domínio
Cliente Acao Cliente. Transacao1..2 11..* *
Transacao geral TransferenciaLimite Credito
Entender Necessidades: Atividades e Artefatos
Quais são as fontes de Requisitos?
Analista
Cliente
Domínio do Problema
Usuários
Parceiros
Visitas ao SiteExperts no Negócio
Analistas de MercadoInfos Competitivas
Requisições IniciaisRelatórios de ErroMudanças de Requisito
Especif. de RequisitosModelo de NegócioPlanos de NegócioObjetivos Pessoais
Como é o Processo?
Aprovado pelo Cliente
Especificação corrigida
Rejeitada Novamente
Especificação corrigida
Rejeitado pelo cliente
Especificação de Requisitos
Cliente
Requisitos Ad-hoc vindos de um cliente Membro do Projeto
Quais problemas podem ser encontrados?• Stakeholders
– Tem uma idéia pré-concebida da solução.– Não sabem exatamente o que querem.– Não conseguem articular o que querem.– Pensam que sabem o que querem, mas não
reconhecem o que sugeriram quando da entrega.• Analistas
– Eles acham que entendem mais sobre os problemas do usuário do que o próprio usuário.
• Todo mundo – Todo mundo vê as coisas sob seu ponto de vista.– Todo mundo é politicamente motivado.
Stakeholder Analista
??
Expressando as Requisições do StakeholderSTRQ
STRQ STRQ
STRQ
STRQ
STRQ
“Estudantes precisam de
acesso fácil das grades”
“Relatórios podem ser impressos”
“Os resultados de fim de ano devem ser enviados por email para os estudantes”
“Professores precisam
saber quem está
matriculado”
“Listas das turmas são enviadas por
email após matrículas”
O Artefato de Requisição do Stakeholder• Vem dos stakeholders.• Tem todas as requisições do
stakeholders.• É consolidado de várias fontes.
– E-mail, especificação de requisitos do cliente, guardanapos, quadro branco, planilhas, e etc.
• Usados pelos membros do projeto para criar requisitos e funcionalidades do sistema.
• Pode conter referências para qualquer tipo de fonte externa.
Docs do Usuário
Espec. Design
Requisições do Stakeholder
Documento de Visão
Esp. Supl.
Modelo de Caso de Uso
Técnicas para Elicitar Requisições do Stakeholder
• Revisar especificações de requisitos do cliente
• Workshop de Requisitos–Workshops de Casos de Uso–Brainstorming e redução de idéias
• Entrevistas• Questionários• Role playing• Protótipos• Storyboards
Revisar as Especificações do Cliente
• Identificar Requisitos. –Reconhecer e rotular:
• Comportamentos da Aplicação• Atributos comportamentais• Questões e Suposições
• Perguntar ao cliente.
Revisão dos Requisitos
Brainstorming• Produza o maior número de idéias
possíveis.
Regras do Brainstorming
Esclareça o objetivo da sessão. Gere o maior número de idéias
possíveis. Deixe a imaginação voar. Não permita críticas ou debates. Mescle idéias.
Brainstorming: Vantagens e Desvantagens
• Vantagens–Usado a qualquer tempo, em qualquer lugar.–Bom para grupos.–Bom para coisas de alto-nível e
pressuposições.–Bom para algum nível de automação.
• Desvantagens–Se aplica mais a processos em grupo.–Não sistemática na forma “clássica”.
Redução de Idéias: Podar e organizar
Afine Diagramas
Redução de Idéias: Priorize Idéias• Priorize idéias restantes.
–Vote• Votos cumulativos
– Compre idéias
• Voto único
–Aplique avaliações– Critério
• Não ponderado• Ponderado
Rational University “bucks”
Definição do Sistema: Atividades e Artefatos
Posicionamento do Produto• Comunica a intenção e importância.
Dica: Use declaração do problema como ponto de partida.
Para (cliente alvo)
Que (declare oportunidade e necessidade)
O (nome do produto)
É um (tipo de produto)
Que (estabeleça os benefícios, que levaria ainvestir no produto)
Diferentemente (concorrente)
Nossoproduto (diferença para o concorrente)
Capture os Requisitos de Software
Especificações de Documentação do
Usuário
Especificação de Projeto
Requisições de Stakeholders
Documento de Visão
Especificação SuplementarModelo de CSU
Requisições Chave do Stakeholder
e Características
Requisitosde Software
Requições do Stakeholder
Passos para criar o Modelo de Casos de Uso
1. Identifique atores e casos de uso.- Descrição Breve.
2. Rabisque cada caso de uso.- Fluxo básico de Eventos.
- Fluxos alternativos.
3. Detalhe cada caso de uso.- Detalhe os fluxos de eventos.
- Estruture cada fluxo do CSU.
- Adicione Detalhes.Condições Pré e Pós, requisitos especiais, relacionamentos,
diagramas de caso de uso, e etc.
Exemplo de Diagrama
Sistema de Notícias
Cliente deNegociação
Sistema de Negociação na Bolsa
Operador
Sistema deCotações
Agendador
Rede Financeira
Efetuar Negociação
Conta
Gerenciar Portfolio
Obter Cotação
Executar Negociação
Distribuir Notícias
Rever Conta
Esboço de cada caso de uso
Nome do Caso de UsoDescrição BreveFluxo Básico 1. Primeiro Passo 2. Segundo Passo 3. Terceiro PassoA1 Fluxo Alternativo 1A2 Fluxo Alternativo 2 A3 Fluxo Alternativo 3
Estruturar o fluxo em passos
Numerar os passos
Porque esboçar casos de uso?Esboço
Caso de Uso
Muito Peq.?
Tamanho do Caso de Uso
Muito Grande?
É mais de um caso de uso?
Esboçar ajuda a identificar fluxos alternativos
? ?
?
Fluxo de Eventos (Básico e Alternativo)
• Um fluxo básico–Cenário do Caminho Feliz–Cenário de sucesso do início ao fim.
• Vários fluxos alternativos–Variantes regulares–Casos ímpares–Fluxos excepcionais (erros)
Fluxo: um conjunto de passos seqüenciais.
Representando fluxos básicos e alternativos
Passo 1
Pas. 2A1
A3
Passo 4
A4 Passo 3
A2A5
<Nome do Caso de Uso>1. Descrição Breve2. Fluxo de Eventos 2.1 Fluxo Básico Passo 1 Passo 2 Passo 3 Passo 4 2.2 Fluxos Alternativos 2.2.1 A1 … 2.2.2 A2 … 2.2.3 A3 … 2.2.4 A4 … 2.2.5 A5 …
O que é um cenário?
Fluxo
CenárioFluxo: um conjunto de passos sequenciais.
Caso de Uso: Um repositório com a descrição de todos os fluxos.
Cenário: Um conjunto ordenado de fluxos que vem do início do caso de uso
até seus pontos finais.
Capturando os cenários do Caso de Uso• Capture os cenários na especificação de
caso de uso em sua própria seção.• Dê um nome a cada cenário.• Liste o nome de cada fluxo em cada
cenário.–Coloque os fluxos em seqüência.
Exemplo do Cenário de Caso de Uso Obter Cotação
Cenário “Conexão do servidor caiu.” Fluxos: “Fluxo Básico,” “Sistema de Cotações Indisponível.”
Esboçe o fluxo de eventos• Fluxo Básico
– Quais eventos iniciam o caso de uso? – Como o caso de uso termina?– Como o caso de uso repete um comportamento?
• Fluxos Alternativos– Há situações não obrigatórias que ocorrem?– O que pode acontecer de estranho?– Quais variantes podem acontecer?– O que pode estar errado?– O que não pode acontecer?– Que tipos de recurso podem ser bloqueados?
Desenho passo-a-passo: Obter Cotação
Fluxo Básico1. O cliente se autentica.2. O cliente requisita a obtenção de uma cotação.3. O cliente seleciona o botão de negociação de ações.4. O cliente obtêm a cotação desejada.5. O sistema apresenta a cotação.6. O cliente obtêm outras cotações.7. O cliente sai do sistema.
Fluxos AlternativosA1. Cliente de Ações não identificado.A2. Sistema de Cotações indisponível. A3. Sair.
Existem outras alternativas?
Packages (Pacote): Organize o Modelo de CSU
Use-Case Packages
Package Raiz
Use Cases
Use-Case PackagesAtores
Refinar a definição do sistema: Atividades e Artefatos
O que são restrições de projeto?
• Um requisito que se refere ao projeto e/ou arquitetura do sistema é uma restrição de projeto.– Distinguir de outros requisitos. – Colocá-la em uma seção especial do Documento de
Requisitos.– Identificar a fonte de cada uma.– Documentar a razão de cada uma.
• Exemplos.– Um algoritmo de uso obrigatório.– O uso de um determinado produto de banco de dados.– A linguagem de programação que deve ser usada.
O queComo
O queComo
O queComo
Necessidades
Características
Casos de Uso
Espec. TécnicaProcedimentos Teste
Planos Documentação
O homem de cima
É o Homem do
outro andar.”
Davis, 1993
O Dilema do O Que-Versus-ComoQuestão: Como especificar um requisito de projeto?
Resposta: Depende de seu ponto de vista.
Características levam a Requisitos de Software
Caract 63 – o sistema de acompanhamento de defeitos irá fornecer informações de tendências para ajudar o gerente de projeto a ter conhecimento do andamento
Informações de tendências serão apresentadas em um gráfico de linhas apresentando tempo em x, e nº de defeitos em y.
Períodos de negocição podem ser digitadas em dias, semanas e meses.
Imprimir Relatóriode Status
Operador Gerente deProjeto
O sistema pode … O sistema deve … O sistema deve ...
Qual escolher?
Como especificar requisitos funcionais?
• Use os casos de uso e setenças declarativas.– Ambos são necessários para entender um sistema de
complexidade relevante.
• Dê preferência a casos de uso, onde apropriados.
+Casos de Uso Sentenças Declarativas
E sobre requisitos que não estão em Casos de Uso?
• Escreva uma sentença declarativa que não esteja em caso de uso.– Use uma palavra-chave que para ajudar na
identificação, por exemplo “deve.”– Numere e dê um título a cada requisito. – Agrupe requisitos relacionados.
• Use language the team easily understands.– Use uma estrutura de setença simples.
• Adjetivo + Substantivo.– Seja conciso e claro.
• Descreva o requisito em 1 a 3 sentenças.• Torne o requisito completo.
– Use termos do glossário.
Requisitos Funcionais em Sentenças Declarativas
• Alguns requisitos são mais fáceis de entender em sentenças declarativas.– Exemplo do sistema RU e-st
1. Localização:
SUPL120: O sistema RU e-st deve suportar a apresentação de todas as mensagens e menus no idioma escolhido pelo usuário a qualquer hora. Os idiomas suportados devem ser Inglês, Espanhol, Francês, Alemão, e Sueco.
Onde as sentenças declarativas são especificadas?
• Se o requisito se aplicar ao caso de uso:–Especifique no caso de uso–Na seção “Requisitos especiais”
• O requisito se aplica a uma parte do sistema: –Especifique na Especificação Suplementar
Variações nos Requisitos Funcionais
O sistema com um pequeno comportamento
externo observável.
O sistema com muito comportamento externo
observável.
Por que detalhar casos de uso?• Para especificar os requisitos de software.
–Criar a especificação que deve ser implementada.
• Esclarecer detalhes importantes do fluxo de eventos.–O que um ator faz.–Como o sistema deve responder ao ator.–Quais informações são trocadas.
• Descrição de informação adicional.–Pré-Condições–Pós-Condições
Detalhe um caso de uso1. Procure atores e casos de uso.
2. Detalhes do caso de uso.
<Nome Caso de Uso>1. Descrição Breve2. Fluxo de Eventos Fluxo Básico de Eventos Fluxos Alternativos3. Requisitos Especiais4. Pré-Condições5. Pós-Condições6. Pontos de Extensão7. Relacionamentos8. Diagramas de Caso de Uso9. Outros diagramas e itens
<Nome Caso de Uso>1. Descrição Breve2. Fluxo de Eventos Fluxo Básico de Eventos Fluxos Alternativos3. Requisitos Especiais4. Pré-Condições5. Pós-Condições6. Pontos de Extensão7. Relacionamentos8. Diagramas de Caso de Uso9. Outros diagramas e itens
Esboço
Adicione Detalhes
Detalhe o fluxo básico de eventos
Estruture o fluxo em passos
Numere e dê títulos a cada passo
Descreva passos (completamente e claramente)
Torne cada passo um conjunto de eventos
Obter Cotação1.1 Fluxo Básico1. Cliente se autentica
O caso de uso se inicia quando o cliente se autentica. O sistema valida login e senha do cliente. O sistema apresenta uma lista de funcionalidades.
2. O cliente seleciona a função “Obter Cotação”O cliente escolhe obter uma cotação.O sistema apresenta uma lista de símbolos de cotação e nomes de seguros.
3. O Cliente seleciona o seguroO cliente seleciona de uma lista de seguros ou informa o símbolo de seguro para a cotação.
4. O sistema obtêm a cotação do sistema de cotaçõesO sistema envia o símbolo de cotação para o Sistema de Cotações, e recebe uma resposta do sistema de cotações.O sistema apresenta a tela correspondente da cotação (veja em campos apresentados na Especificação Suplementar) ao cliente.
Gerenciar Detalhes
Caixa preta Caixa Branca
• Saber quem vai ler.• Escreva para a caixa preta.• Algum texto de caixa branca pode melhorar o
entendimento porque torna o caso de uso mais concreto.
Estruturar os fluxos de caso de uso• Organização interna do caso de uso.
–Melhora legibilidade.–Torna os requisitos mais fáceis de entender.
• Documente os estilos aceitáveis nos Guias de Modelagem de Casos de Uso.
Numeração e Referência CruzadaEstilo do RUP Estilo de Tag
1. Customer Logs On
In Step 1, Customer Logs On, in
{Trading Customer Logs on}
In {Trading Customer logs on},
Alternative FlowsA3 Request Additional Quotes
In Step 3, Customer Gets Quote, in the Basic Flow, if the customer wants additional quotes.
The use case continues at Step 3.
A4 QuitIf at any time the Trading Customer decides to quit.The use case ends.
A5 Unknown Trading SymbolIn Step 3, Customer Gets Quote, in the Basic Flow, if the system cannot recognize the trading symbol, the system notifies the Trading Customer that the trading symbol is not recognizable.
The use case continues at the beginning of Step 3.
Fluxos alternativosA3 Requisitar cotações adicionais
No passo 3, Cliente obtêm cotação, no Fluxo básico, se o cliente desejar cotações adicionais.
O caso de uso continua no passo 3.
A4 SairA qualquer tempo o Cliente de Negociações pode sair do sistema.O caso de uso termina.
A5 Símbolo de negociação desconhecidoNo passo 3, Cliente obtêm negociação, no Fluxo Básico, se o sistema não reconhecer o símbolo de negociação, o sistema notifica o ator que o símbolo não existe.
O caso de uso continua do início do passo 3.
Detalhe fluxos alternativosDescreva o que
Acontece
Condição
Ações
Resuma a Localização
Localização
Evite Comportamento Condicional em série
• Torna os cenários difíceis de entender.
• Mais difícil de implementar e testar.
Prefira fluxos alternativos.
Evite comportamento repetitivo em série
• Torna os cenários mais difíceis de identificar.
• Mais difícil de testar e implementar.
Prefira fluxos alternativos.
Fluxos alternativos X Comportamento Condicional em série
• Fluxos alternativos– Prós
• Pode ser usado em qualquer lugar onde haja comportamento condicional.– REPITA-ATÈ, SE-ENTÃO-SENÃO-FIM-SE
• Torna os cenários fáceis de identificar.– Isto ajuda a implementação e ao teste
– Contras• Aumenta a complexidade de manter referências.
• Comportamento condicional em série– Prós
• Mais de fácil de lidar nos fluxos com pequenas variações.– Contras
• Difícil de identificar cenários, testar e implementar.
Visualizar comportamento alternativoCliente Sistema Sis. Cotação
Sub-fluxos• Melhora a clareza.
• Permite reuso intermo dos requisitos.
• Diferente dos fluxos alternativos, são chamados explicitamente.
• Sempre retorna para a linha de onde foi chamado.
Fluxos Alternativos Subfluxos
Exemplo de Subfluxo
Mantenha a interface do usuário fora do caso de uso
• Texto não é bom para descrever tela.• Casos de uso desconhecem tela.• Descreva tela durante Análise com
protótipos:–Modele a iteração com tela via protótipo
Clique Arrastar FormAbrir Fechar ComboBotão Campo Drop-down Pop-up Rolar Navegar Registro Janela
Pergunta Escolhe Inicia EspecificaSubmete SelecionaComeça Apresenta Informa
Palavra a EVITAR Palavras para usar
Use o glossário efetivamente
GlossárioDetalhes Cadastrais: informações que identificam unicamente e fornecem informações de contato para um cliente localizado nos EUA. A informação consiste de: Nome, 2 linhas de endereço, cidade, estado, cep, e telefone para contato.
Caso de usoEntrar com informações do cliente
O sistema requisita ao cliente que informe seus detalhes cadastrais.O cliente informa seus detalhes cadastrais.O cliente cria uma conta.
Implementação
Pré-condições• Descreve em qual estado o sistema deve se
encontrar para o início do caso de uso.– Não é o evento que inicia o caso de uso.
• Reduz a quantidade de validação necessária.
• Opcional: Use somente se necessário para melhorar o entendimento.
Obter CotaçãoPré-condiçãoO sistema RU e-st deve se estar conectado com o Sistema de Cotação antes do início do caso de uso.
Pós-Condições
• Descreve em qual estado deve estar o sistema ao fim da execução do caso de uso.– Estado garantido de quando terminar o caso de uso.– Pode conter variações.
• Opcional: descreva somente se necessário para melhorar o entendimento.
Executar Previsão
Pós-condição
Ao fim do caso de uso todas as contas
devem estar atualizadas para refletir
as transações que ocorreram.
Seqüência do caso de uso com pré e pós Condições
Casos de uso não interagem.
Outras propriedades dos casos de uso
• Requisitos especiais– Relacionado a este casos de uso, não coberto pelos
fluxos.– Geralmente não funcionais, dados, regras de negócio.
• Pontos de Extensão– Nomeia com conjunto de locais nos fluxos onde há
comportamento de extensão a ser executado.• Relacionamentos (Use-Case-Model)
– Associações com atores e casos de uso.• Diagramas de Casos de Uso
– Modelo visual de todos os relacionamentos envolvendo o caso de uso.
• Outros diagramas e encapsulamentos– Interação, atividade, ou outros diagramas.
Dicas para casos de uso
• Descreva apenas eventos visíveis ao ator:– O que o ator faz.– O que o sistema responde ao ator.
• O que o caso de uso fornece de valor ao ator.• Casos de uso podem ter diferentes níveis de
detalhe.– Detalhe até que cada stakeholder tenha um entendimento
comum dos requisitos de sua perspectiva, e então pare.
• Use termos e vocabulário comum a todos.• Use linguagem precisa.
Checkpoints para casos de uso
• As iterações e trocas com os atores estão claramente descritas?
• A seqüência de comunicação entre atores e casos de uso estão em conformidade com as expectativas do cliente?
• Está claro como e onde os fluxos de caso de uso começam e terminam?
• Subfluxos estão modelados com precisão?
E sobre os requisitos não funcionais?• O “URPS” do FURPS
– Usabilidade– Robustez (Confiança)– Performance– Suportabilidade
• Conformidade com as Leis e Regulamentos– IMMETRO– ANVISA– BC– ISO
• Restrições de Projeto– Sistema Operacional– Ambientes– Compatibilidade– Padrões de Aplicação
FFunctionalityFeature setCapabilities
GeneralitySecurity
UUsability Human factorsAesthetics
ConsistencyDocumentation
RReliability
Frequency/Severityof failureRecoverability
PredictabilityAccuracyMTBF
PPerformance SpeedEfficiency Resource usage
ThroughputResponse time
SSupportabilityTestabilityExtensibility AdaptabilityMaintainabilityCompatibility
ConfigurabilityServiceabilityInstallabilityLocalizabilityRobustness
Exemplo: Requisitos não funcionais
• O sistema RU e-st–O sistema deve fornecer cotações de preço
com um atraso máximo de 15 minutos.
• E quanto aos outros?• Onde cada um deles devem ser
especificados?
Especifique Requisitos de Usuabilidade
• Usabilidade é a facilidade com que o software pode ser aprendido e operado por um usuário.
• Requisitos de Usabilidade incluem:– Requisitos de tempo de treinamento, tempos de tarefas
mensuráveis.– Habilidades do usuário (iniciante/avançado).– Comparação com outros sistemas conhecidos pelo usuário.– Help on-line, dicas, necessidades de documentação.– Conformidade com padrões.
• Exemplos: Windows, guias de estilo, Padrões de Tela
Toda a documentação do usuário deve estar em conformidade com o Manual de Estilo para Documentos Técnicos da Microsoft® .
Especifique requisitos de Confiabilidade
• Confiabilidade é a capacidade que um software tem de se comportar consistentemente da maneira aceitável pelo usuário.
• Requisitos de Confiabilidade incluem:–Disponibilidade (xx.xx%)–Acurácia–MTBF (xx hrs)–Max. bugs per/KLOC (0-x)
O relatório de velocidade da cápsula não tripulada de Marte deve ser em unidade de metros por segundo e estar entre 1 até 1e6.
Especifique Requisitos de Performance
• Performance é a medida de velocidade ou eficiência de um sistema em execução.
• Requisitos de performance incluem:–Capacidade–Throughput–Tempo de resposta
- Memória- Modo de degradação- Use de recursos limitados
- Processador, memória, disco, banda de rede
Não há mais do que 4 protocolos de troca, tamanhos não menores do que 512k bytes cada, entre cliente e servidor para a troca de dados.
Especifique requisitos de Suportabilidade • Suportabilidade é a capacidade do software em ser
facilmente modificável para acomodar melhorias e reparos.
• Requisitos de suportabilidade incluem:– Linguagens, SGDB, ferramentas, e etc.– Padrões de programação.– Manipulação de erros e padrões de relatório.
• Difícil de especificar– Se não mensurável ou observável, assim não é requisito.– É uma restrição de projeto?– É uma intenção ou um objetivo?
Como descrever protocolos de comunicação
• Especifique um protocolo de comunicação se o ator é um sistema externo ou um outro hardware.–A descrição do caso de uso pode estabelecer
se um determinado protocolo é usado.–Se o protocolo é novo, ele será totalmente
descrito no desenvolvimento orientado a objetos.
Estruturar Modelos de Casos de Uso
• Como estruturar modelos?– Transformar partes de casos de
uso em novos casos de uso.
• Por que estruturar o modelo de casos de uso? – Simplificar os casos de uso
originais.• Tornar mais fácil de entender.• Tornar mais fácil de manter.
– Reuso de Requisitos.• Compartilhar pelos diversos casos de
uso.
Relacionamentos entre CSUs
• Include
• Extend
• Generalização
«include»
«extend»
O que é um relacionamento de Include?
• O relacionamento entre um caso de uso origem com um caso de uso incluído.
• O comportamento do caso de uso incluído é explicitamente incluído dentro do caso de uso de origem.
«include»
Origem
Inclusão
Relacionamento de Inclusão
Caso de Uso de Identificar Cliente1. Autenticar2. Validar autenticação3. Entrar com senha4. Validar senhaA1: Autenticação inválidaA2: Senha erradaA3: ...
Caso de Uso de Obter Cotação1. Inclui “Identificar Cliente”
para verificar a identidade do cliente
2. Mostrar Opções. O Cliente seleciona “Obter Cotação”
3. ...
Executar Negociação
Obter Cotação
Identificar Cliente
Outro caso de uso «include»
«include»
«include»
Trading Customer
Execução de um relacionamento de inclusão
• Totalmente executado quando o ponto de inclusão é alcançado.
Instância de Caso de Uso
Caso de UsoBase
Caso de UsoIncluído
Por que utilizar um relacionamento de inclusão?
– Cortar comportamento comum entre 2 ou mais casos de uso.• Evitar descrever o mesmo
comportamento duas vezes.
• Assegurar comportamento igual em vários outros pontos.
– Cortar e encapsular comportamento comum. • Simplificar fluxos de eventos
complexos.
• Cortar partes não primárias do comportamento.
«include»
Base
inclusão
Por que?
O que é um relacionamento de Extend?
• Conecta um ponto de extensão de um caso de uso a um ponto do caso de uso base. –Insere um ponto de comportamento extensível
para um caso de uso base.–Insere apenas se uma condição for
verdadeira.–Insere no caso de uso base um ponto de extensão nomeado.
«extend»
Extension
Base
Relacionamento de Extensão: Exemplo RU e-st
Obter Previsões
Obter Notícias
Obter Cotação
«extend» «extend»
Cliente de Negociações
Sistema especialistaem cotações
Sistema novo
Relacionamento de ExtensãoCaso de Uso Obter CotaçãoFluxo Básico:1. Incluir “Identificar Cliente”
para verificar identidade do cliente.
2. Apresentar Opções. 3. Cliente seleciona “Obter
Cotação.”4. Cliente obtêm cotação.5. Cliente obtêm outras
cotações.6. Cliente faz logs off.A1. Sistema de cotação fora…
Pontos de Extensão:
O ponto de extensão “Serviços Opcionais” ocorre no passo 3 do Fluxo Básico e passo A1.7 no fluxo alternativo Sistema de cotação fora.
Caso de Uso Obtêm NotíciasEste caso de uso extende o caso de
Obter cotações, no ponto de extensão “Serviços Opcionais.”
Fluxo Básico:
1. Se o cliente selecionar “Obter notícias,” o sistema pergunta ao cliente o intervalo de tempo e a quantidade de itens de notícia.
2. O cliente informa os dados. O sistema envia o símbolo de cotação de ações ao sistema de Notícias, recebe a resposta, e apresenta as notícias ao cliente.
3. O caso de uso Obter cotações continua.
A1: Sistema indisponívelA2: Sem notícias para a cotação da ação …
Execução de um Extend• Executado quando o ponto de extensão é
alcançado e a condição de extensão válida.
Instância deCaso de Uso
Caso de Uso Base
Caso de UsoExtendido
Ponto de Extensão
Por que usar um relacionamento de Extend?
• Recortar comportamento excepcional ou alternativo.– Executado somente sob certas
circunstâncias.– Recortar simplifica o fluxo de
eventos no caso de uso base.– Exemplo: Disparar Alarmes.
• Adicionar Comportamento de Extensão.– Comportamento desenvolvido
separadamente, possivelmente em versão posterior.
«extend»
Extensão
Base
Caso de Uso Concreto versus Abstrato
Caosos de Uso Abstratos (A & D):• Não tem de ser completos.• Existem somente em conjunto
com outros casos de uso.• Não possuem sua própria
instância.
Um caso de uso pode ser concreto ou abstrato.
«extend»
«include»
Concrete use cases (B & C):• Tem que ser completos e
claros.• Possuem suas próprias
instâncias.
A
D
CBDica:Mesmo retirando todos os casos de uso abstratos você ainda é capaz de entender o sistema
Por que não estruturar o Modelo de Casos de Uso?
- A solução é mais difícil de ver quando o casos de uso é fragmentado.
- Decomposição de Caso de Uso.
- Diminui entendimento.
- Aumenta complexidade.
- Aumenta esforço de revisores, testadores e desenvolvedores.
- Nem todos os stakeholders estão confortáveis com o formato.
- O Modelo de caso de uso se parece com o design.
«include»
Base
Inclusão
Por que não?
«extend»
Extensão
Filho
• Atores podem ter características comuns. • Múltiplos atores podem ter papéis ou propósitos
comuns ao interagir com os casos de uso.
O que é Generalização de Ator?
Filho 1 Filho 2
Pai
• Pai: Medical Worker– Servidor Hospitalar pode
ler prontuário
• Filhos: Doutor, Enfermeira, Auxiliar– Doutor, Enfermeira, e
Auxiliar podem ler prontuário
Generalização de Atores
Ler ProntuárioEnfermeira
Auxiliar
Servidor Hospitalar
Doutor
Agendar Operação
Por que generalizar atores?
• Simplifica o relacionamento entre vários atores e casos de uso.
• Mostra que o comportamento do pai é herdado pelos filhos.
• Representa diferentes níveis de segurança.
Filho 1 Filho 2
Pai
Atores concretos versus abstratos• Um ator abstrato contém a
parte comum dos papéis. – Não podem ser instanciados.– Exemplo:
• Ninguém terá o cargo: servidor médico.
• Um ator concreto pode ser instanciado.– Exemplo:
• Lauren é Doutora. • Daniel é enfermeiro.
Doutor Enfermeira
Funcionáriode Medicina
Guias para a modelagem de casos de uso
• Notações para usar e não usar.–Por exemplo, quando usar relacionamento de
generalização.
• Papéis, recomendações, estilos, e como descrever um caso de uso.
• Recomendações de quando começar a estruturar os casos de uso(não tão cedo).