Definição de Requisitos 81

A definição de requisitos apresenta a visão geral do que o produto é e do que este deverá fazer. É o "quê" do design.

Apesar de por vezes existir a tendência a começar imediatamente pelo design, antes da definição da aparência do produto, do seu comportamento e funcionamento, é obrigatório o produto ter os seus requisitos definidos e existir uma concordância exata em relação à informação e funcionalidades necessárias para que as personas consigam atingir os seus objetivos (Cooper, Reimann, and Cronin 2007).

Para Garrett (2010), existem dois motivos pelos quais os requisitos deverão ser definidos: para ter noção do produto que se irá desenvolver e para ter noção do produto que não se irá desenvolver.

No primeiro caso, é importante saber que tipo de produto se está a desenvolver porque irá permitir aos elementos da equipa saber quais são os objetivos do projeto e quando serão alcançados. Indefinição dos requisitos levará, na maioria das situações, a indefinição no desenvolvimento.

Definir o tipo de produto que não se irá desenvolver é igualmente importante uma vez que independentemente de quão boas forem algumas ideias para funcionalidades, não significa que estas se coadunem com os objetivos do projeto. Uma definição efetiva irá igualmente permitir uma melhor avaliação da adição constante de ideias para novas funcionalidades ao longo do

processo de desenvolvimento e permitirá uma recolha de ideias que, ainda que possam não ser aplicadas na versão atual do produto, poderão sê-lo em versões posteriores.

A definição de requisitos pode ser dividida em vários passos. Cooper et al. (2007) divide-a em 5 passos:

1. Declarar o problema a resolver e a visão para o produto: (1) A declaração do problema serve para definir o motivo para o qual se está a desenvolver o produto. Qual a situação atual que precisa de ser alterada para personas e mundo de negócios. (2) A declaração da visão define o objetivo a atingir com o produto, começando pelas necessidades do utilizador e transitando para os objetivos em termos de negócio. O conteúdo para estas duas declarações é útil nos casos de um novo design de um produto ou criação para um mercado ainda não explorado. A sua definição é feita com os dados provenientes da fase de pesquisa e de desenvolvimento de personas assim como das entrevistas com os investidores;

2. Brainstorming: Quando é chegada a fase do brainstorming, devido essencialmente à quantidade de investigação que foi realizada em relação aos utilizadores e aos seus objetivos, existem ideias pré-concebidas do que deverá ser o produto. Realizar

brainstorming nesta fase do desenvolvimento é portanto uma maneira de "libertar" os designers das ideias que já tiveram, levando-os a manterem uma mente aberta e flexível

para o desenvolvimento dos cenários e para a definição de requerimentos provenientes desses mesmos cenários. As ideias lançadas nesta fase não deverão ter em conta restrições ou críticas;

3. Identificar as expectativas das personas: O design e o modo de funcionamento do produto deverão estar o mais aproximados possível do modelo mental dos utilizadores. Para isso têm de ser identificadas várias situações em relação às personas como atitudes e experiências, expectativas gerais ou o comportamento que espera por parte do produto;

4. Construir cenários de contexto: São os cenários que irão permitir a melhor definição dos requisitos do utilizador focando-se na perspectiva da persona através de atividades, motivações, perceções, modelos mentais e desejos humanos. O conceito de cenário será abordado neste capítulo, no ponto 4.7.4;

5. Identificar requisitos: Após a elaboração dos cenários de contexto, estes podem ser analisados de modo a providenciar os requisitos para cada persona. Os requisitos podem ser elaborados através de objetos, ações e contextos. Um exemplo de emprego destas três características poderá ser: "Telefonar (ação) a uma pessoa (objeto) diretamente a partir do ecrã do compromisso (contexto)". Para além desta hipótese na definição de requisitos, estes podem ser separados em requisitos funcionais e de dados.

4.7.1 Requisitos de Dados

Estes requisitos definem as informações e objetos que deverão ser representados na interface do sistema e como serão utilizados. Poderão ser vistos como os "objetos" do exemplo anterior. Os requisitos de dados poderão ser apresentados como: contas, pessoas, documentos, mensagens, músicas, vídeos imagens e os atributos de cada um destes conteúdos: estado, datas, tamanho, criador ou tema (Cooper, Reimann, and Cronin 2007; Garrett 2010).

No ponto de vista dos programadores, estes requisitos são úteis pois permitem saber como é que a informação será guardada e formatada. No caso do nome do utilizador, será um campo único, dividido entre nome e sobrenome ou será uma alcunha? A definição deste ponto poderá por exemplo influenciar a forma como é apresentado o nome do utilizador após o típico cumprimento em algumas páginas web que se pauta por um "Bem-vindo utilizador x" (UsabilityFirst 2013k).

4.7.2 Requisitos Funcionais

Definem as operações ou ações que necessitam ser realizadas nos objetos do sistema e os locais onde os objetos e a informação são dispostos na interface. Estes possuem também relação direta com o exemplo referido anteriormente, podendo ser interpretados como sendo as "ações" (Cooper, Reimann, and Cronin 2007).

Basicamente, assim que existir noção das necessidades das personas, torna-se necessário descrever como as diversas funcionalidades devem funcionar de modo a suportar a utilização efetiva que os utilizadores querem obter do produto por forma a alcançarem os seus objetivos. A descrição destas funcionalidades ajuda igualmente na perceção de como estas irão funcionar entre si, uma vez que a interação entre duas ou mais funcionalidades poderá criar novos problemas a nível de design e desenvolvimento (UsabilityFirst 2013k)

Contudo estes requisitos poderão ser alvo de criticas uma vez que se acredita que não refletem realmente o produto. Existem situações em que requisitos definem funcionalidades que durante a fase de desenvolvimento não são passíveis de ser implementadas, não funcionam, ou não funcionam como o esperado. O ideal será fazer do processo de definição de requisitos algo rápido e eficiente, que não se torne por si só num projeto. Os requisitos deverão ser claros e diretos e não terão que abordar todos os aspetos do produto, terão sim de focar-se naqueles que necessitam de melhor definição de forma a evitar situações dúbias durante o design e desenvolvimento do produto (Garrett 2010).

De notar que é importante que as funcionalidades permitam aos utilizadores realizar as tarefas do modo como efetivamente o desejam fazer e não através do modo que será correto no ponto de vista do programador ou investigador do produto. Para além disso, deverão ser excluídas funcionalidades que não apresentem um benefício real para a experiência que o utilizador obtém com o produto (UsabilityFirst 2013k).

4.7.3 Regras para a Definição de Requisitos

No livro "The Elements of User Experience", Garrett (2010), apresenta algumas regras para a escrita dos requisitos:

• Escrever de modo positivo: Não descrever um aspeto negativo do produto, apresentar o que o produto fará para evitar esse aspeto negativo. Por exemplo poderá ser dito: "O sistema irá reencaminhar o utilizador para a página com fios para papagaios se o utilizador tentar comprar um papagaio sem um fio" ao invés de "O sistema não permitirá ao utilizador adquirir um papagaio sem um fio para papagaio";

• As descrições deverão ser específicas: Deverão ser evitadas situações ambíguas que possam levar a dúvidas em relação ao cumprimento de um requisito. Por exemplo ao invés de "Os vídeos mais populares serão destacados", será preferível "Os vídeos com mais visualizações na última semana surgirão no topo da lista";

• Evitar linguagem subjetiva: Tal como na regra anterior, este é um modo de evitar interpretações erróneas. Por exemplo ao invés de "A página terá um estilo na moda e apelativo", poder-se-á ter "A aparência da página irá respeitar o documento com as guias de identidade visual da empresa";

• Utilização de dados quantitativos: Trata-se de mais uma solução para remoção de subjetividade. "O sistema deverá ser capaz de suportar 1000 utilizadores em simultâneo" em detrimento de "o sistema deverá ter um nível elevado de performance".

4.7.4 Cenários

Um dos modos mais efetivos para comunicar ideias dá-se através da criação de narrativas. No campo do design de interfaces e experiências, as histórias permitem despertar a imaginação e considerar novas possibilidades de interação do utilizador com o serviço a ser desenvolvido (Cooper, Reimann, and Cronin 2007).

O facto do design de interação ser genericamente o design dos comportamentos que ocorrem ao longo do tempo, permite que possa ser criado de modo rápido uma narrativa estruturada. Normalmente esta poderá ser concretizada através da criação de storyboards que deverão ser breves e seguir um enredo/cenário (Cooper, Reimann, and Cronin 2007).

Cooper et al. (2007), aborda a investigação feita pela comunidade de HCI onde surgiu o conceito de cenário. Este é utilizado para “descrever um método para resolver problemas de

design através da concretização: fazendo uso de uma história específica para construir e ilustrar soluções de design”. Cooper et al. aborda também a definição de John Carroll (2000),

importância conferida às tarefas em detrimento dos objetivos ou motivações do utilizador. A solução para estas duas limitações, será o uso de personas.

A aplicação de cenários às personas consiste na escrita de narrativas resumidas sobre o modo de utilização a ser empregue para que possam ser atingidos os seus objetivos. Os dados que servem para a construção deste cenário advêm da recolha e análise realizada na fase de investigação. Através da construção de cenários para as personas, é possível focar o design da experiência através do modo como os utilizadores pensam e agem ao invés de objetivos tecnológicos ou de negócio (Cooper, Reimann, and Cronin 2007).

De seguida serão descritos os três tipos de cenários existentes quando o método de design empregue é orientado a objetivos (Cooper, Reimann, and Cronin 2007):

1. Cenários de Contexto: São criados antes de ser realizado qualquer tipo de design da interface, são aliás a etapa inicial para o design. Irão permitir a melhor definição dos requisitos do utilizador focando-se na perspectiva da persona através de atividades, motivações, perceções, modelos mentais e desejos humanos. Na narrativa, são descritas as formas de contacto das personas com o produto ao longo de um determinado período de tempo. O foco é dado às ações realizadas na perspetiva do utilizador em detrimento do detalhe demasiado elevado da descrição ou da interação passível de ser realizada com o produto. A função dos cenários de contexto será de conceder informações para que se torne possível ao designer começar a imaginar a interface ideal que irá ajudar as personas a atingir os seus objetivos (Cooper, Reimann, and Cronin 2007; Moule 2012);

2. Cenários de Percurso: A partir do momento que os elementos funcionais e de informação estiverem definidos e a framework de design tiver sido elaborada, torna-se possível elaborar cenários de percurso. Estes são uma revisão e uma mudança de foco em relação aos cenários de contexto, uma vez que estes últimos focam-se nos objetivos do utilizador enquanto que os cenários de percurso centram-se nas tarefas a serem executadas. Utilizando o vocabulário da framework de interação, permitem uma descrição específica e passo-a-passo das interações principais e dos caminhos seguidos com mais frequência pelo utilizador em relação à interface. A sua evolução e aperfeiçoamento é realizada iterativamente de acordo com a evolução do design do produto;

3. Cenários de Validação: São utilizados para testar as soluções encontradas para a interface. Sendo também normalmente aplicados aos casos extremos. São menos detalhados e baseiam-se na colocação de questões começadas por “E se…” em relação às soluções a serem testadas (Cooper, Reimann, and Cronin 2007; Moule 2012). Se no caso dos cenários de percurso a ideia passa por detalhar as interações e percursos principais, no caso dos cenários de validação, o que será necessário compreender são as interações menos frequentes e importantes tentando descobrir e corrigir falhas que

possam quebrar a o design do produto. No Ponto de vista de Cooper et al. (2007), existem três categorias, cuja ordem deverá ser respeitada, de cenários de validação:

1. Variantes dos cenários de percurso que sejam menos utilizadas, que em certo ponto derivem demasiado dos percursos principais ou que estejam baseados nos objetivos das personas secundárias. (Ex: recurso a ferramentas menos utilizadas);

2. Cenários de utilização necessária incluem ações que apesar de infrequentes, têm de ser realizadas. Como não acontecem frequentemente os utilizadores podem esquecer- se de como aceder à funcionalidade ou como pode ser utilizada. (Ex: Ecrã de configurações ou registo num serviço);

3. Cenários de casos extremos relacionam-se com ocorrências atípicas que idealmente o produto deverá ser capaz de saber lidar. Estes casos não deverão ser o foco do processo de design uma vez que o sucesso do produto estará dependente da sua capacidade de funcionamento no dia a dia e na resposta que é capaz de dar na ajuda a alcançar os objetivos do utilizador e não em situações que possuem uma baixa prioridade. (Ex: uma aplicação de gestão de conteúdos na cloud, qual o seu comportamento quando o utilizador a utiliza mas não está conectado à internet?).