Processo de Negócio e Software - Aula 02

Prévia do material em texto

1
PROFESSOR
MARCO IKURO HISATOMI
Especialista em
Desenvolvimento Gerencial e 
Gestão da Qualidade
PROCESSOS DE NEGÓCIO E SOFTWARE 
Aula 2
Engenharia de Requisitos
Determinar o escopo 
do sistema;
Meio para interação 
com os usuários;
Tipos de requisitos;
Como levantar requisitos.
OBJETIVOS DESTA AULA
“Condição necessária 
para a obtenção de 
certo objetivo.”
Requisitos funcionais 
e não‐funcionais.
Alternativas para melhorar 
e agilizar uma tarefa.
Alternativas para solucionar 
um problema.
DEFINIÇÕES DE REQUISITOS
Qualidade está relacionada com os Requisitos 
designados para o Software.
Não conformidades aos requisitos considera‐se 
falta de qualidade.
Qualidade deve ser definida, medida, monitorada, 
gerenciada e melhorada.
Prioridade na comunicação 
e descrição do requisito.
Visão profissional da qualidade
2
Comenta Harley e as pérolas da comunicação
VÍDEO Vamos refletir um pouco sobre o assunto...
Parece bem fácil quando tudo Parece bem fácil quando tudo 
funciona... não é mesmo?!
Agora, vamos aprender a organizar o 
processo para consigam desenvolver 
corretamente...
REQUISITOS NO PROCESSO Requisitos Engenharia de Software
Requisitos Atendidos
Usuário Software
Atividade a ser executada após a definição 
do Escopo do sistema.
Desempenhada por um Analista de Sistemas, com 
apoio do Analista de Negócios 
e participação dos Usuários finais.
Gerenciar requisitos a serem 
desenvolvidos e em 
desenvolvimento.
Analisar impacto das mudanças 
de requisitos.
ANÁLISE DE REQUISITOS
Demanda em software está a cada dia mais 
específica.
Requisitos são necessidades pontuais.
Sempre deve promover a solução de 
problemas.
RECONHECIMENTO DO PROBLEMA
3
Não importa um bom design e uma boa 
programação, caso os requisitos não refletirem 
o que usuário necessita.
A meta é o reconhecimento dos elementos 
básicos do problema, conforme percebido pelo 
cliente.
RECONHECIMENTO DO PROBLEMA
REQUISITOS MAL DEFINIDOS
“O novo sistema automatizado 
traz maior velocidade aos nossos 
negócios. Vamos perder Clientes 
mais rapidamente.”
Avaliar o problema na situação real, ambiente 
do usuário.
Reconhecer e definir as funcionalidades 
do novo sistema.
Identificar as entradas e saídas do sistema 
(dados e informações).
AVALIAÇÃO DO PROBLEMA 
E SÍNTESE DA SOLUÇÃO
Entender o comportamento 
do sistema.
Estabelecer características 
de Interface.
Determinar as restrições do 
projeto.
AVALIAÇÃO DO PROBLEMA 
E SÍNTESE DA SOLUÇÃO
4
Descrição do fluxo e estrutura da informação.
Refinamento detalhado de todas funções.
Estabelecimento das características das 
interfaces.
ESPECIFICAÇÃO DE REQUISITOS
Foco em “o que” o sistema deverá contemplar, 
não em “como”.
Detalhamento das restrições.
Especificação dos critérios de validação.
Validação dos requisitos com o cliente.
ESPECIFICAÇÃO DE REQUISITOS
Analise o cenário abaixo e responda o que está 
acontecendo.
O cenário ideal o Cliente faria a Especificação 
do Requisito.
ATIVIDADE  EM  SALA
Conhecer o problema 
e alternativas para solução.
Exemplo de como NÃO
deve acontecer...
LEVANTAMENTO DE REQUISITOS
Eu vou subir e ver o que eles 
querem e o resto de vocês 
comecem a codificar.
5
Compreende conceitos abstratos.
Capacidade de sintetizar “soluções”.
Visualizar fatos em fontes conflitantes ou 
confusas.
Entender o ambiente do usuário.
Boa comunicação verbal e 
escrita.
HABILIDADES DE UM ANALISTA
Elaborar uma lista de desejos dos usuários.
Priorizar os requisitos coletados.
Conhecer detalhadamente as regras de 
negócios.
Escolher os envolvidos de acordo com escopo 
do projeto.
Sintetizar o problema.
Revisar e validar requisitos.
LEVANTAMENTO DE DADOS
Certificar‐se de que está executando o 
levantamento com a pessoa certa (é oficial?).
Conhecer restrições que impedem soluções 
do problema (performance, escalabilidade, 
portabilidade, etc).
Conhecimento e não de 
invenção.
INICIANDO LEVANTAMENTO  Vamos refletir um pouco sobre o assunto...
Todas informações novas são Todas informações novas são 
estimulantes, certo?
Mas nem sempre conseguimos 
aprender tudo somente nas 
reuniões...
Facilitaded Application Specification
Techniques.
Conhecida como JAD (Joint Application
Development).
Reunião em local neutro.
Participação dos Analistas 
de sistemas e do Cliente.
REUNIÃO – FAST
Deve ser elaborada um agenda dos pontos mais 
importantes.
Um moderador é designado para controlar 
a reunião.
Um mecanismo é definido (planilha, flip‐chart, 
ou cartazes).
Relacionar as possíveis 
soluções para o problema.
REUNIÃO – FAST
6
Preparação do workshop. 
Conduzir a sessão.
Encontros no qual o analista expõe uma 
tecnologia ou cenário.
Os participantes devem conhecer e dar 
sugestões.
Consolidar resultados.
WORKSHOP
Definir o objetivo do encontro.
Gerar o maior número de idéias para o assunto.
Não permitir críticas ou debates.
Reunir e combinar as idéias.
Todos devem expressar seu voto.
Priorizar cada idéia por 
categoria.
BRAINSTORMING
Exemplo para Brainstorming
Num armazém de 50.000 m2, com 15 metros 
de altura, existem variações da temperatura 
em função da dimensão e da posição do sol.
Dificuldade em manter a temperatura do 
ambiente através de uma máquina de ar frio. 
A tendência é aumentar a 
temperatura, em função 
do produto armazenado.
ATIVIDADE  EM  SALA
Necessidade de manter uma temperatura com 
pouca variação e na média em 20ºC .
Pergunta:
Quais requisitos você acredita que poderiam 
ser descritos para solucionar o problema?
ATIVIDADE  EM  SALA
Glossário
Sinônimos
Siglas
Termos técnicos
Análise de risco
De Projeto
Técnico
REQUISITO – COMPLEMENTO
7
Protótipos e provas
Janelas
Relatórios
Gráficos
Formulários
REQUISITO – COMPLEMENTO
O que o sistema deve fazer (“o que”).
Evidentes – o que é mostrado para o usuário 
em forma de diálogo com o sistema.
Ocultos – o que é executado pelo sistema 
porém não é mostrado na interface com o 
usuário.
Restrições para que o requisito 
não seja atendido
REQUISITO – FUNCIONAL
Restrições colocadas sobre como o sistema 
deve realizar seus requisitos funcionais.
Obrigatórios – devem ser obtidos de qualquer 
maneira.
Desejados – podem ser obtidos caso não cause 
defeito no procedimento.
Restrições a nível do sistema –
ou seja, Suplementares.
REQUISITO – NÃO‐FUNCIONAL
Segurança – restrições de acesso, por perfil de 
usuário à determinadas funções ou 
informações.
Performance – nível de aceitação para resposta 
a uma determinada interface.
REQUISITO – NÃO‐FUNCIONAL
Compatibilidade – tipo de modem, impressora, 
moeda do país, são configuráveis.
Implementação – linguagem de programação, 
reutilização de biblioteca disponíveis (legado).
REQUISITO – NÃO‐FUNCIONAL
Através de Fluxo de informação ou de 
funcionalidade.
Através de Caso de uso.
Representar as interfaces com o usuários.
REQUISITOS – REPRESENTAÇÃO 
8
Descrição funcional;
Descrição comportamental;
Critério de Validação;
Referências.
REQUISITOS – REPRESENTAÇÃO 
Baseado na apostila que mostra 
uma figura com modelo 
de descrição de requisito.
Faça uma análise e comente 
os itens que julgar mais 
importante.
ATIVIDADE  EM  SALA
Engenharia de requisitos
http://www.inf.ufes.br/~falbo/files/Notas_Aula_
Engenharia_Requisitos.pdf
Conceitos: Especificação de requisitos
http://www.macoratti.net/07/
12/net_fer.htm
Saiba mais...
© 2014 – Todos os direitos reservados. Uso exclusivo 
no Sistema de Ensino Presencial Conectado.