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

[email protected]

Eduard

o C

astr

o

JAD (Joint Application Design) para levantamento de requisitos 2

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

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

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.

INTRODUÇÃO

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

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

INTRODUÇÃO

Eduard

o C

astr

o


• 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!

ETERNOS PROBLEMAS

Eduard

o C

astr

o


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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o


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

ETERNOS PROBLEMAS

Eduard

o C

astr

o


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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o


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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o



• 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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o



• 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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o


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.

ETERNOS PROBLEMAS

Eduard

o C

astr

o


Síndrome do “Usuário e o Desenvolvedor”

•Usuários não sabem o que

querem ou não conseguem

articular o que eles querem

•Usuários pensam que sabem o

que querem até os

desenvolvedores entregarem o que

eles haviam dito que queriam

•Desenvolvedores pensam que

entendem os problemas dos

usuários melhor que eles

Reconhecer os usuários como

especialistas naquele domínio;

tentar outras técnicas de elicitação;

Implementar mais cedo, outras

técnicas de elicitação

Colocar-se no lugar do usuário.

ETERNOS PROBLEMAS

Eduard

o C

astr

o


Eduard

o C

astr

o

19

Visão do Desenvolvedor x Usuário

Eduard

o C

astr

o


Eduard

o C

astr

o

20

Necessidades

Características

Requisitos de Software

ou de Sistema

Domínio do

PROBLEMA

Domínio da

SOLUÇÃO

A Pirâmide de Requisitos

“O reflexo de um problema negocial,

pessoal ou operacional (ou uma

oportunidade) que será resolvido

pela aquisição e o uso de um novo

sistema”

“Um serviço que o sistema irá

prover para atender uma ou mais

necessidades do cliente”

Eduard

o C

astr

o


Eduard

o C

astr

o

21

Necessidades

Características

Requisitos de Software ou de Sistema

Domínio do

PROBLEMA

Domínio da

SOLUÇÃO

Requisitos do

Negócio (Necessidades

do Cliente)

Funcionais Não Funcionais

Recursos,

Capacidade,

Comportamento

(Necessidades do

Sistema)


Complementares

Regras de Negócio Qualidade

Eduard

o C

astr

o


Eduard

o C

astr

o

22

Necessidades

Características

Requisitos de Software

ou de Sistema

Domínio do

PROBLEMA

Domínio da

SOLUÇÃO

Analista Negócio:

“O sistema vai precisar de uma

opção para manter o cadastro de

funcionários sempre atualizado”

Analista de Requisitos:

“O sistema deve ter funções de

INCLUSÃO, ALTERAÇÃO e

EXCLUSÃO dos dados de

funcionário”

Cliente:

“Eu preciso de um cadastro com os

dados de todos os meus

funcionários...”


Eduard

o C

astr

o


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.


Eduard

o C

astr

o


Técnicas mais conhecidas:

Técnicas de Elicitação

• Entrevistas e Questionários

• Brainstorming

• Storyboarding e Demonstrações

• Workshops

Eduard

o C

astr

o


• 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


Eduard

o C

astr

o



• Entrevistas e Questionários

Eduard

o C

astr

o


• 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

Entrevistas e Questionários

Eduard

o C

astr

o


• 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


Eduard

o C

astr

o


• 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...


Eduard

o C

astr

o


• 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


Eduard

o C

astr

o


• 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”


Eduard

o C

astr

o


• 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.


Eduard

o C

astr

o



• Brainstorming

Eduard

o C

astr

o


• 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

Brainstorming

Eduard

o C

astr

o


• 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

Brainstorming

Eduard

o C

astr

o



• StoryBoarding

Eduard

o C

astr

o


• 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.

Storyboarding

Eduard

o C

astr

o


• 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

Storyboarding

Eduard

o C

astr

o


• 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...”

Storyboarding

Eduard

o C

astr

o


• 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

Storyboarding

Eduard

o C

astr

o


• 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.

Storyboarding

Eduard

o C

astr

o


• 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)

Storyboarding

Eduard

o C

astr

o



• Workshop

Eduard

o C

astr

o


• 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.

Workshop

Eduard

o C

astr

o


• 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

Workshop

Eduard

o C

astr

o


• 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

Workshop

Eduard

o C

astr

o


• Definição da Agenda:

• Horários de início e término

• Local apropriado

• Pausas

• Atividades

• Etc...

Workshop

Eduard

o C

astr

o


• 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

Workshop

Eduard

o C

astr

o


• 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.

Workshop

Eduard

o C

astr

o




Eduard

o C

astr

o




• Técnica que virou “marca”.

• Origem na IBM.

• Workshop com regras, formalizado, padronizado.

Eduard

o C

astr

o


• 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


Eduard

o C

astr

o


• 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.


Eduard

o C

astr

o


• Cada um tem um papel bem definido na

reunião: • Principais stakeholders

• Equipe de projeto

• Facilitador

• Documentador

• Observadores

• Processo de trabalho é muito estruturado.


Eduard

o C

astr

o


• Visão geral:


1

Definição do

Projeto JAD

2

Pesquisa

3

Preparação

5

Documento

Final

4

Sessão

Eduard

o C

astr

o


• Visão geral:

PROJETO

Preparação Sessão Revisão

Agenda Resultados

Dados Resultados

revisados


Eduard

o C

astr

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

Preparação


Eduard

o C

astr

o


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?

Preparação - Etapas


Eduard

o C

astr

o


3. Elaborar a perspectiva gerencial para

nivelamento e informação sobre as expectativas

da alta administração Objetivos?

Escopo?

Premissas e Restrições?



Eduard

o C

astr

o


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?



Eduard

o C

astr

o


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

5. Preparar ferramenta de documentação



Eduard

o C

astr

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.

Sessão


Eduard

o C

astr

o


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?

Sessão - Etapas


Eduard

o C

astr

o


Sessão - Exemplo


Eduard

o C

astr

o


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...

Sessão - Etapas


Eduard

o C

astr

o


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 ...

Sessão - Etapas


Eduard

o C

astr

o


4. Encerramento Itens da Agenda atendidos?

Expectativas atingidas?

Resultado satisfatório?

Recursos adequados?

Facilitador?

Sessão - Etapas


Eduard

o C

astr

o


Rever a documentação produzida na sessão e

examinar possíveis melhorias na sistemática

adotada.

Revisão


Eduard

o C

astr

o


• 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?

Revisão - Etapas


Eduard

o C

astr

o


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...

Revisão - Etapas


Eduard

o C

astr

o


Primeira Fase

Definição

Terceira

Fase

Preparação

Quinta Fase

Documento Final

Segunda Fase

Pesquisa

Quarta Fase

A Sessão JAD

Guia de

Definições

Gerenciais

Agenda

Documento

de Trabalho

Anotações dos

Documentadores

Documento

Final

Aprovado

Documentos

de Apoio


Visão Geral

Eduard

o C

astr

o

JAD (Joint Application Design) para levantamento de requisitos 72 72

Eduardo José Ribeiro de Castro

[email protected]

www.quaddract.com.br

Obrigado!

Eduard

o C

astr

o


Eduard

o C

astr

o

73

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

Technology