Vamos voltar a um tema já tratado aqui, mas com uma outra visão: UX e o que isso tem a ver com Requisitos de Software de uma forma geral.
Esse tema vem sendo aprofundado em nosso Grupo de Pesquisas (sim, ele existe: http://dgp.cnpq.br/dgp/espelhogrupo/345015) e nos Workshops que promovemos, mais especificamente, o Triplo UX e o Fator UX: Engenharia Empática de Requisitos.
Já conversamos que UX não é uma metodologia, não é um método, não é uma receita de bolo. É simplesmente (???), a denominação da relação ou interação de uma determinada pessoa com um produto ou um serviço. E sabemos, também, que essa relação – “essa experiência” – pode ser boa ou não. Ou melhor, o “uso” deste produto ou serviço pode ser positivo ou negativo.
Existem várias técnicas e métodos que mapeiam a experiência do usuário, fornecendo subsídios para que os produtos de software sejam mais fáceis de usar, intuitivos, traduzindo a sua utilização em uma experiência realmente positiva para o usuário.
Tudo certo até aqui, ok?
Entretanto, percebemos um grande gap entre o que é formalizado pela Engenharia de Requisitos e tudo que se tem falado sobre UX. Identificamos uma “lacuna teórica” que possa oferecer subsídios mais formais para os processos de produção, documentação (essa é uma outra discussão mais à frente… e só para deixar uma pulguinha atrás da orelha, código “documentado” é documentação, tá?), e validação desses requisitos centrados no usuário.
Então, vamos começar falando “daqui pra lá…”, ou, sobre requisitos de qualidade.
Para manter a formalidade, começamos pela ISO 25000 (conhece?). As normas da série ISO/IEC 25000 trazem uma estrutura para a aplicação, controle e avaliação da qualidade do software. São denominadas System and Software Quality Requirements and Evaluation (SQuaRE). Elas realizam uma junção e evolução das regras vigentes nas ISO/IEC 9126 e 14598, descontinuadas após a publicação desta série. As SQuaRE não apresentam a terminologia “requisito não funcional” (agora, lascou…). De acordo com a divisão ISO 25030, os requisitos de um produto de software se classificam em requisitos inerentes e requisitos atribuídos (preço, data de entrega, etc). Os requisitos inerentes, esses sim, são divididos em requisitos funcionais e requisitos de qualidade. Pronto, temos agora um motivo para esquecer de vez essa denominação (“não funcional”) para uma outra, a meu ver, mais adequada: QUALIDADE.
Os requisitos de qualidade de software, por sua vez, incluem requisitos de qualidade em uso, requisitos de qualidade externa e requisitos de qualidade interna.
Simplificando, a norma da divisão 25010 define que a qualidade dos produtos deve seguir o modelo formado por oito características: Adequação Funcional, Performance Eficiente, Compatibilidade, Usabilidade, Confiabilidade, Segurança, Manutenibilidade e Portabilidade.
Esquentou um pouco a cachola? Vamos tentar resumir…
A nova Norma da ISO, a 25000, prevê requisitos inerente ao produto como classificados em requisitos FUNCIONAIS e de QUALIDADE. E são 8 as características que agrupam os requisitos de Qualidade. Cada uma das 8 características está dividida em várias subcaracterísticas. Só isso.
Se você observar algumas dessas subcaracterísticas, vai encontrar conceitos absolutamente coincidentes com o que almejamos se desejamos obter a melhor experiência do usuário em nossos produtos de software. Observe as características de Adequação Funcional, Performance Eficiente e Usabilidade. Isso não tem um cheirinho de UX?…
Vamos continuar esse assunto no próximo bate-papo, com a avaliação mais detalhada dessas subcaracterísticas, quando observadas de lá pra cá (ah, agora entendi…), ou pelos olhos da Experiência do Usuário. Será que tudo que precisamos descobrir, modelar, validar e finalmente implementar estão consideradas neste agrupamento?
Se conseguirmos identificar essa correlação, podemos “formalizar” um alinhamento da Engenharia de Requisitos com o que é preconizado pelo UX, para modelar o comportamento de usuários e mapear suas reais necessidades e anseios.
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/