Requisitos não funcionais

Ao contrário dos requisitos funcionais, que descrevem o que o sistema deverá ser capaz de fazer, os requisitos não funcionais descrevem qualidades e comportamentos do sistema14. Estes requisitos foram pensados para o sistema final do PontoUA, pelo que apenas alguns tiveram

oportunidade de ser implementados no protótipo em questão, o PontoDeCA. Estes requisitos foram divididos nos aspectos relativos à segurança, usabilidade, performance e manutenção.

4.5.3.1.

Usabilidade

De forma geral, as questões relativas à usabilidade foram o ponto central à volta do qual foi desenvolvida todo o sistema. Especificamente, estes requisitos dizem respeito à navegação e estrutura geral da aplicação, bem como à interface final. Tendo em conta o contexto de utilização pública do sistema (SIEP), houve uma preocupação em assegurar que todos os conteúdos são acedidos com o menor número de toques possível. Nesta perspectiva, existem situações em que o utilizador pode aceder à informação sem que sequer necessite de interagir com a aplicação explicitamente (através dos módulos de informação que são exibidos na Home, de modo cíclico). Aspectos relativos à interface, como a transposição de metáforas de interacção e modelos mentais normalmente associados à Web (checkboxes, caixas de pesquisa, radio buttons, comboboxes) foram utilizados como forma de familiarizar o novo utilizador com a utilização do sistema. O teclado virtual por exemplo, utilizado para inserção de texto em determinadas zonas da aplicação, apresenta uma configuração do tipo QWERTY15 e surge sempre do lado direito do ecrã, uma vez que a grande maioria da população utiliza a mão direita como método de input na comunicação homem-máquina (Buxton, 2008). Contemplando, ainda assim, a minoria dos utilizadores que utilizam a mão esquerda16, o teclado virtual pode ser arrastado e movido para o lado esquerdo do ecrã sem dificuldade.

4.5.3.2.

Desempenho

Os aspectos relativos ao desempenho de uma aplicação/sistema estão intimamente relacionados com a eficiência do mesmo. Um desempenho rápido do sistema evita hesitação por parte dos utilizadores, dúvidas quanto ao estado das suas acções e contribui para a satisfação na utilização. Embora não tenham sido definidas regras estritas quanto às necessidades de performance da aplicação construída, o seu método de implementação foi realizado de modo a evitar dependências de factores exteriores que possam influenciar o desempenho global do sistema.

A construção da aplicação foi realizada de modo a que toda a parte relativa à navegação e exibição da interface fosse exclusivamente local, isto é, sem qualquer dependência de ligações externas relativamente à máquina onde a aplicação está instalada. Esta opção evita tempos de carregamento variáveis, uma vez que o carregamento dos vários módulos não depende de uma ligação à Web nem de nenhum outro factor externo. Uma vez que a máquina cumpra os requisitos mínimos de sistema para correr a aplicação, toda a navegação e tempos de resposta deverão ser sempre os mesmos, isto é, curtos (se possível, nunca superiores a um segundo).

15 _{http://en.wikipedia.org/wiki/QWERTY, consultado a 3 de Agosto de 2010}

Toda a informação que é recebida externamente, quer dos vários feeds Web utilizados, quer das consultas da base de dados, dependem naturalmente do estado da ligação à Web. Nas condições ideais, a exibição de toda a informação proveniente da base de dados, por exemplo, levará cerca de um segundo.

4.5.3.3.

Segurança

Os aspectos relativos à segurança são, no caso dos SIEP, normalmente postos em segundo plano, dado que não existe informação sensível a ser exibida. No entanto, o sistema PontoUA / PontoDeCA envolve o reconhecimento do utilizador e a apresentação de informação pessoal e personalizada ao mesmo. Dado que pode existir um processo de login no sistema, torna-se crucial a implementação de medidas que salvaguardem a privacidade dos dados sensíveis de cada utilizador.

No caso da fonte de informação, toda a informação sensível relativa aos utilizadores está armazenada numa base de dados externa. Esta está, naturalmente, protegida contra acesso anónimo pela utilização de uma password de acesso. No caso do protótipo desenvolvido, a base de dados foi local e os ficheiros de servidor que lhe davam acesso estavam também com acesso local, pelo que neste caso, a segurança estava comprometida: o simples acesso à máquina permitia um fácil acesso à informação. No entanto, a solução final para o projecto contempla a transposição dos dados para um servidor externo, onde estas falhas de segurança não se aplicam.

No caso da segurança da própria aplicação, a informação pessoal só pode ser acedida com um login explícito com o cartão de utilizador. Uma vez que o acesso ao sistema é limitado e está confinado à própria aplicação, não existirá, à partida, qualquer outro método de fraude de login. O sistema contempla ainda um módulo de logout automático, baseado na inactividade da aplicação, assegurando assim que nenhum utilizador deixará acidentalmente a sua informação pessoal em constante exibição no sistema.

4.5.3.4.

Manutenção

Os aspectos relativos à manutenção, enquanto requisito não funcional, dizem respeito à forma como o sistema e a aplicação permitem a modificação de conteúdos, identificação e correcção de eventuais problemas, assim como a necessidade de intervenção por parte de um administrador de sistema.

No que diz respeito à alteração dos conteúdos, é necessário separar aqueles que estão disponíveis externamente à aplicação daqueles que foram alimentados manualmente para efeitos de teste do protótipo. Os conteúdos relativos às preferências dos utilizadores são retirados directamente da base de dados, enquanto os conteúdos que se alteram diariamente (notícias, ementas, eventos) são alimentados externamente por feeds Web. Uma vez que não existiam, à data de desenvolvimento, feeds disponíveis para alguns tipos de conteúdo (as ementas, por

exemplo), parte da informação apresentada no protótipo PontoDeCA necessitou de intervenção humana diária para se manter actualizada. Para uma solução final, no entanto, o sistema encontra-se preparado para se actualizar automaticamente em função de alterações da informação. A ideia de manutenção próxima de zero, tendo em conta as necessidades de informação deste projecto, não pôde ser implementada no tempo de desenvolvimento, uma vez que não existiam ainda fontes de informação suficientes para alimentar dinamicamente a aplicação.

Quanto aos erros despoletados pela aplicação, estes estão a ser armazenados num ficheiro de log do sistema que reúne todos os erros. Isto facilita o processo de correcção de problemas, uma vez que um administrador poderá manter-se a par das falhas do sistema mesmo não os experimentando presencialmente.