04-AulaES_RequisitosParte2

Prévia do material em texto

11
1Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Questionário
� Documento para guiar uma ou mais pessoas a responder a 
uma ou mais perguntas
� Elaboração é um processo mais complexo do que parece
� Questionários podem ser utilizados como auxílio a outras 
técnicas de elicitação
� Os tipos mais usados:
– Perguntas abertas não oferecem alternativas 
para o respondente, este deve formular uma 
resposta com suas próprias palavras deixando 
claros o objetivo da resposta e a justificativa, mas o 
respondente tem total liberdade para responder
– Perguntas fechada limitam o respondente a escolher umas das 
opções colocadas que retrata melhor sua opinião
2Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Questionário
� Principais formas de aplicação:
Auto-resposta via e-mail
Torna fácil o envio do questionário a várias pessoas ao mesmo 
tempo, não requer muito tempo e possibilita ao respondente enviar 
a resposta quando lhe for mais conveniente
Auto-resposta em grupo
Um grupo de pessoas é reunido seguindo alguns critérios de 
conveniência e as perguntas são feitas simultaneamente aos 
participantes
Auto-resposta porta a porta
O investigador vai ao encontro do respondente, entrega e explica o 
questionário
3Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Questionário
� Principais Procedimentos
– Formulação do problema deve ser feita a partir 
de uma questão inicial que servirá de base para 
elaboração do questionário
– Essa questão deve ser clara, precisa, realista e pertinente
– Explicação do objetivo do questionário
– Formulação de hipóteses para interação entre a teoria e a 
verificação baseada na experiência
– Orientação para a aquisição de dados
22
4Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Propõe criação de sessões de trabalho estruturadas, por 
meio de dinâmicas de grupo e recursos visuais, em que 
usuários e analistas trabalham juntos
� 04 princípios básicos:
– Uso de sessões facilitadas para aumentar a capacidade dos 
indivíduos (dinâmica de Grupo)
– Uso de técnicas audiovisuais para aumentar a comunicação e 
o entendimento
– Manutenção do processo organizado e racional
– Uso de documentação padrão, preenchida e assinada pelos 
participantes de uma sessão
� Técnica de reunião cuja finalidade é acelerar o 
desenvolvimento e/ou a manutenção de software
5Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development (Design)
� Ajuda a identificar os assuntos que podem necessitar de 
rastreamento e fornece uma perspectiva multifacetada dos 
requisitos
� Permitem aos analistas coletar simultânea e eficientemente 
grande quantidade de requisitos do software junto a uma 
gama de usuários-chave
� À medida que os requisitos são obtidos nas sessões, pode-
se construir um protótipo que demonstre alguma 
funcionalidade destes requisitos
� Aproxima os participantes e torna-se uma ferramenta para a 
conversão do conhecimento implícito em conhecimento 
explícito
6Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development (Design)
� 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
� 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
33
7Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� O comprometimento e o consenso entre os participantes 
criam um ambiente de respeito recíproco e de 
responsabilidade pelo sucesso do software
Projeto
Preparação Sessão Revisão
Dados sobre 
o projeto
Agenda
Objetivos
Dados Pessoais
Resultados
Avaliações
Resultados
Revisados
8Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Preparação
– Estabelecer condições básicas para que a sessão de trabalho 
seja produtiva e completa
� Escolha dos participantes apropriados
� Agenda
� Participantes de acordo quanto aos objetivos
� Material de apoio
– Sub-etapas:
� Examinar se é adequado o uso de JAD
� Perspectiva de sucesso?
� Tamanho do projeto?
� Domínio da técnica?
� Espírito da equipe e do cliente?
9Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Preparação
– Sub-etapas:
� Planejar as sessões
� Quantas?
� Finalidade?
� Elaborar a perspectiva gerencial
� Objetivos?
� Escopo?
� Premissas e Restrições?
� Familiarizar-se com áreas de negócios sob estudo
� Documentação?
� Pesquisa dos envolvidos?
� Convocação?
44
10Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Preparação
– Sub-etapas:
� Preparar a agenda da sessão
� Elemento básico!
� Regras?
� Abordagem?
� Preparar os participantes
� Ganhar tempo antes da sessão
� Preparar a ferramenta de documentação
11Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Sessão
– Realização das reuniões de trabalho com os participantes 
selecionados na fase Preparação
– Sub-etapas:
� Preparação do ambiente
� Arrumação em "U"!
� Equipamentos audiovisuais testados?
� Checklist do material?
� Pastas com agenda, documentação e material para anotação?
� Condução da sessão
� Apresentação de todos
� Explicar a agenda e logística
� Revisar a perspectiva gerencial
� Eventualmente, explicações dos envolvidos
� Revisar as regras de conduta ou código de cooperação
� Começar......
12Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Sessão
– Sub-etapas:
� Documentação
� Responsabilidade do Documentador, do Facilitador!
� Observar os passos da Agenda....
� Seguir indicação do Facilitador....
� Confirmar dados?
� Gerar documentação para os participantes....
� Encerramento da sessão
� Itens da Agenda atendidos?
� Expectativas atingidas
� Resultados satisfatórios
� Recursos adequados?
55
13Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – Joint Application Development
� Revisão
– Rever a documentação produzida na sessão e examinar 
possíveis melhorias na sistemática adotada
– Sub-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?
� Preparar a pasta do JAD
� Material valioso para o projeto!
� Plano das sessões...
� Agenda de cada sessão...
� Participantes e Documentação produzida....
� Avaliações....
14Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
JAD – JointApplication Development
� Vantagens
– comprometer usuários com requisitos que têm decisão
– reduzir o prazo de levantamento de requisitos
– eliminar requisitos de valor questionável
– reduzir diferenças de interpretação dos requisitos
– produzir um primeiro esboço das interfaces de usuário
– trazer a tona problemas políticos que possam surgir
� Desvantagens
– exigência da disponibilidade de tempo dos participantes
– preparação for insuficiente ���� sessão pode não ter sucesso
– relatório incompleto ���� põe em risco a próxima sessão
– cultura organizacional pode não ser compatível com JAD
15Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Brainstorming
� Tempestade de Idéias
� Técnica eficiente para grupos desenvolverem idéias criativas
� A essência básica é reunir um grupo de especialistas no 
software e no negócio para que cada participante possa 
estimular o outro a criar idéias que auxiliem a encontrar a 
solução do problema em uma ou mais reuniões
� As idéias que surgirem e forem discutidas nestas reuniões 
não podem ser recriminadas ou julgadas
66
16Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Boas 
Práticas
Estabelecer 
o papel do 
líder
Definir a tarefa e 
manter o controle na 
sua mão
Indicar o 
objetivo da 
sessão de 
brainstorming
Criar uma 
atmosfera 
positiva
Registrar as idéias
Monitorar 
comunicação 
verbal e não-
verbal
Incentivar o fluxo 
das idéias
17Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Brainstorming
� Para evitar problemas deve-se ficar atento a:
– Local
– Ter um propósito específico
– Saber o que buscar e para que buscá-lo
– Saber facilitar
– Colocar os pontos principais em uma lista
– O conforto é chave
– Estabelecer regras para o grupo
– Adiar críticas
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 ideias
– Relacionadas as ideias, passa-se para a redução das ideias e a 
interpretação dos resultados
18Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
Brainstorming
� Vantagens
– não ter críticas e julgamentos que ajudam a abolir algumas 
das dificuldades inerentes ao processo
– evitar a tendência a limitar o problema muito cedo
– fornecer uma interação social mais confortável do que 
algumas técnicas de grupo mais estruturadas e pode ser 
aprendida, com muito pouco investimento
� Desvantagens
– por ser um processo relativamente não estruturado, não 
produz a mesma qualidade ou nível de detalhes de outros 
processos
77
19Prof. Heitor A. X. Costa – Grupo de Pesquisa em Engenharia de Software (PqES) – DCC/UFLA
RequisitosRequisitos
� Voltando a descoberta de requisitos.....
– Devem ter algumas características;
� Estão corretos: requisitos definidos sem erros
� São consistentes: há requisitos ambíguos ou conflitantes
� Estão completos: estados + mudanças de estado + entrada + 
produtos + restrições estão descritos por algum requisito
� São realistas: o requisito pode ser implementado
� São imprescindíveis: requisito limita o trabalho dos 
desenvolvedores e não estão diretamente ligados ao problema
� São verificados: possibilidade de planejar testes
� São rastreados: fácil identificar o(s) requisitos que trata(m) um 
aspecto do software