M todos de elicita o de requisitos de usabilidade parte 1
This presentation is the property of its rightful owner.
Sponsored Links
1 / 40

Métodos de Elicitação de Requisitos de Usabilidade Parte 1 PowerPoint PPT Presentation


  • 50 Views
  • Uploaded on
  • Presentation posted in: General

Autarquia Educacional do Vale do São Francisco – AEVSF Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE Curso de Ciência da Computação. Métodos de Elicitação de Requisitos de Usabilidade Parte 1. Profa. Cynara Carvalho [email protected]

Download Presentation

Métodos de Elicitação de Requisitos de Usabilidade Parte 1

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


M todos de elicita o de requisitos de usabilidade parte 1

Autarquia Educacional do Vale do São Francisco – AEVSF

Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE

Curso de Ciência da Computação

Métodos de Elicitação de Requisitos de UsabilidadeParte 1

Profa. Cynara Carvalho

[email protected]


Identificando necessidades e estabelecendo requisitos

Identificando Necessidades e Estabelecendo Requisitos

  • Independente dos objetivos do projeto, as necessidades, requisitos e aspirações do usuário têm que ser discutidas, aperfeiçoadas, esclarecidas e seu escopo redefinido.

  • Isso exige um entendimento e um comprometimento da equipe do projeto da interface.


Identificando necessidades e estabelecendo requisitos1

Identificando Necessidades e Estabelecendo Requisitos

  • O quê, como e por quê?

    • Descobrir o que queremos alcançar com o projeto de interfaces.

      • Entendendo o máximo os usuários, suas tarefas e o contexto delas, para que o sistema possa dar suporte na realização das mesmas.

    • Como podemos conseguir esse objetivo?

      • Ciclo de desenvolvimento.

      • Coleta, interpretação e análise dos dados.

    • Por que estabelecer requisitos?

      • Alto índice de atrasos ou falhas em projetos de TI, devido aos requisitos mal detalhados.

      • Se as necessidades dos usuários forem levadas em consideração, o resultado final atenderá suas expectativas e demandas.


Identificando necessidades e estabelecendo requisitos2

Identificando Necessidades e Estabelecendo Requisitos

  • Coleta, captura, elicitação, análise e engenharia de requisitos, embora apontem para o mesmo objetivo, apresentam algumas particularidades.

    • Coleta e captura -> Os requisitos já existem e cabe nós buscá-los ou pegá-los.

    • Elicitação -> Outros (possivelmente clientes ou usuários) conhecem quais são, cabendo a nós fazer com que nos digam.

    • Análise -> Descreve a atividade de investigação de um conjunto inicial de requisitos que foram coletados, elicitados e capturados.

    • Engenharia -> Mais abrangente pois reconhece que desenvolver um conjunto de requisitos constitui um processo iterativo de evolução e negociação que precisa ser cuidadosamente gerenciado e controlado.

  • Estabelecer requisitos representa o fato que os mesmos surgem das atividades de interpretação e coleta de dados, a partir do entendimento das necessidades dos usuários.


M todos de elicita o de requisitos de usabilidade parte 1

Identificando Necessidades e Estabelecendo Requisitos


Afinal o que s o requisitos

Afinal, o que são requisitos?

  • Consiste em uma declaração sobre um produto pretendido que especifica o que ele deveria fazer ou como deveria operar.

  • Devemos torná-los os mais claros possíveis, bem específicos.

  • Exemplo:

    • "o software deve emitir relatórios de compras a cada quinze dias"


Diferentes tipos de requisitos

Diferentes tipos de requisitos

  • Derivados da Eng. Software, os requisitos podem ser:

    • Funcionais -> Os requisitos funcionais descrevem o que o sistema faz, isto é, suas funcionalidades necessárias para atender os objetivos do sistema, descrevendo os fluxos de eventos, prioridades, entradas e saídas de cada recurso.

      Ex: o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".

    • Não Funcionais-> Dizem respeito à qualidade do sistema. Eles descrevem as facilidades do sistema e são diretamente ligados a aspectos que muitas vezes são negligenciados pelos Engenheiros de Software, que são os fatores psicológicos.

      Ex:"o tempo de resposta do sistema não deve ultrapassar 30 segundos".


Requisitos do usu rio x requisitos de usabilidade

Requisitos do usuário X Requisitos de Usabilidade

  • Requisitos do usuário -> Capturam as características do grupo de usuários.

    • Ex.: Um sistema de controle nuclear precede da necessidade dos usuários serem altamente especializados, diferentes de um processador de textos.

  • Requisitos de usabilidade -> Capturam as metas de usabilidade e as medidas associadas para um produto.

    • Ex.: Características do sistema/produto que contemplem as metas de usabilidade (eficácia, eficiência, segurança, utilidade etc.)


Coleta de dados para identifica o de requisitos

Coleta de dados para identificação de requisitos

  • Reunir informações suficientes, relevantes e apropriadas, de forma que um conjunto de requisitos estável possa ser produzido.

    • Questionários

    • Entrevistas

    • Focus Group

    • Observação

    • Análise da Tarefa

    • Análise de competidores

    • Cenários

    • Outros

  • Especificação dos requisitos após análise das coletas de dados.


  • Question rio

    Questionário

    • Questões projetadas a fim de obter informações específicas.

    • Diferentes tipos de respostas: sim/não, múltipla escolha, respostas textuais.

    • Impressos, via e-mail ou em um website ou sistema on-line.

    • A eficiência do método depende do planejamento do questionário.


    Question rio1

    Questionário

    • Atenção: o que as pessoas dizem nem sempre são o que fazem.

    • Questões básicas: Informações demográficas (gênero, idade, formação), experiência do usuário. Descobrir a diversidade dentro de um grupo.

    • Após as questões genéricas, são colocadas as questões específicas, que contribuirão para o estabelecimento dos requisitos.


    Question rio dicas

    Questionário - Dicas

    • Perguntas claras e específicas

    • Sempre que possível, faça perguntas fechadas com várias possibilidades de respostas.

    • Incluir a opção “não tenho opinião” para questões que busquem opiniões.

    • Pense na ordem das perguntas. Gerais devem vir antes de específicas.

    • Se usar escalas, veja se a variação é apropriada e que não se sobrepõe.

    • Evite jargões e forneça instruções claras sobre como completar o questionário (Ex.: marcar “X” na opção)

    • Boas mensagens e formatação e impressão adequada facilitam a compreensão das questões.


    Question rio dicas1

    1

    2

    3

    4

    5

    Questionário - Dicas

    Escalas – Medição das respostas. Likert e Diferencial Semântico.

    Likert – Medir opiniões, atitudes e crenças. Usado com faixa de números (1) ou palavras (2).

    Ex.

    • O emprego de cores está excelente ( onde 1 representa concordar totalmente e 5 discordar totalmente):

    • O emprego de cores está excelente:

      Concordo Totalmente Concordo Ok Discordo Discordo Totalmente


    Question rio dicas2

    Questionário - Dicas

    Diferencial Semântico – Exploram atitudes bipolares, usando pares de adjetivos.

    Ex.:

    Para cada par de adjetivos, assinale com um “X” o ponto entre eles que você considere refletir o quanto acredita que os adjetivos descrevam a homepage. Você deve marcar APENAS um “X” nos espaços reservados em cada linha.

    AtraenteFeio

    ClaroConfuso

    Sem corColorido

    InteressanteSem graça

    MaçanteAgradável

    ÚtilInútil

    PobreBem Projetado.


    Question rios on line

    Questionários On-line

    • Alto alcance, baixo custo e rapidez.

    • Facilidade na análise dos dados.

    • Facilidade nos ajustes.

    • Produzir uma versão eletrônica livre de erros a partir da versão impressa. Se um campo de resposta é marcado, os demais podem ficar indisponíveis.

    • Testar o questionário em vários navegadores e monitores com resoluções diferentes. Evitar necessidade de downloads para preenchimento.

    • Precauções para confidencialidade dos pesquisados.

    • Testar com usuários antes de distribuir os questionários.


    Question rios on line1

    Questionários On-line


    Entrevistas

    Entrevistas

    • Obter informações e opiniões importantes dos atuais e futuros usuários.

    • Tipos:

      • Não-estruturadas;

      • Estruturadas;

      • Semi-estruturadas;

      • Em grupo (focus group).

    • A abordagem mais apropriadas depende dos objetivos a serem estabelecidos.


    Planejando a entrevista

    Planejando a entrevista

    • Faça perguntas sucintas e diretas. Perguntas longas são difíceis de lembrar;

    • Evite sentenças compostas dividindo-as em duas ou mais perguntas separadas;

    • Evite utilizar jargões ou linguagens que o entrevistado possa desconhecer, mas acabar não admitindo por vergonha;

    • Busque a neutralidade nas perguntas;

    • Solicite que colegas revisem as perguntas;

    • O entrevistado está prestando um favor, portanto, tente tornar a atividade mais agradável possível e fazer com que ele sinta-se confortável.


    Realizando a entrevista

    Realizando a entrevista

    • Os passos seguintes ajudarão a realizar uma boa entrevista:

      • Sessão de Introdução – Apresentação e explicações dos motivos da entrevista. Questões éticas podem ser envolvidas e, se for o caso, pedir autorização para gravar a entrevista.

      • Sessão de Aquecimento – Perguntas fáceis e que não “intimidam” devem ser realizadas primeiramente.

      • Sessão de Principal – Apresentar as questões em uma seqüência lógica, procurando deixar as mais difíceis para o final.

      • Sessão de descanso – Algumas poucas questões fáceis, para dissipar eventuais tensões.

      • Sessão de encerramento – Agradecimentos ao entrevistado e procedimentos finais.

    • Seja profissional e trate a entrevista com responsabilidade e seriedade.


    Tipos de entrevistas

    Tipos de entrevistas

    Entrevistas não-estruturadas

    • Focam um tópico em particular e com freqüência, aprofundando-o;

    • Perguntas abertas, com formato de perguntas e respostas não predeterminados;

    • O entrevistado é livre para responder da maneira que desejar;

    • Pode haver um direcionamento da entrevista;

    • Deve-se certificar que respostas a questões relevantes estão sendo obtidas;

    • Organizar um plano com os principais pontos a serem abordados;

    • Embora possam surgir dados significativos, a análise pode consumir um tempo maior e ser mais difícil.


    Tipos de entrevistas1

    Tipos de entrevistas

    Entrevistas estruturadas

    • Perguntas pré-determinadas como um questionário;

    • Úteis quando as metas do estudo são claramente entendidas;

    • Perguntas específicas, curtas e claramente escritas;

    • Respostas podem ser selecionadas a partir de um conjunto de opções lidas ou apresentadas;

    • Questões revisadas por outro colega do grupo;

    • Normalmente as questões são fechadas e o estudo padronizado para os diversos participantes.


    Tipos de entrevistas2

    Tipos de entrevistas

    Entrevistas semi-estruturadas

    • Combinam características das anteriores;

    • Consistência mantida por um roteiro básico;

    • Os mesmos tópicos serão abordados por diferentes entrevistados;

    • Deve-se iniciar por questões planejadas.


    Tipos de entrevistas3

    Tipos de entrevistas

    Focus Group

    • Grupo de 03 a 10 pessoas, como amostra representativas de usuários típicos, compartilhando algumas características (Ex. Grupos separados para estudantes, professores e técnicos);

    • Agenda pré-determinada e facilitador/mediador para encorajar as discussões e controlar os falantes;

    • Levantamento de questões importantes que passariam despercebidas;

    • Método eficiente, de baixo custo e resultados rápidos;

    • Pode ser difícil reunir as pessoas em hora e local apropriado;

    • Registros devem ser feitos em papel, áudio ou vídeo;

    • O objetivo não deve ser o consenso em torno de idéias e sim obter uma gama de opiniões sobre o assunto a ser tratado.


    Observa o do usu rio

    Observação do Usuário

    • Envolve ver, ouvir e registrar tarefas significativas do usuário;

    • Útil para dados quantitativos (tempo de execução) e qualitativos (estratégias e práticas) dos usuários em relação às tarefas;

    • Não deve fazer que o usuário alterem seu comportamento na frente do observador;

    • Observar diversas situações (normalidade, críticas, aprendizado etc.);

    • Escolha do método de registro e testar antes;

    • Reforçar a mensagem de que se trata de conhecer uma situação ou procedimento e não de avaliar o desempenho na atividade;

    • Fotos do local ajudarão a análise do trabalho;

    • O relatório deve ser elaborado assim que a observação terminar.


    An lise da tarefa

    Análise da Tarefa

    • Envolve ver, ouvir e registrar tarefas significativas do usuário;

    • Usada para analisar os fundamentos e propósitos do que as pessoas realizam ou estão tentando realizar;

    • Envolve diferentes técnicas como a Análise Hierárquica de Tarefas (AHT);

    • Empregada no projeto, desenvolvimento e testes de sistemas computacionais interativos.

      • Análise de requisitos,

      • Na construção do modelo inicial,

      • Na avaliação na fase de prototipação,

      • No desenvolvimento de documentação de suporte para o uso.


    An lise hier rquica de tarefas

    Análise Hierárquica de Tarefas

    • Dividir uma tarefa em sub-tarefas e estas em “sub sub-tarefas”, agrupadas como podem ser realizadas em uma situação real;

    • O ponto de partida é um objetivo do usuário, a partir do qual as tarefas são subdivididas;


    An lise hier rquica de tarefas1

    Análise Hierárquica de Tarefas

    • Na decomposição da tarefa, o nível mais alto corresponde ao objetivo maior do usuário e os níveis inferiores correspondem aos sub-objetivos que os usuários devem visar de modo a alcançar o objetivo maior;

    • A estrutura terá uma forma de árvore ou tabela hierárquica, com indicação numérica de planos e seqüências ordenadas.

    Fonte: K-MAD-eCybis, 2007


    Hora de treinar

    É hora de treinar....

    1 – Elaborar um questionário para ser aplicado aos possíveis usuários do seu sistema ou dispositivo, com o objetivo de coletar ou estabelecer os requisitos de interface para o seu projeto.

    2 – Fazer o diagrama com a AHT de uma ação importante na utilização do seu protótipo ou sistema.


    M todos de elicita o de requisitos de usabilidade parte 2

    Autarquia Educacional do Vale do São Francisco – AEVSF

    Faculdade de Ciências Aplicadas e Sociais de Petrolina - FACAPE

    Curso de Ciência da Computação

    Métodos de Elicitação de Requisitos de UsabilidadeParte 2

    Profa. Cynara Carvalho

    [email protected]


    Coleta de dados para identifica o de requisitos1

    Coleta de dados para identificação de requisitos

    • Reunir informações suficientes, relevantes e apropriadas, de forma que um conjunto de requisitos estável possa ser produzido.

      • Questionários

      • Entrevistas

      • Focus Group

      • Observação

      • Análise da Tarefa

      • Análise de competidores

      • Cenários

      • Outros


    An lise de competidores

    Análise de Competidores

    • Identificar pontos fortes e fracos de produtos competidores mais conhecidos ou relevantes (Porter, 2001);

    • Posicionamento do novo produto no mercado;

    • Conhecer bem as funcionalidades dos concorrentes;

    • Avaliação em conjunto pode facilitar identificação dos pontos em questão;

    • Tabular os resultados e, preferencialmente, elaborar um quadro resumo das características.


    An lise de competidores1

    Análise de Competidores

    Exemplo: Analisando ambientes virtuais de ensino competidores (Ramos, 2006)

    • Procurar diferenciais, conhecer bem os produtos e propor inovações.


    An lise de competidores2

    Análise de Competidores

    Exemplo: Analisando ambientes virtuais de ensino competidores (Ramos, 2006)


    An lise de competidores3

    Análise de Competidores

    Exemplo: Analisando ambientes virtuais de ensino competidores (Ramos, 2006)


    Cen rios

    Cenários

    • Um cenário representa uma situação fictícia que poderá ser vivenciada por um usuário, quando em determinado momento realiza uma ação e deseja obter um resultado;

    • Ajuda a entender e criar sistemas computacionais que sirvam como artefatos mediadores da atividade humana - como ferramentas educacionais, ferramentas de trabalho e interação entre pessoas (CARROLL, 2000);

    • O uso de cenários no processo de design é focado em usos futuros do sistema pelos usuários.


    Cen rios1

    Cenários

    • De acordo com Carrol (2000), os elementos que caracterizam um cenário são:

      • O ambiente: aborda um estado inicial para o episódio a ser narrado, descrevendo tanto o ambiente fisicamente – dimensões e posições dos objetos, quanto as pessoas que dele fazem parte.

      • Atores ou agentes: são os personagens do episódio descrito. Pode haver vários agentes e cada um pode possuir objetivos, ou seja, mudanças que esperam alcançar nas circunstâncias específicas do ambiente.

      • O roteiro: seqüência de ações e eventos que representa o que os atores fazem durante o episódio, o que lhes acontece e que mudanças ocorrem no ambiente. Ações e eventos podem ser irrelevantes, obstruir, facilitar ou mesmo mudar os objetivos dos atores.

    • Um cenário é, acima de tudo um exercício de imaginação, criatividade e percepção.


    Cen rios2

    Cenários

    • Cenários positivos e negativos (Bødker, 2000) – Ilustram situações e conseqüências positivas ou negativas de uma determinada solução de design proposta. (Ex.Pag 280, livro texto 01)

    • O texto deve descrever os principais das atividades dos usuários: objetivos, motivações, tarefas a serem realizadas e se possível o tempo esperado para realização de cada tarefa. (Ex.Pag 141, livro texto 02).

    • Os requisitos já podem estar assinalados dentro do texto.


    Outras t cnicas

    Localizar livros

    Efetuar o registo do empréstimo

    Bibilotecário

    Usuário da Bibiloteca

    Outras técnicas

    • Personas – Semelhante aos cenários, sendo que o foco não está em uma tarefa em particular e sim na pessoa que faça parte do público-alvo do sistema.

      • Ao invés de caracterizar o ambiente, descreve-se o perfil da pessoa envolvida com o produto. (Ex. Fulano de tal é solteiro, tem 28 anos, mora em..., trabalha com...., gosta de.... etc)

    • Casos de uso – Também assemelham-se a cenários. Enfocam mais a interação do usuário com o sistema que na própria tarefa do usuário. Podem ser descritos graficamente, na forma de diagramas.


    Organizando os requisitos

    Organizando os requisitos

    • Em cada técnica/metodologia empregada, serão extraídos vários requisitos, que devem ser listados em uma seqüência lógica;

    • Os mesmos requisitos podem aparecer em mais de uma lista, pois são identificados pelas diferentes técnicas. Isso é um forte indicativo para que eles sejam efetivados;

    • A equipe do projeto deve escolher e priorizar os requisitos de interface a serem implementados no sistema ou produto.

    • Questionários

      • REQ 1 – Descrever...

      • REQ 2 - Descrever...

    • Entrevistas

      • REQ 1 – Descrever...

      • REQ 2 - Descrever...

    • Cenários

      • REQ 1 – Descrever...

      • REQ 2 - Descrever...

    • Competidores

      • REQ 1 – Descrever...

      • REQ 2 - Descrever...


    Hora de treinar1

    É hora de treinar....

    1 – Elaborar um cenário descrevendo uma ação de uso do seu produto/sistema, com o objetivo de coletar ou estabelecer os requisitos de interface para o seu projeto.

    2 – Realizar uma análise de competidores do seu produto/sistema, identificando pontos fortes e fracos (quanto a questões de interfaces) desses concorrentes.


  • Login