INTERAÇÃO HUMANO-

COMPUTADOR
UNIDADE II - Processos da Engenharia de Requisitos.
Tema: Técnicas para modelagem de usuário: coleta de dados e geração de personas.
AGENDA

Técnicas para modelagem de usuário: coleta de dados e geração de personas.

▪ Coleta de Dados
▪ Análise de dados
▪ Descrição de papéis de usuário e Geração de personas
COLETA DE DADOS
COLETA DE DADOS

A coleta constitui uma parte importante da atividade de identificação de

requisitos e também da avaliação.
O propósito da Coleta de Dados é reunir informações suficientes, relevantes e
apropriadas, de forma que um conjunto de requisitos estáveis possa ser
produzido.
TÉCNICAS PARA COLETA DE DADOS

▪ Entrevistas individuais
▪ Entrevistas em grupo (grupo focal)
▪ Questionários
▪ Casos de Uso
▪ Jogo de Funções
▪ Brainstorming
▪ Workshop de Requisitos
▪ Observação Natural
▪ Netnografia
TÉCNICAS PARA COLETA DE DADOS

▪ Entrevistas individuais
▪ 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
TÉCNICAS PARA COLETA DE DADOS
▪ Entrevistas
▪ Quem são o cliente e o usuário?
▪ Possuem necessidades diferentes?
▪ Quais são suas
▪ Capacidades
▪ Backgrounds
▪ Ambientes, etc.
▪ Qual é o problema?
▪ Como é resolvido atualmente?
▪ Qual a razão para resolvê-lo?
▪ Qual o valor de uma solução bem-sucedida?
▪ Onde mais uma solução pode ser encontrada?
TÉCNICAS PARA COLETA DE DADOS

▪ Entrevistas em grupos (grupo focal)

▪ é uma entrevista em que um grupo diverso e
representativo dos usuários são convidados a dar suas
opiniões sobre um assunto ou produto.
TÉCNICAS PARA COLETA DE DADOS

▪ Questionários
▪ Aplicabilidade a mercados específicos
▪ Onde perguntas são bem definidas
▪ Hipóteses
▪ Perguntas relevantes podem ser decididas antecipadamente
▪ Leitor ouve da maneira desejada
▪ Suprime o que é bom sobre análise
▪ Úteis após uma entrevista inicial
TÉCNICAS PARA COLETA DE DADOS

▪ Caso de uso
▪ Discuta com o cliente o que o sistema fará
▪ Identifique quem interage com o sistema
▪ Identifique que interfaces o sistema terá
▪ Verifique se não há requisitos faltando
▪ Verifique que os desenvolvedores entendem os requisitos
▪ Vantagem é ter apelo visual dos requisitos mais relevantes do
cliente
TÉCNICAS PARA COLETA DE DADOS

▪ Jogo de Funções
▪ Engenheiro de requisitos
▪ Assume a função do usuário ou cliente
▪ Entender o domínio do problema
▪ Cliente
▪ Assume a função do usuário
▪ Entender os problemas que podem passar
TÉCNICAS PARA COLETA DE DADOS

▪ Brainstorming
▪ Estabeleça o objetivo da sessão
▪ Gere quantas ideias for possível
▪ Deixe sua imaginação livre
▪ Não admita críticas ou debates
▪ Ajuste e combine as ideias
TÉCNICAS PARA COLETA DE DADOS

▪ Workshop de Requisitos
▪ Põe todos os stakeholders juntos por um período intensivo
(focado)
▪ Facilitador conduz a reunião
▪ Todos têm sua vez de falar
▪ Resultados são disponíveis imediatamente
▪ Provê um ambiente para aplicar outras técnicas de
elicitação
TÉCNICAS PARA COLETA DE DADOS

▪ Observação Natural
▪ A observação fornece uma visão rica, implicando passar algum
tempo com os stakeholders enquanto realizam suas tarefas
diárias.
▪ Observar o trabalho como ele realmente ocorre, em seu
ambiente natural.
▪ Tomar notas, fazer perguntas e observar o contexto natural das
atividades
TÉCNICAS PARA COLETA DE DADOS

▪ Netnografia
▪ Com o advento da internet e das diversas possibilidades de
criação de comunidades virtuais, seja em fóruns ou em redes
sociais, o projetista pode fazer uma observação imersiva em tais
ambientes e assim aprender sobre diferentes aspectos dos
públicos-alvo pesquisados, suas características predominantes,
seus hábitos de consumo, de linguagem, temas de interesse, etc.
 COLETA DE DADOS

Diretrizes:
● Concentrar-se na identificação das necessidades dos stakeholders.
● Envolver todos os grupos de stakeholders.
● Envolver somente uma pessoa do grupo de stakeholders não é suficiente, especialmente se
existe um grupo grande.
● Utilizar uma combinação de técnicas de dados.
● Oferecer apoio adequado às sessões de coleta de dados, como descrições das tarefas,
protótipos, se disponíveis.
● Executar uma sessão–piloto, se possível, a fim de assegurar que a sua sessão de coleta de dados
provavelmente ocorrerá conforme planejado.
● Ter conhecimento sobre o que deseja para caso necessário, abrir mão das situações ideias.
● Registrar os dados durante as técnicas de coleta de requisitos.
 INTERPRETAÇÃO DE DADOS E ANÁLISE

O objetivo da interpretação é começar a estruturar e registrar as descrições

dos requisitos. Utilizar templates que podem ressaltar os tipos de
informações que devem ser possíveis buscas e que guiam a interpretação e
a análise dos dados. Ter a possibilidade de rastrear os dados e quais outros
documentos são originados.
INTERPRETAÇÃO DE DADOS E ANÁLISE
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Uma análise dos dados mais focada irá seguir uma interpretação inicial.
Técnicas diferentes e notações existem para investigação de aspectos
diferentes do sistema, os quais, por sua vez, farão surgir os requisitos
diferentes.
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Requisitos são analisados utilizando-se de:

○ Diagramas de fluxo de dados
○ Diagramas de estado
○ Diagrama de workflow
○ Diagrama de sequência
○ Diagramas de entidade-relacionamento
○ Diagramas de classe
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de fluxo de
dados

Ex. Carregamento do
Título e apoio ao
cliente
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de estado

Ex. Despertador
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de estado

Ex. Pesquisa
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de sequência

Ex. Criação de conta

bancária
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de entidade-
relacionamento

Ex. Jogo hóquei

 INTERPRETAÇÃO DE DADOS E ANÁLISE

Diagramas de classes

Ex. Consulta
 INTERPRETAÇÃO DE DADOS E ANÁLISE

Essa atividade de identificação de requisitos itera várias vezes antes que

um conjunto de requisitos estáveis evolua.
Quanto mais técnicas de análise e interpretação forem aplicadas, um
entendimento mais profundo acerca de requisitos irá surgir e as descrições
deles irão expandir-se e tornar-se mais claras.
 DESCRIÇÃO DE TAREFAS

Existem diferentes tipos de descrições de tarefas:

● cenários
● caso de uso
● caso de uso essenciais
 DESCRIÇÃO DE TAREFAS - CENÁRIOS

Um cenário consiste em uma "descrição narrativa informal". Descreve as atividades ou tarefas

humanas em uma história que permite a exploração e discussão de contextos, necessidades e
requisitos.
● Não descreve explicitamente o uso de software ou de outro suporte tecnológico para realizar
uma tarefa.
● Utiliza o vocabulário e as expressões dos usuários para melhor entendimento dos stakeholders.
● Construção de cenários por stakeholders é o primeiro passo no estabelecimento de requisitos.
● Nível de detalhe de um cenário pode variar e não tem parâmetro para o que pode ou não ser
inserido.
 CENÁRIOS - EXEMPLO

● Cenário para um Sistema de agenda compartilhada

"O usuário digita o nome de todos os participantes da reunião, juntamente com algumas
restrições, tais como a duração da reunião, quando (vagamente) ela irá acontecer e
possivelmente onde deverá ser realizada. O sistema procede então a uma checagem, de acordo
com os horários pessoais de cada um e com os do departamento central, e apresenta ao usuário
uma série de datas em que todos estão livres. Então a reunião poderá ser marcada nas agendas
pessoais. O sistema poderia enviar uma mensagem automática e perguntar se a data poderia
ser confirmada antes de ser marcada definitivamente."
 DESCRIÇÃO DE TAREFAS - CASO DE USO

Os casos de uso enfocam os objetivos do usuário, mas a ênfase se dá mais na interação

entre usuário e sistema do que na própria tarefa do usuário.
● Foco específico na interação entre o usuário e o software
● O termo cenário também é utilizado no contexto do caso de uso representando um
caminho a seguir no caso de uso.
● Um caso de uso é associado a um ator, e é o objetivo do ator ao utilizar o sistema que
o caso de uso quer capturar.
● Sequências possíveis chamadas de cenários alternativos ou cursos alternativos, devem
ser identificadas
 CASO DE USO - EXEMPLO

● Fluxos para um Sistema de agenda compartilhada

Fluxo Principal Fluxos Alternativos
1. O usuário escolhe a opção de organizar uma reunião Fluxo alternativo 1
2. O sistema solicita ao usuário os nomes dos participantes 5. Se a lista da pessoa é inválida
3. O usuário digita uma lista de nomes 5.1. O sistema apresenta uma mensagem de
4. O sistema verifica se a lista é válida erro
5. O sistema solicita as restrições do usuário 5.2. O sistema retorna para o passo 2
6. O usuário digita suas restrições
7. O sistema busca nas agendas uma data que satisfaça às restrições Fluxo alternativo 2
8. O sistema exibe uma lista de datas possíveis 8. Se não forem encontradas datas possíveis
9. O usuário escolhe uma data 8.1. O sistema exibe uma mensagem
10. O sistema marca a reunião na agenda adequada
11. O sistema envia um e-mail para todos os participantes da reunião 8.2. O sistema retorna para o passo 5
 DIAGRAMA DE CASO DE USO

Diagramas de caso de
uso

Ex. Sistema de adoção

de pets
DESCRIÇÃO DE PAPÉIS DE USUÁRIO
E GERAÇÃO DE PERSONAS
DESCRIÇÃO PAPÉIS DE USUÁRIOS

▪ Os papéis de usuários são as relações que cada tipo de usuário

mantém em relação ao sistema, podendo ser o atual ou o
futuro.
▪ Nome ou identificação do papel;
▪ Atividades que realizam;
▪ Objetivos junto ao sistema;
▪ Contexto de uso;
▪ Exigências e requerimentos para usar o sistema.
 DESCRIÇÃO PAPÉIS DE USUÁRIOS

▪ Exemplos
de perfis
PERSONAS

▪ Descrições detalhadas de usuários típicos do sistema a ser projetado

para os quais os projetistas guiarão o processo de design.
▪ Deve capturas as características dos usuários
▪ Não são pessoas reais, mas uma síntese de características de
usuários reais
▪ Não deve ser idealizado
▪ “Trazê-los à vida”, dando nome, características, objetivos e
background
▪ Deve-se desenvolver múltiplas personas
 PERSONAS

▪ Personagens fictícios (mas com base em conhecimento sobre usuários reais)

▪ nome, foto
▪ descrição
▪ arquétipos de usuários
▪ representam as necessidades de grandes grupos de usuários
▪ objetivos
▪ características pessoais
▪ motivações
▪ expectativas
▪ que motivam seu comportamento na aplicação permitem que os designers se coloquem no lugar
de seus usuários
▪ focam o esforço de design em apoiar os objetivos dos usuários, em vez de ideias da equipe de
design ou dos executivos
PERSONAS

▪ Objetivo
▪ projetar para um conjunto reduzido de personas e agradar todos os
usuários com objetivos semelhantes
▪ Como obter dados para projetar personas?
▪ entrevistando usuários reais e stakeholders que interajam os
usuários
▪ elaborando questionários
▪ realizando pesquisa de mercado
▪ prestando atenção no que “não está sendo dito”
 PERSONAS
▪ objetivos e necessidades dos
usuários se tornam um ponto
comum de foco para a equipe
▪ a equipe pode se concentrar no
design para algumas personas,
sabendo que elas representam as
necessidades de muitos usuários
▪ são relativamente rápidas de
desenvolver e substituem (até um
certo ponto) a necessidade de
delinear toda a comunidade de
usuários e gastar meses
coletando requisitos de usuários
▪ esforços de design podem ser
priorizados com base nas personas
▪ discordâncias sobre decisões de
design podem ser resolvidas se
referindo às personas
▪ alternativas de design podem ser
avaliadas constantemente face às
personas, reduzindo a frequência
de testes de usabilidade mais
caros
 PERSONAS

▪ Exemplo
 PERSONAS

▪ Exemplo
BIBLIOGRAFIA

Barbosa, S., & Silva, B. (2010). Interação humano-computador. Elsevier Brasil.

PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen. Design de interação : além da int
eração homem-computador. Tradução Viviane Possamai. Porto Alegre: Bookman, 20
05.
https://web.tecgraf.puc-rio.br/~abraposo/inf1403/INF1403_03_EngCog.pdf
https://www.inf.ufpr.br/laura/IHC-2016-2/Material%20anterior/IHC-Engenharia-Cogni
tiva-26-09-16.pdf
https://www.passeidireto.com/arquivo/44515791/ihc-aula-08-eng-cognitiva
http://projetos.fatecjales.edu.br/guilhermearaujo/docs/ihc.pdf
https://pt.slideshare.net/andreconstantino/aula-4-fatores-humanos-parte-1-disciplin
a-de-ihc