No post anterior, “User eXperience e Requisitos de Qualidade: olhando daqui pra lá …”, conversamos sobre as características e subcacarterísticas da Norma ISO 25000, que trata dos requisitos de qualidade de software, e não os referencia mais como requisitos não funcionais.
Observamos que várias dessas classificações tratam de conceitos coincidentes com o que esperamos de um software para se atingir a melhor experiência no seu uso.
Essas definições, agora vistas “de lá pra cá…”, ou pelos olhos do UX – Experiência do Usuário, se forem avaliadas como aderentes à prática de se buscar a melhor experiência possível centrada no usuário, pode fornecer subsídios importantes para o profissional de Requisitos, e “estreitar” o distanciamento entre esses segmentos.
Recapitulando, como já citamos as palavras de Fabrício Teixeira, UX Designer (https://brasil.uxdesign.cc/), quando você usa algum objeto, você tem uma experiência. “Se você já passou nervoso na frente do caixa eletrônico porque ele não entregou o dinheiro que você estava esperando e não deu nenhuma explicação sensata sobre o motivo da recusa, você possivelmente teve uma péssima experiência enquanto usuário do caixa eletrônico”. Não queremos isso para os nossos produtos de software, também.
Voltando a figura que contempla todas essas características e subcaracterísticas da Norma, fiz uma pequena enquete com meus colegas (se quisermos uma pesquisa mais fundamentada, precisaremos formalizar e expandir essas questões…), e identificamos conceitos que representam os objetivos gerais de UX.
Para não ficar muito chato (mas vai ficar um pouquinho…), relacionei abaixo uma descrição dessas características e subcaracterísticas sinalizadas na figura. Leia com atenção (é rápido…).
Adequação funcional – produto ou sistema deve fornecer funções que correspondam as necessidades explicitas e implícitas.
- Completude funcional – refere-se a um conjunto de funcionalidades que deve abranger todas as tarefas e objetivos específicos dos seus usuários. : funções e operações devem funcionar conforme especificado nos manuais do usuário ou requisitos especificação; Funções e operações devem fornecer um resultado razoável e aceitável para alcançar o objetivo específico pretendido da tarefa.
- Correção ou exatidão funcional – sistema deve fornecer os resultados corretos com o grau de precisão necessário. : evitar resultado incorreto ou impreciso causado por dados inadequados; evitar dados com poucos dígitos para cálculo preciso; manter a consistência entre os procedimentos atuais de operação e os descritos no manual de operação; evitar diferenças entre os resultados esperados reais e razoáveis das tarefas executadas.
- Adequação funcional – as funções devem facilitar a realização de tarefas para atender os objetivos específicos. : apresentação ao usuário das etapas necessárias para concluir uma tarefa, excluindo as etapas desnecessárias.
Usabilidade – um produto ou sistema deve ser usado por um usuário específico para o alcance de metas específicas com eficácia, eficiência e satisfação em um contexto de uso determinado.
- Acessibilidade – O sistema inclui facilidades de acesso para usuários com necessidades físicas especiais ou por idade. Ex.: o sistema deve possibilitar a que pessoas com deficiências visuais acessem com eficiência.
- Apreensibilidade – relaciona-se à Aprendizagem, o sistema permite ao usuário aprender a usá-lo com eficácia, eficiência em situações de emergência. O sistema disponibiliza manuais, tutoriais, documentação para treinamento e acesso a dados e/ou help on-line Ex.: Documentação de fácil uso e entendimento.
- Estética da interface do usuário – estabelece que a interface de usuário deve permitir uma interação agradável e satisfatória para o usuário. Ex.: layouts leves e responsivos.
- Operabilidade – produto ou sistema possui atributos que o tornam fácil de operar e controlar. Ex.: a navegação pelo sistema é rápida; o sistema oferece feedback adequado ao usuário para as tarefas que são executadas; o software permite adaptações para atender a necessidades locais/específicas, pelo próprio usuário.
- Proteção contra erro – o software contribui para que erros sejam evitados e tratados durante sua utilização, grau em que um produto ou sistema protege os usuários contra erros. Ex.: é simples, fácil e seguro corrigir um erro (reversibilidade); o sistema implementa a verificação de valores válidos em entradas de dados ; o sistema evita operações incorretas.
- Reconhecimento apropriado – O usuário consegue identificar um modelo de processo de software adequado aos seus objetivos. Avaliar o grau em que os usuários conseguem compreender se um modelo de processo de software é apropriado para suas necessidades ou não. Ex.: o sistema deve ser adequado aos processos de negócio do usuário.
Confiabilidade – um sistema, produto ou componente executa funções específicas sob condições determinadas em um dado período de tempo, de forma confiável, apresentando situações de erro controladas e reversíveis.
- Maturidade – relaciona-se a quantidade de erros que o sistema apresenta em operação. Ex.: o sistema deve apresentar durante determinado período percentual inferior a um percentual de erros considerando uma quantidade de transações efetuadas.
- Disponibilidade – estabelece o tempo que o produto ou componente está operacional e acessível quando necessário para uso. Ex.: tempo total durante o qual o sistema, produto ou componente está em um estado ativo, 24 por 7, etc.
O que você acha? Está de acordo? Concorda que essas definições remetem ao que compreendemos por atingir “a melhor experiência do usuário”?
E tudo isso pra quê?
Para demonstrar que a aplicação do conceito de UX aos nossos produtos de software é possível e pode ser feita com bases formais da Engenharia de Requisitos. E, tratados como Requisitos de Qualidade, as diretrizes de UX podem ser alcançadas pelos processos envolvidos de produção, documentação e validação de requisitos, como os funcionais, por exemplo.
Assim, ao “formalizar” esse alinhamento da Engenharia de Requisitos com o que é preconizado pelo UX, podemos modelar o comportamento de usuários e mapear suas reais necessidades e anseios.
Agora, como vamos identificar esses requisitos de qualidade, que técnicas, que ferramentas podemos usar, isso é outra conversa. Uma coisa é clara… O Analista de Requisitos necessita desenvolver uma postura e uma prática cada vez mais “empática” neste processo.
Até breve.
Fernando Guimarães é coordenador e professor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Centro Universitário de Brasília – UniCEUB. Também é professor do Curso de Pós-graduação Lato Sensu em Engenharia de Requisitos do UniCEUB, nas modalidades presencial e a distância. Graduado em Engenharia Elétrica, com especialização Eletrônica, pela UnB – Universidade de Brasília, fez especialização em Análise de Sistemas na UCB – Universidade Católica de Brasília. Possui Mestrado em Gestão do Conhecimento e da Tecnologia da Informação pela UCB – Universidade Católica de Brasília. Possui Certificação PMP – Project Management Professional, pelo PMI – Project Management Institute e Certificação CBPP – Certified Business Process Professional, pela ABPMP – The Association of Business Process Management Professionals. Toda a atividade profissional exercida foi em Projetos de Desenvolvimento de Software e em consultoria em Gerenciamento de Processos de Negócios.
Endereço do Currículo Lattes: http://lattes.cnpq.br/5724480423308682
Endereço no Linkedin: https://www.linkedin.com/in/fernando-de-albuquerque-guimarães-msc-pmp-cbpp-78924423/