M todos de elicita o de requisitos de usabilidade parte 1
Download
1 / 40

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


  • 80 Views
  • Uploaded on

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]

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Métodos de Elicitação de Requisitos de Usabilidade Parte 1' - imani-downs


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.



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.

    Atraente Feio

    Claro Confuso

    Sem cor Colorido

    Interessante Sem graça

    Maçante Agradável

    Útil Inútil

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



    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.


    ad