Casos de uso, use cases, conceitos criados por Ivar Jacobson em 1986, são textos ou diagramas que descrevem e justificam as tarefas a realizar em uma plataforma ou sistema através das interações com seus usuários. Criados a partir de estruturas previamente definidas, são utilizados para identificar, registrar, organizar e avaliar interações em sequência de um sistema para os desenvolvedores. São elaborados a partir da análise das pesquisas de usuários e levam à criação de soluções funcionais objetivas.
O “cadastro em um sistema”, o “login em uma plataforma”, “um pedido online de informação”, “o fechamento de uma compra”, podem ser descritos tecnicamente com casos de uso interligados, relacionados a um sistema de comércio online.
A finalidade principal dos casos de uso é capturar o comportamento de um sistema sob o ponto de vista do usuário final, para que ele/a faça o que precisa fazer. São muito úteis em projetos de ferramentas novas ou de sistemas cujo modo de funcionamento não seja bem conhecido pela equipe.
O uso de um programa de e-mail ou de atualização de um blog, por exemplo, não precisa ser descrito para que os desenvolvedores implementem as funcionalidades, a não ser suas especificidades. O uso de uma rede social por professores de uma determinada escola pode precisar ser descrito por apresentar características únicas.
A Johnson & Johnson realizou um estudo sobre o comportamento dos usuários de suas plataformas digitais e criou um grupo com formação em desenvolvimento de produtos que traduz os requisitos de negócios em especificações técnicas. Eles têm a responsabilidade não apenas da criação e do desenvolvimento, como da medida e da avaliação dos resultados dos projetos.
A gestão e o acompanhamento destes mesmos produtos ao longo do tempo se mantém constante, sem a perspectiva de que, depois de lançados, perdem o foco para outros produtos em desenvolvimento. Assim, depois do lançamento de um app, os comportamentos dos usuários são acompanhados e é avaliado se suas expectativas são alcançadas. De modo, os produtos são continuamente aperfeiçoados. (1)
O projeto de sistemas complexos envolve a identificação e documentação de vários casos de uso, cada um relacionado a um segmento do que o software deverá contemplar.
Casos de uso e stakeholders
Durante um projeto de mídia digital, a equipe pode recorrer a casos de uso para analisar, entender e estabelecer consenso sobre o funcionamento de uma plataforma ou sistema. Alguns segmentos de stakeholders se beneficiam especialmente destas narrativas:
■ Em projetos ágeis, os “donos dos produtos” os utilizam para obter a aprovação da equipe sobre o funcionamento do sistema.
■ Os gerentes de projeto ou de produto os utilizam para planejar e avaliar o trabalho necessário a cada iteração.
■ Os arquitetos da informação identificam, através deles, os fluxos e encadeamentos necessários à realização das ações.
■ Os desenvolvedores os consultam para compreender o passo a passo das ações do sistema. A maioria está acostumada a estas ferramentas, por isso pode compreendê-las facilmente.
■ Especialistas em testes de usabilidade os utilizam como base para identificar as funcionalidades a serem verificar.
■ A equipe de marketing recorre aos casos de uso para se comunicar com a equipe técnica quando se refere a uma situação de uso.
Modelo de caso de uso
Casos de uso podem ter mais ou menos elementos, de acordo com a natureza e extensão do produto. De modo geral, constam de:
Título/nome – Um resumo identificador para documentos ou conversas. O título de um caso de uso de customização de uma ferramenta de busca para acessar um banco de dados pode ser “Ferramenta de busca interna”.
Atores – Agentes (humanos ou máquinas) que vão realizar as ações. Os atores descritos podem ser apenas humanos ou apenas máquinas. No exemplo do sistema de buscas, os agentes são as pessoas que buscam, o sistema que responde e os profissionais que inserem dados no sistema. Os agentes são identificados por suas funções, não por nomes de pessoa ou máquinas.
Objetivo – O que o caso de uso procura alcançar. No exemplo citado, como os usuários vão encontrar o que buscam.
Detonadores (triggers)– Eventos que disparam o começo do use case, como a usuária verificar que precisa fazer uma busca.
Condições iniciais – O que acontece quando o usuário começa a usar o sistema. No caso da busca, seria o acesso do usuário ao campo de busca.
Condições finais – O que acontece ao final do caso de uso. O usuário da ferramenta de busca achou o que procurava? Se não achou, o que ela deve fazer? O que o sistema deve fazer?
Principais etapas (fluxo básico) – Passo a passo das ações a realizar, com descrição detalhada de cada uma. No caso de uso da ferramenta de busca, as etapas podem ser:
■ A autora da busca abre o site/app de busca na tela do dispositivo
■ Ela precisa de uma informação (motivação) e digita uma palavra-chave relacionada no campo de busca (usabilidade)
■ Sistema verifica informações que aceita da pesquisa
■ Sistema compara informações com os arquivos indexados em bancos de dados
■ Sistema gera lista com os resultados encontrados
■ Sistema registra busca em sistema de estatísticas de uso e atualiza algoritmo
■ A autora da busca verifica se os resultados são satisfatórios (motivação). Em caso afirmativo, seleciona uma informação ou link (o valor aparente da busca). Em caso negativo, faz nova busca, desiste da busca (algo deve ser melhorado para atender à demanda?), ou vai procurar em outra fonte.
■ (Como saber se funcionou?) Sistema verifica o grau de satisfação com a avaliação do tempo entre buscas, pela não realização de segunda busca, pela seleção de um link pela usuária
Os autores destas descrições localizadas evitam usar termos técnicos, preferindo a linguagem do usuário final e suas perspectivas/modelos mentais no momento do uso.
Exceções – Situações em que o use case não funcionaria, como quando o usuário não dispõe de acesso a um programa ou dispositivo para realizar a busca, ou não está online. Ou situações em que a busca não retorna resultados.
Fluxos alternativos – Outros casos de uso relacionados à mesma funcionalidade. No caso da busca, o uso de filtros de informações ou a inserção de um link de “Busca avançada”, por exemplo, ou a seleção de um link patrocinado.
Casos de uso relacionados – Outras funcionalidades mais restritas (“filhotes”) que podem estar interligadas à principal.
Como os dados podem estar organizados no banco de dados para retornar os resultados esperados a uma busca? Como é feita a entrada e a atualização de dados no sistema?
Qualidades – especificações ideais, a alcançar. Podem ser requisitos contextuais, como as condições físicas de acesso pelo usuário numa determinada ocasião ou circunstância de uso. Ou requisitos funcionais, como o tempo de processamento da busca, ou o fato da usuária ter selecionado alguns dos resultados.
Os elementos podem variar de projeto a projeto, e incluir também fluxos alternativos, conexões com outros casos de uso.
Limitações
Como qualquer metodologia, casos de uso não são perfeitos e devem ser aplicados a partir de visões mais amplas, obtidas a partir das pesquisas com usuários, pois reforçam pontos de vista técnicos, não enfocando fatores subjetivos ou culturais que afetam o uso do produto.
Outro fator que dificulta o emprego de casos de uso é que muitas vezes o modelo adotado não inclui aspectos relacionados à descrição, e o caso de uso se mostra falho no final do projeto. É sempre importante lembrar que são feitos por pessoas, cujas escolhas, preferências e interpretações influenciam o resultado.
Há também um limitador operacional: a criação de casos de uso, especialmente de sistemas e plataformas muito grandes, pode consumir muito tempo do projeto, e nesse caso devem ser incorporados ao desenvolvimento do produto em si (e não a processos sem comprometimento com o produto final). Em projetos com prazos apertados, pode ser mais indicado criar resumos descritivos menos rigorosos e mais genéricos, como cenários, e gerar os casos de uso a partir daí.
(Texto publicado em 22.1.2012. Atualizado em 10.3.2017)
Referências
→ Use Case Examples – Effective Samples and Tips, Darren Levy (gatherspace, acesso em 24.1.2017)
1) Developing a global digital strategy, Gail Horwood (McKinsey, acesso em 19.10.2014)
→ Livro: Communicating Design: Developing website documentation for design and planning, Dan M. Brown. Berkeley: New Riders, 2007
→ Promise, vision, scenario, and user stories, Jared M. Spool (User Interface Engeneering, acesso em 2.10.2014)
→ Use of narrative in interactive design (Boxes and Arrows, acesso em 30.11.2004, não mais disponível no endereço acessado)
→ Livro: Storytelling for user experience – crafting stories for better design, Whitney Quesenbery e Kevin Brooks. New York: Rosenfeld Media, 2010