ARQUITETURA

DE SISTEMAS

Diego Bittencourt de Oliveira

Projeto da interface de uma
arquitetura de sistemas
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Determinar os aspectos a serem considerados no projeto de uma

interface.
 Identificar o usuário, as tarefas e os requisitos do ambiente.
 Descrever as etapas do projeto de uma interface.

Introdução
Neste capítulo, você vai compreender a importância de uma interface
bem projetada, em que a interação homem–máquina ocorre de ma-
neira transparente, em ritmo cadenciado, permitindo que as tarefas
sejam concluídas de maneira tranquila. Verá também que uma interface
construída de forma errônea, em que o usuário se depara com um
problema atrás do outro, resulta em frustração e baixo rendimento
no trabalho.
Nesse sentido, você vai identificar os requisitos para o projeto
de uma interface, com base na identificação dos usuários, de suas
tarefas e dos requisitos do ambiente no qual eles estão inseridos.
Dessa forma, pode-se propor uma interface eficaz, que propicie uma
interação homem–máquina que aumente a satisfação e o rendimento
do usuário no exercício de suas funções. Ainda, neste capítulo, serão
abordadas as etapas que o projeto de uma interface deve conter para
garantir o sucesso no ambiente em que será inserida.
2 Projeto da interface de uma arquitetura de sistemas

Aspectos a serem considerados

no projeto de uma interface
Em interfaces de interação homem–máquina, existem três regras básicas:

1. Deixar o usuário no comando — Pressman e Maxim (2016) relatam

que muitos projetistas tendem a simplificar as interfaces, introduzindo
limitações e restrições que acabam por frustrar o usuário. Os resultados
dessa simplificação são interfaces simples de serem construídas, mas
limitadas do ponto de vista do usuário. Para evitar quebrar a regra de
permitir ao usuário estar no comando, existem alguns aspectos que de-
vem ser seguidos no projeto de uma interface, conforme listado a seguir.
■ Não force o usuário a realizar ações desnecessárias: um exemplo
disso seria o usuário acessar um documento, entrar no modo de edição
e não possuir a opção para voltar ao estado anterior. Ou seja, o usuário
deve poder entrar em modo de edição e sair quando bem entender.
■ A interação deve ser flexível: usuários possuem necessidades dife-
rentes uns dos outros. Por exemplo, um desenhista teria dificuldades
para confeccionar uma figura por meio de comandos de voz, assim
como não seria prático para um editor escrever um texto com a
caneta digitalizadora.
■ Deve ser possível interromper e desfazer interações: um usuário
deve poder pausar uma determinada interação, realizar outra tarefa e
não perder o trabalho da primeira, possibilitando, assim, a retomada
dessa interação para concluir a mesma; ele também deve ser capaz
de desfazer uma ação, se julgar necessário.
■ Permita a criação de macros: ao realizar tarefas iguais e de forma
repetitiva, um usuário tende a se desmotivar. Macros podem ajudar
o usuário a sanar esse problema, fazendo com que ele se sinta — e
realmente seja — mais produtivo.
■ A interação deve ser direta com objetos que apareçam na tela: por
exemplo, esticar uma imagem é uma implementação de manipulação
direta que dá ao usuário a sensação de controle, por ser uma ação
similar à que ele realizaria com o objeto físico.
2. A carga de memória do usuário deve ser reduzida — Pressman e
Maxim (2016) apontam que, quanto mais dependente da memória do
usuário um sistema é, mais suscetível a erros ele se torna. Sendo assim,
o sistema deve se encarregar de evidenciar fatos históricos que auxiliem
o usuário na execução de uma determinada tarefa.
 Projeto da interface de uma arquitetura de sistemas 3

■ Reduza ou não demande memória recente: um exemplo é quando

os resultados de interações anteriores são necessários para a ação
atual; esses resultados devem ser exibidos no sistema, e não memo-
rizados pelo usuário.
■ Estabeleça padrões: o usuário deve ser capaz de restaurar os parâ-
metros de uma interface para o seu estado original; essa ação pode
ser realizada por meio de um simples botão.
■ Os atalhos devem ser intuitivos: Ctrl + C é um famoso exemplo
desse tipo de atalho intuitivo; o atalho é formado por uma tecla de
controle e uma tecla com a letra inicial do comando — nesse caso,
o comando copiar.
3. Torne a interface consistente — segundo Pressman e Maxim (2016),
toda a aplicação deve seguir o mesmo padrão. Por exemplo, se, em um
conjunto de interações, o comando de copiar é Ctrl + C, ele não pode
ser alterado para Alt + S em outro conjunto de interações. Esses padrões
devem ser globais para a aplicação; caso contrário, vão confundir o
usuário, frustrando-o.

Todos os conceitos apontados até o momento podem ser considerados básicos,

mas de suma importância para o sucesso de uma aplicação. Pressman e Maxim
(2016) relatam que a análise e o projeto de uma interface de usuário partem do
desenvolvimento de diversos modelos, que visam criar uma percepção do mundo
externo. O primeiro passo é definir quais são as tarefas que giram em torno da
interação humana, que é vital para a execução das funções do sistema. Depois
disso, inicia-se a prototipagem dessas interfaces, seguida do desenvolvimento
de um modelo de projeto para a validação junto aos usuários finais.
Basicamente, são utilizados quatro modelos para realizar a análise de uma
interface. O modelo de usuário e o modelo de projeto são desenvolvidos por
um engenheiro de software; o usuário final cria um modelo mental, que reflete
sua percepção do sistema, e o desenvolvedor cria o modelo de implementação.
Muitas vezes, esses quatro modelos podem diferir entre si, cabendo ao desen-
volvedor conciliar essas diferenças, criando uma representação consistente
com base nesses modelos.
O modelo de usuário, em suma, estabelece o perfil dos usuários finais do
sistema, realizando um levantamento de suas características (por exemplo,
idade, gênero, níveis de educação, dentre outros). Em sua maioria, os profis-
sionais da equipe de projeto estão empenhados em satisfazer os usuários, e
esse modelo ajuda na percepção de quem verdadeiramente são esses usuários,
conforme relata Pressman e Maxim (2016).
4 Projeto da interface de uma arquitetura de sistemas

A seguir, no Quadro 1, é possível observar um exemplo de modelo de

usuário, em que temos algumas informações sobre os mesmos, como a quan-
tidade de funcionários no setor, sua faixa de idade, tempo médio de trabalho
na empresa, etc. A partir dessas informações, é possível identificar que os
funcionários do setor de compras possuem um bom tempo de casa e, talvez,
sejam os que possuem maior domínio de suas funções dentro da empresa.

Quadro 1. Modelo de usuário

Nível de Tempo
Número de Faixa de
Setor educação médio na
funcionários idade
predominante empresa

Vendas 22 24-31 anos Técnico 2,5 anos

Compras 2 29-38 anos Superior 8 anos

Direção 1 48 anos Superior 18 anos

O modelo mental é uma imagem do sistema delineada na mente dos usuá-

rios. Dependendo do nível de conhecimento do usuário, essa imagem pode ser
muito superficial; usuários com experiências mais variadas podem gerar um
modelo mental mais completo. Na Figura 1, podemos observar a ilustração de
um mapa mental de um processo de venda, em que temos as implicações que
vêm à cabeça do usuário ao descrever um processo do tipo. Com relação aos
clientes, surge um pensamento sobre se o mesmo possui crédito; os produtos
remetem à ideia de estoque, e o processo de venda remete às regras do governo
— nesse sentido, a nota fiscal é um pensamento recorrente entre os usuários.

Figura 1. Exemplo de mapa mental.

 Projeto da interface de uma arquitetura de sistemas 5

O modelo de implementação combina a aparência e a percepção da in-

terface com as informações de apoio que descrevem a interface. Segundo
Pressman e Maxim (2016), o fato de o modelo de implementação e o modelo
mental possuírem similaridades indica que os usuários se sentirão à vontade
com o software e vão utilizá-lo de maneira eficaz. Em suma, esses modelos
citados são abstrações das funções que o usuário exerce, pensa ou deveria
estar realizando; ou seja, é possível afirmar que, conhecendo o usuário, você
terá a percepção das tarefas que este realiza.
Na Figura 2, podemos observar o que pode ser um modelo de implemen-
tação. Realizando uma analogia ao mapa mental da Figura 1, possuiríamos,
nos modelos implementados, recursos para realizar uma venda, consultar e
analisar o estoque de produtos, bem como a possibilidade de emissão da nota
fiscal, para informar ao governo sobre a transação.

Figura 2. O processo de projeto de interface do usuário.

Fonte: Desenvolvimento... ([2013], documento on-line).

Como é possível observar, o processo de análise e projeto de uma interface

pode ser representado utilizando um modelo em espiral (Figura 3). A escolha
do modelo em espiral se dá pelo fato de que cada validação junto ao usuário
pode gerar a necessidade de elaboração de requisitos adicionais, para que a
interface contemple os modelos mencionados anteriormente.
6 Projeto da interface de uma arquitetura de sistemas

Figura 3. O processo de projeto de interface do usuário.

Fonte: Pressmann e Maxim (2016, p. 234).

Ainda na Figura 3, é possível observar quatro processos:

1. análise e modelagem de interfaces;

2. projeto de interfaces;
3. construção de interfaces;
4. validação de interfaces.

Como indicado por Schach (2011), a cada interação, esse conjunto de

processos pode ser repetido, até que a interface seja satisfatória.
No processo de análise e modelagem de interfaces, basicamente são
realizadas três análises:

1. Análise de interfaces — é centrada no perfil de usuários que vão operar

o sistema; vários registros são realizados, como os níveis de habilidade,
conhecimento e receptividade ao novo sistema, além da definição
de categorias de usuários, buscando compreender o entendimento de
sistema que cada classe de usuário possui.
2. Análise de tarefas — inclui todas as tarefas que o usuário realiza para
realizar sua função.
3. Análise do ambiente do usuário — essa análise se concentra no am-
biente de trabalho físico, identificando todos os fatores que podem
interferir no funcionamento do sistema e, mais especificamente, das
interfaces que o usuário vai operar.
 Projeto da interface de uma arquitetura de sistemas 7

Na análise do ambiente, algumas questões devem ser observadas. Por exemplo, se

no ambiente em que o usuário em questão trabalha existir muitos ruídos, os alertas
de sistema que emitem som não vão conseguir exercer a sua função, que é chamar a
atenção do usuário para o alerta em questão. Nesse caso, alertas de cores ou animações
devem ser considerados.

Todas as informações coletadas até o momento são utilizadas para a criação

de um modelo de interface. Por meio desse modelo, o projeto da interface é
realizado, com a definição de objetos e ações da interface que possibilitem
ao usuário final a execução das tarefas, visando a atender às necessidades de
usabilidade do sistema.
Na construção da interface, é desenvolvido um protótipo, que possibilita avaliar
os cenários. Já na validação da interface, a análise se concentra em três questões:

 A interface contempla todas as tarefas do usuário e atende a todos os

requisitos?
 Existe um grau satisfatório de facilidade de uso e aprendizado na interface?
 Existe consenso por parte dos usuários de que a interface é um elemento
facilitador na execução das tarefas?

Para a validação de interfaces, também podemos utilizar a heurística de Nielsen (1994).

Entre os conceitos definidos nessa heurística, podemos destacar os seguintes:
 Relacionamento entre a interface do sistema e o mundo real — toda comu-
nicação do sistema precisa ser contextualizada ao usuário e ser coerente com o
chamado modelo mental do usuário.
 Reconhecimento, em vez de memorização — o usuário não deve decorar o
funcionamento da interface, mas ter a capacidade reconhecer os controles ao
abrir a interface, compreendendo a função deles e o resultado que será obtido
ao operar os mesmos.
 Flexibilidade e eficiência de uso — o sistema precisa ser fácil para usuários leigos,
mas flexível o bastante para se tornar ágil para usuários avançados.
8 Projeto da interface de uma arquitetura de sistemas

Após esses questionamentos, é possível definir se o resultado é satisfatório

ou se ainda existem questões a serem mais bem analisadas e implementadas. Daí
a necessidade de uma nova interação no modelo espiral, demonstrado na Figura
3, em que todo o processo será repetido, até o resultado satisfatório ser atingido.

Identificação do usuário, das tarefas e dos

requisitos do ambiente
Schach (2010) relata que, na engenharia de software, é fundamental compre-
ender o problema antes de propor uma solução. A partir desse entendimento,
é possível afirmar que, para compreender o problema, temos que identificar
os usuários, visto que estes são os clientes do engenheiro e vão efetivamente
utilizar as ferramentas. Além disso, é preciso identificar as tarefas que esses
usuários realizam no desempenho de suas funções e, por último, os requisitos
do ambiente onde esse usuário desempenha suas funções.

Identificar o usuário
A partir do termo “interface do usuário”, já se pode perceber o motivo pelo
qual é dedicado tanto tempo para compreender o usuário, em vez de focar
somente nos detalhes técnicos do software. Para compreender os usuários, é
possível utilizar algumas fontes de informações:

 Os próprios usuários — conforme relata Schach (2011), com entrevistas

diretas entre a equipe de desenvolvimento e os usuários finais é possível
compreender as necessidades, a cultura de trabalho, as motivações,
dentre outras características do usuário. Nessas entrevistas, sejam elas
em grupo ou individuais, é possível obter as informações dos usuários.
 Setor de vendas — Pressman e Maxim (2016) relatam que o setor de
vendas da empresa de software acaba por encontrar de forma regular
os usuários, e estes podem fornecer suas percepções e, a partir delas,
ajudar a classificar os usuários e compreender os requisitos.
 Setor de suporte — possuindo uma ligação muito grande com os
usuários, por conversar diariamente com estes, o setor de suporte da
empresa de software é uma fonte informações de grande valia, capaz
de classificar o que funciona e o que não funciona, o que os usuários
gostam e não gostam e quais recursos geram mais suporte e, logo, não
são adequados, conforme lecionam Pressman e Maxim (2016).
 Projeto da interface de uma arquitetura de sistemas 9

Os questionamentos a seguir podem guiar o engenheiro de software nessa

busca de informações:

 Quais são os segmentos de idades dos usuários?

 Qual é o gênero predominante?
 Quais são as consequências do uso incorreto do sistema?
 Qual é o nível de especialização dos usuários frente ao nicho em que
se encontram?

Esses questionamentos, aliados a outros definidos pelo engenheiro de

software, vão ajudar na definição dos usuários, ajudando a agrupá-los por
classes ou perfis, bem como indicam como uma interface deve ser para atender
às suas necessidades.

Dedique tempo para verdadeiramente conversar com os usuários. Observe que uma
opinião bem formulada pode não ser consenso entre todos e pode realmente não
ser o melhor caminho para o desenvolvimento de uma interface coesa frente às
necessidades dos usuários.

Identificar as tarefas
Para identificar e representar as tarefas, são utilizadas algumas técnicas. A
seguir, essas técnicas são apresentadas em detalhes, com base em Pressman
e Maxim (2016).

User story (história de usuário)

Trata-se da descrição de uma necessidade do usuário pelo seu ponto de vista.

Um user story visa a definir e capturar detalhes de requisitos necessários para
o desenvolvimento da funcionalidade que atenderá à necessidade do usuário.
Na Figura 4, temos um exemplo de user story. Esse exemplo consiste em uma
citação de um usuário, fazendo referência a uma funcionalidade de pesquisa
de livros em uma espécie de e-commerce, por meio do título da obra — ou
seja, trata-se de uma funcionalidade que deve ser prevista.
10 Projeto da interface de uma arquitetura de sistemas

Figura 4. Exemplo de user story.

Fonte: O que... ([2018], documento on-line).

Diagramas de casos de uso

Em resumo, um diagrama de casos de uso ilustra a forma com que o usuário

interage com o sistema. Ao ser utilizado na análise de tarefas, o caso de uso é
desenvolvido para evidenciar como o usuário realiza uma determinada tarefa.
Apesar de o caso se uso descrever de forma básica uma tarefa, por meio dele
é possível extrair tarefas, objetos e o fluxo geral de interação. Na Figura 5,
podemos observar um diagrama de casos de uso, em que temos a identificação
de dois usuários (proprietário e administrador do sistema) e a função que cada
um realiza no sistema. Por exemplo, o administrador reconfigura os sensores
e as características relacionadas ao sistema.

Figura 5. Diagrama de casos de uso identificando os

usuários e a interação de cada um com os sensores.
Fonte: Pressmann e Maxim (2016, p. 153).
 Projeto da interface de uma arquitetura de sistemas 11

Elaboração de tarefas

Essa análise busca auxiliar na compreensão das atividades realizadas pelo

usuário em uma interface. Para compreender as tarefas que uma atividade
deve atender, é necessário compreender as tarefas que os usuários realizam
atualmente, mapeando-as em um conjunto de tarefas implementadas na in-
terface do usuário. Em um modelo de projeto de interface, é necessário levar
em conta cada uma das tarefas, de forma consistente com o modelo de usuário
e a visão do sistema. A Figura 6 ilustra um diagrama de atividades em que
um fluxo de atividades é mapeado, incluindo possíveis tomadas de decisão.
Nesse exemplo, é verificada a necessidade de priorização formal de requisitos.

Figura 6. Diagrama de atividades, ilustrando as tarefas dos usuários.

Fonte: Pressmann e Maxim (2016, p. 155).
12 Projeto da interface de uma arquitetura de sistemas

Elaboração de objetos

Deixando de lado as tarefas, é possível já nessa fase analisar os objetos cons-

tantes nos casos de uso, visando a classificá-los em classes, definindo seus
atributos e avaliando as ações relacionadas a cada objeto, obtendo, a partir
daí, uma lista de operações. Na Figura 7, podemos identificar um diagrama de
classes, em que o objeto “Sensor” é ilustrado com seus atributos (Nome, Tipo,
Localização, Área e Características) e seus métodos (Identificar, Habilitar,
Desabilitar e Reconfigurar).

Figura 7. Diagrama de classes.

Fonte: Pressmann e Maxim (2016, p. 156).

Fluxo de trabalho

Em casos de usuários realizando papéis diferentes em uma interface de

usuário, é necessário aplicar a análise de fluxo de trabalho. Essa técnica
ajuda a compreender como uma tarefa é realizada por vários usuários
envolvidos nela. Um exemplo seria uma empresa automatizando a pres-
crição e a entrega de medicamentos. Na Figura 8, podemos observar um
diagrama de raias UML, com a representação de um fluxo de trabalho em
que o paciente solicita uma revalidação da sua receita médica. Podemos
observar as tarefas e as decisões realizadas por cada um dos envolvidos
(paciente, farmacêutico e médico).
 Projeto da interface de uma arquitetura de sistemas 13

Figura 8. Diagrama de raias para a função de revalidação de receita.

Fonte: Pressmann e Maxim (2016, p. 330).

Observando o diagrama da Figura 8, podemos concluir que cada usuário

realiza tarefas diferentes; assim, a interface projetada para cada um deve
ser diferente, de acordo com o ponto de vista de cada um frente à tarefa em
questão. O médico e o farmacêutico devem possuir informações secundárias,
como medicamentos alternativos e estoque disponível, respectivamente. Várias
14 Projeto da interface de uma arquitetura de sistemas

atividades do diagrama de raias podem ser mais bem analisadas por meio de
uma análise de tarefas e da elaboração de objetos.

UML é a abreviação da expressão unified modeling language (linguagem de modelagem

unificada), sendo essa uma linguagem que define artefatos que nos auxiliam na tarefa
de modelar e documentar sistemas. Você pode consultar mais informações no site
oficial da UML por meio do link a seguir.

https://qrgo.page.link/p298o

Análise do ambiente de trabalho

Conforme Schach (2011) relata, em diversos casos, a interface do usuário é
disponibilizada em um ambiente que facilita a tarefa do usuário, com ilumina-
ção, climatização e acesso de forma ergonômica. Porém, em outras situações,
como um chão de fábrica, por exemplo, muitas vezes, a iluminação, os níveis
de ruído e o acesso físico não são adequados — por exemplo, existem casos
em que o acesso a teclado e mouse não é uma opção plausível. O engenheiro
de software deve estar atento a essas questões, pois elas restringem as opções
que facilitariam o projeto da interface. Nesses casos, torna-se necessário veri-
ficar as opções, para se adequar ao ambiente e propiciar a melhor experiência
possível ao usuário.

Design de interação
Após a análise da interface ser concluída, com as tarefas, os objetos e as ações
identificados, tem início o projeto da interface. Esse processo une todo o projeto
na área de engenharia de software, além de ser interativo — cada etapa do
projeto ocorre uma série de vezes, até que todos os requisitos sejam atendidos.
Segundo Pressman e Maxim (2016), a definição dos objetos da interface
e das ações aplicadas a eles é uma importante etapa do projeto. Visando
complementar as informações, os cenários são analisados, os casos de uso são
descritos e os objetos e as ações são listados. Depois disso, o leiaute da tela é
 Projeto da interface de uma arquitetura de sistemas 15

criado. Assim como outras atividades do projeto de interfaces, a criação do

leiaute da tela é um processo interativo, no qual é realizado o projeto gráfico,
são determinadas as posições dos ícones, e são criados o texto descritivo, o
texto das janelas e os itens de menu.
A Figura 9 ilustra um projeto gráfico dos leiautes de um sistema. Nessa etapa,
não necessariamente devem ser apresentadas as telas reais do sistema; é preciso
demonstrar a aparência geral das telas, a posição dos componentes, algumas
descrições, dentre outras informações, visando ilustrar a aparência da tela.

Figura 9. Exemplo de projeto de leiautes de um sistema.

Fonte: Viktorus/Shutterstock.com.
16 Projeto da interface de uma arquitetura de sistemas

Requisitos não funcionais do projeto

Segundo Rogers, Sharp e Preece (2013), os requisitos funcionais são aqueles
que descrevem como os sistemas vão tratar determinadas situações cruciais
para o seu funcionamento. Porém, muitas vezes, são deixados de lado, em
virtude de serem menos atraentes, ou somente é identificada a sua necessidade
quando ocorrências ligadas a esses requisitos ocorrem.
Pressman e Maxim (2016) relatam que, conforme o projeto da interface de
usuário avança, alguns problemas de projeto surgem. Esses problemas, em muitos
casos, só começam a ser tratados pelo engenheiro de software uma vez que o
projeto já se encontra em um estágio avançado. Assim, até que ele perceba essas
necessidades, algumas interações já podem ter ocorrido de forma desnecessária.
Logo, torna-se mais vantajoso determinar alguns requisitos não funcionais a
serem implementados no início do projeto, conforme indicados a seguir.

Tempo de resposta

O tempo de resposta de um sistema é uma das principais reclamações dos

usuários. O tempo de resposta se dá do momento em que o usuário utiliza a
tecla “enter” ou clica com o mouse em um determinado controle até o sistema
retornar a resposta ou a ação desejada. Esse tempo de resposta possui duas
características: duração e variabilidade.
Se uma resposta de sistema for inevitavelmente longa, vai existir frustação
e estresse por parte do usuário. A variabilidade é referente ao desvio do tempo
médio de resposta, e a característica mais importante é o tempo. A baixa va-
riabilidade permite ao usuário encontrar um ritmo de trabalho. Por exemplo,
um tempo de resposta de 1,5 segundo é preferível do que uma resposta que
varia de 0,5 a 8 segundos, visto que um tempo maior faz com que o usuário
não saiba se sua ação foi executada corretamente.

Muitas vezes, dependendo da infraestrutura que executa a aplicação, os tempos de

resposta podem estar ligados a infraestruturas subdimensionadas. Nesses casos, a
falha pode não estar no software desenvolvido, mas decorrer de uma deficiência ou,
até mesmo, de uma falha dos equipamentos ou das instalações. Logo, o engenheiro
de software deve estar atento a essas questões da infraestrutura.
 Projeto da interface de uma arquitetura de sistemas 17

Recursos de ajuda

Independentemente do nível de conhecimento do usuário, muitas vezes, ele

se depara com situações em que necessita de ajuda — seja uma dica de um
colega ou uma consulta aos vários volumes do manual de ajuda do software.
Na atualidade, os softwares possuem recursos de ajuda on-line, que pos-
sibilitam ao usuário obter uma resposta sem ter de abandonar a interface.
Pressman e Maxim (2016) indicam alguns problemas de projeto relacionados
a isso. Veja-os a seguir.

 A ajuda vai estar disponível para todas as funções do sistema e a qualquer

momento? A ajuda pode estar disponível a apenas um subconjunto de
funções e ações ou para todas as funções.
 De que forma o usuário solicitará ajuda? Por meio de um menu de ajuda,
uma tecla de função especial ou um comando HELP?
 De que forma será representada a ajuda? Por meio de uma janela separada,
uma referência a um documento impresso (não ideal) ou uma sugestão de
uma ou duas linhas produzida em uma localização fixa da tela?

Tratamento de erros

Normalmente, alertas de erros são indicadores de más notícias aos usuários.

Atualmente, os usuários ainda são expostos a mensagens de erro que não
fazem o menor sentido para eles — a Figura 10 exemplifica isso. Usuários mais
avançados podem compreender o que significa a mensagem, mas dificilmente
vão encontrar uma solução. Porém, o exemplo da Figura 10 não demonstra
nenhum motivo para o erro ter ocorrido, muito menos menciona uma fonte
de informações para se verificar mais dados sobre o mesmo.

Figura 10. Exemplo de mensagem de erro de um sistema.

Fonte: Lars Poyasky/Shutterstock.com.
18 Projeto da interface de uma arquitetura de sistemas

Pressman e Maxim (2016) indicam uma série de características que não

devem faltar em um alerta de erro:

 o erro deve descrever o problema em uma linguagem que o usuário

consiga compreender;
 a mensagem de erro deve fornecer informações construtivas para a
recuperação do erro;
 a mensagem deve indicar as consequências do erro — dessa forma, o
usuário pode avaliar suas perdas e, assim, tomar medidas corretivas;
 algum sinal audível ou visual deve ser emitido, indicando o erro;
 a mensagem não deve, sob hipótese alguma, colocar a culpa no usuário.

Mesmo que o engenheiro de software tome todas as medidas para tornar

os erros mais “agradáveis”, poucos usuários vão se sentir contentes com
eles. Porém, uma estratégia de erros bem pensada pode diminuir bastante a
frustação e o estresse do usuário.

Os conceitos de UI (user interface) e UX (user experience) devem ser levados em conta

na elaboração dos requisitos não funcionais, uma vez que definem diversos padrões
em prol de uma melhor interface e uma melhor experiência entre usuário e interface.
Mais informações podem ser encontradas no link a seguir.

https://qrgo.page.link/tHG2n

Acessibilidade das aplicações

Muitas vezes, usuários podem possuir limitações, sejam elas de ordem física,
visual, auditiva, motora, de fala ou de aprendizado. Frente a essas necessidades,
o engenheiro de software deve garantir que o projeto da interface possua me-
canismos que permitam a fácil operação do sistema por pessoas que possuam
necessidades especiais.
 Projeto da interface de uma arquitetura de sistemas 19

O World Wide Web Consortium (W3C) é um consórcio internacional em que organi-

zações filiadas mantêm uma equipe em tempo integral trabalhando juntamente com
o público para desenvolver padrões para a web. Dentre esses padrões, estão várias
técnicas que permitem acessibilidade. O Brasil possui um escritório filiado à W3C,
que disponibiliza uma cartilha de acessibilidade na web. Mais informações podem
ser acessadas no link a seguir.

https://qrgo.page.link/GDmEQ

Internacionalização

Na maioria das vezes, as interfaces são desenvolvidas para um país e um idioma,

e, então, são criadas as ditas “gambiarras” para funcionar em outros locais ou
idiomas. Criar um software globalizado é um desafio para os engenheiros de
software. Assim, as interfaces devem ser criadas de forma genérica e, por meio
de recursos de localização, ser personalizadas para o mercado em questão.

DESENVOLVIMENTO de aplicativos. Tríscele, Florianópolis, [2013]. Disponível em: https://

www.triscele.com.br/desenvolvimento-web/desenvolvimento-de-aplicativos. Acesso
em: 12 jun. 2019.
NIELSEN, J. 10 Usability heuristics for user interface design. Nielsen Norman Group, [s. l.],
24 abr. 1994. Disponível em: https://www.nngroup.com/articles/ten-usability-heuristics/.
Acesso em: 12 jun. 2019.
O QUE é a user story? Knowledge21, [s. l.], [2018]. Disponível em: https://www.knowledge21.
com.br/sobreagilidade/user-stories/o-que-e-user-story/. Acesso em: 12 jun. 2019.
PRESSMAN, R., MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed.
Porto Alegre: AMGH, 2016.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interação: além da interação humano-com-
putador. 3. ed. Porto Alegre: Bookman, 2013.
SCHACH, S. R. Engenharia de software: os paradigmas clássico & orientado a objetos. 7.
ed. Porto Alegre: AMGH, 2011.