oitavaAulaEngenhariaDeRequisitos

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

terça-feira, 3 de julho de 2012
Quinta Aula
Capítulo 73 
 Requisitos Funcionais
Disciplina
 Engenharia de Requisitos
Prof.: Luiz Loja
1
Agenda da nossa Apresentação
Cronograma
 
 
1
Revisão
 
 
2
Requisitos Funcionais
 
3
Conclusão
 
2
1
Revisão
O que já vimos?
 
 
 
3
Revisão
Necessidade de coleta de requisitos
O que são requisitos
Ciclo de desenvolvimento de software e requisitos
Dificuldades
Tipos de requisitos
Artigo
There is no Silver Bullet
4
Revisão
Processo de levantamento de Requisitos Volore
Ponta pé inicial
Coleta de requisitos
Prototipação de requisitos
Escrever os requisitos
Portal de qualidade
5
Blastoff
Ponta pé inicial
Primeira reunião
Trindade
Escopo
Colaboradores 
Objetivos
Criação do documento de visão
Escopo
Fronteiras do software
Áreas de domínio
O que devemos entender do trabalho
Sistemas adjacentes
Colaboradores
Tipos de colaboradores
Clientes
Consumidores
Usuários 
Especialistas
Consultores
Outros
Objetivo
PAM(Purpose, advantage e mesurement)
Propósito
O que o produto deverá fazer
Vantagem
A vantagem que produto proporcionará
Medição
Como é medida a vantagem
Documento de Visão
Propósito do projeto
O escopo do projeto
Os colaboradores
Restrições
Nomes
Fatos relevantes e suposições
Custo estimado
Os riscos
Primeiro protótipo de baixo custo
Fazer ou não fazer
10
Caso de Uso
Entender o trabalho
Diagrama de caso de uso
Caso de Uso
Atores
Relacionamento 
Associação
Relacionamento, extensão, inclusão, generalização
Documento de caso de uso
Revisão
Levantar Requisitos
Melhorar o trabalho do usuário
Utilizar Modelos
Caso de Uso
Diagrama de Atividade
Mapas Mentais
Focar na essência do problema
Tipo de Requisito
Consciente
Inconsciente
Inimagináveis
Revisão
Técnicas
Aprendiz
Observando Padrões e Estruturas
Entrevistas
Brainstorm
Persona
Workshops de Caso de Uso
Papel de Parede
Blogs, wikis e fóruns
Arqueologia de Documentos
Vídeo e Fotos
13
Reunião JAD
3 etapas
Preparação
Sessão
Revisão
 
 
2
Requisitos Funcionais
O que é mesmo que você quer?
 
 
 
15
Introdução
Especifica o que o produto deve fazer
Razões fundamentais para a existência do produto
Entender os requisitos funcionais para passar aos desenvolvedores
Aprendemos
Como levantar os requisitos
Escrever os cenários
Escreve-se os requisitos funcionais a partir dos cenários levantados
Processo de Criação de Requisitos Funcionais
Requisitos Funcionais
Requisitos Funcionais
Independentes de tecnologia
Descritos pelos colaboradores como algo que o sistema deve fazer
Essência funcional do trabalho
Requisitos funcionais e Requisitos de negócio
São diferentes
Geralmente são descobertos simultaniamente
Separar os requisitos
19
Requisitos Funcionais
Serve como um contrato para o produto
Descrever com detalhes o que o sistema deve fazer
Não deve deixar duvidas para o desenvolvedor
Encontrando requisitos funcionais
Encontrando Requisitos Funcionais
A partir dos cenários é possível levantar os requisitos funcionais
Cada passo do cenário pode ser decomposto em um requisito funcional
Exemplo
Este caso de uso mostra o sistema gerando a escala de descongelamento das rodovias
O banco de dados de mapa termais é um sistema adjacente
Exemplo
Caso de Uso: Produzindo a escala de descongelamento das rodovias
Cenário
O engenheiro insere a data da escala e o identificador do distrito
O sistema seleciona os mapas termais relevantes
O sistema utiliza os mapas termais, leituras de temperatura dos distritos, e condições do tempo para predizer as temperaturas para cada parte da rodovia do distrito
O sistema determina qual rodovia irá cogelar e quando.
O sistema avalia quais caminhões estarão disponíveis em cada deposito
Sistema mostra a escala para o engenheiro
Exemplo
O engenheiro insere a data da escala e o identificador do distrito
Qual requisito funcional pode ser criado?
O produto deve aceitar a data da escala
Pergunta sobre se existe algum fato sobre as datas
Cliente responde que o sistema só poderá fornecer com exatidão uma escala para dois dias a partir do dia atual
Qual requisito podemos levantar?
O produto deve avisar se a data fornecida não for hoje, nem amanhã.
Faltou algum requisito?
O produto deve aceitar somente distritos validos
Exemplo
O que é um distrito válido?
É valido quando o distrito é de responsabilidade do engenheiro que está usando o sistema.
Produto deve verificar se o distrito está sobre responsabilidade do egenheiro que está usando o sistema
Identificando Requisitos Funcionais
Maioria o número de requisitos de cada passo varia de 1 a 6
Apenas um requisito por passo
Caso de uso nivel de detalhe muito granular
Mais de seis por passo
Caso de uso está bem complexo
Identificando Requisitos Funcionais
O sistema determina qual rodovia irá cogelar e quando.
O sistema deve determinar quais áreas poderão congelar 
O sistema deve determinar quando estas áreas irão congelar 
O sistema deve determinar quais rodovias passam por áreas que já estão congeladas
Nivel de detalhe e granularidade
Nível de detalhe e Granularidade.
Requisitos são escritos com um sentença e um verbo.
Evitar usar conjunção "e"
Vantagens
Evitar ambiguidade 
Requisitos testáveis
Começar com "O produto deve"
Isso ajuda a determinar o que o produto deve fazer.
Nível de detalhe e Granularidade.
A palavra "deve" não quer dizer que os desenvolvedores irão achar a solução.
Apenas determina o que o sistema deveria fazer
Evitar outro tipo de palavra
Pode
Irá
Poderá
O colaborador pode verificar o requisito e falar se ele está correto
O colaborador pode falar se já foi escrito requisitos suficientes para atingir a saída do caso de uso
Pertuntar apenas para os colaboradores "problema"
Cenários de Exceção e Alternativos
Cenários de Exceção e Alternativos
Exceções são inevitaveis
Erros
Ações incorretas
Os cenários de exceção mostrão como o sistema se recuperar de estados indesejáveis
Vá a cada passo e faça o mesmo levantamento
Faça um requisito que deixe claro a exceção
Se não houver caminhões disponíveis, o sistema deverá gerar um alerta de emergencia para os depósitos de caminhões mais pertos da área de congelamento
Cenários de Exceção e Alternativos
Cenários alternativos são variações do caso de uso normal
Caso de uso da Amazon-1Click
Sistema deve adicionar o item selecionado ao carrinho de compras
Caso de uso alternativo
Se o 1-Click estiver abilitado, o sistema deverá vender o item selecionado
Evitando Ambiguidade
Evitando Ambiguidade
Ambiguidade deve ser evitada
Não importa a forma de levantamento dos requisitos.
Sempre haverá ambiguidade
Linguagem é cheia de homonimos
Mesmo pronuncia ou grafia e sentidos diferentes
Considere a palavra arquivo
Evitando Ambiguidade
Considerar o requisito
Sistema deve apresentar o tempo 24 horas
O produto deve comunicar o tempo que poderá acontecer.
O produto deve verificar o tempo nas estações de termais e comunicar o tempo atual.
Evitando Ambiguidade
O sistema deve comunicar todas as rodovias que poderão congelar
"Todas" é referente as rodovias tratadas pelo sistema
"Todas" é referente as rodovias examinadas pelo usuário
Definir o contexto do requisito
Voltar ao contexto do caso de uso para esclarecer ambiguidades
Evitando Ambiguidade
Nos queremos que os caminhões tratem as rodovias antes que congelem.
Evitar pronomes 
Substituir pelas próprias palavras.
Requisitos Tecnológicos
Requisitos Tecnológicos
São requisitos necessários devido a tecnologia selecionada
Exemplo
Ice-break
Sistema interage com banco de dados de mapas termais
Via internet
Protocolo de comunicação seguro
Não são levantados por causa do negócio
Separar este tipo de requisitos dos demais
Requisitos e não Soluções
Requisitos e não Soluções
Diferença entre requisitos e soluções
Escrever requisitos ao invés de soluções
Requisitos existem apesar da tecnologia empregada
Refletir a essência do negócio
É fácil definir soluções mais obvias e deixar as melhores de lado
Requisitos e não Soluções
Errado
O produto deve apresentar fotos dos produtos para o cliente clicar
Certo
O sistema deve permitir o cliente selecionar os produtos que deseja comprar
Permite outras implementações
Agrupando Requisitos
Agrupando Requisitos
Agrupar requisitos por casos de uso
Fácil de identificar requisitos relacionados
Testar a completesa da funcionalidade
Agrupar requisitos por funcionalidades
O que o sistema deve fazer?
Verificar os contextos
Alternativa para requisitos Funcionais
Alternativas para Requisitos Funcionais
Comunicar o entendimento de diferentes formas
Caso o escopo seja bem conhecido
Escrever os cenários de forma mais técnica
Se ficar complicado volte a abordagem anterior
Misturando requisitos funcionais e cenários
Se você construir modelos de processos 
Use-os para levantar os requisitos
Alternativas para Requisitos Funcionais
Alternativas para Requisitos Funcionais
Diagrama conceitual
 
 
3
Estou fazendo a coisa certa?
Conclusão
 
 
 
51
Luiz Fernando Batista Loja
Luizloja@gmail.com
 
Perguntas?
52