Pessoal, estou no processo de clipagem e fichamento para meu texto. Aproveito isso para divulgar material muito bom que acho na minha peneirada pela Web. Esse clip é um dos blogs mais completos que já vi sobre o assunto, pretendo lê-lo todo, mas para quem está envolvido com design da interação, interfaces e projetos focados em interfaces que lidam com usuários é uma ótima pedida para estudo.
Bom proveito! 
2 Projetando interações
Este capítulo apresenta as definições sobre o projeto de interação com o usuário (PIU), o que é e para que servem os processos de interação e as atividades do projeto de interação. Apresenta ainda as questões práticas do PIU que inclui necessidades e requisitos, projetos alternativos, versões interativas, avaliação e as diversa condições envolvidas no processo de documentação dos artefatos nas etapa de desenvolvimento do projeto de interação com o usuário. São tratadas ainda considerações emergenciais para o projeto de interação e modelos de ciclo de vida na área de IHC e uma forma de projetar a interação por meio da engenharia semiótica.
É comum encontrar o termo “Design de Interação”, mas prefiro não entrar em detalhes sobre o significado de termo Design[1] e utilizar uma tradução mais objetiva para o termo: Projeto. Sendo assim, quando falarmos de Projeto de Interação estaremos falando de Design de Interação.
1. Contextualização
Na interação homem computador os processos que caracterizam diálogos são formados por ações empregadas por uma entidade comunicativa na qualidade de usuário ou computador. O objetivo é provocar uma troca de informações: respostas às reações geradas por estímulo. A isto se denomina interação. Dentro deste escopo, garantir um processo efetivo e com sucesso para o diálogo passa pelo Projeto de Interação com o Usuário, o PIU.
Segundo Saffer (2007) esta disciplina é proveniente de raízes do design industrial, fatores humanos, interação homem computador, experiência do usuário dentre outras áreas que ainda ajudam a definir os limites desta nova disciplina. Mas independente de suas raízes o projeto de interação possui um caráter essencialmente comportamental. Este comportamento está associado com algo praticamente intangível e invisível, algo difícil de ser definido como ideal. Diferente da aparência, por exemplo, que pode causar reações imediatas. O comportamento está associado a reação onde, por exemplo, dois produtos diferentes que fazem a mesma coisa causam impactos diferentes no uso, mas isso só pode ser reconhecido somente depois da experiência de manipulação ou uso.
De forma simples é tornar simples a vida de quem usa alguma coisa. É definir processos para comunicação e interação humana com os artefatos ou produtos interativos, o que inclui decisões sobre detalhes dos procedimentos da comunicação de ordem lógica ou física e comportamental. Mas ainda se discute sobre os objetivos desta disciplina. Dentro deste escopo são definidos os processos de um produto interativo que fornecem suporte às atividades cotidianas das pessoas, seja no lar, no trabalho ou no entretenimento. Os produtos mais associados ao projeto de interação, no entanto, são produtos tecnológicos como softwares e equipamentos que favoreçam a utilização de um sistema lógico.
O projeto de interação oferece a um determinado produto todo um sistema de uso para usas funcionalidades. Em resumo o projeto de interação se aplica a QUALQUER COISA USÁVEL! Mais especificamente, é possível projetar uma variedade de equipamentos e produtos que permitam a troca de informações entre as partes.
Para entender melhor o objeto do projeto de interação é preciso entender que podem ser utilizadas uma série de elementos nas interações que oferecem saída e entrada de dados para a geração de estímulos permitindo, assim, um diálogo fluido. Saídas e entradas de dados acontecem por meio de INTERFACES que são compostas por artefatos como gráficos, sons, superfícies que estimulam o tato, sinestesia[1], cheiros (Figura 5), os próprios equipamentos que recebem respostas do ambiente ou de humanos, entre outros.
Figura 5 - Interfaces em realidade virtual, com estímulo sinestésico e olfativo, apresentadas no Laval Virtual em 2004 na França. O sistema sinestésico oferece manipulação de objetos virtuais com retorno físico que permite identificar dimensões e peso dos objetos virtuais. O estímulo olfativo do jogo “Fragra” (Visual-Olfactory VR Game) permite explorar relações interativas entre visão e olfato. É um jogo de erro e acerto onde os cheiros podem não corresponder a fruta fazendo o jogador dizer qual é o cheiro da vez. O sistema pede que uma fruta seja selecionada utilizando a luva com sensores, levando-a próximo ao nariz o usuários revelado em voz alta o nome da fruta correspondente ao cheiro que é exalado pela luva. Ao pronunciar o nome da fruta o usuário pode acertar ou errar. O terceiro equipamento é um Phantom, dispositivo que permite usar a força para esculpir objetos virtuais.
Os estímulos computacionais estão associado às entradas dos dados que podem acontecer via voz (ou sons), via apontadores sensíveis à movimentação e controlados por dispositivos variados (mouse, olho, caneta, etc) ações de seleção (clique por exemplo) em formato mecânico (mouse) ou manual (touch screen), dentre outros que envolvem tecnologias ainda em pesquisa como o aproveitamento de impulsos neurais.
Não importa a quantidade de elementos de interface de entrada ou saída utilizados – embora quanto maior o número de elementos mais complicado e complexo pode ser o processo de interação. O importante é projetar os processos de troca de informação com o usuário de forma a usável. A facilidade de uso é a base do princípio de usabilidade. Mas só a base. Ser agradável é também algo que determinará a satisfação do usuário.
Esta condição básica nos leva a entender o termo USABILIDADE. Os vários conceitos da usabilidade, no entanto, estão associados a diversos fragmentos que permitem a condição de “COISA USÁVEL”. Estes conceitos serão vistos mais a frente em forma de metas e princípios de um projeto de interação.
Nos concentraremos agora em entender melhor o que é o projeto de interação, quais são seus processo e as questões práticas do projeto de interação, para, então, entender como acontece o ciclo de vida de desenvolvimento do projeto de interação.
2. O que é projeto de interação?
O projeto de interação é uma atividade prática e criativa que tem por objetivo final o desenvolvimento de um produto que ajude os usuários a atingirem suas metas.
Segundo Verplank (2003) o projeto de interação deve responder sobre como o usuário fará alguma coisa, como ele se sente e como ele sabe fazer esta coisa. Verplank ilustra este cenário descrevendo que até o mais simples dispositivo requer manipulação, conhecimento e sentimento como acontece com o apertar de um botão luminoso e ver (ou sentir) a luz acender. Mas, mas para isso é preciso entender como funciona o mapeamento deste controle. Quanto mais afastados estiverem controles de entrada (botão) e saída (luz), mais complexo e demorado será o modelo de compreensão do usuário sobre o fazer e sentir.
Faz parte deste processo compreender aspectos relacionados à interação em tarefas que dão suporte às atividades cotidianas. O envolvimento do usuário no processo interativo por meio de métodos centrado no usuário é, também, de igual importância. Outros modelos de projeto com outros “centros” também podem ser considerados, mas o usuário é nosso cliente e como cliente, ‘quase’ sempre tem razão. Para que tudo isso seja possível é importante iniciar bem, e para isso temos as conhecida técnica de levantamento de necessidades e requisitos.
Bom, as estratégias para a criação de um projeto de interação envolvem procedimentos que ajudam a responder questões deste tipo. Mas, tão importante quanto isso é entender se existe uma forma eficiente de comunicar um projeto ao usuário e fazê-lo integrar-se à equipe de desenvolvimento transformando-o num colaborador durante o desenvolvimento do produto. Isso se aplica de forma diferente para produtos novos ou atualização tecnológica.
O projeto de interação trata da construção de um conhecimento lógico apresentado e comunicado de formas diversas tanto à equipe de desenvolvimento quanto ao usuário final. Soluções triviais popularizadas são mais fáceis de serem absorvidas e entendidas pelos usuários. O que talvez dê mais trabalho são modelos conceituais inovadores que exigem mais esforço do usuário para aprender o processo de interação. O sucesso desses produtos inovadores dependerá de aspectos como necessidade de mercado, grau de desafio de uso e satisfação proporcionado ao usuário. Ah! Inclua nesta fórmula estratégia de marketing. Você tem acompanhado as críticas do iPhone da Apple?
Projetar a interação é tão importante quanto realizar os casos de uso, os diagramas de seqüência e todos os outros elementos relacionados à documentação tradicional de sistema. O PIU, Projeto de Interação com o Usuário, envolve uma série de processos e instrumentos relacionados a forma como o usuário irá se comportar quando estiver utilizando o sistema. Por isso envolve uma série de artefatos e procedimentos.
3. Processos do projeto de interação
Não existe um processo ou modelo mais correto, existem, sim, aqueles mais adequados levando-se em conta os fatores decisivos para o desenvolvimento do produto, tais como dimensão do projeto, cronograma, orçamento, equipe, etc.
O projeto de interação, no entanto, não é visto como uma técnica isolada e diferente dos processos conhecidos na engenharia de software e outras áreas comuns.
Uma forma de estabelecer uma relação detalhada do processo de interação é descrever o processo rico em detalhes com descrição de objetivo, ação, resultado e detalhes (Quadro 1). Os resultados levam ao desenvolvimento de protótipos de telas (wireframes ou templates) que esclarecem o procedimento passo a passo de forma visual, minimizando as barreiras que possam gerar dúvidas aos desenvolvedores e aos usuários.
Quadro 1 – Exemplo simplificado que detalha a atividade de fechar um programa
Objetivo
Fechar o programa
Localizar elemento visual e levar o cursor do mouse até o símbolo, botão, rótulo e clicar.
Se houver arquivo aberto com alterações a serem salvas oferecer mensagem permitindo a ação de salvar ou fechar sem salvar.
Detalhes
Deve existir mensagem específica para quando houver mais de um arquivo aberto.
Resultado
Ação esperada
Uma solução agregada ao UML
Conhecida e utilizada por profissionais da área de computação, a Unified Modeling Language (UML) baseada num processo unificado de desenvolvimento de software oferece condições de detalhamento das atividades de interação de um sistema. O problema é que, quando utilizada para a documentação de projeto, dificilmente entra em detalhes tão importantes da interação.
Como o próprio modelo evidencia, não se observa a natureza iterativa e incremental do processo de desenvolvimento para manutenção e ajustes de problemas. Além disso não oferece destaque para a interface com o usuário. Diante disto Hudson (2000) propõe uma extensão do processo unificado que incorpora as 10 técnicas mais populares em projeto de interfaces (Figura 6). O objetivo é centrar o processo ainda mais no usuário para obter sistemas mais usáveis.
Figura 6 - Processo UML alterado para suportar as atividades do projeto de interação. Em vermelho as etapas inseridas que auxiliam no projeto de interação. (Hudson, 2000)
Na Figura 6, em vermelho, observam-se os pontos em que este processo sofreu alterações destacando a adição das atividades de:
- Identificação e desenvolvimento de cenários de uso: Técnicas relevantes: cenários de uso (com base em dados colhidos em observações de potenciais usuários na realização de trabalho, por exemplo) e avaliação de sistemas existentes.
- Análise de contexto: Técnicas relevantes: análise de usuário/identificação de perfis, identificação de tarefas e estabelecimento de requisitos de usabilidade.
- Projeto da interface: Técnicas relevantes: projeto de navegação, projeto visual da interface e protótipos de baixa fidelidade.
- Avaliação de usabilidade: Técnicas relevantes: avaliação de usabilidade por especialistas e teste informal de usabilidade.
4. Atividades do projeto de interação
De forma geral podem ser observadas quatro atividades básicas que definem o processo do projeto de interação (Preece et al, 2005):
1. IDENTIFICAR NECESSIDADES E ESTABELECER REQUISITOS: Trata-se da base dos requisitos do produto. Esta atividade sustenta o design e o desenvolvimento. O objetivo desta etapa é conhecer o usuário alvo e o tipo de suporte útil que o produto deve oferecer. Para isso é fundamental iniciar uma abordagem centrada no usuário.
2. DESENVOLVER PROJETOS ALTERNATIVOS QUE VÃO DE ENCONTRO AOS REQUISITOS: Atividade central do projeto de interação. É quando surgem as idéias que devem atender aos requisitos, as quais devem ser geradas com base em algum tipo de suporte. São as sub-atividades da geração de idéias. O projeto conceitual ou o modelo conceitual do produto ganha forma juntamente com a descrição sobre o que o produto fará, como se comportará e parecerá. O projeto físico pode, então, ser iniciado com detalhes de interação e de interfaces, o que pode incluir o estudo de cores, sons, imagens, menus, animações, ícones, etc.
3. CONSTRUIR VERSÕES INTERATIVAS DE MANEIRA QUE POSSAM SER COMUNICADAS E ANALISADAS: Fornecer meios de simular o processo de interação. Afinal, como os usuários saberão e verificarão se as necessidades estão sendo atendidas? As versões prototipadas são os meios mais conhecidos para mostrar ao usuário como um produto está sendo modelado e verificar a primeira reação de aceite. Mas isso não significa que deva ser uma versão funcional. Protótipos em papel podem ser desenvolvidos e aplicados com rapidez, são baratos e eficazes na busca de problemas nas primeiras fases do projeto. O usuário tem uma noção real de como será a interação.
4. AVALIAR O QUE ESTÁ SENDO CONSTRUÍDO E MEDIR SUA ACEITABILIDADE: São formas de determinar a usabilidade e aceitabilidade do produto utilizando vários critérios, tais como número de erros cometidos pelo usuário, atratividade, preenchimento dos requisitos, etc. Não substitui testes de qualidade que certificam o produto final. Mas ajudam a verificar se todo ou parte do produto encontra-se em condição de uso.
Estas 4 atividades (Figura 7), que ainda veremos com mais detalhes, podem se repetir em etapas diferentes do desenvolvimento do projeto. Prototipagem, por exemplo, pode acontecer tanto na fase inicial de documentação como no decorrer da programação. A exemplo do UML proposto para o projeto de interação, pode-se identificar que as atividades de interação precisam ser reconsideradas em diferentes etapas do processo. Mas a etapa crítica, a que precisa de muita atenção, é o levantamento ou elicitação de requisitos.
Figura 7 - Atividades básicas do PIU
Independente do momento do projeto devem ser consideradas algumas características-chave no PIU: usuários envolvidos no desenvolvimento do projeto, identificação ou especificação de metas de usabilidade no início do projeto e complementação e iteração (repetição) nas atividades básicas com ênfase nos processos de avaliação. Considere, portanto:
1. Foco no usuário: Se não for possível garantir seu envolvimento considere o desenvolvimento de soluções voltadas para o usuário e contexto de uso específico. Em outras palavras, projetar e avaliar pensando como o usuário, focar nas tarefas como se estivessem sendo realizadas para o usuário e dar atenção aos processos e mensagens de retorno.
2. Critérios específicos de usabilidade: Os objetivos específicos devem ser claramente documentados, pois isso ajuda na idealização de diferentes alternativas de projeto. Desta forma é fica mais fácil identificar metas de usabilidade e, posteriormente, verificar o atendimento dos princípios de usabilidade.
3. Iteração: Significa repetição, que neste caso, se refere aos processos de testes e avaliações para o refinamento do projeto, ainda com base no retorno do usuário.
O envolvimento do projetista e do usuário ajuda a definir uma série de critérios para o desenvolvimento do projeto (domínio, requisitos, necessidades, desejos, aspirações e muitos outros direcionadores). Este processo conduz ao entendimento da necessidade da interação, muito importante quando se trata de um produto inovador onde as idéias precisam ser revisadas à luz do retorno do usuário.
ALGUMAS QUESTÕES PRÁTICAS DO PIU
É possível encontrar diferentes listas de atividades para o processo de interação. Também é fácil encontrar uma série de propostas e modelos de como atuar em cada fase ou etapa proposta para o projeto. Mas em linhas gerais devemos entender que o projeto de interação com o usuário é baseado em duas abordagem:
- FERRAMENTAS DE NEGOCIAÇÃO: elas propiciam a comunicação de idéias por meio de reuniões, discussão em grupos, serviços de fóruns, entrevistas participativas. O importante desta abordagem é gerar resultados de forma documentada.
- PRODUÇÃO DE ARTEFATOS: são passos mais objetivos para o desenvolvimento do projeto de interação que inclui atividades de:
- Conceitualização: É produzido com o auxílio das primeiras atividade de levantamento de requisitos e resulta na produção de:
- mapa mental dos conceitos para o usuário;
- lista dos aspectos de requisitos eleitos como importantes de forma a adequá-los à curva de aprendizado do usuário; e
- definição dos contextos de uso para condições culturais, sociais, simbólicas e tecnológicas;
- Estruturação: Diagrama de interação social, fluxograma de interação, wireframes, protótipos de baixa fidelidade;
- Apresentação: Detalhes estéticos, definição de aspectos visuais como a identidade visual do produto, leiaute e protótipos de alta fidelidade.
- CONCEITUALIZAÇÃO: Está associada ao levantamento de requisitos
- ESTRUTURAÇÃO: Está associada aos projetos alternativos. Embora possa gerar discussões intermináveis, oferecer mais de uma solução de interface, quando o cronograma permite, permite visualizar tarefas, elementos de interface e processos de diferentes pontos de vista.
- APRESENTAÇÃO: São as versões interativas que permitem iniciar avaliação mais detalhadas.
(1) Necessidades e requisitos
Para entender as questões práticas envolvidas no projeto de interação não precisa ir muito longe. Estas atividades também acontecem em outras áreas. Por exemplo, na arquitetura é necessário conhecer o cliente, futuro utilizador do espaço construído. Para isso é necessário definir uma lista de necessidades (o que o cliente quer, quantos filhos tem, se gosta de receber visitas, parentes para ficar por mais tempo, etc) além de viabilidades legais que ajudarão, por exemplo, a identificar o zoneamento possível (organização dos espaços para alocação da edificação no terreno), dando início ao partido do projeto (primeiro protótipo visual dos espaços a serem edificados) e prosseguindo com os detalhamentos do projeto. As atividades iniciais estão baseadas no estudo e envolvimento do usuário e legislação. Em projetos urbanos, por exemplo, estes usuários são em maior número e tão diversificado quanto na utilização de sistemas computacionais, e por isso devem ser consideradas questões sociais e costumes e rotinas da população para o projeto de espaços urbanos. Tudo isso só é possível com a realização de etapas de entrevistas envolvendo, dentro das possibilidades, aqueles que farão uso do espaço.
_____________________
Na engenharia de produto são feitas pesquisas de satisfação com relação a produtos no mercado. Clientes potenciais também são chamados para oferecer sugestões sobre novos propostas de produtos. Os profissionais envolvidos são de áreas como design gráfico, arquitetura, urbanismo, engenharias (industriais de produção, de software) entre muitos outras.
Cada disciplina apresenta sua própria interpretação e processos para desenvolvimento do projeto. Mas podemos entender a tarefa de projetar a interação como sendo um (1) plano ou esquema concebido na mente de alguns, (2) idealizado por uma equipe de profissionais especializados que desenvolvem artefatos que permitam a (3) execução prática do produto.
De qualquer forma, não importa a área. Cada uma delas trata, do seu jeito, questões similares, tais como:
- conhecimento sobre o uso e domínio-alvo do produto;
- investigação sobre o uso de artefatos;
- entender as restrições práticas quanto ao material, custo e viabilidade; e
- solução do problema antes da execução levando em conta os usuários.
Diante de uma série de considerações é importante notar, ainda, possíveis compensações em que devem ser pesadas a habilidade do usuário e o equilíbrio de necessidades conflitantes.
As necessidades e requisitos para o projeto de interação não são diferentes daqueles conhecidos pelo analista de sistema definidos para realizar o documento técnico de sistemas computacionais. Mas no projeto de interação é comum encontrar o usuário como foco de qualquer atividade. Embora outros[1] modelos de centros de projeto possam ser encontrados na literatura, o centro no usuário é o mais explorado. Os processos mais comuns para o desenvolvimento de projeto são baseados no USUÁRIO, na ATIVIDADE e na AÇÃO.
Esta atividade deve ser realizada em parceira direta com usuários e clientes. As atividades definidas por processos como RUP (Rational Unified Process) e UML (Unified Model Language) são os procedimentos conhecidos e comumente adotados. Eles oferecem muitos recursos para a tarefa de documentação das necessidades e estabelecimento dos requisitos.
EM TEMPO!
Qual a diferença entre Necessidade e Requisito? Primeiro, requisito é um derivado de necessidade. Veja o exemplo para as diferenças para um produto do tipo telefone:
Engenharia de requisitos
A engenharia de requisitos é um processo criterioso de identificação do que deve ou pode ser desenvolvido e das tecnologias e insumos envolvidos. É objetivo da engenharia de requisitos evitar problemas de desenvolvimento de sistemas que levem ao não atendimento das expectativas do usuário. Para isso é necessário realizar uma exaustiva e criteriosa fase de definição de requisito. Os níveis de abstração dos requisitos são (Figura 8):
- de negócios (objetivos do usuário): documento de escopo ou de visão;
- de usuários (descreve as atividades que os usuários deverão desempenhar); e
- funcionais (o que o sistema deve possuir para que os usuários possam executar suas atividades para alcançar os objetivos de negócio).
Figura 8 - Níveis de abstração dos requisitos
Outros requisitos necessários sugeridos por Blaschek (2002):
- requisitos não funcionais (padrões e regulamentos com os quais o sistema precisa ter conformidades, como por exemplo, descrição de interfaces externas e requisitos de desempenho);
- restrições (limites de recursos e infra estrutura); e
A maioria dos processos de Engenharia de Requisitos pode ser descrita por meio de um macro-modelo de atividades (Figura 9) composto de atividades como elicitação, análise e negociação, documentação, validação e gerência de requisitos, conforme mostrado na Figura 9. Mas muitas outras atividades podem ser encontradas na literatura com o objetivo de identificar requisitos. Ribeiro (sem data) realizou uma pesquisa onde apresenta uma lista de processos sugeridas por quatro diferentes autores. Algumas das atividades encontradas são repetidas, a exemplo dos requisitos apresentados por Blaschek (2002), que determinam apenas quatro etapas incluindo elicitar os requisitos, analisá-los, gerar a documentação e a realizar a validação. As outras atividades são:
- atributos de qualidade de software (ISO 9126).
- Análise de domínio (considerada apenas por 1 autor)
- Elicitação de requisitos (considerada por 4 autores)
- Modelagem (considerada por 1 autor)
- Análise de requisitos (considerada por 3 autores)
- Negociação (considerada por 2 autores)
- Documentação (considerada por 1 autor)
- Especificação de requisitos (considerada por 2 autores)
- Análise da Especificação (considerada por 1 autor)
- Verificação (considerada por 1 autor)
- Comunicação (considerada por 1 autor)
- Concordância (considerada 2 autores)
- Validação (considerada por 1 autor)
- Documentação do processo, das decisões e das fontes dos requisitos (considerada por 1 autor)
- Gerência de requisitos (considerada 2 autores)
- Evolução de requisitos (considerada 2 autores)
Macro-modelo de atividades do processo de engenharia de requisitos
Como não existe um processo único que contemple todas estas fases também não existem limites definidos entre as atividades. Mas cada uma delas pode ser utilizada na prática com interpolações entre elas. A idéia é que o processo seja realizado até que o grau de satisfação de todos os usuários seja alcançado ou até que a pressão do cronograma precipite o início da fase de projeto do software (indesejável). As atividades mais importantes, no entanto – elicitação, análise de requisitos, documentação, validação e gerência de requisitos - são aquelas destacadas em negrito e serão discutidas a seguir com mais detalhes.
40% a 60% de todos os problemas encontrados em um projeto de software são causados por falhas na fase de levantamento de requisitos (Leffingell, 1997).
- suas características *;
- suas capacidades *;
- o que estão tentando alcançar;
- como fazem isso atualmente; e
- questionar se elas atingirão o objetivo com mais eficiência com outro tipo de suporte.
Exemplo que influencia nas decisões e que nem sempre são pensadas para os usuários típico:
- tamanho das mãos podem afetar no tamanho e posição dos botões;
- nervosismo, questões culturais, outros.
Antes de continuar reforcemos o entendimento sobre Engenharia de Requisito e Elicitação de Requisito.
- Engenharia de Requisito: Macromodelo composto de uma série de atividades para tratamento de requisitos.
- capacidades motoras podem afetar a adequação de certos dispositivos de entrada e saída;
- o uso da força deve ser considerada em um equipamentos para crianças (tipo de usuário – criança/adulto tempo de vida do equipamento); e
- Elicitação de Requisito: Uma das atividades da Engenharia de Requisitos.
Elicitação de Requisitos
Elicitar requisitos é a tarefa de descobrir, identificar, deduzir, extrair, evocar ou obter dados que contribuam com uma análise de qualidade (Blaschek, 2002).
É importante ter boa redação, declaração de visão e escopo do sistema.
Usuários, clientes e especialistas de domínio são identificados e trabalham junto com os engenheiros de requisitos para descobrir, articular e entender a organização como um todo. São consideradas atividades para entender o domínio da aplicação, os processos de negócio específicos, as necessidades que o software deve atender, os problemas e deficiências dos softwares atuais, os diferentes pontos de vista dos participantes do processo, bem como as oportunidades e restrições existentes, os problemas a serem resolvidos, os serviços e o desempenho requeridos, as restrições de hardware, dentre outros.
A atividade não se resume a perguntar às pessoas o que desejam. Também não é uma simples transferência de conhecimento. Existem várias técnicas de elicitação, sendo que a escolha depende do tempo e dos recursos disponíveis além do tipo de informação que necessita ser elicitada. As técnicas de elicitação de requisitos podem ser classificadas em (Batista, 2003):
- técnicas tradicionais: englobam técnicas genéricas, tais como o uso de questionários e pesquisas, investigação de documentos e entrevistas;
- técnicas de elicitação em grupo: exploram as dinâmicas de grupo, tais como técnicas de grupos focados – focus groups, workshops RAD – Rapid Application Development e JAD – Joint Application Development;
- prototipação: tem sido usada quando existe incerteza sobre os requisitos ou quando se torna necessário ter um retorno inicial dos usuários, podendo ser combinada com outras técnicas;
- técnicas dirigidas a modelos: fornece um modelo específico para o tipo de informação a ser obtido e conduz o processo de elicitação englobando os métodos baseados em objetivos e métodos baseados em cenários;
- técnicas contextuais: surgiram nos anos 90 como uma alternativa às técnicas tradicionais e cognitivas e incluem o uso de técnicas de etnografia, tais como observação dos participantes e análise de conversação.
- técnicas cognitivas: incluem técnicas desenvolvidas originalmente para aquisição de conhecimento em sistemas baseados em conhecimento. Dentre elas, pode-se citar análise de protocolo e classificação de cartões (card sorting).
A escolha da técnica dependerá do foco que se quer dar ao processo. As abordagens tradicionais e cognitivas baseiam-se no uso de modelos abstratos independentes do contexto. Por outro lado as abordagens contextuais levam o contexto local como premissa básica para o entendimento do comportamento organizacional e social. Embora exista incompatibilidade entre estes formatos as abordagens podem ser complementares.
8. Atividades
- Crie um celular de tamanho pequeno (máximo de 3 x 3 centímetros) com opções de realizar ligações e incluir números na agenda do telefone. Realize as seguintes atividades:
- Qual modelo de ciclo de vida sua equipe usaria?
- Quais são as necessidades e requisitos e como foram realizadas estas atividades?
- Esboce a idéia de um modelo interativo e pelo menos um projeto alternativo?
- Que tipo de versão interativa foi produzida?
- Como a equipe avaliaria o seu produto?
- Do que trata o PIU, para que serve e como funciona?
- Qual a relação entre o PIU e a usabilidade?
- Quais são as 4 atividades do PIU?
- Identificar necessidades e requisitos é uma das atividades do PIU. Esta já é uma atividade tradicionalmente realizada no desenvolvimento de sistemas. Mas existe uma consideração que dá a esta atividade um enfoque mais específico e cuidadoso, e que nem sempre é considerado pelos analistas tradicionais. Qual é ?
- Qual a fórmula rápida para o levantamento de necessidades e definição de requisitos? Como isso deve ser feito?
- Na engenharia de requisitos são citados 3 níveis de abstração dos requisitos. Quais são?
- Engenharia de requisitos é um macromodelo de atividades. Destaque 5 destas atividades discutidas na apostila.
- Qual a diferença entre Engenharia de Requisitos e Elicitação de Requisitos?
- Cite algumas técnicas de elicitação de requisitos – foque naquelas que possuem aplicação mais objetiva.
- Qual a diferença entre Elicitação de Requisito e Análise de requisitos?
- A documentação de requisitos, uma das atividades da engenharia de requisitos, pode ser entendida como “Especificação de requisitos”, Documento de Requisitos” ou “Especificação de Requisitos”. Isto está correto?
- A documentação de requisitos, uma das atividades da engenharia de requisitos, pode ser descrita, apenas, em um modelo formal de linguagem. Isto está correto?
- Em que momento da engenharia de requisitos a documentação que detalha os requisitos se torna um objeto que poderia ser usado como contrato de desenvolvimento de softwares?
- Para que servem wireframes ou mockups?
- Como funcionam os protótipos de papel?
- Qual a característica que torna o modelo de ciclo de vida ESTRELA apropriado para projetos de interação?
- Cite três modelos de ciclo de vida sugeridos para uso em projetos de interação.
- Desenvolva o modelo de tarefa para o seguinte cenário: Seu Eustáquio precisa de dinheiro e vai até o banco. Ele entra em sua conta e percebe que houve um crédito esperado há dias, mas resolve verificar o extrato da sua conta. Ele verifica que houve o débito automático de sua conta de luz de R$100,00. Verifica que há saldo suficiente e então prossegue com a retirada do dinheiro. Ele digita o valor referente à quantia desejada e confirma a operação com sua senha. Ele obtém uma confirmação impressa da transação e verifica o seu saldo mais uma vez. Ao final sai do sistema.
[1] O material apresentado é apresentado retirado de apresentações desenvolvidas pelos pesquisadores da linguagem (Serg, 2008: http://www.inf.puc-rio.br/~inf1403/3wd/slides/IHC_2009.1_aula15_molic.pdf e Prates, 2006: http://homepages.dcc.ufmg.br/~rprates/ihc/aula14_modelagem_interacao.pdf) Acessado em julho de 2009. Veja ainda o vídeo por Ugo Sangiorgi em http://molicdesigner.googlepages.com/
[1] No Blog Usabilidoido de Frederich Von Amstel você pode encontrar mais informações sobre os projetos centrados nas seguintes abordagens: no designer; no cliente; no sistema; no comportamento; na atividade; na tarefa; e na ação. Muitas vezes o projeto idealizado por projetistas é tão lógico e racional que o comportamento humano pode encontrar problemas para seguir o raciocínio, levando-se em conta que o ser humano pode ser irracional ao julgar algum processo de realização da tarefa. Este assunto é explorado sob a ótica da “Lógica Versus Uso” e destaca a importância do projeto centrado na atividade – não no usuário. Veja o artigo “The Case for Activity-Centered Design” publicado em http://www.jnd.org/dn.mss/logic_versus_usage_t.html (uma coluna dedicada a artigos sobre interação no CACM, 2006).
[1] difere do tato porque envolve força ou vibrações
[1] Pode ser encontrada uma série de justificativas para a manutenção do termo em inglês no nosso vocabulário. A frase “Design is to design a design to produce a design” por John Heskett sugere que design representaria variações semânticas da palavra como verbos e substantivos tendo como resultado palavras como projetar, produzir, processo e objeto”.
Figura 21 - Modelo de ciclo de vida da Engenharia de Usabilidade
O modelo de CICLO DE VIDA da engenharia de usabilidade envolve detalhes complexos sobre o desenvolvimento do produto, mas permite que pessoas com pouco conhecimento de usabilidade trilhem este caminho com mais facilidade. O modelo que é apoiado na engenharia de software é baseado em três tarefas essenciais: 1) Análise de requisitos, 2) Projeto/teste/desenvolvimento e 3) Instalação. Fica claro neste modelo a necessidade de identificação das metas de usabilidade na tarefa 1 (Figura 21).
Figura 20 - Modelo de ciclo de vida Estrela
O CICLO DE VIDA ESTRELA é uma proposta que não especifica um ordenamento das atividades, mas sua flexibilidade exige que uma avaliação sempre seja feita antes de iniciar uma nova atividade. Este modelo surgiu das observações de Hartson e Hix que verificaram que dois processos eram utilizados por designers de interface como modelos de ciclo de vida. O ANALÍTICO com característica de organização, formalidade e com uma visão que partia do sistema para a visão do usuário e o SINTÉTICO caracterizado pela criatividade, livre pensamento e improviso com a visão que partia do usuário para a do sistema. Este modelo inclui a implementação e a análise de tarefas. As outras atividades vão de encontro com as atividades básicas dos projeto de interação: 1) necessidade e requisitos, 2) versões alternativas (projeto conceitual), 3) protótipos e avaliação (Figura 20).
Figura 19 - Modelo de ciclo de vida Simples para projeto de interação
O CICLO DE VIDA SIMPLIFICADO do projeto de interação possibilita um número ilimitado de repetição do ciclo, desde que a última atividade sempre seja um teste. Este modelo foi proposto por Preece et. Al após observações sobre como a prática do projeto de interação acontece na vida real. Ele possui o foco no usuários e determina e possibilita que um produto evolua da forma que for compreendida como melhor pela equipe, havendo uma única limitação de repetições: o orçamento. Perceba que este modelo contempla as 4 etapas básicas do PIU: 1) Identificar necessidade e estabelecer requisitos, 2) Construir versões alternativas, 3) Projeto/re-projeto (protótipos) e avaliação. A sequência das atividades nos ciclos iterativos (nas repetições) depende da dinâmica estabelecida pela equipe e dos problemas encontrados nas avaliações (Figura 19).
Na área de IHC poucos modelos de ciclo de vida foram propostos, mas os que merecem destaque são: o modelo simplificado proposto por Preece et. Al (2005), o modelo estrela sugerido por Hartson e Hix em 1989 e o modelo da engenharia de usabilidade proposto por Mayhew em 1999.
Modelos de ciclo de vida sugerem processos que representam conjuntos de atividades e suas relações para o projeto, desenvolvimento e distribuição do produto. As muitas atividades envolvidas no processo do projeto de interação são similares e os modelos tradicionais de ciclo de vida da engenharia de software podem ser aplicados no projeto de interação (cascata, RAD, espiral, tec). A forma como as tarefas são tratadas pode diferenciar no resultado desses projetos. Mas percebe-se que modelos simplificados são os mais praticados na área de IHC, embora projetos de grande escala necessitem de modelos de ciclo de vida mais elaborados.
7. Ciclo de vida do projeto de interação
Figura 17 - Diferentes fluxos para o mesmo processo (Serg, 2008). Estes exemplo mostram acessos ubíquos, onde mais de uma atividade é encontrada em uma cena.
Figura 18 - Da interação para a interface
6. Considerações emergenciais para o projeto de interação
Tem-se por princípio que todo produto possui um objetivo de uso. Ao se adquirir o produto entende-se que ele atenderá à sua função. Isso leva a crer que o objeto deva ser eficaz, pois atenderá ao seu propósito.
É difícil que alguém compre algo que não atenda ao seu objetivo. Mas se por algum motivo um produto mau projetado cair nas mãos de um usuário, ele ainda tentará utilizá-lo. Mesmo havendo uma frustração inicial poderá haver, ainda, um voto de confiança e a continuidade de tentativas na esperança de obter sucesso. Mas se o usuário não obtiver êxito haverá frustração, xingamento, abandono, críticas, etc. “Mas o que será que este projetista imaginava durante o desenvolvimento deste produto?” Bom, pode não ser culpa do projetista, afinal maus resultados de projetos de interação podem ocorrer por corte, não previsão orçamentária ou falta de tempo destinado às avaliações.
Considerando, portanto, que o projeto de interação leva em conta a manipulação de elementos por um determinado USUÁRIO, este indivíduo é naturalmente visto como o elemento importante do projeto de interação. Ao considerar o usuário imagina-se que a interação projetada dependerá de suas capacidades e habilidades em compreender e manipular os elementos de interface. Pensar o usuário durante o desenvolvimento do projeto, então, é evitar o sacrifício do mesmo e uma possível degradação do produto e da marca.
SACRIFICAR O USUÁRIO NÃO É UMA OPÇÃO NO PROJETO DE INTERAÇÃO.
E não deveria ser também uma opção da empresa. Afinal desconsiderá-los pode gerar resultados catastróficos. Quando o usuário não pode ser utilizado durante o desenvolvimento do projeto esta preocupação deve ser redirecionada. Algumas soluções de projeto podem ser tomadas por meio de parâmetros de comparação entre bons e maus exemplos.
BOM x RUIM
Soluções baseadas no mundo real podem caracterizar uma boa opção de projeto. Mas nem sempre é a melhor saída. Exemplo disso é quando o modelo coloca em risco a segurança do usuário ou do equipamento. A tecnologia de realidade virtual, por exemplo, oferece opções de simulação de atividades impossíveis ou difíceis de serem executadas na vida real. As atividades são projetadas para parecerem o mais real possível, mas sem causar prejuízo ao usuário. Do que adiantaria, por exemplo, replicar as condições reais de uso de um laboratório de química ou física se o sistema oferecesse ao usuário exatamente as mesmas condições de perigo do ambiente real. Alguns comportamentos precisam ser reinterpretados para fornecer a informação de perigo ao usuário. Falaremos mais sobre isso quando discutirmos metáforas e modelos conceituais.
Como descobrir se um projeto é bom ou ruim?
A diferença entre projeto de interação Bom e Ruim é o resultado sobre ser fácil de aprender, ser eficaz, atender ao objetivo e ser agradável. Estes parâmetros podem ser compreendidos como um resumo da usabilidade, e isso pode ajudar a comparar o Bom e o Ruim, identificando pontos fracos e pontos fortes. O projeto RUIM é normalmente identificado por pontos fracos que causam irritabilidade, confusão, incapacidade (pela ineficiência do sistema ou dificuldade de uso), desistência, entre outros. MAS ISSO É FÁCIL DE DESCOBRIR. DIFÍCIL É:
- descobrir por que é difícil de ser utilizado?
- descobrir como seria possível melhorá-lo?
Os meios mais eficazes de descobrir isso é permitindo que usuários reais utilizem o produto enquanto são observados.
Figura 16 – Representação do tempo de resposta (Serg, 2008)
O tempo de resposta do processamento e, desta forma, da resposta ao usuário deve ser tratado conforme Figura 16 com uma instrução anexada ao diálogo de processamento. Outra condição são as formas como são tratados os fluxos de interação (Figura 17). Segundo Serg (2008) para cada meta ou fragmento de conversa na interação é necessário considerar a sequencia de atividades, os resultados possíveis, os problemas e dificuldades e as alternativas. Por fim, para entender como a interação vira interface, acompanhe as sugestões de Serg na Figura 18.
Figura 15 - Prevenção de erro (na ordem: passiva, ativa, apoiada) (Serg, 2008)
A fala de recuperação de breakdonw apontada na Figura 14serve para prevenir o erro. A prevenção pode acontecer de três formas: passivas, ativa ou apoiada (Figura 15).
Figura 14 - Detalhes do diálogo no MoLic (Modelagem da tarefa utilizando MoLic (Prates, 2006))
Figura 13 - Modelos de interação: transições (Prates, 2006) e definição de elementos do diálogo
Figura 12 - Exemplo de modelagem MoLic com início e fim
Figura 11 - Exemplo de um projeto de interação na forma de mapa conceitual de sistema com relações das tarefas associadas à três perfis de usuários desenvolvido em Visio.
Na engenharia semiótica existem técnicas que permite a modelagem do desempenho das tarefas realizadas pelos usuários. Uma delas é o modelo de interação MoLIC proposto na PUC-Rio (BARBOSA; PAULA, 2003). Este processo é muito prático de ser utilizado em sistemas com funcionalidades limitadas. Pode ser utilizado em avaliações preditiva (feitas por especialistas que observam, por meio da modelagem de interação, se o projeto é adequado e viável) ou para, somente modelar com clareza e detalhes as tarefas do usuário. O resultado obtido por esta modelagem é gráfico e podem ser obtidos com o uso software desenvolvido especificamente para este fim (SANGIORGI; BARBOSA, 2009 e SILVA, 2004).
MoLIC é linguagem para modelagem da interação com o usuário que permite construir diagramas que simulam uma conversa entre os usuários e o projetista do software. A linguagem é baseada na engenharia semiótica e utiliza diagramas para a construção destes diálogos. Para suportar o desenvolvimento destes projetos foi desenvolvido o MoLIC Designer, uma ferramenta que ajuda na construção destes diagramas. A pessoa que o utiliza precisa, apenas, ter o mínimo de conhecimento sobre a engenharia semiótica. Assim como a linguagem MoLIC ajuda a pensar a interação a ferramenta ajuda a estruturar e organizar o projeto como um todo. O MoLIC ajuda a modelar os cenários de interação baseado na engenharia semiótica com recursos gráficos similares ao UML.
O funcionamento da linguagem MoLIC utiliza padrões gráficos de representação dos acontecimentos[1]. O projeto dos caminhos de interação (caminhos que o usuário pode percorrer: fluxo normal, caminhos alternativos, de exceção ou erro) consiste da definição da cena (cenário de determinado assunto composto por cada passo da interação na qual são definidos os diálogos entre usuário e sistema) (Quadro 2 – Exemplo de cena (Prates, 2006)Quadro 2), do tópico do diálogo (tema central) e do foco do diálogo (trecho de conversa sobre algum aspecto específico do tópico).
Quadro 2 – Exemplo de cena (Prates, 2006) Os Termos U: e S: referem-se a usuário e sistema.
Tópico: marcar uma reunião Em um sistema de agenda, “marcar reunião” pode constituir uma cena contendo o seguinte diálogo: Foco: compromissos desta semana
U: Preciso examinar a semana atual.
S: Ei-la.
Foco: compromissos da próxima semana U: Não há horário disponível para marcar minha reunião de 3 horas. Deixe-me ver a próxima semana. S: Aqui está.
Foco: horários disponíveis U: Tem horário disponível na 3ª feira, a partir das 14h. Foco: novo compromisso U: Vou marcar um compromisso. Foco: dados do novo compromisso S: Que tipo de compromisso? Com quem e onde? U: Reunião com meu chefe. Ainda não sei onde será.
Foco: verificação do novo compromisso S: OK, marcado A modelagem na prática deve conter início e fim (Figura 12Erro! Fonte de referência não encontrada.), mas a extensão do gráfico dependerá da complexidade do diálogo. Este processo interno do diálogo é o mais importante, pois dependerá de como o diálogo poderá ser conduzido. São as transições que representam a mudança de rumo na conversa causada por uma fala do usuário (a partir de uma cena) ou por uma fala do preposto (a partir de um processamento). A transição, que pode acontecer a partir de uma cena ou a partir de um processo, é representada por uma seta preta que indica a direção da transição e por um rótulo que pode ser (Figura 13):
- uma pré-condição: condições que devem ser satisfeitas para que o usuário ou preposto possa enunciar a fala correspondente.
- uma ou mais falas do usuário ou do preposto do designer. No caso do usuário, trata-se de enunciados do usuário que causam a transição. No caso do preposto, trata-se de falas que revelam resultados de algum processamento do sistema que causam a transição.
- uma pós-condição: condições que passam a ser verdadeiras durante a transição.
A modelagem do desempenho da tarefa é a tradução das interações de um produto. Isto pode ser apresentado formalmente, com uso de métodos tradicionais (TAG – task-action grammars ou UAN – user action notation) utilizando ou não dicionário de termos ou pode ser feito informalmente. As tarefas devem ser consideradas sem a influência de elementos de interface, mas devem levar em conta o comportamento do usuário e do sistema ao longo do processo de utilização do produto. Isso pode ser feito por meio de qualquer esquema que permita o reconhecimento do fluxo de tarefa como mostra a Figura 11, e pode ser utilizada qualquer ferramenta que permita o desenho deste esquema. Existem, no entanto, algumas ferramentas que se propõe a facilitar este processo.
- A forma como acontece esta conversa.
- O conteúdo de uma conversa; e
A engenharia semiótica oferece uma visão mais detalhada do processo de design de forma que o designer tenha uma variedade maior de visões do usuários na utilização de algo. Ela difere do IHC pois abrange um enfoque maior da comunicação designer–sistema- usuário. Segundo Prates (2006) a modelagem de interação em engenharia semiótica permite prever a interação entre usuário e sistema a partir do que seria uma conversa predefinida pelo designer. Esta conversa é representa os possíveis passos do usuários e as possíveis respostas e processamentos do sistema. A modelagem da interação é a especificação de todas as possíveis conversas que os usuários poderão travar com o sistema. Dentre deste contexto deve ser modelado:
5. Modelagem do desempenho das tarefas
Figura 10 – Diagramas propostos por Pagani (2008) em modelo de documentação descomplicada
Pagani (2008) oferece uma forma de documentação rápida, prática e de fácil entendimento pelo desenvolvedor e cliente. Elabore uma macro-arquitetura de informação do sistema ou website com um diagrama da estrutura de navegação, faça os wireframes das telas e os diagramas estruturais. Naturalmente isso não pode ser feito sem uma conversa para entendimento das necessidades, mas acelera e simplifica o processo de documentação. Saiba mais em http://blog.talitapagani.com.
Considere o uso de diagramas estruturais para entender o escopo geral e, se houver tempo, explorar tarefas críticas. Muitas ferramentas ajudam na criação de diagramas para estruturar uma seqüência lógica de atividades em diferentes níveis de abstração (caneta e papel, MS-Visio, Axure, Morae, PowerMapper, Word, Open Office, etc). Detalhamentos podem ser gerados de acordo com o tempo disponível. Quanto mais detalhado mais claro se torna o processo que deverá ser desempenhado pelos diferentes atores do sistema.
As técnicas mais práticas baseiam-se em entrevistas, brasinstorms, prototipação, JAD e método JK.
1. Entrevistas: Dificilmente deixam de ser utilizadas, pois trata-se da forma mais natural de comunicação entre as pessoas. Mas embora pareçam simples elas exigem procedimentos mais específicos do que apenas perguntar. A técnica se torna mais eficaz quando é estruturada e quando a equipe passa a dominar o processo. Ajuda descobrir como o processo atual acontece e entender quais são as expectativas para o novo processo ou sistema. As perguntas podem ser feitas por um ou mais entrevistadores e podem ser divididas em 3 tipos:
- estruturadas – segue uma estrutura rígida e seqüencial.
- semi estruturadas – utiliza uma lista estruturada mas permite a ocorrências de questões extra ou são anotadas observações extra mencionadas pelo entrevista.
- não estruturadas – parte de um ponto estabelecido (ou não) e anda de acordo com a motivação do entrevistado.
2. Brainstorm: É bastante utilizada e conhecida, mas não envolve, necessariamente, o usuário. Ela serve para gerar idéias a partir de discussões realizadas por um conjunto de especialistas onde todos colaboram com as idéias de todos, com a liberdade que só a criatividade pode fornecer. Neste processo são feitas críticas e julgamentos. Esta técnica pode ser aplicada no início da fase do desenvolvimento quando pouco do projeto é conhecido e são necessárias idéias novas. Os resultados de uma sessão bem estabelecida contribuem com boas soluções para todas as questões exploradas.
3. Prototipação: Este processo é utilizado para detalhar requisitos de software definidos pelo cliente. Este técnica pode ser utilizada para avaliação ou verificação dos possíveis procedimentos de interação entre o homem e a máquina. O modelo permite ainda refinar os requisitos identificados na fase de concepção, sejam eles funcionais ou não.
4. Joint Application Design – JAD: Desenvolvida pela IBM no fim dos anos 70 esta técnica tem base na criação de sessões de trabalho estruturadas utilizando dinâmica de grupo e recursos visuais. Participam analistas e usuários para, juntos, projetarem um sistema com a compreensão adequada dos requisitos básicos e podendo chegar, inclusive, no desenvolvimento de leiaute de telas e relatórios. A idéia é manter a cooperação e o entendimento entre os participantes. O papel dos desenvolvedores é ajudar os usuários a formular problemas e explorá-los com o objetivo de indicar possíveis soluções. Os usuários se sentem parte integrante da equipe de desenvolvimento. O JAD é baseado em quatro princípios básicos:
- dinâmica de grupo com técnicas que possam aumentar a capacidade dos indivíduos;
- uso de técnicas audiovisuais para aumentar a comunicação e o entendimento;
- manutenção do processo organizado e racional; e
- utilização de documentação-padrão, que é preenchida e assinada por todos os participantes.
A técnica JAD tem duas grandes etapas: PLANEJAMENTO, cujo objetivo é elicitar e especificar requisitos; e PROJETO, em que se lida com o projeto do software. Os participantes de uma sessão de JAD desempenham seis diferentes papéis:
- líder da sessão;
- representantes do usuário;
- especialista;
- analista;
- representantes dos sistemas de informação; e
- patrocinador executivo.
A técnica ajuda a identificar os assuntos que podem necessitar de rastreamento e fornece uma perspectiva multifacetada dos requisitos. Sessões JAD permitem aos analistas coletar simultânea e eficientemente uma grande quantidade de requisitos do sistema junto a uma gama de usuários-chave. São úteis por considerar necessidades específicas dos usuários.
O JAD também pode ser usado em conjunto com outra técnica de elicitação como, por exemplo, a prototipação. À medida que os requisitos são obtidos nas sessões pode-se construir protótipos que demonstrem alguma funcionalidade destes requisitos.
5. Método KJ (Kawakita Jiro): É uma atividade que ajuda a realizar uma lista de requisitos por investigação contextual ou de afinidades onde a observação dos envolvidos ajuda a estabelecer e reunir prioridades para se chegar em um consenso de grupo. O método KJ foi desenvolvido pelo japonês Kawakita Jiro que buscava reduzir o tempo da realização da tarefa de elicitação de requisitos. Para elaborar o processo deve-se ter o foco claro em cada uma das rodada que estabelece o processo que se utiliza de uma pergunta. Os principais focos para o levantamento de necessidades costumam ser:
- quem é o seu público-alvo;
- quais tarefas ele deve estar apto a realizar ao final do programa de formação;
- o que este público já sabe;
- em quanto tempo estas pessoas devem formar o conhecimento; e
- quais sãos os recursos disponíveis para realizar este programa.
Uma equipe experiente consegue realizar duas rodadas por hora da dinâmica. Isso significa que em até 3 horas seria possível realizar a análise. É um processo de análise de necessidades com consenso em tempo recorde. Veja um exemplo do processo em Ideários.com (Lopez, 2006) para a elaboração de um programa de formação com KJ-Method.
Análise e negociação de requisitos
É onde os requisitos elicitados são compreendidos e detalhadamente analisados por todos os interessados no sistema (Blaschek, 2002). Esta atividade auxilia na descoberta de problemas nos requisitos levantados e na obtenção de concordância sobre as alterações. Como resultado a satisfação de todos os envolvidos deve ser atingida. Se na etapa anterior houve uma elicitação dos requisitos mais importante, nesta fase é necessário estabelecer um conjunto acordado de requisitos completos, consistentes e sem ambigüidades, que possa ser usado como base para o desenvolvimento do software.
Como resultado deve ser gerado um documento rascunho que será levado aos engenheiros e arquitetos de informação. Eles manipularão os requisitos de forma que possam agrupá-los de acordo com regras estabelecidas (funcionalidade, por exemplo), farão explorações e classificações que estabelecerão prioridades. Assim os requisitos são examinados em relação à sua necessidade, completeza, consistência, riscos, viabilidade técnica, operacional e econômica, bem como em busca de omissões, ambigüidades, sobreposições e conflitos.
Problemas e conflitos encontrados nos requisitos são ressaltados. Todos os indivíduos (stakeholders) classificam os requisitos com problemas e negociam até chegarem a um acordo sobre as modificações a serem feitas. Esta atividade pode ser direcionada por necessidades pré-estabelecidas, por requisitos específicos para os diferentes usuários, por restrições de projeto e de implementação e pelo orçamento e cronograma disponíveis.
Documentação de Requisitos
Requisitos compreendidos, analisados e aceitos. Agora é só documentar. A proposta de integração do processo associado ao projeto de interação ao UML ajuda a identificar o momento em que o projeto de interação deve ser realizado (Blaschek, 2002). É a representação dos resultados obtidos até agora, em um documento oficial e formal que contém os requisitos do software com descrições detalhadas sobre o que ele fará, mas ainda sem descrever como fazer o software em termos de tecnologia ou linguagem de programação a ser adotada, por exemplo. Esse documento deve estar correto, sem ambigüidades, completo, consistente, classificado por importância e/ou estabilidade dos requisitos, verificável, modificável e rastreável, além de ser entendível pelos usuários, organizado e conciso. Não há um nome padrão para esse documento, podendo ser adotado, dentre outros, “Especificação de Requisitos de Software (ERS)”, “Documento de Requisitos” ou “Especificação Funcional”.
Este documento descreve:
- o escopo e os objetivos do software;
- os serviços e as funções que o software deve fornecer;
- as informações sobre o domínio de aplicação do software;
- as restrições sob as quais o software deve operar;
- as propriedades gerais do software, tais como atributos de qualidade e desempenho;
- as definições de outros softwares com os quais deve interagir; e
- as restrições ao processo de desenvolvimento adotado.
Uma informações importante neste documento é indicar a fonte dos requisitos, seja uma pessoa, um grupo ou documento. Outras informações importantes são os problemas que se pretende resolver, além das razões e justificativas da escolha de cada solução ou decisão tomada, as demais alternativas consideradas, os fatores avaliados e as argumentações que guiaram cada decisão ou solução. Estes dados adicionais enriquecem a visão do software.
O documento pode ser descrito em linguagem natural, em notações e linguagens semi-formais ou formais. Combinações também são possíveis.
- A linguagem natural facilita a comunicação, pois é expressiva e flexível, mas é pobre para capturar as semânticas do modelo, possibilita ambigüidades. Permite um fácil entendimento pelos usuários, mas a ausência de semântica possibilita a livre interpretação.
- Uma notação semi-formal reflete a estrutura e utiliza semântica com alguma verificação de consistência – é o caso da UML (Unified Modeling Language) com diagramas e relacionamentos.
- Os métodos formais descrevem artefatos de software de forma difícil de compreensão e, por isso, requerem maior tempo de aprendizado, pois não são legíveis para usuários não técnicos.
Não existe um limite claro entre a engenharia de requisitos e o início da fase de projeto do software dando margem ao dilema “o que” versus “como”. Os requisitos são obtidos na engenharia de requisitos (“o que”) ao passo em que são organizados, agrupados e documentados na hierarquia proposta para o projeto de arquitetura (“como”), de forma a organizar uma estrutura de sub-sistemas para o projeto.
Algumas diretrizes propostas ajudam a melhorar a estrutura e organização do documento:
- definir uma estrutura padrão para o documento, contendo, em geral, uma parte comum, mas permitindo algumas variantes e seções opcionais;
- explicar como cada classe de leitores deve usar o documento;
- incluir um sumário de requisitos;
- incluir uma seção explicando por que o software é necessário e como irá contribuir para os objetivos gerais de negócio da organização;
- definir termos especializados em um glossário;
- organizar o leiaute do documento para facilitar a leitura;
- auxiliar os leitores a encontrar a informação, incluindo recursos tais como listas de conteúdo e índices e organizando os requisitos em capítulos, seções e sub-seções identificadas; e
- tornar o documento fácil de alterar.
Validação de Requisitos
Depois de documentados os requisitos devem ser validados quanto à consistência e à completude. Fase ideal para a correção de erros antes do desenvolvimento (Blaschek, 2002). Validar significa avaliar o software durante ou ao final do processo de desenvolvimento. O objetivo é verificar se o resultado satisfaz o usuário, se foram solucionadas todas as demandas e se existem falhas. A validação se cumpre quando os requisitos e modelos documentados atendem às reais necessidades e requisitos dos usuários. A meta é garantir que este documento possa ser aprovado antes de ser usado como base para o desenvolvimento do software.
A verificação ou validação é executada por clientes, usuários, especialistas de domínio, engenheiros de requisitos, gerentes do projeto, projetistas do software e pelos gerentes de testes. Processos como o modelo CMM – Capability Maturity Model e o padrão ISO/IEC TR 15504 podem ajudar na verificação e a validação contribuindo inclusive com a garantia de qualidade do software.
Várias técnicas complementares de verificação e validação dos requisitos têm sido propostas, tais como análise dos requisitos, revisão técnica formal, análise de rastreabilidade, prototipação, validação, ou não, de modelos automática, inspeção, testes de requisitos e planejamento inicial do teste do software.
Apesar das atividades de análise de requisitos e validação de requisitos serem abordadas em separado, elas têm muito em comum, pois envolvem julgar se as necessidades dos usuários estão descritas de forma apropriada e se estão sendo verificados os problemas nos requisitos. Ambas podem ser executadas em paralelo, mas existem diferenças importantes entre elas. A análise de requisitos preocupa-se em investigar os requisitos elicitados junto aos usuários e ainda não discutidos com eles, que muitas vezes estão incompletos e expressos de forma não estruturada e informal. A validação de requisitos deve ter, idealmente, um conjunto completo e acordado de requisitos como ponto de partida.
Na Engenharia de Requisitos, a validação leva a uma revisão e aprovação da documentação por todos os envolvidos no processo, que se torna um contrato de desenvolvimento de software. Mudanças de requisitos solicitadas depois que a documentação estiver aprovada poderão ser consideradas. No entanto, o cliente deve estar ciente de que cada mudança posterior pode ser uma extensão do escopo do software e, por conseguinte, pode aumentar o custo e/ou alongar o prazo de entrega.
Gerência de Requisitos
Freqüentemente usuários e especialistas propõem mudanças nos requisitos, resultantes de fatores como a descoberta de erros, omissões, conflitos e inconsistências nos requisitos, melhor entendimento por parte dos usuários de suas necessidades, entre outros. Isso pode originar novos requisitos, problemas técnicos, de cronograma ou de custo, mudança nas prioridades do cliente devido a mudanças no ambiente de negócios, o aparecimento de novos competidores, mudanças econômicas, mudanças na equipe, mudanças no ambiente onde o software será instalado e, ainda, mudanças organizacionais ou legais.
Essas solicitações de mudanças podem surgir durante o processo de engenharia de requisitos, ao longo do processo de software ou, ainda, após a implantação do produto de software. Diante deste cenário destaca-se a atividade de gerência de requisitos.
A gerência de requisitos apóia as demais atividades abordadas e se preocupa em gerenciar as mudanças nos requisitos já acordados.
Outra atividade associada é a manutenção de uma trilha de mudanças identificando o gerenciamento dos relacionamentos entre os requisitos e as dependências entre o documento de requisitos e demais artefatos produzidos.
Existe uma preocupação com os procedimentos, processos e padrões a serem usados para gerenciar as mudanças. Ela deve permitir o registro das solicitações de mudança e a identificação dos requisitos afetados pela mudança solicitada, além de avaliar o impacto das mudanças, os riscos, os custos e benefícios, os recursos e alterações no cronograma, obter a aprovação dos clientes e, então, documentar, projetar e implementar a mudança.
Se as mudanças não forem controladas, alterações com baixa prioridade podem ser implementadas antes de outras de alta prioridade e modificações com custo alto, que não são realmente necessárias, podem ser aprovadas. A rastreabilidade também é importante, pois garante descrições da vida de um requisito por todo o ciclo de vida de desenvolvimento do software.
(2) Projetos alternativos
Projetistas de interação não costumam ser treinados para criar projetos alternativos. O resultado é que poucas soluções alternativas são geradas. Ter muitas idéias e gerar opções diversas para poder então extrair uma boa idéia é uma prática que deveria ser mais comum dentro das equipes de desenvolvimento. Isto pode ser feito em diferentes etapas do processo de criação ou geração de soluções.
Reuniões de Brainstorms, por exemplo, contribuem para o levantamento de requisitos, mas também oferecem idéias alternativas de interação no início do projeto. Existem outras forma de manter esta prática em outros pontos do desenvolvimento do projeto. Técnicas emprestadas de outras áreas podem ajudar, como por exemplo, os aspectos do design tradicional que ajudam em situações já estabelecidas de compreensão e entendimento do produto.
Mas tudo isso precisa ser comunicado, afinal foi gerado um plano que deverá ser expresso de forma que permita ser revisto, revisado e melhorado. Este plano utilizará formas diversas de apresentação, tais como esboços preliminares, diagramas, protótipos, entre outros. A combinação de técnicas será mais efetiva na comunicação. Outros dois aspectos importantes na comunicação do plano é o cuidado no uso de jargões e notações técnicas e a qualidade da redação dos documentos.
Escolher um design alternativo implica tomar decisões acerca dos procedimentos de interação pensados e dos dispositivos para entrada e saída de dados, além do formato da informação. Além disso devem ser considerados o fácil acesso, a eficiência no uso, o retorno adequado, o tempo de resposta, a qualidade e quantidade de informação. Qualidade pode ser a chave para a escolha do melhor protótipo, mas isso depende da definição do critério de qualidade que precisa ser estabelecido.
Produzir projetos alternativos depende do pré-requisito sobre a compreensão das necessidades, dos usuários e das tecnologias disponíveis para elaborar soluções e determinar as melhores soluções dentre as diversas alternativas. Os protótipos de projetos alternativos podem ser não funcionais ou funcionais, mais ou menos elaborados e devem ser desenvolvidos por meio de wireframes, mockups de telas e protótipos de papel para testes iniciais com o usuário.
(3) Versões interativas
Embora protótipos não funcionais ofereçam uma boa idéia do comportamento dos procedimentos de interação, são as versões interativas que fornecerão uma sensação mais realística do processo. A escolha do protótipo dependerá do tempo e orçamento destinado ao projeto. O importante é que existam formas de comunicar os processos e condições para poder analisá-los como se fossem o produto final.
O protótipo de papel é uma solução de baixa fidelidade, mas barata e simples de ser realizada também nesta etapa. Ela ajuda a verificar as condições de interação do sistema com desenhos simples das telas e dos processos.
(4) Avaliação
No processo de avaliação centrada no usuário é dito que o usuário se torna o co-designer do projeto. Sua participação normalmente aponta alterações de melhoria nos sistemas, mas este envolvimento pode acontecer ao longo de todo o desenvolvimento do projeto com participações do usuário. Ele é envolvido em processos de observação, conversas, entrevistas, mas o objetivo é sempre testar o sistema e seus processos de interação – e não o usuário. Falaremos mais sobre isso nos últimos capítulos onde veremos técnicas e procedimentos adequados à esta atividade. Projetos alternativos são utilizados nas primeiras avaliações e também podem utilizar usuários. Independente do formato da avaliação a qualidade do protótipo direciona os objetivos da avaliação conforme abordagens de baixa, média e alta fidelidade (Reis, 2004).
MAS NÃO TEMOS TEMPO DE DOCUMENTAR!
Em projetos em que o cronograma é definido com data de entrega “para ontem”, qualquer atividade de projeto e documentação acaba sendo prejudicada. Os procedimentos mínimos para a elaboração de documentos exigem tempo, principalmente as atividades de entrevistas e ajustes. Mas pelo menos a regra de negócio precisa estar claramente estabelecida.
Bom! A fórmula da solução rápida NÃO EXISTE! A entrevista e/ou outra abordagem de reconhecimento do processo do negócio e das condições de envolvimento dos usuários são de extrema necessidade. Se isso não puder ser feito por uma equipe alocada par este fim, utilize qualquer outro recurso para entender a atividade, o processo e seus usuários. A resolução do problema poderá não ser a ideal, mas os problemas decorrentes poderão ser minimizados para o usuário e cliente do produto.
Como fazer isso então? Tente criar estratégias rápida de definição de processos de interação por meio de entrevistas rápidas com o cliente e, se possível, com algum usuário representativo. A documentação pode acontecer de forma não estruturada durante as entrevistas. Uma dica é fazer o maior número de questionamentos possível para não errar na hora do desenvolvimento. DOCUMENTE O MÁXIMO QUE PUDER, mas OBJETIVE O MÍNIMO para viabilizar a CONSTRUÇÃO DE TELAS.
Uma boa opção para um projeto com prazo apertado é tocar as atividades de projetos alternativos em paralelo. Assim, alguns wireframes, ou mesmo telas, podem ser iniciadas para colaborar na construção de uma documentação. As telas poderão apresentar o produto na forma de um protótipo não funcional antes da implementação – e das decisões tomadas por programadores (preservadas as exceções, programadores costumam tomar decisões voltadas à estrutura da programação e seus bancos de dados, desconsiderando usuários e processos de interação usáveis). Protótipos só são possíveis após o levantamento de requisitos. Mas se o cenário exigir, tente viabilizar os passos 1 (Necessidades) e 2 (projetos alternativos) em paralelo.
Nenhum comentário:
Postar um comentário