Analise de SISTEMAS ORIENTADA A OBJETO

Prévia do material em texto

ANÁLISE DE SISTEMAS O.O.
Aula 03 – Técnicas de Elicitação 
de Requisitos
Profª. Yonara Costa Magalhães
yonara.magalhaes@ceuma.br
1
Processo de ER 2
Processo de ER 3
Técnicas de Elicitação de Requisitos
 Nenhuma técnica individualmente é suficiente para levantar
requisitos.
 Utiliza-se várias técnicas concomitantemente, para se ter um
levantamento de requisitos mais eficaz.
 A escolha das técnicas adotadas é dependente de
características do projeto (tempo, custo etc.) e dos
envolvidos.
 Cada técnica pode possuir diferentes objetos de investigação
ou podem ter foco em tipos diferentes de requisitos.
 O emprego de diferentes técnicas visa capturar diferentes
tipos de informação (fontes dos requisitos) e em diferentes
estágios do processo de levantamento de requisitos.
4
5Técnicas de Elicitação de Requisitos
Análise de 
documento
Prototipagem
Pontos de 
Vista
Observação
Entrevista Questionário Cenários Workshop
Brainstorming JAD etc.
 Independentemente da técnica a ser adotada deve-se:
Técnicas de Elicitação de Requisitos 6
4. Refletir: preencher os espaços em branco (lacunas/dúvidas), analisar e apontar as
tarefas etc.
3. Fechar: agradecer os envolvidos, validar os achados (submeter as informaçõe à
revisão dos usuários e obter o aceite), fornecer informação de contato e anotar/agenda
próximos encontros.
2. Executar: mantenha o planejamento e replaneje, caso necessário;
1. Planejar: Identificar os objetivos, aprender o domínio de aplicação antecipadamente,
decidir o método e forma de registro, identificar (envolvidos, datas, locais etc.), obter
permissão da gestão por meio de documento formal.
 Objetivo: identificar a existência de documentos (em diferentes
formatos) com os clientes e usuários, realizando ações para
descrever e representar as informações coletadas de forma
unificada, sistematizada e distinta da original facilitando a
recuperação e o compartilhamento das informações.
 Procedimento: elaborar um template para registrar as
informações coletadas, a origem da fonte, data, pessoa que
forneceu o material etc.
1 - Análise documental 7
Relatórios (de 
desempenho, de 
tomada de decisão, 
consolidados etc.) 
Formulários e 
fichas
Planilhas (de 
controle, de 
gestão etc.)
Manuais de 
operação e de 
processos.
Legislações 
externas e 
internas.
Etc...
 Objetivo: criar uma versão inicial do sistema desenvolvido
rapidamente (com o essencial).
 Permite:
 tornar os requisitos mais reais e diminui lacunas de
entendimento;
 estimular os usuários a pensar e a estabelecer um diálogo
sobre os requisitos;
 resolver mais rapidamente as incertezas sobre os requisitos;
 capturar as reações iniciais do usuário em relação ao sistema;
 auxiliar os usuários a vislumbrar novas capacidades, pela
interação/experimentação com o protótipo;
 explorar alternativas de projeto (design), de funcionalidades
e de interfaces (layout) familiarizando os usuários com as
soluções disponíveis.
82 - Prototipagem
“Criticar é mais fácil do que 
criar”
2 - Prototipagem 9
 Risco: os usuários podem confundir o protótipo com o
sistema final.
 Um protótipo pode ser descartável ou evolutivo;
 Os protótipos iniciais podem ser gradativamente
transformados no produto final (sequência de iterações de
desenvolvimento).
103 – Pontos de Vista
• Objetivo: conhecer e representar o problema por várias
perspectivas (pontos de vista);
• Existem várias pessoas que participam de um projeto de
desenvolvimento de sistema envolvendo técnicos e usuários (em
diferentes papéis) que são chamados de stakeholders;
• Importante:
• os pontos de vista diferentes dos atores sobre o problema
(cenário).
• cada um vê o problema de modo diferente.
• Etapas:
1) Identificar os possíveis pontos de vista:
- Isto está relacionado com os atores (aqueles que vão interagir
com o sistema).
2) Estruturar os pontos de vista:
- agrupar ou organizar os pontos de vista relacionados, segundo
uma hierarquia.
- identificar os serviços/funcionalidades comuns estão
localizados nos níveis mais altos da hierarquia e são herdados
por pontos de vista de nível inferior.
3) Documentar: refinar a descrição dos pontos de vista e serviços
identificados. Ex: descrever as responsabilidades de cada ator da
hierarquia.
4) Mapear: identificar objetos em um projeto O.O., utilizando as
informações de serviço que estão encapsuladas nos pontos de
vista.
3 – Pontos de Vista 11
3 – Pontos de Vista 12
Ex: sistema de controle de operações bancárias
3 – Pontos de Vista 13
 Vantagem:
 Possibilita ter uma visão geral sobre as funcionalidades
(serviços) que o sistema deverá ter organizado pelos
atores que as utilizam.
 Desvantagens:
 Não é possível detalhar como os serviços
(funcionalidades) acontecem, sendo necessário utilizar
outra técnica para complementar essas informações.
 Restrições, condições, cálculos e validações não são
possíveis de representar.
 Objetivos:
 estudar pessoas em seu ambiente natural, sendo uma técnica
utilizada para compreender os requisitos sociais e
organizacionais;
 O analista (engenheiro de requisitos) se insere na organização
do cliente e observa o trabalho no dia a dia e documenta como
as tarefas são realizadas pelos funcionários.
 Como documentar:
 elaborar um roteiro com os aspectos/itens a serem observados;
 o roteiro pode ser algo geral ou elaborado com base em
informações originadas de outras técnicas e na qual o
observador deseja aprofundar.
144 – Observação (etnografia)
“Vá ao local de trabalho do cliente e observe o trabalho à medida que 
ele é realizado.”
 Permite:
 descobrir como as pessoas realmente trabalham;
 compreender a cooperação das atividades de outras pessoas;
 descobrir detalhes importantes que outros métodos omitem;
 Identificar os requisitos derivados da maneira como as
pessoas realmente trabalham (como os processos são
executados) e não do modo como os processos são
documentados ou explicados;
 Identificar os requisitos derivados do relacionamento entre o
indivíduo que toma decisões e outros membros da
organização;
 descobrir padrões de trabalho;
 formular hipóteses, a partir dos fatos observados;
 descobrir aspectos relevantes para o projeto.
154 – Observação (etnografia)
 Deve-se:
 planejar - definir o que observar e porque observar;
 selecionar quem - considerar a experiência e o
conhecimento do observado;
 definir o onde e quando (período/horário/tempo) - se o
indivíduo a ser observado estará trabalhando nos
processos de interesse no período agendado da
observação e se esse processo de negócio a ser
observado tem uma ocorrência significativa no período
considerado;
 definir como (registrar/documentar) o que se deseja
observar.
 Efetividade da técnica: varia na medida em que os usuários
tendem a ajustar o modo como realizam suas tarefas
quando sabem que estão sendo observados.
164 – Observação (etnografia)
 Características:
 conversa direcionada com um propósito específico, que utiliza um
formato “pergunta-resposta” e feita por um entrevistador.
 Vantagem:
 caso haja erros de interpretação da pergunta isto pode ser esclarecido
pelo entrevistador.
 Procedimento (Porque? Quem? Quando? Onde? Como?):
 Estabelecer os objetivos da entrevista;
 Decidir quem entrevistar;
 Marcar com antecedência (horário, local e duração);
 Definir os tipos de questões e a sua estrutura;
 Pode ser realizada individualmente ou coletivamente.
 Ler previamente o material de apoio e demais fontes de
informação;
 Validar as respostas do entrevistado ao final da entrevista para
evitar contradições e erros de interpretação.
175 – Entrevista
 Pode ser de dois tipos:
Aberta:
 não existe um roteiro pré definido.
 o entrevistador tem uma liberdade para as perguntas
ou para suas intervenções, permitindo-se flexibilidade.
 O entrevistador precisar dominar o tempo e o
conteúdo.
 Fechada:
 as perguntas já estão previstas, assim como a ordem e
a maneira de formulá-las.
185 – Entrevista
• Objetivo: coletar informações por meio de perguntas cujas 
as respostas são preenchidas pelo próprio informante;
• Características:
• Pode ser aplicado simultaneamente;
• Permite o anonimato;
• Possibilita coletar informações e respostas mais reais.
• Definir:
• a finalidade, o formato (papel ou eletrônico), a quantidade 
de perguntas, a organização e a ortografia.
• Vantagens:
•é acessível;
•Pode ser aplicado em áreas distantes geograficamente;
•O pesquisado tem mais tempo para responder;
6 – Questionário 19
• Desvantagens:
• as perguntas pode gerar incompreensão e comprometer as
respostas;
• não se tem garantia de quantos retornarão (pode comprometer a
amostra), demora do retorno, respostas incompletas ou em
branco
• dificuldade de controlar a veracidade das informações, pois pode
ser preenchido por alguém que não faz parte da amostra;
• a população pesquisada deve ser alfabetizada;
• Cuidados:
• As perguntas devem estar alinhadas ao objetivo;
• Perguntar apenas o essencial;
• Não inclua perguntas que o pesquisado não possa responder;
• Não elabore perguntas com palavras ou expressões não
familiares;
• Considere o nível intelectual dos entrevistados.
6 – Questionário 20
• Os enunciados das questões podem ser:
1) Objetivos (fechados)
– número limitado de opções ou alternativas.
- permite obter respostas mais precisas e de entendimento mais
fácil, mais simples aplicar, codificar, tabular e analisar.
2) Abertos (subjetivos):
- sem restrições de alternativas (respostas livres);
- recolhe-se respostas mais ricas, variadas e amplas;
- A codificação, tabulação e análise tem maior grau de dificuldade.
• As perguntas podem ser ainda:
1) Sem contexto (que independem do cenário onde serão
aplicadas, mas ainda assim, relevantes). Ex.: Quem é o cliente?
Quais são os usuário? Suas necessidades são diferentes?
2) Com contexto (que dependem do cenário, ou seja, que são
específicas para o cenário analisado).
Elaboração de questões - Entrevista e 
Questionário 21
• Evite questões tendenciosas.
Ex.: O que você acha do sistema que está sendo
substituído?
• Evite duas questões em uma, pois o entrevistado pode
responder a apenas uma delas, ou pode se confundir
em relação à pergunta que está respondendo.
Ex.: Quais são os relatórios que vc deseja e quais
informações de cada um deles?
• Uma questão não deve conter mais de uma variável,
pois não é possível medir ao mesmo tempo duas
variáveis em uma mesma questão.
Ex.: Você utiliza software licenciado e software livre em
sua empresa? ( ) sim ( ) não
22
Elaboração de questões - Entrevista e 
Questionário
• Evite perguntas com negativas pois dificultam o raciocínio e
podem induzir respostas. Ex.: Você não precisa de um
relatório consolidado dessas informações?
• Evite opções desnecessárias ou de duplo sentido nas
questões que mensuram variáveis no nível nominal. Ex.:
23
Elaboração de questões - Entrevista e 
Questionário
• Ex.:
24
Elaboração de questões - Entrevista e 
Questionário
 Objetivo: descrever uma situação de uso do sistema (funcionalidade)
por meio de uma sequência específica de interações entre ator e o
sistema, ou seja, se refere a uma porção do trabalho que está sendo
realizado pelo sistema (enredo/história).
 Características:
 tendem a ser curtos (ex. entre 3 a 8 passos);
 descrevem cenários positivos (comportamento requerido) ou
negativos (comportamento indesejado);
 podem descrever cenários indicativos (sistema atual) ou optativos
(como deve ser);
 não há formato padrão para a definição dos campos de informação;
 os cenários são usados permitem entender os procedimento de um
caso de uso (passo a passo como é realizado);
 enredo designa uma porção de trabalho dividida em um nº de
passos/cenas;
 os cenários requerem uma abordagem incremental e interativa.
257 – Cenários
 Inclui campos de informação:
 Nome da Funcionalidade: descrito por um verbo no infinitivo;
 Ator: primário e secundário;
 Pré-condição: caso haja algo obrigatório de ocorrer antes do
cenário ser realizado;
 Cenário - Fluxo normal: descrito em passos e ordenado;
 Cenários - Fluxos alternativos: pode haver mais de um; deve ser
descrito em passos e ordenado.
 Vantagens:
 os stakeholders tendem a utilizá-los mais facilmente;
 cenários curtos são muito bons para ilustrar rapidamente interações
específicas;
 deve-se criar um template para padronizar os campos.
 Desvantagem:
 Se for utilizado com detalhes de implementação ou de projeto,
pode dificultar o entendimento ou ficar desatualizado rapidamente.
7 – Cenários 26
 Nome da Funcionalidade: Sacar dinheiro (Auto Atendimento)
 Ator: Correntista
 Pré-condição: Conta ativa e senha inicial validada
 Cenário - Fluxo normal:
1. Informar o valor do saque
2. Confirmar dados da operação
3. Digitar e confirmar a senha
4. Validar senha
5. Verificar o saldo
6. Debitar valor da conta
 Cenário – Fluxo alternativo 01: Erro da senha
4.1 Apresentar aviso ao correntista
4.2 Voltar ao passo 3
 Cenário - Fluxos alternativo 01: Saldo insuficiente
5.1 Apresentar aviso ao correntista
5.2 Voltar ao passo 1
277 – Cenários: exemplo
287 – Cenários: ampliando o modelo
 Esta técnica será ampliada mais à frente, com a utilização
de um template que detalhará todos os fluxos de um Caso
de UsoDividido em 3 áreas: identificação, fluxos e pós
condições.
Vamos exercitar!
LISTA DE EXERCÍCIOS 02
Aplicar as técnicas de:
• Pontos de Vista
• Questionário
• Cenários
29