Você está na página 1de 138

Interfaces Homem-Máquina

Universidade Federal do Tocantins


Curso: Ciência da Computação
Disciplina: Interfaces Homem-Máquina
Professor: Eduardo Ferreira Ribeiro
Projetos de DESIGN
O que é design?
Projeto (ou design) é “plano ou
concepção intelectual que será executada
posteriormente”
 Nosso foco: design de IHC
◦ design de “produtos interativos que forneçam
suporte às atividades cotidianas das pessoas,
seja no lar ou no trabalho”.
Design Centrado no Usuário:
Mudança de Paradigma
Por que envolver usuários no design
de interação?
 Gerenciamento de expectativas
◦ expectativas realistas
◦ No surprises, no disappointments
◦ Treinamento antecipado
◦ Comunicação, e não “marketing”
 Sentimento de “propriedade”
◦ Usuários como participantes ativos
◦ Mais propícios a perdoar ou entender problemas
◦ Pode fazer a diferença no sucesso e aceitação do
produto
Abordagem centrada no usuário
(DCU) Design Centrado no Usuário

 Baseada em:
◦ Focar desde cedo nos usuários e tarefas:
estudar diretamente características cognitivas,
comportamentais, antropomórficas, etc
◦ Medição empírica: reações e performance dos
usuários em relação aos cenários, manuais,
simulações e protótipos são observadas,
gravadas e analisadas
◦ Design iterativo: ao encontrar problemas
com os testes com usuários, corrigi-los e
fazer mais testes
Design Centrado no Usuário

O usuário pode ser enquadrado em diversas dimensões,


tais como:

1) O usuário como sujeito em testes de usabilidade e


prototipagem, onde o foco é saber a performance do
sujeito com relação a um sistema particular ou a uma
característica deste sistema;
2) O usuário com alguém que tem preferências,
particularmente com produtos comerciais;
3) O usuário como experiente em assuntos específicos,
como provedor de informações.
4 atividades básicas do Design de
Interação
 1. Identificar necessidades e estabelecer
requisitos
 2. Desenvolver designs alternativos
 3. Construir versões interativas dos
designs
 4. Avaliar designs
Design Centrado no Usuário - ISO 13407

Identificar a
necessidade do projeto
centrado no usuário

Analisar e especificar
o contexto de uso

O sistema satisfaz Especificar as


Avaliar o projeto
as exigências dos exigências dos
contra as exigências
usuários usuários

Produzir soluções
de projeto
Design Centrado no Usuário - ISO 13407

Pesquisa

“Ideação”

Desenvolvimento Avaliação Design

Prototipação
Fase 1 – Pesquisa E Ideação
 Coleta de pré-requisitos
 Identificar a necessidade do projeto
centrado no usuário
 Analisar e especificar o contexto de uso
Questões do DCU
 Quem são os usuários?
◦ Obviamente, quem usa o sistema.
◦ Mas também, quem tem relação direta com quem usa
(por exemplo: superiores ou subordinados, clientes,
etc.)
 Quais são as “necessidades”?
◦ Todo o apoio computacional que um sistema pode
oferecer para as atividades do usuário.
◦ relacionado com as atividades atuais do usuário; ou
◦ relacionado com as novas oportunidades que o
sistema pode criar.
 De onde vem as alternativas?
 Como escolher dentre as alternativas?
Quem são os usuários ?
 Não é tão óbvio quanto você imagina:
◦ quem interage diretamente com o produto
◦ quem gerencia o usuário direto
◦ quem recebe output do produto
◦ quem toma a decisão de comprar o produto
◦ quem usa produto concorrente
Sistema de caixa de supermecado:
usuários
O que são “necessidades dos
usuários” ?
 Identificar as necessidades dos usuários
significa conhecer o máximo possível
sobre eles, seu trabalho e o contexto
desse trabalho para definirmos a forma
como o sistema em desenvolvimento
pode fornecer-lhes suporte na realização
dos seus objetivos.
◦ (Preece et al., 2005)
Quais são as “necessidades”?
 Usuários raramente sabem o que é possível
 Usuários não sabem dizer o que precisam
 Ao invés disso, observe as tarefas
existentes:
◦ contexto
◦ que informações elas precisam?
◦ quem colabora na execução da tarefa?
◦ porque a tarefa é feita dessa maneira?
 Tarefas “adicionais”:
◦ Podem ser incluídas no novo cenário
◦ Podem ser descritas para futuros cenários
O que são “requisitos dos usuários” ?
 “Um requisito consiste em uma
declaração sobre um produto pretendido
que especifica o que ele deveria fazer ou
como deveria operar” (Preece et al., 2005
p.224)
 Não precisa ser muito rígido, mas é
preciso estar certo de que os requisitos
não irão se alterar radicalmente durante
o processo de design.
Como estabelecer requisitos?
 De forma bem geral temos que:
◦ Coletar dados sobre os usuários, seus objetivos,
seu trabalho, o contexto de uso, suas capacidades
cognitivas, seu conhecimento prévio sobre o
domínio, sistema similares, tecnologia, e etc.;
◦ Interpretá-los, isto é, decidir quais são
importantes para o sistema sendo desenvolvidos
e de que forma; e
◦ Extrair os requisitos, ou seja, construir sentenças
sobre o que o sistema deve fazer e como.
Estabelecer requisitos
 Concentrar-se na identificação das necessidades
dos usuários envolvidos
 Considerar TODO o grupo de usuários
envolvidos: certificar-se de que dispõe de todos os
pontos de vista das pessoas certas
 Envolver mais de um representante de cada
grupo
 Combinar técnicas de coletas de dados 
perspectivas diferentes
 Oferecer apoio adequado a sessões de coletas
◦ Descrições das tarefas, descrições dos protótipos
 Sessão piloto
 Registrar os dados
Identificando Necessidades e
Estabelecendo Requisitos
O que, como e por que?
•Por que: Definição de requisitos é o estágio onde as falhas ocorrem mais
comumente

 Obter os requisitos corretamente é crucial


Design Centrado no Usuário - ISO 13407

Identificar a
necessidade do projeto
centrado no usuário

Analisar e especificar
o contexto de uso

O sistema satisfaz Especificar as


Avaliar o projeto
as exigências dos exigências dos
contra as exigências
usuários usuários

Produzir soluções
de projeto
O que são “necessidades dos
usuários”?
 Identificar as necessidades
dos usuários significa
conhecer o máximo
possível sobre eles, seu
trabalho e o contexto
desse trabalho para
definirmos a forma como o
sistema em
desenvolvimento pode
fornecer-lhes suporte na
realização dos seus
objetivos. (Preece et al.,
2005)
O que são “requisitos
dos usuários”?
 “Um requisito consiste em uma
declaração sobre um produto
pretendido que especifica o que ele
deveria fazer ou como deveria
operar” (Preece et al., 2005 p.224)
◦ Não precisa ser muito rígido, mas é
preciso estar certo de que os
requisitos não irão se alterar
radicalmente durante o processo de
design.
O que são “requisitos dos
usuários”?
Como estabelecer requisitos?
 De forma bem geral
temos que:
◦ Coletar dados sobre os
usuários, seus objetivos, seu
trabalho, o contexto de uso,
suas capacidades cognitivas,
seu conhecimento prévio
sobre o domínio, sistema
similares, tecnologia, e etc.;
◦ Interpretá-los, isto é,
decidir quais são importantes
para o sistema sendo
desenvolvidos e de que forma;
e
◦ Extrair os requisitos, ou seja, construir sentenças
sobre o que o sistema deve fazer e como.
Diferentes Tipos de Requisitos
 Funcionais:
◦ O que o sistema deve fazer
 (Não-funcionais: tamanho
de memória, tempo de
resposta...)
 Dados:
◦ Que tipos de dados
costumam ser armazenados?
◦ Como serão armazenados
(e.g. banco de dados)?
Diferentes Tipos de Requisitos
 Ambiente / contexto de uso:
◦ físico: barulho? Iluminação? Vibração? calor?
◦ social: compartilhamento de arquivos ou de
displays, privacidade, etc.
◦ organizacional: hierarquia, suporte a usuário,
treinamento, infraestrutura de comunicação.
Técnica de Coleta de Dados
 Questionários – questões específicas
◦ ampla distribuição (>= 50)
◦ respostas livres, múltipla escolha ou checkboxes
◦ informações quantitativas e qualitativas (principalmente
quantificáveis)
 Entrevistas – explorar questões
◦ número reduzido: importância da seleção dos
entrevistados
◦ entrevistas estruturadas, livres ou semi-estruturadas
◦ informações qualitativas
Técnica de Coleta de Dados
(cont.)
 Grupos de foco
◦ 3 a 5 sessões (com 6 a 12 pessoas
cada)
◦ vários pontos de vista
◦ áreas de consenso e conflito
◦ informações qualitativas
 Observação natural
 Estudo de documentação
Questionários
 O que perguntar?
◦ informações demográficas: idade, sexo, profissão, instrução, habilidade e
experiência prévia
◦ com computadores e aplicações, tipo de computador utilizado,
nacionalidade
◦ necessidades e preferências sobre a prática atual (forma de realizar as
tarefas)
◦ problemas ou dificuldades encontradas na prática atual ou em outras
aplicações
 Quando utilizar?
◦ no início do projeto; assim que a aplicação é implantada; após um
período de uso
 Como fazer?
◦ questionário curto, com respostas rápidas, e de fácil análise
◦ motivar respostas precisas e completas
◦ incentivar o fornecimento de novas informações que não puderam ser
previstas
◦ verificar a utilidade das respostas
Cuidados na construção de
questionários
 questionário deve conter uma introdução, incluindo:
◦ objetivos do questionário
◦ como as respostas serão utilizadas
◦ garantia do anonimato
◦ instruções sobre
 como preencher o questionário e
 para quem devolvê-lo
◦ vocabulário simples e claro
 evitar termos desconhecidos dos usuários (e.g. voltados para a
tecnologia)
◦ ambigüidades, interferências ou desvios devem ser evitados
 “Quantas vezes por semana você faz compras pela Internet?”
◦ perguntas “negativas” bem marcadas
 Com qual destas opções você MENOS se identifica?
◦ perguntas semi-abertas
 opção “Outros: ____________”
Estabelecer Requisitos
 Concentrar-se na identificação das necessidades dos
usuários envolvidos
 Considerar TODO o grupo de usuários envolvidos:
certificar-se de que dispõe de todos os pontos de
vista das pessoas certas
 Envolver mais de um representante de cada grupo
 Combinar técnicas de coletas de dados ->
perspectivas diferentes
 Oferecer apoio adequado a sessões de coletas
◦ Descrições das tarefas, descrições dos protótipos
 Sessão piloto
 Registrar os dados
Caracterizações de Perfil de
Usuários
Caracterizações do Ambiente de
Trabalho
 Ambiente físico
◦ espaço físico
◦ uso de equipamento
◦ nível de ruído
 Ambiente social
◦ pressão
◦ distribuição geográfica
 •Ambiente cultural
◦ diversidade de nacionalidade
◦ hábitos estabelecidos
Personas
Personas
 Descrições detalhadas 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 idéias da equipe de design ou dos
executivos
Personas (cont.)
 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 com os usuários
◦ elaborando questionários
◦ realizando pesquisa de mercado
◦ prestando atenção no que “não está sendo dito”

 * “indivíduos ou organizações que serão afetados pelo sistema e


que têm influência direta ou indireta nas necessidades deste
sistema”
Estudo de caso – Por onde
começamos
Definição das variáveis (que distinguem os
usuários)

Objetivo de uso do produto:


O que as pessoas querem fazer

Atitudes:
Como eles percebem a própria experiência

Comportamento:
como eles fazem isso.

Motivações e frustrações
O que gostam/detestam, etc.
Criando Personas
 A “criação” deve estar
baseada nas informações
coletadas por meio de
entrevistas e questionários
junto à população-alvo do
sistema. (Cybis et. al 2010)
Criando Personas
Para definir uma persona, Courage e Baxter
(2005) enumeram os seguintes elementos
característicos:
 Identidade - Nome e sobrenome e dados
demográficos representativos o perfil e incluir
uma foto.
 Status – Primário, secundário, stakeholder ou
antiusuário
 Objetivos – Quais os objetivos desta persona?
 Habilidades – Qual é sua especialidade?
Educação, treinamento e competências
específicas.
Criando Personas
Para definir uma persona, Courage e Baxter (2005)
enumeram os seguintes elementos característicos:
 Tarefas – Quais tarefas básicas e críticas a persona
realiza? Qual é a frequência, importância e duração
das tarefas?
 Relacionamentos – Entender quem a persona se
relaciona, ajuda a identificar outros stakeholders.
 Requisitos – De que a persona precisa: Inclua
citações que ajudam a dar mais vida a essas
necessidades.
 Expectativas – Como a persona acredita que o
produto funciona? Como ela organiza as informações
no seu domínio ou trabalho?
Ex: Personas p/ Portal da Celtins
Exemplo
Joao
Exemplo
João tem 52 anos de idade e trabalha como mecânico numa empresa que oferece
serviço de manutenção aos clientes quando seus carros enguiçam. Ele trabalha
nisso há 12 anos e conhece bem o seu trabalho. Muitos mecânicos mais jovens
pedem conselhos para o João quando se encontram no depósito, pois ele sempre
sabe as soluções para os problemas mecânicos difíceis. João gosta de
compartilhar seu conhecimento com os mais jovens, pois isso o faz se sentir
parte valorizada da equipe.
João trabalha durante o dia e em alguns turnos noturnos. Por volta de 20% dos seus
serviços são complexos e de vez em quando ele precisa consultar os manuais.
Ele tenta evitar usar os manuais na frente dos clientes, pois ele acha que isso lhes
dá a impressão de não saber o que está fazendo.
João viu várias mudanças na companhia ao longo desses anos e tentou se adaptar a
elas. Entretanto, ele achou um pouco desafiador quando um novo computador
foi instalado na sua caminhonete há alguns anos, e agora ele ouviu boatos de que
o computador vai ser substituído por um com uma tela maior, que deve ser mais
rápido e melhor.
Disseram a João que ele poderá acessar a intranet da empresa no seu novo
computador. Ele ouviu falar na intranet e a viu uma vez numa versão anterior, no
computador do seu gerente. Ele se pergunta se ele conseguirá descobrir o que
está acontecendo na empresa mais facilmente, principalmente porque os
clientes parecem saber mais sobre as notícias da empresa do que ele próprio.
Isso pode ser embaraçoso e freqüentemente tem sido uma fonte de frustrações
para o João durante todo o tempo em que trabalhou na empresa.
João se pergunta se ele conseguirá lidar com o novo sistema computacional. Ele
não se importa em pedir ajuda aos seus netos quando quer enviar uma
mensagem para o seu irmão que mora em outro continente, mas pedir ajuda
para o pessoal no trabalho é uma outra história.
Quais os objetivos de João ao
acessar a intranet?
 evitar parecer ignorante ou
burro
◦ perante aos clientes
◦ perante aos colegas
 manter o seu status de
mentor, experiente
◦ compartilhar conhecimento com
seus colegas mais jovens
 usar a intranet para saber
mais sobre as notícias da
empresa do que seus clientes
 aprender a utilizar o sistema
sem pedir ajuda aos colegas
de trabalho
Representação alternativa de
persona: Mecânico experiente
Benefícios de se utilizar
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 freqüência de testes de
usabilidade mais caros
Referências sobre o uso de
personas para o design da
interação
 Cooper, A.The Origin of Personas. Disponível online em:
◦ http://www.cooper.com/content/insights/newsletters/2003_08/Origin_o
f_Personas.asp
 Calabria,T. An introduction to personas and how to create
them. Mar/2004. Disponível online em:
◦ http://www.steptwo.com.au/papers/kmc_personas/
 Goodwin, K. Perfecting Your Personas. Jul-Aug/2001
Disponível online em:
◦ http://www.cooper.com/newsletters/2001_07/perfecting_your_persona
s.htm
 Develop Personas. Disponível online em:
◦ http://www.usability.gov/analyze/personas.html
 Personas: Setting the Stage for Building Usable
Information Sites. Jul-Aug/2003. Disponível online em:
◦ http://www.infotoday.com/Online/jul03/head.shtml
Design Centrado na
Comunicação -
Metas e Cenários
Análise de Tarefas – Cenários
• O levantamento de requisitos sobre as tarefas e os
usuários pode ser melhor realizado quando os analistas procuram
descrever situações do processo de trabalho.
• Método de cenários: coleção de narrativas de
situações no domínio do problema que permitem a
identificação de componentes de design.
• usuários envolvidos podem então avaliar, criticar e fazer
sugestões
• podem também ser usados para se formar uma base de casos
que pode ser útil no aprendizado de IHC ou no reuso de designs.
Análise de Tarefas – Cenários
 narrativas textuais, pictóricas ou encenadas, de
situações fictícias mas plausíveis (senão
desejáveis) de uso situado da aplicação.

 devem ser ricos em contextualização e possuir


um foco claro que transmita a usuários e
designers as idéias sendo testadas.

 meio de representação de fácil compreensão para


os usuários envolvidos (mesmo de formação
heterogênea).

 podem ser utilizados em diversos pontos do


processo de design.
Diferentes tipos de Metas
 Meta final
◦ “Eu (usuário no papel <Papel>) quero utilizar o
sistema para atingir <MetaFinal>”
 Meta instrumental planejada
◦ “Eu quero <MetaInstrumental> para <atingir
MetaFinal> <de modo mais eficiente / fácil / ...>”
 Meta instrumental oportunista (já leva
em consideração o design da
interação)
◦ “Daqui onde estou (na interação), eu decido agora
realizar <MetaInstrumental> para <atingir
MetaFinal> <de modo mais eficiente / fácil / ...>”
Questões relacionadas a Metas
 para descobrir as metas
◦ O que você { quer | pode | precisa } fazer com o sistema?
 para cada meta
◦ Utilidade
 Por que você { quer | pode | precisa } fazer isto? Para que serve isto?
◦ papéis
 Quem pode fazer isto? Além de P, quem mais pode fazer isto? Se P não
estiver disponível, quem poderá fazer isto?
◦ pré-condições
 De quem isto depende?
 Que informações ou artefatos são necessários para atingir esta meta?
 O que precisa ser feito antes disto?
◦ resultados
 Qual é o resultado desta meta?
 Quem { pode | deve } ser avisado do atingir desta meta?
 Que informações ou artefatos devem resultar desta meta?
 Quem poderá utilizar essas informações ou artefatos?
Questões relacionadas aos
itens de informações
 para cada item de informação, artefato ou
conceito { criado | manipulado | utilizado |
destruído } ao atingir cada meta
◦ O que é isto?
◦ Para que serve isto? Como você { pode | deve }
utilizar isto?
◦ Quem pode { criar | manipular | utilizar | destruir
} isto?
◦ De onde vem esta informação? Quem a produz?
Quando?
◦ Para onde vai esta informação? Quem a utiliza?
Para quê?
Design Centrado na
Comunicação
Cenário para um Sistema de
Biblioteca

“Um aluno chega na biblioteca e procura as referências dos livros-texto


desejados.”

“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 artigos lhe é
apresentada. Ele então manda imprimir todas as referências encontradas.”
– Pessoas que
interagem com o
computador ou com o
contexto
– A descrição de um
ator no cenário deve
incluir as
características pessoais
que forem relevantes
ao cenário
– Detalhes circunstanciais que
motivam ou explicam
objetivos, ações e reações dos
atores do cenário
– Ação ou reação externa
produzida pelo computador ou
outras caracterísitcas do
ambiente
– Podem estar ocultadas dos
atores, mas serem relevantes
para o cenário
Efeitos na situação que
motivam as ações que
os atores realizam
– Comportamento observável
– Atividade mental voltada para
interpretar caracterísiticas de
uma situação
plano

Atividade mental voltada para converter um


objetivo em comportamento
Casos de Uso – (Cenários +
Personas em diagramas)
Conceitos
 Casos de Usos são identificados:
◦ Através de entrevistas com usuários típicos.
◦ Observação da maneira como o usuário trabalha e
utiliza os sistemas existentes.
◦ Pelo levantamento de todas as características da
interação que eles esperam ter com o sistema.
 Para cada ação discreta que eles pretendem executar, damos
um nome e escrevemos algumas linhas para descrevê-la.
 Numa primeira fase não interessa capturar todos os detalhes,
mas apenas aqueles que se revelam essenciais para
compreender os requisitos dos sistema como um todo.

 As técnicas acima podem e devem ser usadas de forma complementar.


Finalidades e Interações
 É importante distinguir
◦ Objetivos dos usuários, de caráter mais
conceitual.
 Ex.: “garantir formatação consistente para um
documento”; “garantir que a formatação de um
documento pode ser repetida noutro”.
◦ Interações com o sistema, de caráter mais
próximo da implementação.
 Ex.: “definir estilos”, “alterar um estilo”, copiar um
estilo de um documento para outro”.
Finalidades e Interações
 Os casos de uso correspondentes às
interações com o sistema são
melhores para efeito de
planejamento.
 Os correspondentes aos objetivos
dos usuários são úteis para explorar
eventuais alternativas de interações
com o sistema.
◦ Por isso é preferível começar por eles.
Diagramas de Casos de Uso
 Atores e Casos de Uso são os principais
componentes de um Modelo de Casos de
Uso.
Personas e Cenários em Casos de
Usos
 Uma persona é um exemplo de ator em
um caso de uso.

 Um Cenário é um exempo de um caso de


uso.
Diagramas de Casos de Uso
Diagramas de Casos de Uso
 Objetivos do usuário - o que o usuário está
realmente tentando fazer.
◦ Quando o usuário faz um empréstimo, seu objetivo é
pegar um exemplar emprestado - o que pode envolver
outras atividades.
 Interações com o sistema - o que o usuário
terá de fazer nas várias circunstâncias que
eventualmente o levarão a atingir o seu
objetivo.
◦ Por exemplo, para fazer um empréstimo precisamos dos
seguintes casos de uso:
 verificar se o exemplar está disponível (não está emprestado ou
reservado);
 verificar se o usuário não ultrapassou o numero máximo de
empréstimos;
 se o usuário está em débito; etc.
Atores
 • Um ATOR é alguém ou alguma
coisa que deve interagir com o
sistema a ser desenvolvido.
Atores
 Normalmente são pessoas (personas)
desempenhando diferentes papéis em
relação ao sistema.
◦ Ex.: funcionário, cliente, gerente
 Podemos ter várias pessoas diferentes
desempenhando o mesmo papel -
nesse caso representamos um único
ator.
 Uma mesma pessoa pode representar
vários papéis - nesse caso
representamos com vários atores.
 Um ator executa um caso de uso.
Atores
 É importante pensar em termos de atores
(papéis abstratos) em vez de pensar em
termos de pessoas.
 É muito mais fácil pensar em termos de
atores do que pensar em termos de casos de
uso.
 Ao fazer a análise do sistema é uma boa idéia
começar por uma lista dos atores e, a partir
dela, elaborar então uma lista dos casos de
uso.
 Os atores não são necessariamente humanos.
Por exemplo, um sistema externo ao sistema
em análise também pode ser considerado um
ator.
Atores
 Atores são classes não instâncias
 Portanto, um ator não modela uma
pessoa ou empresa particular, mas
sim uma classe ou grupo de pessoas
ou empresas.
◦ Por exemplo:
 Empresa de Entregas, não UPS, DHL, ou FedEx
 Funcionário, não João, Sandra, Pedro ou Ana.
Atores
 Para identificar os atores

◦ Quem usará as funções principais do sistema ?


◦ Quem precisará do sistema para executar suas
tarefas diárias ?
◦ Quem manterá e administrará o sistema ?
◦ Quais os equipamentos que o sistema
controlará ?
◦ Com quais outros sistemas o sistema precisará
interagir?
◦ Quem tem interesse nos resultados que o
sistema produz?
Casos de Uso
 “ Um conjunto de seqüência de
ações executadas por um sistema
que geram resultados para um
determinado ator ”
◦ Casos de Uso são descrições da
funcionalidade do sistema independentes de
sua implementação.
Casos de Uso
 Um Caso de Uso é uma classe e não
uma instância.
 Descreve a funcionalidade como um
todo, incluindo possíveis alternativas,
erros e exceções que podem
ocorrer durante a execução do Caso
de Uso.
 Uma instanciação de um Caso de
Uso é chamada de cenário.
Casos de Uso
 Um Caso de Uso sempre é iniciado
por um ator.
 Um Caso de Uso retorna uma
resposta para um ator.
 Um Caso de Uso é completo, ou seja,
deve ser uma descrição completa. Não
devemos dividir um Caso de Uso em
pequenos Casos de Uso.
 Um Caso de Uso não está completo
até que o valor final seja produzido.
Casos de Uso
 Descrevem as interações típicas entre
os usuários e o sistema
◦ Identifica os diferentes usuários do sistema.
◦ Identifica objetivos para cada classe de usuários.
◦ Nomeia os objetivos.
◦ Descreve a interação necessária para alcançar o
objetivo.
 Oferecem as possíveis situações do
mundo real para o teste do sistema.
 Servem de base para formular a
documentação do usuário.
Casos de Uso
 Nomeando um Caso de Uso

◦ O nome deve ser adequadamente


escolhido de modo que diga que
processamento está ocorrendo.

◦ Uma vez que o nome é normalmente


um verbo e um substantivo, uma breve
descrição precisa ser acrescentada.
Casos de Uso
 Descrevendo um Caso de Uso
◦ Um Caso de Uso deve possuir uma
descrição textual.
◦ Uma especificação simples e
consistente sobre como os atores e
casos de uso interagem.
◦ Deve-se concentrar-se no
comportamento externo do sistema e
ignorar como as coisas são executadas
dentro do sistema.
Casos de Uso
 A descrição textual deve incluir:
◦ Objetivo do Caso de Uso.
◦ Como o Caso de Uso é iniciado.
◦ O fluxo das mensagens entre os atores e o
Caso de Uso.
◦ Fluxo alternativo, no caso de condições e
exceções.
◦ Como o Caso de Uso termina com o valor
que será retornado para o ator.
◦ Deve ser clara, o usuário deverá
compreendêla.
Casos de Uso
Casos de Uso
Casos de Uso - Exemplo
Casos de Uso
 Os casos de uso são muito úteis para
auxiliar na análise de requisitos do
sistema que vamos projetar. Na
maioria dos casos, é a primeira coisa a
fazer ao abordar um projeto.
 Cada caso de uso corresponde a um
requisito potencial.
◦ É importante ter isso em mente porque
um requisito que não se consegue
esclarecer é um requisito que não se pode
considerar no projeto.
Casos de Uso - relacionamentos
 Podem existir três tipos de
relacionamentos:
◦ Estende: um Caso de Uso pode estender
outro Caso de Uso adicionando ações
ao Caso de Uso mais geral.
◦ Usa: um Caso de Uso usa um outro
Caso de Uso (faz parte).
◦ Agrupa: quando um conjunto de Casos
de Uso possui funcionalidade similar,
eles podem ser agrupados em um
pacote.
Casos de Uso - relacionamentos
 Usamos um relacionamento de uso
quando se tem um bloco cujo
comportamento é o mesmo para
vários casos de uso. Nesse caso, tem
sentido isolálo, e fazer com que
esses casos de uso o “chamem”
quando precisarem dele.
Casos de Uso - relacionamentos
 • No exemplo tanto o caso de uso
“Analisar Risco” como o caso de
uso “Negociar Preço” usam o caso
de uso “Avaliar”.
Casos de Uso - relacionamentos
 Usamos um relacionamento de
extensão quando se tem um caso de
uso que é praticamente igual a
outro, mas que faz um pouco mais.
Nesse caso, isola-se esse caso de uso
e diz-se que ele é uma “extensão”
do primeiro.
Casos de Uso - relacionamentos
Casos de Uso - relacionamentos
 Para definir os relacionamentos de
extensão faça o seguinte:
◦ Começe capturando o caso de uso básico.
◦ Para cada fase desse caso de uso, faça a
pergunta: “O que é que poderia ocorrer de
diferente?” ou “Como é que isto poderia
acontecer de outra maneira?”.
◦ Todas as variantes são desenhadas como
extensões do caso de uso básico. Podemos
obter uma grande quantidade delas, mas as
coisas ficam muito mais fáceis de entender.
Casos de Uso - relacionamentos
 Apesar das semelhanças, os
relacionamentos implicam coisas
diferentes nas suas ligações com os atores:
◦ Nas extensões, os atores têm um relacionamento
com o caso de uso que passa a ser estendido.
Partimos do princípio de que um mesmo ator pode
executar tanto o caso de uso como as suas
extensões.
◦ Nos relacionamentos de uso é freqüente não haver
ator associado com o caso de uso partilhado. Mesmo
que haja, não se espera que esse ator execute os
casos de uso ligados ao que está partilhado.
Casos de Uso - relacionamentos
 De um modo geral, podemos
considerar que:
◦ Utilizamos um relacionamento de
extensão quando pretendemos
descrever um comportamento que é
uma variante do comportamento
normal.
◦ Utilizamos um relacionamentos de uso
quando se identifica uma repetição em
dois ou mais casos de uso e se pretende
evitar essa repetição.
Casos de Uso
 Cenários
◦ A descrição de um cenário ilustra um caso
específico, com instâncias dos atores e Casos
de Uso envolvidos.
 Diagrama de atividades
◦ Um Caso de Uso pode ser descrito por um
diagrama de atividades.
◦ Um diagrama de atividades apresenta uma
seqüência das atividades, e condições
opcionais.
Cenários
 Usa-se a expressão cenário para
descrever um único percurso, dos
muitos possíveis na execução de um
dado caso de uso. Um cenário
corresponde a uma das formas
possíveis de executar o caso de uso.
◦ Por exemplo, associados a um dado caso de uso
pode existir:
 um cenário que corresponde à situação em que tudo
corre bem,
 um cenário em que não há produtos em quantidade
suficiente,
 outro cenário em que o crédito é recusado,
 etc.
Cenários
 Como em geral há mais de uma
maneira de executar um caso de
uso, diz-se que um mesmo caso de
uso pode ter várias maneiras de se
realizar.
 É importante identificarmos os
cenários onde um caso de uso pode
falhar.
 As falhas podem ser escritas como
extensões dos casos de uso.
Cenários em Casos de Uso
Cenários em Casos de Uso
Cenários em Casos de Uso
Casos de Uso e Cenários
 Do que preciso para construir
cenários e casos de uso?
◦ Saber quem é o usuário
◦ Saber o que ele faz e como
◦ Ter uma visão de como o sistema pode e
deve apoiá-lo
◦ Ter uma visão do ambiente onde sistema será
usado
Casos de Uso e Cenários
(cont.)
 Para que servem cenários e casos
de uso?
◦ Para REPRESENTAR um conhecimento
adquirido sobre o usuário e suas necessidades
◦ Para REPRESENTAR alternativas de design
 Para ser objeto de AVALIAÇÃO
 pelos designers e desenvolvedores
 pelos usuários
◦ Para gerar NOVAS ALTERNATIVAS de design
◦ Para ampliar/construir uma base de casos de
design de interação
Trabalho
Trabalho– Requisitos:
Especificações
 PROJETO:
◦ Uma locadora de veículos contratou você para
construir um sistema que permitirá aos seus
funcionários e assistentes realizarem tarefas
rotineiras para os seus clientes.
 Sistema atual:
◦ A locadora de veículos tem cerca de 1000
clientes.
◦ Em média, 35 pessoas entram na locadora
diariamente.
◦ Na locadora existem veículos leves, pesados e de
rally.
Trabalho– Requisitos:
Especificações (cont.)
 Sistema atual (cont.):
◦ Já existe um computador que armazena em um
banco de dados todos os carros e cada item é
identificado por um único código (placa).
◦ A locadora tem também dois computadores,
localizados no meio da loja, para os clientes
consultarem todos os carros. Este sistema está
adequado e, portanto não será atualizado.
◦ O sistema usado pelos funcionários está obsoleto
e precisa ser refeito. Este é o objetivo deste
projeto.
Trabalho– Requisitos:
definições (cont.)
 Contexto das tarefas:
◦ Os funcionários executam diversas tarefas como
verificar a limpeza e conformidade dos carros,
auxiliar os clientes na escolha do melhor modelo,
cadastrar novos veículos.
◦ Uma das suas tarefas é o trabalho no balcão de
atendimento, que é o objetivo deste projeto.
◦ Durante os períodos mais movimentados, um
funcionário fica permanentemente no balcão e
chama os demais assim que começa a formar fila.
As filas em geral variam entre 1 e 2 pessoas. Filas
maiores são raras. Cada cliente demora cerca de
20 a 30 minutos para ser atendido.
Trabalho– Requisitos:
definições (cont.)
 Usos previstos para o novo sistema:
◦ O sistema tratará das rotinas de locação, que incluem
atualmente:
◦ Ajudar os funcionários a responderem as dúvidas do
cliente (tanto no balcão como por telefone);
◦ Informar aos clientes a sua situação, ou seja, se possui
cadastro, se possui descontos, se necessita atualização.
◦ Controlar a entrada e saída de veículos;
◦ Receber pagamentos;
◦ Fornecer vouchers e promoçoes para clientes frequentes;
◦ Verificar o vencimento da locação de um carro;
◦ Ligar para pessoas que ainda não devolveram os carros e
para pendencias vistas após a devolução.
Trabalho– Requisitos:
Especificações (cont.)
 Restrições do sistema:
◦ A locadora possui um sistema que contém
todo o seu acervo em um Banco de Dados
bem rápido.
◦ Não se espera trocar o SGBD e o seu sistema
tem que se comunicar com ele.
◦ A locadora tem vários PCs com Windows
localizados no balcão de atendimento e não
espera ter de trocá-los. Portanto seu sistema
terá que funcionar nesta plataforma.
Trabalho– Requisitos: Cenários
 Cenário 1:
◦ Maria, uma experiente funcionária que
trabalha em horário integral na locadora, abre
a loja de manhã. Ela começa o dia verificando
todos os carros que foram devolvidos
durante no dia anterior, cujo número varia
entre 5 e 10 carros. Ela pára sua tarefa assim
que chega algum cliente que solicita seus
serviços. Ela normalmente verifica os carros
devolvidos e os deixa com um funcionário
para levá-los até a garagem.
Trabalho– Requisitos: Cenários
(cont.)
 Cenário 2:
◦ João, um cliente regular da locadora de vídeos, se aproxima de
Maria e pergunta se tem a camionete que ele usa para ir ao
Jalapão levar seus clientes rotineiramente.

◦ Ela consulta, verifica que o modelo está alugado e pergunta se o


que pode ser é o modelo “xxxxxx” da marca “YYY” , e ele diz
que sim. Ela então chama o funcionário para que traga o carro,
verifica com o mesmo se é esse o modelo, e os dois vão até o
balcão. Maria lhe pergunta qual o seu CPF para verficar seu
cadastro, mas João não se lembra qual é. Maria então procura
pelo seu nome completo e vê que João é um cliente antigo. Ela
então verifica que a saída do carro “zzzz” teve um atraso de dois
dias e lembra a João que ele precisa verificar essa pendência. Ele
então lhe diz que quando devolver esse carro também pelo
atraso do outro.
Trabalho– Requisitos: Cenários
(cont.)
 Cenário 3:
◦ O próximo cliente de Maria é Raul. Raul é um
cliente regular da locadora que costuma devolver
os carros sempre com atraso, nunca se lembra de
seu número de CPF e vive acumulando multas.
Ele está devolvendo 3 carros, sendo que dois
deles estão com atraso. Maria começa a checar
os carros devolvidos, porém um deles está com
um arranhado. Ela então verifica se o cliente fez o
seguro do carro e separa para corrigir o
problema depois.
Trabalho– Requisitos:
Atividades
 1 – Identifique o perfil dos usuários do sistema.
(Construa as Personas)
◦ Ex.: Usar os três exemplos (joão e maria e raul) e fazer a
ficha de cada uma (inventar um quarto personagem).
 2 – Identifique e categorize os requisitos do
sistema. (Construa os Cenários)
◦ Cite alguns planos, contextos de uso, algumas
ações do sistema, alguns eventos, algumas
avaliações e objetivos
◦ Ex.: O sistema tem de ter:
 Rápida devolução e locação de carros;
 Procurar clientes;
 Mostrar a situação dos clientes (carros emprestados, atrasados,
multas, seguro etc.)
 Eliminar pendencias;
Trabalho– Requisitos:
Atividades
 III – A partir das Personas e dos Cenários,
constua alguns diagramas de caso de usos
para algumas situações. (incluindo
relacionamentos)
 Usar capítulo 07 do livro como referência

 Trabalho individual
 Enviar por email: uft.eduardo@gmail.com
 Assunto: 2º Trabalho de Interfaces Homem
Máquina
Nas próximas aulas...
Design Centrado no Usuário - ISO 13407

Identificar a
necessidade do projeto
centrado no usuário

Analisar e especificar
o contexto de uso

O sistema satisfaz Especificar as


Avaliar o projeto
as exigências dos exigências dos
contra as exigências
usuários usuários

Produzir soluções
de projeto
Desenvolver designs alternativos
 Design conceitual: como representar?
◦ Representações abstratas (em notações gráficas ou
textuais)
◦ Representações “em discurso” (textos descritivos
/narrativos em português ou outra língua, com/sem
ilustrações gráficas)
 Como criar?
◦ Examinar problemas similares e suas respectivas
soluções
 Adaptar soluções correntes
 Construir uma (ou mais) solução(soluções) nova(s)
◦ Não havendo problemas similares
 Inventar uma solução e explorar alternativas para ela
De onde vem as alternativas?
 Humanos tendem a optar pelo que eles
sabem que funciona
 Mas considerar alternativas é importante
para “quebrar a caixa”
◦ “The best way to get a good idea, is to get lots of
ideas” (Linus Pauling)
 Designers são treinados para considerar
alternativas; engenheiros de software não
 Como gerar alternativas?
◦ Pesquisa e síntese
◦ Busca por inspiração: olhar produtos similares e
produtos bastante diferentes
Como escolher dentre as
alternativas?
 Avaliação com usuários ou colegas, e.g.
protótipos
 Viabilidade técnica: alguns não são possíveis
 Garantia de qualidade
◦ Critérios de usabilidade definidos desde o início
e verificados constantemente
 segurança: quão seguro?
 utilidade: que funções são supérfluas?
 efetividade: provê suporte apropriado à gama de tarefas
que quero realizar? A informação está disponível?
 Eficiência: medidas de performance
Questões úteis sobre inovação
(Scott Berkun, autor de The Myths of Innovation)
 Por que isso é feito assim?
 Quem iniciou isso, e por quê?
 Que alternativas foram consideradas, ou que
idéias essa nova idéia substituiu?
 Quais são as principais reclamações (minhas, dos
meus amigos, ...) sobre como isso
funciona/ocorre?
 Como isso é feito em outras cidades, países,
culturas, ou épocas?
 Que diferentes suposições fizeram ou quais
restrições tinham?
 Como posso aplicar essas coisas a o que eu faço?
Construir versões interativas
 Construir versões interativas (avaliáveis,
mesmo que como esboço ou maquete)
dos designs
◦ Design físico: como representar?
 Esboços ou maquetes
 Protótipos (de baixa ou de alta fidelidade, parciais
ou completos)
Prototipação para escolher melhor
alternativa
 Para a prova, esses slides fazem parte do
capítulo 7 do livro texto.