JAD e levantamento de requisitos

www.quaddract.com.br

O uso da técnica
JAD – Joint Application Design
para levantamento de requisitos

Eduardo Castro, MSc
ejrcastro@gmail.com

Eduardo Castro
Agenda
• Introdução
• Eternos Problemas
• Visão do Desenvolvedor x Usuário
• A Pirâmide de Requisitos
• Técnicas de Elicitação
• JAD – Joint Application Design
• Referências Bibliográficas

2 JAD (Joint Application Design) para levantamento de requisitos

Eduardo Castro
INTRODUÇÃO
• Uma questão fundamental na Engenharia de Requisitos
é como encontrar as reais necessidades do usuário
para a implementação do software.

• Pesquisas tem comprovado que muitos projetos de
implementação de software têm falhado por problemas
de elicitação dos requisitos do software, ou seja, os
requisitos obtidos muitas vezes são incompletos, mal
entendidos e ambíguos


Eduardo Castro
INTRODUÇÃO
• Identificar corretamente os requisitos do software não é
uma tarefa fácil, em parte devido à própria natureza
abstrata do software.

• Para entendermos melhor os problemas enfrentados na
elicitação dos requisitos podemos analisá-los a partir
de dois grandes grupos:

• problemas acidentais e

• problemas essenciais.


Eduardo Castro
INTRODUÇÃO
• Os problemas acidentais são aqueles oriundos da falta
de controle sobre aquilo que precisa ser construído,
dentre os quais podemos destacar:

• pouco esforço despendido no levantamento de
informações junto ao usuário,
• documentação pobre sobre o requisitos obtidos,
• pouca revisão dos requisitos obtidos,
• definição e especificações incorretas dos requisitos
e
• tendência em iniciar logo o processo de
desenvolvimento do software


Eduardo Castro
INTRODUÇÃO
• Os problemas acidentais podem ser considerados
menos difíceis de serem superados.

• A adoção de um processo sistemático que oriente a
elicitação, análise, especificação, validação e
gerenciamento dos requisitos tende a solucionar, ou
pelo menos minimizar, os problemas dessa categoria


Eduardo Castro
INTRODUÇÃO
• Os problemas essenciais são aqueles inerentes à
elicitação dos requisitos, dentre os quais podemos
destacar:

• dificuldade do usuário em saber efetivamente o que
ele quer,
• Dificuldade de comunicação entre usuário e
desenvolvedor e a
• natureza mutante dos requisitos


Eduardo Castro
INTRODUÇÃO
• Problemas essenciais são mais difíceis de serem
superados, uma vez que fazem parte da natureza dos
requisitos.
• A problemática que naturalmente existe no processo de
comunicação e compreensão humana, que está no
cerne da elicitação de requisitos, necessitará de uma
abordagem que leve em consideração:
• o contexto em que as pessoas exercem suas
atividades e reconhecem os objetos que lhe são
pertinentes,
• o histórico de evolução dessas atividades e seus
instrumentos de mediação, e
• outros aspectos de relevância social e psicológica
que afetam os usuários do software a ser
desenvolvido

Eduardo Castro
INTRODUÇÃO
• Sendo assim, os problemas essenciais da elicitação de
requisitos não poderão ser resolvidos numa abordagem
puramente tecnológica, uma vez que os aspectos
sociais assumem grande importância nessa atividade.

• É preciso aplicar uma metodologia para operacionalizar
a participação e envolvimento do usuário no
desenvolvimento de sistemas.

• O objetivo é facilitar interações entre usuários e
analistas, onde técnicas de dinâmica de grupo são
empregadas para elicitar e refinar idéias


Eduardo Castro
ETERNOS PROBLEMAS
• Vamos analisar alguns problemas na elicitação
dos requisitos a partir dos problemas
essenciais

• Comunicação:

• Não era isso que eu queria!
• Você tem que diminuir este prazo!
• Os nossos usuários não conseguem ser criativos!
• O usuário não sabe o que quer!


Eduardo Castro
ETERNOS PROBLEMAS
Não era isso que eu queria !
• Com essa simples afirmação o usuário acabou de jogar por terra o
trabalho árduo de todo um grupo; que pode significar desde mais
um esperado atraso na entrega do sistema até a "fritura" da
equipe do projeto.
• Não adianta mostrar documentos, especificações ou layouts com a
assinatura do usuário aprovando produtos intermediários do
desenvolvimento, porque se o sistema não servir, êle não será
implantado.
• O que é que provoca essa distância entre a expectativa do usuário
e o produto do analista? Porque o usuário esperava um cavalo e o
analista entregou um camelo?
• Certamente a principal razão é a barreira de comunicação
existente entre êles.


Eduardo Castro
ETERNOS PROBLEMAS
Você Tem Que Diminuir o Prazo !
• - Daqui a 18 mêses o mundo já mudou e não precisamos mais
dêsse sistema! Quem sabe se a empresa até lá ainda estará
operando?
• Com êste argumento jogado em cima do seu plano de
desenvolvimento, o analista se prepara para reduzir prazos daqui
e dali, provavelmente aumentando o risco do projeto.
• O tempo de levantamento junto ao usuário, a identificação das
reais necessidades do negócio, suas prioridades, a especificação
do sistema é minimizado
• Infelizmente, não há como transferir o conhecimento do cérebro do
usuário para o do analista de forma mecanizada.
• E não há como suprimir essa fase no desenvolvimento, sob pena
de se construir um sistema que vai ficar engavetado por não
atender as necessiades do seu usuário


Eduardo Castro
ETERNOS PROBLEMAS
Os nossos usuários não conseguem ser criativos!
• O pessoal da informática lamenta que os sistemas se limitam a
automatizar as velhas rotinas de trabalho.
• Esta tendência a manter o status quo é uma faceta da nossa
velha conhecida resistência a mudanças.
• É um problema que, obviamente, transcende aos usuários da
informática e passa a ser de toda a empresa.
• A discussão sobe de nível e envolve a área de estratégia de
negócios.
• Não se trata tão somente de se ter um bom sistema de conta
corrente ou de controle de estoques, mas, sim, em como ter tudo
isso melhor que o concorrente seguindo as estratégias de negócio.
• É evidente que êste desafio exige uma nova forma de
relacionamento entre analistas e usuários.


Eduardo Castro
ETERNOS PROBLEMAS
O Usuário não sabe o que quer!
• Esta é a contrapartida do analista às queixas dos usuários.
• Na verdade, o usuário sabe o que quer, mas não sabe como pedir.
• Diante de perguntas como "quais são as suas necessidades de
informações?", "que entidades externas se comunicam com o
sistema?", "qual o tempo de resposta requerido pela transação
xyz?", o usuário se inibe por não estar familiarizado com a
linguagem e, portanto, teme falar bobagens.
• A tendência é que êle coloque suas dificuldades atuais, explique
como realiza as tarefas do setor e fique esperando que os
analistas tragam soluções miraculosas.
• Por sua vêz, a sensação que o analista experimenta é a de que o
usuário não sabe o que quer.


Eduardo Castro
ETERNOS PROBLEMAS
• Quanto mais usuários o analista ouvir, mais dificuldades terá em
conciliar interêsses e alcançar consenso nas decisões.
• Essas entrevistas fornecem uma falsa sensação de que o analista
entende o sistema atual e conhece seus principais problemas
• Eu já conheço o bastante da aplicação e não posso perder mais
tempo visitando os usuários, porque o prazo está curto.
• O resultado é o chamado "sistema centrado no analista".
• Êle resolve os conflitos de opiniões surgidos no levantamento,
decide sobre questões típicas do negócio (que êle imagina
dominar), estabelece novos procedimentos, etc.


Eduardo Castro
ETERNOS PROBLEMAS
• Muito provavelmente, o resultado será satisfatório.
• O analista experiente, com certeza, irá pesquisar sistemas
semelhantes; quem sabe já desenvolveu um parecido em outra
empresa?
• No entanto, a expectativa do usuário estava muito alta. O sistema
entregue não chegou a impressionar.
• A solução miraculosa não apareceu.
• A informática continua devendo, mesmo depois dos milhares de
reais investidos.


Eduardo Castro
ETERNOS PROBLEMAS
Síndrome do “Usuário e o Desenvolvedor”

• Derivada do gap de comunicação entre o usuário e o
desenvolvedor.

• Scharer (1981) identificou as razões do problema e
sugeriu algumas soluções.


Eduardo Castro
ETERNOS PROBLEMAS
Síndrome do “Usuário e o Desenvolvedor”

•Usuários não sabem o que
querem ou não conseguem Reconhecer os usuários como
articular o que eles querem especialistas naquele domínio;
tentar outras técnicas de elicitação;

•Usuários pensam que sabem o
que querem até os
Implementar mais cedo, outras
desenvolvedores entregarem o que técnicas de elicitação
eles haviam dito que queriam

•Desenvolvedores pensam que
entendem os problemas dos
usuários melhor que eles Colocar-se no lugar do usuário.


Eduardo Castro
Visão do Desenvolvedor x Usuário


Eduardo Castro
A Pirâmide de Requisitos
“O reflexo de um problema negocial,
pessoal ou operacional (ou uma
Domínio do oportunidade) que será resolvido
PROBLEMA Necessidades pela aquisição e o uso de um novo
sistema”

“Um serviço que o sistema irá
Características prover para atender uma ou mais
necessidades do cliente”
Domínio da
SOLUÇÃO

Requisitos de Software
ou de Sistema


Eduardo Castro

Requisitos do
Domínio do
Necessidades Negócio (Necessidades
PROBLEMA
do Cliente)

Recursos,
Capacidade,
Características Comportamento
(Necessidades do
Domínio da Sistema)
SOLUÇÃO

Requisitos de Software ou de Sistema

Funcionais Complementares Não Funcionais

Regras de Negócio Qualidade

Eduardo Castro
Cliente:
“Eu preciso de um cadastro com os
dados de todos os meus
Domínio do funcionários...”
PROBLEMA Necessidades
Analista Negócio:
“O sistema vai precisar de uma
opção para manter o cadastro de
funcionários sempre atualizado”

Características
Analista de Requisitos:
Domínio da “O sistema deve ter funções de
SOLUÇÃO INCLUSÃO, ALTERAÇÃO e
EXCLUSÃO dos dados de
funcionário”

Requisitos de Software
ou de Sistema


Eduardo Castro
Necessidades e Características

• O usuário ou cliente não reconhece essa divisão.
• Ele tentará transmitir as suas necessidades ou as
características desejadas sem essa distinção ou
classificação.
• A iniciativa de desenvolver um bom processo de
elicitação deve ser da equipe de projeto.


Eduardo Castro
Técnicas de Elicitação
Técnicas mais conhecidas:

• Entrevistas e Questionários

• Brainstorming

• Storyboarding e Demonstrações

• Workshops


Eduardo Castro
• Simples, baratas e objetivas
• Nenhuma técnica é perfeita para todos os casos
• A escolha de uma técnica depende:
• Tipo e complexidade da aplicação
• Perfil da equipe de desenvolvimento
• Perfil do cliente
• Criticidade da aplicação e da tecnologia


Eduardo Castro

• Entrevistas e Questionários


Eduardo Castro
Entrevistas e Questionários
• Simples, direta e pode ser utilizada na quase totalidade
das situações.

• Chave para uma boa entrevista: predisposição do
entrevistador em não interferir na troca de informações,
pois...
• Deficiência natural para “ouvir”
• Modelos mentais
• Experiências anteriores


Eduardo Castro
• Preparação é importante:
• Pesquisar os entrevistados
• Preparar um roteiro ou uma lista de
perguntas independentes de qualquer
contexto de solução
• Previsão de tempo
• Reservar local adequado


Eduardo Castro
• Durante a Entrevista:
• Apresentar-se...
• Repassar a agenda (objetivos, patrocinador, motivo da
escolha do entrevistado)
• Manter postura de entrevistador: credibilidade, isenção,
discrição; não criar ressentimentos
• Deixar o entrevistado falar (redução da interferência)
• Direcionar a discussão para os objetivos
• Seguir a agenda, o roteiro e o tempo
• Notar sinais de impaciência
• Anotar tudo...


Eduardo Castro
• Estilo para entrevistar:
• Relacione a parte da entrevista c/ partes do sistema
• Obtenha pontos de vista alternativos
• Solicite detalhes do item que você estiver
interessado
• Estabeleça a dependência do assunto com outros
• Confirme os dados obtidos
• Não confunda sintomas com o problema


Eduardo Castro
• Possíveis problemas:
• “Você está tomando tempo demais”
• “Você está ameaçando meu emprego”
• “Você não conhece a nossa empresa”
• “Você está tentando mudar o modo que as coisas
são feitas aqui”
• “Não queremos esse sistema”
• “Mudei de opinião”
• “Aqui não há consenso de como a coisa deve ser
feita”


Eduardo Castro
• Questionários não devem substituir as
entrevistas: nada substitui o contato pessoal e
a interação que a entrevista proporciona.

• Se precisar, agende uma visita e observe as
instalações e a forma de trabalho.

• Entrevistar as pessoas certas, com perguntas
corretas, de forma apropriada, certamente
produzirá uma sólida compreensão das
necessidades e das características do sistema.


Eduardo Castro

• Brainstorming


Eduardo Castro
Brainstorming
• Ideal para a geração de novas idéias ou
soluções criativas.

• Pode complementar os Workshops.

• Benefícios:
• Encoraja a participação de todos
• Permite o desenvolvimento das idéias
• Produz-se muito em pouco tempo
• Permite o livre pensamento


Eduardo Castro
Brainstorming
• Regras:

• Liberdade para todos expressarem suas opiniões

• Nenhuma crítica prévia deve ser feita

• São válidas as colocações por impulso

• O que vale é a quantidade de idéias

• Relacionadas as idéias, passa-se para a redução das idéias e
a interpretação dos resultados


Eduardo Castro

• StoryBoarding


Eduardo Castro

Storyboarding
• O propósito da técnica é obter uma reação
antecipada dos usuários com relação aos
conceitos propostos para uma aplicação.

• Amigável, informal e interativa.

• Ótima para validar interfaces do sistema.

• Fácil de criar e fácil de modificar.


Eduardo Castro

Storyboarding
• Na prática, não há regras ou restrições para a
aplicação da técnica.

• Entretanto, storyboards podem ser
categorizadas em três tipos, dependendo do
modo de interação com o cliente:

• Passiva
• Ativa
• Interativa


Eduardo Castro

Storyboarding
• Storyboard Passiva:
• Conta-se uma história para o cliente

• Sketches, figuras, apresentações PowerPoint, etc.

• O analista de requisitos executa o papel do sistema
e simplesmente “navega” com o cliente pelo
storyboard.

• “Quando você faz assim, acontece isso...”


Eduardo Castro

Storyboarding
• Storyboard Ativa:
• Tenta-se fazer com que o cliente veja “um filme que
ainda não foi feito”.

• Animação ou automação.

• Provê uma descrição automatizada do
comportamento do sistema numa utilização típica
ou num cenário operacional.

• Wireframe


Eduardo Castro

Storyboarding
• Storyboard Interativa:

• Deixa-se o cliente experimentar o sistema de forma
realística e prática.

• Requer a participação intensiva do usuário.

• “Demonstração” do sistema.


Eduardo Castro

Storyboarding
• Nos 3 casos, o storyboarding exercita 3
elementos essenciais em qualquer atividade:

• Quem são os envolvidos (atores)

• O que acontece com os envolvidos
(comportamento)

• Como isto acontece (descrição da interação)


Eduardo Castro

• Workshop


Eduardo Castro
Workshop
• Se tiver que escolher apenas uma técnica de
elicitação...
• ...que pode ser aplicada em qualquer circunstância...
• ...independente do contexto do projeto...

• ...a melhor opção é o workshop de requisitos.


Eduardo Castro
Workshop
• A técnica é projetada para encorajar o consenso e a
concordância em um curto espaço de tempo.

• Benefícios:
• Todos trabalham visando um único propósito: o sucesso do projeto
• Envolve todos os interessados (stakeholders)
• Consenso sobre o que a aplicação deve fazer
• Expõe e resolve aspectos políticos que podem interferir no projeto
• Avaliação imediata da identificação preliminar das características da
aplicação


Eduardo Castro
Workshop
• Preparação:
• Vender o conceito: comunicar os benefícios

• Garantir a participação dos principais envolvidos: identificação prévia
dos stakeholders

• Preparar a logística: organização detalhada

• Prover material preparatório: aumento da produtividade

• Escolher o facilitador: não envolvido, independente


Eduardo Castro
Workshop
• Definição da Agenda:
• Horários de início e término

• Local apropriado

• Pausas

• Atividades

• Etc...


Eduardo Castro
Workshop
• O Facilitador tem um papel crucial no
processo:
• Estabelece o tom profissional e objetivo do encontro
• Começa e termina no tempo pré-definido
• Estabelece e reforça as regras do encontro
• Introduz os objetivos e a agenda do encontro
• Mantém a agenda elaborada
• Facilita o processo de decisão e de geração de consenso, sem se
envolver
• Não exarceba os problemas entre os envolvidos
• Garante a participação de todos
• Controla comportamentos de ruptura ou contraproducentes


Eduardo Castro
Workshop
• A saída do processo será uma lista de idéias ou de
sugestões a respeito das características da aplicação.

• Esta lista pode, mais adiante, ser entendida, detalhada
e validada pela equipe de projeto.


Eduardo Castro



Eduardo Castro

• Técnica que virou “marca”.

• Origem na IBM.

• Workshop com regras, formalizado, padronizado.


Eduardo Castro
• Usuários e desenvolvedores trabalham juntos
em uma reunião com o objetivo de:

– identificar o problema
– propor elementos de solução
– negociar diferentes abordagens
– especificar um conjunto preliminar de
requisitos de solução


Eduardo Castro
• Com as reuniões de trabalho, os usuários se
sentem prestigiados e parte integrante do
processo de desenvolvimento.

• Decisão obtida por consenso (não
necessariamente unânime...).

• Facilitador elimina os conflitos e conduz um
processo produtivo.


Eduardo Castro
• Cada um tem um papel bem definido na
reunião:
• Principais stakeholders
• Equipe de projeto
• Facilitador
• Documentador
• Observadores

• Processo de trabalho é muito estruturado.


Eduardo Castro
• Visão geral:

2 3
1 Pesquisa Preparação
Definição do
Projeto JAD

4 5
Sessão Documento
Final


Eduardo Castro
• Visão geral:

PROJETO

Dados Resultados
revisados

Preparação Sessão Revisão
Agenda Resultados


Eduardo Castro
Preparação

• Estabelecer as condições básicas para garantir
uma sessão de trabalho produtiva.
• Escolha dos participantes apropriados
• Agenda
• Participantes de acordo quanto aos objetivos
• Material de apoio


Eduardo Castro
Preparação - Etapas

1. Examinar se é adequada a utilização do JAD
 Perspectiva de sucesso?
 Tamanho do projeto?
 Domínio da técnica?
 Espírito da equipe e do cliente?

2. Planejar as sessões
 Quantas?
 Finalidade?


Eduardo Castro

3. Elaborar a perspectiva gerencial para
nivelamento e informação sobre as expectativas
da alta administração
 Objetivos?
 Escopo?
 Premissas e Restrições?


Eduardo Castro

4. Familiarizar-se com a área de negócio
 Documentação?
 Pesquisa dos envolvidos?
 Convocação?

5. Preparar a agenda da sessão
 Elemento básico !
 Regras?
 Abordagem?


Eduardo Castro

4. Preparar os participantes
 Ganhar tempo antes da sessão...

5. Preparar ferramenta de documentação


Eduardo Castro
Sessão

 Realizar a reunião de trabalho com os
participantes selecionados, com o objetivo de
produzir as informações necessárias ao
desenvolvimento do sistema.


Eduardo Castro
Sessão - Etapas

1. Preparar o ambiente físico
 Arrumação em “U” !
 Equipamentos audiovisuais testados?
 Check-list do material?
 Pastas com agenda, documentação e material para anotação?


Eduardo Castro
Sessão - Exemplo


Eduardo Castro
Sessão - Etapas

2. Condução da sessão
 Apresentação de todos
 Explicar a agenda e a logística
 Revisar a perspectiva gerencial
 Eventualmente, explicações dos envolvidos
 Revisar as regras de conduta ou código de cooperação
 Começar...


Eduardo Castro
Sessão - Etapas

3. Documentação
 Responsabilidade do Documentador, auxiliar do Facilitador !
 Observar os passos da Agenda ...
 Seguir indicação do Facilitador ...
 Confirmar dados ?
 Gerar documentação para os participantes ...


Eduardo Castro
Sessão - Etapas

4. Encerramento
 Itens da Agenda atendidos?
 Expectativas atingidas?
 Resultado satisfatório?
 Recursos adequados?
 Facilitador?


Eduardo Castro
Revisão

 Rever a documentação produzida na sessão e
examinar possíveis melhorias na sistemática
adotada.


Eduardo Castro
Revisão - Etapas

• Rever a documentação
 Informações completas?
 Falhas entre Facilitador e Documentador?
 Encaminhada a documentação aos participantes

• Examinar as avaliações
 Informações completas?


Eduardo Castro
Revisão - Etapas

3. Preparar a pasta do JAD
 Material valioso para o projeto !
 Perspectiva Gerencial...
 Plano das Sessões...
 Agenda de cada sessão...
 Participantes...
 Documentação produzida...
 Avaliações...


Eduardo Castro
Visão Geral

Primeira Fase
Guia de Segunda Fase
Definição Definições Pesquisa
Gerenciais

Documento
de Trabalho Terceira Agenda
Quarta Fase Fase
A Sessão JAD Preparação
Documentos
de Apoio

Anotações dos Quinta Fase Documento
Documentadores Documento Final Final
Aprovado


Eduardo Castro
Obrigado!

Eduardo José Ribeiro de Castro

ejrcastro@gmail.com

www.quaddract.com.br


Eduardo Castro

Referência Bibliografica
• COSTA, Osvaldo Wilson, JAD, joint application design. 2ª. Edição. Rio
de Janeiro: Liv. e Edit. Infobook, 1994
• DINSMORE, Paul - Como se tornar um Profissional em Gerenciamento
de Projetos - 2ª Edição;
• HACKETT, D., Martin, C.; Facilitation Skills for Team Leaders, Crisp
Publications, 1993.
• JUSTICE, T., Jamieson, D.; The Facilitator's Fieldbook, HRD Press, 1999
• LEFFINGWELL, Dean Managing Software Requirements, Second
Edition: A Use Case Approach, ed. Pearson , 2003
• PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática.
2ª edição – 2004
• PRESSMAN, Roger. S. Engenharia de software: um enfoque prático. 3.
ed. São Paulo: Makron Books, 1995.
• SOMMERVILLE, Ian.Engenharia de Software. 6ª ed. São Paulo: Addison
Wesley, 2003
• WOOD, J.; Silver, D.; Joint Application Development, 2a edição, John
Wiley & Sons, 1996.

JAD e levantamento de requisitos

Mais conteúdo relacionado

Mais procurados

Destaque

JAD e levantamento de requisitos