Caderno do Aluno
Engenharia de Requisitos de Software
Visão Geral
João Sousa
Apoio:
Desenvolvimento de Sw - Como estamos?
• Segundo o Standish Group (CHAOS Report 2004):
– 34% dos projetos com sucesso.
– 15% dos projetos cancelados antes de completados.
– 51% dos projetos completados com problemas:
• Custo adicional médio: 46%
• Prazo adicional médio: 82%
• Entrega média: 52% do escopo previsto
Nota: Já foi pior!! – Veja relatório de 1994
Nota: E não tem melhorado Em 2008 32% dos projetos com sucesso
http://www.standishgroup.com/newsroom/chaos_2009.php
Slide 2
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
1
Caderno do Aluno
Fatores de Sucesso
• Características normalmente presentes em projetos bem
sucedidos:
– Apoio da alta direção.
– Stakeholders comprometidos e participando
efetivamente do projeto.
– Definição clara dos requisitos e método controlado de
modificações.
– Processo de desenvolvimento organizado.
– Estimativas realistas.
– Gerenciamento efetivo do projeto (incluindo riscos).
Slide 3
Disciplinas
Uma disciplina é uma coleção de atividades que estão
relacionadas a uma área de conhecimento.
• As disciplinas são:
– Modelagem de Negócios
– Requisitos
– Análise e Design
– Implementação
– Implantação
– Gerência de
Configuração e Mudança
– Gerenciamento de
Projeto
– Teste
Slide 4
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
2
Caderno do Aluno
Relacionamento entre as Principais Disciplinas
orientam
Escopo
Requisitos
Gerência
Projetos
projetados
verificados
implementados
planeja
acompanha
construídos
Análise e
Design
avaliados
Implementação
controlados
Testes
Gerência de
Configuração e Mudança
Slide 5
Importância dos Requisitos
• “A parte individual mais difícil da construção de um sistema de
software é decidir o que construir. Nenhuma parte do trabalho
danifica tanto o sistema resultante se for feita de forma incorreta.
Nenhuma outra parte é mais difícil de se consertar depois.”
Fred Brooks
• Quanto mais tarde no processo de desenvolvimento um defeito for
detectado, maior será o custo para consertá-lo.
• Estágio
Custo Relativo
Requisitos
1-2
Design
5
Codificação
10
Teste de Unidade
20
Teste de Aceitação
Manutenção
50
200
Slide 6
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
3
Caderno do Aluno
Importância dos Requisitos
Problema Real
Requisitos
Especificação
Correta
Especificação
com Erro
• Os erros são propagados e
aumentam substancialmente quanto
mais cedo forem cometidos.
• Erros em requisitos contribuem
para 70% do retrabalho e podem
consumir de 25% a 40% do
orçamento do projeto.
Fonte : Boehm e Papaccio
Design
Implementação
Testes
Design
com Erro
Design
Correto
Design Baseado em
Especificação com Erro
Código
Correto
Código
com Erro
Funções
Corretas
Erros Fácil
Correção
Código Baseado em Código Baseado em
Design com Erro Especificação com Erro
Erros “Difícil’
Correção
Erros Ocultos
Slide 7
Requisito - Definição
• Algo que se deseja ou precisa (Webster´s Dictionary)
• Uma característica que o usuário necessita para resolver um
problema ou atingir um objetivo (IEEE Standard)
• Uma característica que o sistema deve possuir para
satisfazer um contrato, padrão ou outro documento formal
(IEEE Standard)
Slide 8
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
4
Caderno do Aluno
Níveis de Abstração - Problema x Solução
Necessidades
Problema
Solução
Características
(requisitos de alto nível)
Visão
Especificação
Detalhada
Requisitos detalhados
do software
Slide 9
Necessidade
Eu preciso me comunicar
com outras pessoas, seja
por iniciativa minha ou
delas, a qualquer tempo,
onde quer que eu esteja.
Slide 10
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
5
Caderno do Aluno
Solução
O que diferencia uma solução da outra?
Como conhecer essas diferenças?
Slide 11
Refinamento de Requisitos
Necessidade
Especificação Detalhada
Acompanhar indicadores de
qualidade ao longo do
projeto.
Requisito 63.1:
Apresentar um relatório de histograma
mostrando o tempo no eixo x e o
número de defeitos encontrados no eixo
y.
Visão
Sistema de
Controle de Defeitos
Característica 63:
Apresentar graficamente a
evolução da quantidade de
defeitos ao longo do projeto.
Requisito 63.2:
O usuário pode informar o período a ser
apresentado no relatório em uma das
seguintes unidades: dias, semanas ou
meses.
Padrão: semanas
Requisito 63.3:
O usuário pode informar o conjunto de
módulos do sistema que serão
considerados no relatório.
Padrão: todos.
Requisito 63.4:
O relatório de histograma deve seguir o
formato descrito no apêndice X.
Slide 12
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
6
Caderno do Aluno
Requisitos Funcionais x Não Funcionais
• Requisitos Funcionais
– Funcionalidades disponibilizadas pelo software, de modo a
capacitar os usuários a executar suas tarefas e satisfazer às
necessidades do negócio.
– São ações que o produto deve realizar de modo a fornecer
funcionalidades úteis para seus usuários.
– Ex: emitir conta telefônica mensal
• Requisitos Não Funcionais
– São propriedades ou qualidades que o produto deve possuir
– Em sua maioria, não expressam nenhuma função a ser
realizada pelo software, e sim necessidades e restrições que o
mesmo deve satisfazer.
– Relacionados com a Arquitetura do Software
– Ex: desempenho, robustez, facilidade de uso, ...
Slide 13
Modelo Genérico da Engenharia de Requisitos
Levantamento
dos
Requisitos
Análise e
Negociação
dos Requisitos
Especificação
dos Requisitos
Verificação e
Validação dos
Requisitos
Gerência dos Requisitos
Slide 14
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
7
Caderno do Aluno
Levantamento
• Entender as atividades, os conceitos, os problemas, a
cultura e a linguagem dos usuários para construir
sistemas que atendam às suas necessidades.
• Entrevistas
• Observação / Demonstração
• Reuniões Estruturadas
– Brainstorming e Brainwriting
– Workshops
– JAD: Joint Application Development
– ...
Slide 15
Análise e Negociação
• Já falei com os interessados. Agora é só escrever os casos
de uso, certo?
• Analisar o que foi levantado:
– Registrar os problemas / necessidades.
– Modelar o entendimento sobre o contexto (dados, processos,
envolvidos, locais, eventos/ciclos temporais,
motivações/regras).
– Entender a importância relativa das necessidades.
– Identificar conflitos, inconsistências, omissões.
– Propor e negociar alternativas de solução.
Slide 16
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
8
Caderno do Aluno
Especificação
• Requisitos são especificados de forma que todos os
envolvidos possam ter um entendimento comum sobre o
que deve ser construído.
• Como especificar?
– User Stories
– Casos de Uso
– Especificações Tradicionais
• Preciso mesmo especificar?
– Nossa memória tem capacidade limitada.
• Projeto Boeing 777: 300.000 requisitos!!
Slide 17
Refinamento de Requisitos
• Até que nível de detalhe devemos ir?
• Definir:
– Cada entrada e saída
– Cada validação
– Cada transformação
– Os comportamento normais e alternativos
– Os comportamentos em cada exceção
• Não se esqueça das questões não funcionais
– Performance, robustez, confiabilidade, segurança, etc.
• E a Interface com o Usuário?
– Nível mais concreto observado pelo usuário.
– Deve ser validada antes de se investir grande esforço na
construção.
Processo de Refinamento: “Os problemas surgem nos detalhes!”
Slide 18
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
9
Caderno do Aluno
Verificação e Validação
• Estamos construindo o produto correto?
• Estamos construindo o produto da forma correta?
• A especificação é examinada de forma a tentar assegurar
que os requisitos foram definidos sem ambigüidades,
inconsistências ou omissões, e que todos os defeitos foram
detectados e corrigidos.
• Inspeção e utilização de Checklists
• Diferentes Perspectivas (Cliente, Testador, ...)
• Protótipos e Maquetes.
Slide 19
Gerência de Requisitos
• Define uma abordagem sistemática para levantar, organizar e
documentar as modificações nos requisitos.
• É executada em paralelo durante todo o processo de
desenvolvimento.
• Fornece instrumentos para apoiar a análise de impacto das
mudanças.
• Verifica a consistência entre os requisitos e todos demais
produtos relacionados (código, modelos, cenários de testes, ...).
• Captura de informações de apoio à gerência do projeto:
– Importância, Risco, Release previsto, ...
Slide 20
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
10
Caderno do Aluno
Controlar as mudanças dos Requisitos
Cliente
Fornecedor
Solicitar
Mudança
Identificar
Requisitos
Impactados
Definir
Impacto da
Mudança
Aprovar
Solicitação
de Mudança
Estimar
Impacto da
Mudança
Revisar
Impacto da
Mudança
Implementar
e Validar
Mudança
•
Ferramenta de Workflow para acompanhamento – JIRA, ClearQuest, ...
Slide 21
Rastreabilidade
Necessidade
Característica
Requisito
Suplementar
Caso de Uso
Caso de Teste
Regra
Módulo
Implementação
Todos os itens de projeto e implementação partem de um
requisito inicial e se identificam com ele!
Slide 22
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
11
Caderno do Aluno
Processo
• Conjuntos de atividades definidas
– Insumos
– Resultados
– Papéis
– Instrumentos de apoio - Ferramentas
• e uma seqüência estabelecida entre elas
– pode conter ciclos
– deve conter possibilidade de paralelismo
• Define os artefatos que serão desenvolvidos
• Define quando e como eles serão desenvolvidos (atividades)
• Define o perfil de quem irá desenvolvê-los
Slide 23
Processo
Métodos / Técnicas
Processo
Pessoas habilitadas,
treinadas e motivadas
Ferramentas /
Equipamentos /
Tecnologia
Slide 24
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
12
Caderno do Aluno
Processo de Requisitos – Exemplo
Necessidades
An. Requisito
Visão Geral
Software
Definir
Escopo
Projeto
Lista de Casos
de Uso
An. Requisito
Identificar
Comportamento
do Software
Casos de Uso
An. Requisto
Detalhar
Requisitos do
Software
M
Aprovação
Requisitos
Cliente
Aprovação
Detalhamento
M
Cliente
Plano Gerência Requisitos
Atributos e Rastreabilidade
An. Requisito
Gerenciar
Requisitos
Slide 25
Definir a Visão Geral da Solução
• Entender o problema a ser resolvido.
• Identificar os stakeholders e suas necessidades.
• Definir as fronteiras da solução.
• Identificar restrições e premissas.
• Definir características funcionais que o software deve
apresentar para atender as necessidades.
• Definir características suplementares que o software deve
apresentar para atender as necessidades.
• Definir características que poderiam ser aplicáveis, mas que
não serão contempladas pelo software.
Slide 26
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
13
Caderno do Aluno
Caso de Uso
• O comportamento funcional do software pode ser descrito
através da técnica de casos de uso.
• O comportamento do software é documentado em um modelo de
Caso de Uso que ilustra as funcionalidades existentes no
software (Casos de Uso), suas fronteiras (Atores) e os
relacionamentos entre os Casos de Uso e os Atores (Diagramas
de Caso de Uso).
• Um caso de uso é um curso completo de eventos iniciados por
um ator, especificando as interações que ocorrem entre atores e
o software, incluindo variações, de modo que um resultado de
valor observável seja obtido.
• O papel mais importante deste modelo é comunicar o
comportamento do software aos clientes ou usuários finais.
Slide 27
Ator
• Representa alguém ou alguma coisa que interage com o
software. Não fazem parte do software. Eles delimitam
os elementos externos ao software.
• Escreva para cada ator uma breve descrição e defina as
suas responsabilidades.
• Questões:
– Ator Cliente X Operador ? Quem utiliza o sistema?
– Temporizador x Ator primário
Slide 28
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
14
Caderno do Aluno
Identificando Casos de Uso
• Normalmente é difícil decidir se um determinado conjunto
de interações constituem apenas um caso de uso ou vários
casos de uso.
• Exemplo:
– Inserir latas e garrafas
– Solicitar impressão do recibo
Quantos casos de uso você identifica neste exemplo?
Slide 29
Decomposição Funcional
• Quebrar um problema em partes pequenas e isoladas.
– As partes trabalham juntas para prover a funcionalidade do
sistema.
– Muitas vezes não fazem sentido isoladamente.
• Casos de Uso:
– NÃO é decomposição funcional.
– Mantém a funcionalidade agrupada para descrever um uso
completo do sistema.
– Provê contexto.
– Mesmo nível de detalhe da decomposição funcional mas
estruturados para facilitar o entendimento dos stakeholders
Slide 30
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
15
Caderno do Aluno
Decomposição Funcional: Um Exemplo
Processar Transação
Inserir Cartão
Consórcio
Bancos
Entrar PIN
Selecionar Conta Destino
Selecionar Transferência
Cliente
Entrar Montante
de Fundos
Selecionar Conta Origem
Selecionar Saque
Selecionar Saldo da Conta
Slide 31
Evitar Decomposição Funcional
Sintomas
Ações Corretivas
– Casos de uso muito
pequenos
– Muitos casos de uso
– Casos de uso sem resultado
de valor
– Nomes com operações de
baixo nível
• “Operação” + “objeto”
• “Função” + “dados”
• Exemplo: “Inserir cartão”
– Buscar um contexto maior
“Por que estamos construindo o
sistema?”
– Coloque-se no papel do
usuário
“O que o usuário quer
alcançar?”
“O objetivo de quem esse caso
de uso satisfaz?”
“Que valor este caso de uso
agrega?”
– Dificuldade em entender o
modelo com um todo
Slide 32
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
16
Caderno do Aluno
Casos de Uso (sem decomposição funcional)
Sacar Dinheiro
Transferir Fundos
Consórcio
Bancos
Cliente
Depositar Fundos
Slide 33
Caso de Uso - Atividades de Identificação
• A identificação dos casos de uso é uma atividade de
definição da solução
• É fundamental contextualizar o motivo da existência de
cada caso de uso
• Entender como os casos de uso colaboram entre si para
atender as necessidades e os objetivos da solução
• Combinar o entendimento funcional e de informações
(domínio)
• Análise do problema para definição da solução
Slide 34
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
17
Caderno do Aluno
Caso de Uso - Atividades de Identificação
• Definir Módulos
– Organizar os casos de uso em pacotes a partir do domínio do
problema.
• Identificar Atores
• Identificar Casos de Uso
– Nome e Descrição Resumida
• Contextualizar o motivo da existência de cada caso de uso
– Relacionar Casos de Uso identificados com atividades,
entidades(domínio) e eventos do negócio.
– Existe uma “ordem de execução” desses casos de uso?
– Representar o ciclo de vida para entidades que tiverem uma
dinâmica de estados significativa.
Slide 35
Elaborar Modelo de Domínio (Conceitual)
Conferência
Edição da Conferência
1
0..*
Tópico de Interesse
0..*
0..*
1
*
Remetente
Pessoa
1
+classicado em
*
*
Autor
*
*
Artigo
*
Slide 36
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
18
Caderno do Aluno
Elaborar Modelo de Domínio (Estados)
Visão Dinâmica da Entidade de Negócio Artigo
UC - Cancelar Submissão
UC - Submeter Artigo
UC - Submeter Artigo
Com Pendência
Submetido
UC - Cancelar Submissão
Cancelado
UC - Realizar Triagem Artigo : [ Artigo Não OK ]
UC - Cancelar Submissão
UC - Realizar Triagem Artigo : [ Artigo OK ]
Liberado para Distribuição
Slide 37
Casos de Uso
• Um caso de uso descreve um conjunto de caminhos
que podem ser seguidos durante a utilização do
sistema em um determinado contexto.
Ex: Registrar Venda
A) Venda normal
B) Produto não está disponível
C) Cancelamento de Item
D) Cancelamento da Venda
Fluxo normal e Fluxos alternativos/exceções
Slide 38
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
19
Caderno do Aluno
Casos de Uso X Cenários
• Cenário de utilização é a descrição de uma situação real que
os usuários do software poderão encontrar.
• Cada caso de uso está relacionado com uma coleção de
cenários.
• Explorar os cenários auxilia na definição dos Casos de Uso.
– Cenários (concreto) x Caso de Uso (abstração).
Slide 39
Cenários - Exemplo
• Caso de Uso Empréstimo de Filme - Cenário 1
• O sócio José de matrícula 111 solicita o empréstimo do
filme “Avatar”.
• O sócio não está com saldo devedor.
• O sócio não possui outros filmes emprestados em seu
poder.
• Existem cópias do filme disponíveis (não estão nem
emprestadas e nem reservadas por outro sócio).
Slide 40
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
20
Caderno do Aluno
Cenários - Exemplo
• Caso de Uso Empréstimo de Filme - Cenário 2
• O sócio José de matrícula 111 solicita o empréstimo do
filme “Avatar”.
• O sócio não está com saldo devedor.
• O sócio possui cinco outros filmes emprestados em seu
poder.
• Existem cópias do filme disponíveis (não estão nem
emprestadas e nem reservadas por outro sócio).
Slide 41
Cenários - Exemplo
• Caso de Uso Empréstimo de Filme - Cenário 3
• O sócio José de matrícula 111 solicita o empréstimo do
filme “Avatar”.
• O sócio não está com saldo devedor.
• O sócio não possui outros filmes emprestados em seu
poder.
• Não existem cópias do filme disponíveis (todas as
cópias estão emprestadas ou reservadas por outros
sócios).
Slide 42
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
21
Caderno do Aluno
Formato da Especificação de Caso de Uso
• Vários formatos foram propostos por diferentes autores
• Componentes Principais
– Identificador do Caso de Uso (ID)
– Nome do Caso de Uso
– Descrição ou Resumo – Objetivo do Caso de Uso
– Atores Participantes
– Pré-condições
– Pós-condições
– Fluxos de Eventos
• Fluxo Normal
• Sub-Fluxos
• Fluxos Alternativos
• Fluxos de Exceção
Slide 43
Formato da Especificação de Caso de Uso
• Componentes Auxiliares
– Outros requisitos (tipicamente requisitos não funcionais)
– Regras de Negócio (específicas desse caso de uso)
– Dados (detalhamento dos fluxos de dados utilizados em
diferentes pontos do caso de uso)
– Detalhamento das Interfaces
• Alternativas para os componentes auxiliares:
– Seção específica na descrição detalhada do caso de uso para
os itens que relacionados só a um caso de uso específico.
– Documento específico para os itens relacionados a vários
casos de uso.
– Repositório Corporativo (baseado em SGBD) melhor
Slide 44
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
22
Caderno do Aluno
Formas de Detalhamento dos Fluxos
Passos numerados com rótulos
IDENTIFICAÇÃO DO SÓCIO
1.
Atendente solicita ao sistema iniciar o registro de um aluguel de
cópias.
2.
Sistema solicita a identificação do sócio que está alugando as
cópias.
3.
Atendente informa o código do sócio.
4.
Sistema verifica que o código informado corresponde a um
sócio que pode alugar cópias.
5.
Sistema apresenta o número máximo de cópias que o sócio
pode levar.
Slide 45
Formas de Detalhamento dos Fluxos
Passos numerados com rótulos (estilo jornal)
IDENTIFICAÇÃO DAS CÓPIAS
6.
Atendente informa a identificação de cada cópia a ser alugada.
7.
A cada cópia informada, o sistema apresenta o título do filme
correspondente, o preço de aluguel da cópia e o valor total do
aluguel.
PAGAMENTO
8.
Atendente informa o valor pago pelo sócio e confirma o aluguel.
9.
Sistema emite o comprovante de aluguel de cópias.
10. O sistema registra as informações do aluguel realizado e o caso
de uso se encerra.
Slide 46
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
23
Caderno do Aluno
O que descrever nos Fluxos?
• Como e quando o caso de uso é iniciado
– Atendente solicita ao sistema iniciar o registro de um aluguel
de cópias.
• Informações/eventos que são trocados entre um ator e o
sistema
Atendente informa a identificação de cada cópia a ser alugada.
(Ação do Ator)
Sistema apresenta o nome do filme correspondente, o preço de
aluguel da cópia e o valor total devido (Resposta Externa)
• Armazenamento/Atualização de informações no sistema
– O sistema registra as informações do aluguel realizado.
(Resposta interna)
• Indicação de verificações realizadas pelo sistema
– Sistema verifica que o código informado corresponde a um
sócio que pode alugar cópias (Verificação).
• Como e quando o caso de uso termina
Slide 47
Especificação
Tudo se resume a especificar casos de uso?
RNF
Dados
Caso de Uso
Interações
(Fluxos)
Regras
GUI
48
Slide 48
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
24
Caderno do Aluno
Recomendações Gerais
• Use um estilo consistente e padronizado de descrição
(trabalho em equipe).
• Explore todos os cenários possíveis
• Evite advérbios e adjetivos (muito, mais, melhor,...).
• Cuidado com pronomes (seu, sua, dele, ...)
• Evite utilizar termos que representem elementos concretos
de interface com o usuário (botão, listbox, clicar, ...)
• Seja conciso e objetivo
• Dilema - Diferentes perspectivas de detalhamento
– Comunicar ao usuário o funcionamento do software
– Comunicar aos desenvolvedores as funcionalidades a serem
desenvolvidas
– Roteiro para os testes
– Documentar o Software
Slide 49
Referências
• Managing Software Requirements: A Use Case Approach, Second
Edition. Leffingwell, D.; Widrig, D. Addison-Wesley Pub Co, 2003.
ISBN: 032112247X.
• Software Requirements, Second Edition. Wiegers, K. Microsoft Press,
2003. ISBN: 0735618798.
• Use Case Modeling. Bittner, K; Spence, I. Addison-Wesley Pub Co,
2002. ISBN: 0201709139.
• Writing Effective Use Cases. Cockburn, A. Addison-Wesley Pub Co,
2000. ISBN: 0201702258
Slide 50
Engenharia de Requisitos
Copyright © 2011 Alexandre Correa e João Sousa. Todos os direitos reservados.
Este documento não poderá ser reproduzido, na íntegra ou em parte, sem prévia
autorização por escrito dos autores.
25