serg O Processo de Design Requisitos semiotic engineering research group Informática PUC-Rio

(1)

serg

semiotic engineering research group Informática

PUC-Rio

O Processo de Design

Necessidades dos Usuários

(2)

Relembrando …

Interação Humano-Computador Processo de comunicação que envolve um ciclo contínuo de interpretação e ação entre

usuários e sistemas interativos.

• Atividades básicas do design de interação:

1. Identificar necessidades e estabelecer requisitos. 2. Desenvolver designs alternativos.

3. Construir versões interativas (avaliáveis, mesmo que como esboço ou maquete) dos designs.

(3)

Atividades Básicas do Design de Interação

1. Identificar necessidades e estabelecer requisitos

2. Desenvolver designs alternativos

3. Construir versões interativas (avaliáveis, mesmo que

como esboço ou maquete) dos designs

4. Avaliar as alternativas

– Descrever os diferentes tipos de requisitos

– Distinguir os diferentes tipos de requisitos a partir de uma descrição

– Pode-se usar diferentes técnicas de coletas de dados

– Desenvolver um cenário e um caso de uso a partir de uma simples descrição

(4)

O que, como e por que?

•Por que:

Definição de

requisitos é o

estágio onde as

falhas ocorrem

mais

comumente

(5)

Modelo do Ciclo de Vida Simples para IHC

Identificar necessidades/ estabelecer requisitos Como identificar? Como representar? Avaliar Avaliar (Re)Design (Re)Design Construir versões interativas Produto final

(6)

(cont.)

Atividade em Foco

Análise de tarefa/funcional Implementação

Modelo do Ciclo de Vida Estrela (Hartson & Hix)

1. Identificar necessidades e estabelecer requisitos. Avaliação Design conceitual/formal Especificação de requisitos Prototipação

(7)

(cont.)

Atividade em Foco

1. Identificar necessidades e estabelecer requisitos. Modelo do Ciclo de Vida para a Engenharia de Usabilidade

(8)

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)

(9)

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

(10)

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.

(11)

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)?

(12)

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

(13)

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 – informações qualitativas

• 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

(14)

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

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

(15)

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 • 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

(16)

Perguntas Fechadas vs. Perguntas Abertas

Considerando como exemplo um sistema de agenda, um trecho de um questionário básico poderia ser o seguinte:

1. Você possui uma agenda?

( ) sim, sempre tive

( ) sim, há muito tempo (quanto:_______) ( ) sim, há pouco tempo (quanto:_______)

( ) não, porque ______________________________

Caso você possua uma agenda, responda as perguntas 2 a 4: 2. O que costuma anotar nela?

___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________

3. Você gosta de utilizar sua agenda?

muito ( ) ( ) ( ) ( ) ( ) nem um pouco

Porque ______________________________________________________________________ __________________________________________________________________________

4. Quando você está sem sua agenda, você

( ) se sente totalmente perdido.

( ) marca compromissos com apreensão. ( ) marca compromissos com tranqüilidade. ( ) nem se lembra dela.

( ) outros. Favor explicitar: ___________________________________________________ ___________________________________________________________________________

(17)

Entrevistas

• Uma série de perguntas abertas

– Perguntas não-estruturadas – Perguntas semi-estruturadas – Perguntas estruturadas

• O entrevistador tem oportunidade de esclarecer alguma

dúvida ou perguntar mais sobre uma experiência pessoal

que lhe interesse

• Como dão mais trabalho e exigem mais tempo,

normalmente são realizadas com um número menor de

usuários

(18)

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

(19)

Caracterizações de Perfil de Usuários

• Papéis

• Características pessoais

– estilos de aprendizado – tipos de personalidade – preferências

• Características físicas

• Realização das tarefas

– grau de especialização e freqüência de realização – aprendizado de uma tarefa – histórico e evolução das

tarefas

• Conhecimento de

• Características físicas

• Motivação

– origem da nova solução – poder de decisão

• Conhecimento de

ferramentas

– experiência e forma de

aprendizado das ferramentas – satisfação com as

ferramentas

– conhecimento prévio

(20)

• Ambiente físico

– espaço físico – uso de equipamento – nível de ruído

• Ambiente social

– pressão

Caracterizações do Ambiente de Trabalho

– pressão

– distribuição geográfica

• Ambiente cultural

– diversidade de nacionalidade – hábitos estabelecidos

(21)

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 – 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

(22)

Exemplo Persona

Quando sai uma nova tecnologia, Rircardo é o primeiro a questionar sua aplicabilidade. Se ele pudesse, colocaria um freio no mercado para que diminua a produção de novas tecnologias e melhore as já existentes. "Não é preciso reinventar a roda" é uma das frases que ele mais gosta.

Ricardo não é um líder carismático, mas sabe organizar muito bem uma Ricardo não é um líder carismático, mas sabe organizar muito bem uma

equipe se precisar. É um bom planejador porque faz de tudo para cumprir os prazos combinados, mesmo em condições precárias de orçamento e prazo. Infelizmente, outras pessoas se aproveitam dessa sua qualidade para mantê-lo constantemente sob pressão e isso lhe causa grande frustração. "Um dia eu chuto o

pau-da-barraca", diz ele consigo mesmo quando está nervoso.

(23)

(24)

Cenários

narrativas

pictóricas

textuais

(25)

Cenários

concretos

ricos em

detalhes

contextuais

25

detalhes

contextuais

reais ou

plausíveis

(26)

Cenários

situações de uso

(27)

Cenários: Para quê?

conhecimento adquirido

sobre

o usuário

27

o usuário

e

suas necessidades

(28)

Cenários: Para quê?

representar e gerar

alternativas de design

(29)

Cenários: Para quê?

para obter

feedback do usuário

29 sem o custo de se construir um protótipo funcional

(30)

Cenários: Por quê?

• flexíveis

• representação

provisória

• focam as

conseqüências para usabilidade

de propostas de design específicas

• o uso do sistema

em detalhes

• o uso do sistema

em detalhes

• linguagem natural

, compreensível por todos os stakeholders • provocam discussões e perguntas do tipo

“e se”

(31)

Elementos de Cenários

atores

31

(32)

Elementos de Cenários

32

(33)

Elementos de Cenários

eventos

(34)

Elementos de Cenários

objetivos

(35)

Elementos de Cenários

planos

(36)

Elementos de Cenários

ações

36

(37)

Elementos de Cenários

Rosson & Carroll. 2002

avaliação

(38)

Elementos de Cenários

atores

contexto

planos

ações

eventos

objetivos

ações

(39)

Cenários: dois “tipos”

• para análise do problema – Quem são os usuários? – O que eles fazem?

– Como?

– Que problemas enfrentam?

39

• para projeto

– Como eu, designer, vou apoiar os usuários?

– Como o sistema que estou projetando vai se encaixar no ambiente de uso?

(40)

Exemplo concreto

João Pedro estava às vésperas de fazer a prova de Física IV na faculdade, e a matéria da prova eram vários capítulos do livro do Halliday. Sempre atarefado com suas atividades extra-curso, João Pedro acabou não comprando o livro do Halliday e agora chegava a hora da prova e ele precisava estudar. Sua única chance era pegar o livro na Biblioteca. Ele

foi para o primeiro terminal disponível e entrou no sistema de bibliotecas da

faculdade. Não sabia o nome do livro e, na verdade também não sabia escrever “Halliday”. Só ouvia o professor e os colegas falarem sempre no tal livro. Que

ator evento plano objetivo ações contexto 40

“Halliday”. Só ouvia o professor e os colegas falarem sempre no tal livro. Que fazer? Para começar, resolveu fazer uma busca por autor, digitando como nome

“Haliday”. O resultado foi negativo; nenhuma obra com aquele autor foi

encontrada. (...) avaliação plano ação ator contexto evento objetivo plano ação avaliação