O processo de Engenharia de Requisitos

Apresentação em tema: "O processo de Engenharia de Requisitos"— Transcrição da apresentação:

1 O processo de Engenharia de Requisitos
Plano Aprovado O objetivo da PETROBRAS é montar uma “carteira de projetos – NTI” em execução, com pré-projetos aprovados pelos clientes ou Ordem de Serviço (OS) expressa. Isto tem sido feito no GID, software que deve ser desativado, migrando-se para o NTI o registro das necessidades, das demandas... Existem quatro fases principais no processo de engenharia de requisitos. - Estudo de viabilidade: é feita uma estimativa para verificar se as necessidades dos usuários que foram identificadas podem ser satisfeitas com a utilização das atuais tecnologias de software e hardware. O estudo decidirá se os sistema proposto será viável do ponto de vista comercial, e se poderá ser desenvolvido considerando certas restrições orçamentárias. - Levantamento e Análise de Requisitos: este é o processo de obter os requisitos do sistema pela observação de sistemas existentes, pela conversa com usuários e clientes em potencial, pela análise de tarefas e assim por diante. Ele pode envolver o desenvolvimento de um ou mais diferentes modelos e protótipos de sistema. Ajuda o analista a compreender o sistema a ser especificado. - Especificação de Requisitos: é a atividade de traduzir as informações coletadas durante a atividade de análise em um documento que defina um conjunto de requisitos. Validação de Requisitos: esta atividade verifica os requisitos quanto a sua pertinência, consistência e integralidade. Durante este processo, inevitavelmente são descobertos erros na documentação de requisitos. Os requisitos devem estão ser modificados afim de corrigir esses problemas. Fonte: Sommerville, pag. 46.

2 2. Obtenção e Análise dos Requisitos
Avaliar os problemas na situação atual Principal foco para o novo sistema: O QUE e não COMO: qual o fluxo e o conteúdo de informação quais as funções do sistema quais dados o sistema produz e consome qual o comportamento do sistema quais as características de interface com outros subsistemas quais são as restrições do projeto

3 2. Obtenção e Análise dos Requisitos – cont.
Sintetizar uma ou mais soluções conforme delineado em um Plano de Projeto de Software o processo de avaliação e síntese continua até que o analista e o cliente concordem que o sistema esteja adequadamente especificado é a maior área de esforço

4 Durante a atividade de avaliação e síntese devem ser criados
Modelagem Durante a atividade de avaliação e síntese devem ser criados modelos do sistema para se compreender melhor o fluxo de dados e de controle: padrão de comportamento padrão da informação esses modelos devem garantir o atendimento aos requisitos O modelo serve como fundamento para o projeto do sistema e como base para a criação de sua especificação

5 3. Especificação dos Requisitos
Refinamento detalhado de todos os requisitos  Requisitos de Produto Funções descritas em detalhe Estabelecimento das características de interface Com outros subsistemas Ambiente de implementação Interface Humano-Computador Segurança, etc Identificação das restrições de projeto Especificação dos critérios de validação

6 Verifica os requisitos
4. Validação Verifica os requisitos Critérios: pertinência, consistência, completude As revisões são conduzidas pelo Cliente e pelo Desenvolvedor A base para a revisão são os documentos produzidos na Especificação dos Requisitos O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise

7 A Gerência do Processo de Desenvolvimento

8 Qual o propósito de estabelecer um Ciclo de Vida para o Software?
Definir que atividades devem ser executadas em um projeto de desenvolvimento de sistemas Introduzir consistência entre vários projetos de desenvolvimento de sistemas de uma mesma organização Prover pontos de controle para prever, gerenciar e controlar o desenvolvimento de sistemas

9 Cascata Evolucionário Formal Orientado a Reuso Espiral Incremental
Ciclo de Vida Cascata Evolucionário Formal Orientado a Reuso Espiral Incremental Fonte: Pressman

10 Prevê um processo de desenvolvimento com etapas seqüenciais
Cascata Ciclo de Vida Clássico Prevê um processo de desenvolvimento com etapas seqüenciais Base: engenharia convencional O resultado de cada fase envolve a elaboração de um ou mais documentos que são aprovados

11 Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção
Cascata Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção

12 Cascata Problemas: Para grandes projetos o tempo que decorre desde a especificação até sua implantação é grande O Ambiente Externo evolui e é diferente daquele que deu origem a sua especificação Na prática os estágios se sobrepõem O processo de software envolve interações

13 Base Dois tipos: Evolucionário Desenvolver uma implementação inicial
Expor o resultado ao comentário do usuário Aprimoramento por meio de muitas versões Até que o sistema tenha sido totalmente desenvolvido Dois tipos: Exploratório Protótipos descartáveis

14 Protótipos descartáveis
Evolucionário Exploratório Trabalhar com o cliente O desenvolvimento inicia com as partes do sistema que são compreendidas O sistema evolui com as novas características propostas pelo cliente Protótipos descartáveis O protótipo experimenta os requisitos não compreendidos Neste caso o objetivo é a Especificação de Requisitos Falaremos de protótipos mais adiante

15 Evolucionário Especificação Versão Inicial Desenvolvimento Versões
Intermediárias Descrição do Esboço Descrição do Esboço Validação Versão Final

16 Produz sistemas que atendem as necessidades imediatas do cliente
Evolucionário Produz sistemas que atendem as necessidades imediatas do cliente Problemas O processo não é visível Não se produzem documentos que reflitam as versões do sistema Freqüentemente são mal estruturados Software sem estrutura Modificações cada vez mais custosas Ferramentas e técnicas especiais Possibilitam rápido desenvolvimento Poucas pessoas podem ter a habilitação necessária para usá-las

17 Evolucionário Início Definição de Fim Requisitos e Refinamento Produto
Projeto Rápido Constru- ção do Protótipo Avaliação do Usuário do protótipo Produto Final Evolucionário Fim

18 Formal Base: a transformação matemática formal de uma especificação de sistema em um programa executável A especificação de requisitos é redefinida com uma linguagem formal Especificação de Requisitos Especificação Formal Transformação Testes

19 Adequada a sistemas críticos
Formal Transformação formal Várias etapas Representação mais detalhada, matematicamente correta Adequada a sistemas críticos Permite verificação automática de consistência Model checking utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições Prova de teoremas axiomas do comportamento do sistema são empregados para derivar uma prova de que o sistema vai se comportar de uma determinada forma

20 Ampla base de componentes reusáveis Infra-estrutura de integração
Orientado a Reuso Ampla base de componentes reusáveis Infra-estrutura de integração Etapas: De posse da Especificação de Requisitos, buscam-se componentes para implementá-la Negociação – requisitos são modificados para que se possa usar os componentes Redução do esforço de desenvolvimento

21 Partes do processo são repetidas enquanto os requisitos evoluem
Iteração de processo Existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema Partes do processo são repetidas enquanto os requisitos evoluem Modelos Híbridos Apóiam a iteração do processo Desenvolvimento Espiral Desenvolvimento Incremental

22 O processo de desenvolvimento se move sobre uma espiral evolucionária
Modelo Espiral O processo de desenvolvimento se move sobre uma espiral evolucionária Melhores características do Ciclo de vida clássico Evolucionário – Prototipação Acrescenta Análise de Riscos As fases são executadas de forma iterativa As fases de análise e projeto não são monolíticas e distintas Este é o Modelo PETROBRAS de Desenvolvimento

23 Modelo Espiral Boehm 88

24 Desenvolvimento e Validação Avaliação feita pelo Cliente
Modelo Espiral Planejamento objetivos, alternativas e restrições Análise de Riscos Análise de alternativas e identificação/resolução de riscos Prototipação pode ser usada Simulações e outros modelos podem ser usados para definir melhor o problema Desenvolvimento e Validação Desenvolvimento do produto no “nível seguinte” Avaliação feita pelo Cliente Volta ao Planejamento

25 Enfoque Incremental Uma variação do modelo cascata onde a partir da fase de especificação de requisitos são feitos incrementos sucessivos. Estratégia para minimizar riscos, obtendo- se resultados de médio e curto prazo sem se descuidar do objetivo final

26 Enfoque Incremental Uma interação Requisitos Design Codificação Testes
Implantação Requisitos Design Codificação Testes Implantação tempo

27 Desenvolvimento Incremental
O Processo de Desenvolvimento RUP está em conformidade com o Desenvolvimento Incremental.

28 Desenvolvimento Incremental
Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em partes, com cada incremento entregando parte da funcionalidade requerida Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados“, embora possam continuar a evoluir para incrementos posteriores

29 Desenvolvimento Iterativo e Incremental (RUP)
O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software.  Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.  Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis. A figura acima mostra a arquitetura geral do RUP. O RUP tem duas dimensões: - o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve - o eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza. A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos. A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase. O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais tempo com implementação. Fonte: RUP

30 Engenharia de Requisitos

31 Engenharia de Requisitos
Compreender a natureza do software a ser desenvolvido é realmente muito complexo Conseqüentemente é difícil estabelecer o que o sistema deve fazer Estabelecer o que o sistema deve fazer descrevendo suas funções e restrições é conseguir determinar todos os seus requisitos O Processo de: Descobrir Analisar Documentar Verificar É chamado de Engenharia de Requisitos

32 Engenharia de Requisitos
Engenharia de Requisitos é dividida em tarefas interativas: A engenharia de requisitos é composta pela produção e pela gerência de requisitos. Elicitação (captura, descoberta, aquisição) de requisitos Análise de Requisitos detecção e resolução de conflitos, descoberta dos limites e interações do sistema com o ambiente (mapeamento dos requisitos do sistema para requisitos do software) Especificação de requisitos (estrutura, qualidade e verificação do documento de requisitos) Validação de requisitos (verificação de omissões, conflitos e ambiguidades) + adequação às normas de qualidade. Gerência de requisitos (gestão de mudanças, manutenção da consistência com as fases posteriores) A gerência de qualidade inclui a verificação ou análise do requisito (inspeção). Os requisitos são registrados (centro da figura).

33 Engenharia de Requisitos
O processo de estabelecer as funções que um cliente requer de um sistema e as restrições sob as quais ele deve funcionar e ser desenvolvido Os requisitos são descrições das funções e restrições que são geradas durante o processo de engenharia de requisitos

34 Atividades de Engenharia de Requisitos – Recursos Humanos

35 Atividades de Engenharia de Requisitos
Analista de Negócio Cliente Analista de Requisitos Inspetor Testador Elicitação dos Requisitos - Especificação e Modelagem dos Verificação e Validação dos Rastreabilidade e Gestão de Mudanças As principais atividades da gerência de requisitos são: · Elicitação dos Requisitos de Negócio; · Especificação e Modelagem dos Requisitos; · Validação/Verificação dos Requisitos; · Rastreabilidade e Gestão de Mudanças dos Requisitos. Fonte: Padrão Gerenciamento de Requisitos (PETROBRAS)

36 Organização e Responsabilidade - Papéis
Analista de Negócios Negocia junto com os clientes e os demais envolvidos a lista dos requisitos iniciais e suas ampliações, priorizando-os e quando necessário agrupando-os em pacotes a serem desenvolvidos em iterações. É responsável por explicitar as regras de negócio e o glossário associado ao negócio. Analista de Requisitos Elicita os requisitos de produto e registrá-os de forma adequada. Garante a rastreabilidade dos requisitos de negócio e requisitos de produto ao longo do projeto. Cliente Aprova a versão final do escopo da aplicação, descrito na Especificação de Requisitos de software Inspetor Inspeciona a Especificação de Requisitos de Software com relação ao formato. Testador Aplica o Plano de Testes e assegura que os requisitos implementados estão de acordo com o requisitado pelo cliente. O objetivo de ter-se papéis definidos é manter uma estrututura independente da mudança de estrutura na Petrobras. Este tópico apresenta de forma geral a divisão de trabalho entre os papéis que compõe a equipe do projeto de desenvolvimento de um software, porém o líder de projeto pode usar outra configuração de equipe em função das necessidades do projeto, sua complexidade, abrangência e tamanho. Fonte: Plano de Gerenciamento de Requisitos (PETROBRAS)

37 Elicitação dos Requisitos de Negócio
Explicitar o domínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios O analista de negócios é o responsável, não é uma figura única no processo. Regras de Negócio Glossário Documento de Visão

38 Especificação e Modelagem de Requisitos
Regras de Negócio Glossário Documento de Visão Elicitar Requisitos de Produto Especificar casos de uso e validá-los Especificar requisitos não funcionais Analisar e validar os requisitos Analista de Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção

39 Verificação e Validação dos Requisitos
Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção Verificar conflitos de requisitos Verificar consistência de requisitos Verificar completude de requisitos Verificar existência de requisitos ambíguos Inspetor Garantir a rastreabilidade dos requisitos Validar requisitos com o cliente Analista de Requisitos Especificação de Requisitos Atualizada Resultado dos Casos de Teste

40 Rastreabilidade e Gestão de Mudanças
Necessidade Avaliar o impacto nos requisitos Validar com o cliente Notificar os envolvidos Atualizar as especificações de requisitos Garantir a rastreabilidade nos requisitos Analista de Negócios Solic. Mudança Analista de Requisitos Especificação de Requisitos Atualizada Documento de Visão Atualizado

41 Resumo da nomenclatura e templates
Requisito Tipos Documento Requisitos de Negócio (RQN) F, NF, I Documento de Visão Requisitos de Produto F Casos de Uso (UC) NF Especificação Suplementar (SUPL) Regras de Negócios (RN) - Regras de Negócios Termos (TERM) Glossário A rastreabilidade nesses casos ocorre da seguinte maneira: RQN para UC = RQN originou um UC RQN para SUPL = RQN originou um SUPL RN para TERM = RN originou um termo RN para UC = RN seguida num UC (adotada, usada) Legenda: F = Funcionais NF = Não Funcionais I = Inversos

42 Elicitação de Requisitos

43 Elicitação dos Requisitos de Negócio
Explicitar o domínio do problema Identificar possibilidade de reuso de solução Identificar pessoas e áreas impactadas Elicitar e classificar os requisitos de negócio Envolver a área de serviços e definir alternativas de solução Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão

44 Elicitação de Requisitos
Atividades que envolvem a descoberta de requisitos de um sistema: identificação das fontes de informação técnicas de elicitação (coleta de fatos) comunicação (estabelecer uma linguagem comum) Envolve pessoal objetivando descobrir: o domínio de aplicação serviços que devem ser fornecidos restrições Engenheiros e desenvolvedores de software trabalham diretamente com clientes e usuários finais na tentativa de achar problemas a serem resolvidos, serviços que o sistema deve prestar, requisitos de performance, restrições de hardware e outro. Para isso não é necessário apenas perguntar para as pessoas o que elas querem, requer uma análise muito mais cuidadosa da organização, do domínio da aplicação e dos processos de negócio onde o sistema será usado. ( )

45 Elicitação de Requisitos
Pode envolver diferentes tipos de pessoas em uma organização (stakeholders): usuários gerentes desenvolvedores especialistas de domínio sindicatos,... A equipe de desenvolvimento e clientes trabalham em conjunto visando identificar: detalhes do domínio da aplicação serviços que o sistema deve oferecer desempenho restrições de hardware, ... Stakeholders: pessoas relacionadas ao software, direta ou indiretamente. São também conhecidas como os atores desse universo.

46 Elicitação de Requisitos
Problemas: Em geral, stakeholders não sabem o que querem de fato dificuldade de expressão pedidos não realistas Stakeholders expressam requisitos em sua própria terminologia conhecimento implícito Stakeholders distintos podem ter requisitos conflitantes Fatores políticos podem influenciar os requisitos do sistema Ambientes econômicos e de negócios são dinâmicos requisitos mudam durante o processo de análise novos requisitos podem surgir (novos stakeholders) Fonte: Processo de Engenharia de Requisitos - UFBa

47 Elicitação de Requisitos
Atividades do Processo: Compreensão do domínio Coleta de requisitos Classificação Resolução de conflitos Definição de Prioridades Verificação de requisitos Sommerville, pag. 105

48 Compreensão do Domínio
Os analistas devem desenvolver sua compreensão do domínio da aplicação se estiver desenvolvendo um sistema de supermercado deverá descobrir como este funciona utilizar técnicas para descobrir este funcionamento aprender a linguagem do usuário elaborar um Glossário

49 Interagir com stakeholders para descobrir os requisitos
Coleta de Requisitos Interagir com stakeholders para descobrir os requisitos A coleta de requisitos é feita através de técnicas Os requisitos são simplesmente documentados à medida que são coletados resulta em documento preliminar (draft) A coleta de requisitos é feita através de técnicas, estudadas no decorrer deste curso.

50 Classificação dos Requisitos
Consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidas Classificação: Funcional Ex.: Deve ser possível consultar o preço de uma mercadoria Não Funcional Ex.: A consulta deve retornar uma resposta em no máximo 5s Inversos Ex.: O sistema não fará controle de estoque.

51 Resolução de Conflitos
É normal que ocorram requisitos conflitantes Por exemplo R-23: O sistema deve ... R-45: O sistema não deve ... Cliente é o responsável por resolver conflitos e ambigüidades Conflitos: afirmações conflitantes – contraditórias- duas ou mais coisas que não são possíveis simultâneamente Ambiguidades : requisitos mal definidos – denota incerteza, insegurança, indeciso – indeterminado, impreciso, incerto

52 Atribuição de Prioridade
Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar

53 Requisitos podem ser agrupados em classes, por exemplo:
Prioridade Requisitos podem ser agrupados em classes, por exemplo: Essenciais Importantes Desejáveis Em princípio, o sistema deve abranger todos os requisitos de essenciais para desejáveis

54 A consulta ao extrato bancário deve visualizar dados segundo padrão X
Exemplo de Prioridade A consulta ao extrato bancário deve retornar dados do movimento até o dia anterior Prioridade: Essencial A consulta ao extrato bancário deve visualizar dados segundo padrão X Prioridade: Importante A consulta ao extrato bancário deve usar cores vermelhas para saldos negativos Prioridade: Desejável

55 Verificação de Requisitos
Os requisitos são verificados Completos? Consistentes? Em concordância com o que os stakeholders desejam?

56 Processo de Elicitação de Requisitos
Especificação de Requisitos Verificação dos Requisitos Compreensão do Domínio Definição de Prioridades Documento de Requisitos Coleta de Requisitos Resolução de Conflitos Fonte: Sommerville, 2003, pag. 106. Classificação

57 Técnicas de Elicitação

58 Técnicas de Elicitação
What follows is a crash course in elicitation techniques. We will briefly discuss each topic in turn. Many of these techniques can be used together. There are many other techniques such as: Production software Task analysis ... Note: Storyboarding and prototyping have been moved to “Module 7: Refining the System Definition”. Entrevistas Questionários Leitura de Documentos Observação Reuniões Brainstorming JAD – Joint Application Design Cenários Existem várias técnicas para elicitação de requisitos, dentre elas temos as entrevistas, Questionários, Leitura de Documentos, Observação, Reuniões, JAD e Elaboração de Cenários.

59 Pode ser guiada por um questionário
Entrevistas Refer back to the interview exercise we did at the beginning of the class to determine their needs for this class. Técnica direta Pode ser usada na análise do problema e na elicitação de requisitos Objetivo Entender os problemas reais e soluções potenciais das perspectivas dos usuários, clientes, e outros stakeholders Pode ser guiada por um questionário Entrevista é provavelmente a técnica mais útil para coletar as necessidades dos stakeholders. É acomselhavel entrevistar os stakeholders "chaves" para determinado projeto. Uma técnica de entrevista direta de pessoa para pessoa que seja eficiente exige a preparação de uma lista de perguntas elaboradas para se obter uma compreensão dos problemas reais e das possíveis soluções. Para obter respostas o mais imparciais possível, você precisará certificar-se de que as perguntas feitas serão sem contexto. As perguntas sem contexto são perguntas abstratas de alto nível que podem ser feitas na fase inicial de um projeto para obter informações sobre propriedades globais dos problemas dos usuários e de suas possíveis soluções. Uma pergunta sem contexto é: - Sempre apropriada. - Formulada para ajudá-lo a entender as perspectivas dos envolvidos. - Imparcial em relação ao conhecimento das soluções ou à sua opinião de quais seriam as soluções. Script de Entrevistas Sem Contexto:  Existem grandes oportunidades em nossa indústria para aprimorar os esforços de desenvolvimento de aplicativos. Compreender as necessidades dos usuários ou dos envolvidos antes de iniciar o desenvolvimento é crucial para aprimorar esse processo. Há muitas técnicas disponíveis para identificar as necessidades dos usuários ou dos envolvidos. Uma técnica simples e de baixo custo que poderá ser adequadamente usada em praticamente todas as situações é a Entrevista Genérica. A Entrevista Genérica poderá ajudar o desenvolvedor ou o analista a compreender os objetivos e os problemas dos usuários ou dos envolvidos. Com esse discernimento, os desenvolvedores poderão criar aplicativos que se ajustem às necessidades reais dos usuários ou dos envolvidos e que aumentem sua satisfação. A Entrevista Genérica pode conter perguntas que exploram os requisitos de funcionalidade, usabilidade, confiabilidade, desempenho e suportabilidade do aplicativo. Com o uso da Entrevista Genérica, o desenvolvedor ou o analista obterá um conhecimento do problema que está sendo resolvido, assim como uma compreensão das percepções dos usuários ou dos envolvidos acerca das características das soluções bem-sucedidas. Diretrizes de Uso: Se a Entrevista Genérica não estiver adequada às suas necessidades, você poderá modificá-la sempre que desejar. Com um pouco de preparação e uma entrevista bem estruturada, qualquer desenvolvedor ou analista poderá entrevistar de maneira eficiente. Abaixo são relacionadas algumas dicas: ·         Faça uma pesquisa prévia da formação dos envolvidos ou dos usuários e da empresa. ·         Revise as perguntas antes da entrevista. ·         Consulte o formato durante a entrevista para assegurar que as perguntas certas estão sendo feitas. ·         Resuma os dois ou três problemas principais no final da entrevista. Repita o que você aprendeu para confirmar sua compreensão. Não deixe que o script limite demais as suas iniciativas. Depois de ter sido desenvolvida uma harmonia, a entrevista tomará vida própria, e o envolvido ou o usuário poderá falar bastante sobre as dificuldades pelas quais está passando. Não os interrompa. Anote essas respostas o mais rápido possível. Faça perguntas após obter essas informações. Depois que essa troca de informações chegar a um fim lógico, prossiga com as outras perguntas contidas na lista. Fonte: RUP

60 Quatro tipos de questões são importantes em entrevistas:
Sobre o usuário Sobre o processo Sobre o produto Meta-perguntas Quatro tipos de questões são importantes em entrevistas: Sobre o usuário – características dos usuários Sobre o processso – o modo como as pessoas executam as tarefas Sobre o produto – – funcionalidades e características do produto final (exemplo, um relatório, uma consulta) Meta-perguntas– é uma técnica onde se faz perguntas a partir de outra pergunta. Exemplos de perguntas sem contexto usadas para encontrar atores: Quem é o cliente? Quem é o usuário? Suas necessidades são diferentes? Quais são suas formações, habilidades, ambientes? Exemplos de perguntas sem contexto que ajudam a compreender os processos de negócios: Qual é o problema? Qual é a razão para que se deseje resolver esse problema? Existem outras razões para que se deseje resolver esse problema? Qual é a importância de uma solução bem-sucedida? Como se resolve o problema agora? Qual é o ponto de equilíbrio entre tempo e valor? Em que outro lugar a solução para esse problema pode ser encontrada? Exemplos de perguntas sem contexto que ajudam a compreender os requisitos do sistema ou do produto a ser criado: Que problema esse produto resolve? Que problemas de negócios esse produto poderá ocasionar? Que riscos poderão existir para o usuário? Que ambiente o produto encontrará? Quais são as suas expectativas em relação à usabilidade? Quais são as suas expectativas em relação à confiabilidade? Que desempenho/precisão é exigido? Exemplos de meta-perguntas sem contexto: Estou fazendo muitas perguntas? Minhas perguntas parecem relevantes? Você é a pessoa certa para responder a essas perguntas? As suas respostas são requisitos? Posso fazer mais perguntas depois? Você aceitaria participar de uma revisão de requisitos? Há algo mais que eu poderia perguntar a você? São exemplos de perguntas que necessitam de contexto: Perguntas que induzem a uma determinada resposta: "Você precisa de uma tela maior, não é?" Perguntas que se auto-respondem: "São suficientes cinqüenta itens?" Instruções de controle: "Podemos responder às minhas perguntas?" Muito longas e muito complexas: "Tenho uma pergunta que se divide em três partes, ..." Ao formular um conjunto de perguntas, você também deverá levar em consideração o seguinte: Não peça às pessoas que descrevam algo que não costuma descrever. Não faça perguntas que pressuponham que os usuários podem descrever atividades complexas. Exemplo: amarrar o cadarço do sapato. Em geral, as pessoas podem fazer muitas atividades que não conseguem descrever. Evidências empíricas - poucas correlações. Faça perguntas para as quais não haja respostas definitivas. Evite perguntas iniciadas por "Por que...?", já que elas poderão levar a uma postura defensiva. Ao conduzir uma sessão de entrevista, lembre-se: Não espere respostas simples. Não apresse o entrevistado em suas respostas. - Ouça, ouça, ouça!

61 Usuário: Quem é o cliente? Quem é o usuário?
Entrevistas Usuário: Quem é o cliente? Quem é o usuário? Suas necessidades são diferentes? Quais são suas formações, habilidades, ambientes? Quatro tipos de questões são importantes em entrevistas: Sobre o usuário – características dos usuários Sobre o processso Sobre o produto Meta-perguntas

62 Processo: Entrevistas Qual é o problema? Como é resolvido atualmente?
Qual a razão para resolver o problema? Existe outra solução para este problema? Qual o valor de uma solução bem-sucedida? Quatro tipos de questões são importantes em entrevistas: Sobre o usuário Sobre o processso – o modo como as pessoas executam as tarefas Sobre o produto Meta-perguntas.

63 Produto: Entrevistas Que problema esse produto resolve?
Que problemas de negócios esse produto poderá ocasionar? Que riscos poderão existir para o usuário? Que ambiente o produto encontrará? Quais são as suas expectativas em relação à usabilidade (facilidade de uso)? Quais são as suas expectativas em relação à confiabilidade? Que desempenho/precisão é exigido? Quatro tipos de questões são importantes em entrevistas: Sobre o usuário Sobre o processso Sobre o produto – funcionalidades e características do produto final (exemplo, um relatório, uma consulta) Meta-perguntas

64 Meta-perguntas: Entrevistas Estou fazendo muitas perguntas?
Minhas perguntas parecem relevantes? Você é a pessoa certa para responder a essas perguntas? As suas respostas são requisitos? Posso fazer mais perguntas depois? Você aceitaria participar de uma revisão de requisitos? Há algo mais que eu poderia perguntar a você? Quatro tipos de questões são importantes em entrevistas: Sobre o usuário Sobre o processso Sobre o produto Meta-perguntas – é uma técnica onde se faz perguntas a partir de outra pergunta.

65 Acesso a um grande número de pessoas Vantagens: Desvantagens:
Questionários Should still be prefaced by interviews to determine the correct questions to ask. How many customers should be interviewed to determine a good cross-section of questions? Usually is adequate. Most items should be categorized to allow for statistical analysis. Always leave some open-ended questions to allow for new ideas. Acesso a um grande número de pessoas Vantagens: padronização de perguntas possibilidade de tratamento estatístico das respostas Desvantagens: limitação do universo de respostas pouca interação (impessoalidade técnica) Um questionário pode ser útil para coleta de dados, mas deve ainda ser antecedida por entrevistas para determinar as perguntas corretas a serem feitas. Quantos clientes devem ser entrevistados para determinar um bom conjunto de perguntas? Normalmente, de é adequado. A maioria de itens devem ser categorizados, para permitir a análise estatística. Sempre deixe algumas perguntas em aberto para permitir a coleta de novas idéias. Fonte: Mota, 2006.

66 Aplicabilidade a mercados específicos Em questionários:
Should still be prefaced by interviews to determine the correct questions to ask. How many customers should be interviewed to determine a good cross-section of questions? Usually is adequate. Most items should be categorized to allow for statistical analysis. Always leave some open-ended questions to allow for new ideas. Aplicabilidade a mercados específicos com perguntas bem definidas Em questionários: perguntas relevantes podem ser decididas antecipadamente, por entrevistas o leitor interpreta a pergunta da maneira que deseja possibilidade de análise com questões abertas

67 Análise de documentos referentes ao sistema
Leitura de Documentos Ask group if they’ve used this technique. If anyone has used CRC cards they can share how they were used and if they were successful. The CRC Card technique is based on paper by Kent Beck and Ward Cunningham. The technique was made popular by Rebecca Wirffs-Brock. Análise de documentos referentes ao sistema Documentos técnicos: relatórios, manuais Documentos legais: normas, leis, atas Análise de formulários

68 Deve ser usada com outras técnicas Técnica de observação: etnografia
Analista se insere no ambiente de trabalho em que o sistema será utilizado Observa trabalho diário Anota as tarefas reais dos participantes Analista é imparcial Deve ser usada com outras técnicas Técnica de observação: etnografia Etnografia: a etnografia é uma técnica de observação que pode ser utilizada ara compreender os requisitos socias e organizacionais. Um analista se insere no ambiente de trabalho em que o sistema será utilizado, observa o trabalho diário e anota as tarefas reais em que os participantes estão envolvidos. O valor da etnografia é que ela ajuda a descobrir requisitos de sistema implícitos, que refletem os processos reais, em vez de os processos formais, em que as pessoas estão envolvidas. Fonte: Sommerville, 2003, pag. 114

69 É eficaz na descoberta de dois tipos de requisitos
Observação É eficaz na descoberta de dois tipos de requisitos Os derivados da maneira como as pessoas realmente trabalham e não a forma como deveriam trabalhar Operadores desligam alarme de colisão em um controle aéreo Os derivados da cooperação e conscientização das atividades de outras pessoas Um controlador de tráfego aéreo pode prever quantas aeronaves entrarão no seu setor de controle, observando trabalho em setores adjacentes Portanto o sistema deve prever alguma visibilidade destes setores adjacentes

70 Permite uma interação mais natural entre pessoas
Reuniões Permite uma interação mais natural entre pessoas Revela múltiplas visões sobre a questão abordada explicitar cada problema encontrado nos requisitos todos os interessados devem ter a oportunidade de comentar (criação coletiva) oportunidade para priorizar requisitos

71 Estratégias para Reuniões:
Desvantagens: possibilidade de dispersão custo Estratégias para Reuniões: Brainstorming Joint Application Design (JAD)

72 Reuniões - Brainstorming
Fase de exploração de requisitos Regras para Brainstorming Estabeleça o objetivo da sessão Gere quantas idéias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as idéias Fonte: Mota, 2006. Orientações de Trabalho: Brainstorming e Filtro de Idéias A atividade de brainstorming implica que todas as pessoas da sala do workshop se dediquem durante um curto período de tempo, digamos 15 minutos, a expressar tudo o que acham importante para o projeto. Depois disso, um facilitador conduzirá o grupo durante a organização e priorização dos resultados. As regras de brainstorming são as seguintes: - Começar definindo claramente o objetivo da sessão de brainstorming. - Gerar o maior número possível de idéias. - Deixar a imaginação fluir. - Não permitir críticas ou debates durante a reunião de informações. - Depois da reunião das informações, transformar e combinar as idéias. A reunião das informações normalmente é muito informal. As idéias são expressas para o facilitador, que as anota em folhas de blocos de anotações autocolantes e depois as cola em flip charts. As informações são então "podadas" para que as idéias semelhantes sejam combinadas e as idéias inadequadas sejam eliminadas. Outras técnicas para reduzir a quantidade de anotações autocolantes consistem em: Fazer com que todos expressem seus votos ou Deixar que todos priorizem cada idéia por categoria (por exemplo, muito importante, importante e desejável), com pesos atribuídos a elas (por exemplo, 3, 2, 1). A soma das prioridades de cada idéia identificará a sua importância em relação às outras. Algumas idéias poderão ser simplesmente guardadas para uma sessão posterior caso tenham que ser melhor elaboradas. As anotações autocolantes restantes serão então redistribuídas e organizadas de uma maneira que faça sentido. Fonte: RUP

73 Joint Application Design Surgiu em meados de 1970, na IBM
Reuniões - JAD Joint Application Design Surgiu em meados de 1970, na IBM Similar a um Workshop de requisitos Fase de especificação de requisitos Põe todos os stakeholders juntos por um período intensivo (focado) Pode utilizar representações de Engenharia de Software

74 Provê um ambiente para aplicar outras técnicas de elicitação
Reuniões - JAD Ask: “Has anyone participated in a similar workshop?” This section is much more effective if it is presented in the context of a real (or close to real) workshop in which you have actually participated -- or at least in the context of an imaginary one which you might want to set up. Provê um ambiente para aplicar outras técnicas de elicitação Facilitador conduz a reunião Todos têm sua vez de falar Resultados estão disponíveis imediatamente

75 Executivo patrocinador:
JAD - Definições Executivo patrocinador: Gerente de nível mais alto comprometido com JAD Patrocina o processo do início ao fim Fornece diretrizes sobre os objetivos e metas de um projeto Define expectativas claras para saída do processo JAD Realiza breve palestra; não participa de atividades das sessões detalhadas, pode ser chamado para esclarecer questões administrativas críticas Gerentes funcionais e usuários finais: Peritos em sessões JAD detalhadas Tem a capacidade de descrever porque precisam do sistema

76 Representantes da TI: Líder de sessão JAD JAD - Definições
Poucas pessoas Convidadas a participar das sessões Tem conhecimentos técnicos das aplicações atuais do negócio pelo ponto de vista dos sistemas Líder de sessão JAD Coração do processo JAD Seu papel é conduzir as entrevistas preparatórias antes da sessão JAD real com o executivo patrocinador e com gerentes funcionais para a definição do escopo básico do processo

77 Escribas JAD - Definições
Registrar oficialmente todas as informações pertinentes ao sistema estudado Sessões maiores – 2 escribas Um descreve os comportamentos do sistema Outro (da mesma área dos usuários) controla questões de negócio levantadas pelos usuários durante a sessão de dinâmica de grupo Uso de ferramentas automatizadas para capturar os requisitos e exibir de volta para os usuários as telas, relatórios, etc.

78 Reuniões - JAD Ask: “Has anyone participated in a similar workshop?”
This section is much more effective if it is presented in the context of a real (or close to real) workshop in which you have actually participated -- or at least in the context of an imaginary one which you might want to set up. FONTE: (Valacich, 2001)

79 Quatro etapas: Processo JAD Orientação inicial
Familiarização com a área/aplicação Preparação do material para o workshop Workshop Fonte:http: notas de aula Profas Rosângela Aparecida D. Penteado e Júnia Coutinho Anacleto (UFSC) //

80 Processo JAD – Orientação Inicial
Definição global do projeto documentando os seguintes itens finalidade do projeto escopo do projeto e áreas funcionais envolvidas objetivos que devem ser alcançados no final do workshop suposições técnicas e de negócio que afetam o projeto fatores críticos de sucesso Informações são obtidas pelo líder com o executivo patrocinador com os gerentes funcionais e de sistemas ligados ao projeto antes do workshop

81 Processo JAD - Familiarização com a área/aplicação
Análise de procedimentos atuais do negócio e identificação do fluxo geral de trabalho dos documentos no local do trabalho Documentar procedimentos, ressaltando: finalidade da tarefa dados de entrada dados de saída descrição do processo feito problemas/oportunidades

82 Processo JAD - Preparação do material para o workshop
Analista de Sistema (pode ser o líder JAD) constrói um modelo elementar do sistema esboço de telas e relatórios veículos para simular as idéias

83 Processo JAD - Conduzir o workshop
Duração: 3 a 5 dias 1º dia: Explicar a finalidade do projeto Descrever os compromissos de todos os participantes com apoio da administração Dar as informações gerais relacionadas ao escopo, objetivo Revisar o material detalhado e consolidado antes da reunião - abordagem estruturada, passo a passo Conforme o workshop progride, os escribas transcrevem as decisões para telões, permitindo rápidas revisões do trabalho realizado até o momento

84 Cenários Esboço da interação Os métodos baseados em Cenários consistem de uma coleção de narrativas de situações do domínio do problema que permitem a identificação de componentes do projeto Meio de representação de fácil compreensão para os usuários envolvidos que passam a poder avaliar, criticar e fazer sugestões

85 Esboço da interação Podem incluir: Cenários
Uma descrição do estado do sistema no início do cenário Uma descrição do fluxo normal de eventos no cenário Uma descrição do que pode sair errado e de como lidar com isso Informações sobre outras atividades que possam estar em andamento ao mesmo tempo, e Uma descrição do estado do sistema no final do cenário.

86 Exemplo de Cenário de uso típico para um sistema da biblioteca:
Cenários Exemplo de Cenário de uso típico para um sistema da biblioteca: Um aluno chega na biblioteca para procurar livros-texto dos cursos que está freqüentando. Ele entra no sistema e seleciona os cursos, e obtém uma lista de todos os livros-texto e sua localização na biblioteca. Seleciona a opção de “bibliografia complementar” e uma nova lista de livros e periódicos lhe é apresentada. Ele então manda imprimir todas as referências encontradas

87 Cenários – Técnica de Questionamento Sistemático
É uma técnica psicolingüística que permite a psicólogos e lingüistas examinarem o conteúdo e a estrutura de informações contidas numa narrativa Objetivo é investigar de que maneira as narrativas são efetivamente compreendidas Pode ser utilizada pelos analistas e projetistas tanto para adquirir mais rapidamente conhecimentos sobre o domínio como para inferir objetos e interações não-descritos na narrativa

88 Cenários – Técnica de Questionamento Sistemático
Abrange quatro Etapas: Geração do Cenário Elaboração da Rede de Proposições Análise Questionamento Sistemático

89 Cenários – Técnica de Questionamento Sistemático
Geração do Cenário As narrativas que compõem o cenário devem ser escritas pelo especialista no domínio. O analista pode motivá-lo fazendo perguntas como num processo convencional de entrevista Um exemplo de cenário seria: “Eu quero sacar R$ 100,00. Eu insiro o cartão no caixa eletrônico, pressiono o botão de saque, digito minha senha, retiro o cartão e o dinheiro”

90 Cenários – Técnica de Questionamento Sistemático
Elaboração da Rede de Proposições As narrativas devem ser simplificadas e expressas através de proposições, como por exemplo: “cliente insere cartão no caixa eletrônico” “cliente pressiona botão de saque rápido” “cliente digita a senha” “cliente pega cartão” “cliente pega dinheiro”

91 Cenários – Técnica de Questionamento Sistemático
Análise A partir das proposições, pode-se determinar o perfil das tarefas (ações e objetos) e dos usuários (agentes das ações)

92 Cenários – Técnica de Questionamento Sistemático
Novas proposições podem ser elaboradas através de questões que são feitas sobre elementos das proposições anteriores, num processo iterativo. Existem diversos tipos de questões: Por que ...? visa revelar consequências e causas a respeito de eventos da narrativa

93 Cenários – Técnica de Questionamento Sistemático
Como ...? Oferece maiores detalhes a respeito de determinados eventos, permitindo determinar sub-tarefas e maiores detalhes sobre a interação O que é ...? Pode ser feita sobre objetos e revelam atributos e hierarquias de objetos Então “isto” é/ocorre assim...? Pode ser feita para saber se as proposições estão sendo entendidas corretamente

94 Quais técnicas poderiam ser usadas em:
Exercício Quais técnicas poderiam ser usadas em: Sistema da padaria de pequeno porte Sistema inteligente de preenchimento do IRPF Sistema de abertura automática de porta