Histórico de Revisões

Data	Versão	Descrição	Autor
01/09/2016	1.0	Criando tópicos	João Vitor Araujo

---

1. Introdução
2. Usabilidade
3. Confiabilidade
4. Desempenho
5. Suportabilidade
6. Restrições de Design

---

1. Introdução

1.1 Finalidade

A finalidade deste documento é definir os requisitos não-funcionais do aplicativo Android de calendário colaborativo. Esta especificação suplementar define requisitos que não foram listados diretamente no Documento de Visão ou no Modelo de Caso de Uso.

1.2 Escopo

Esta Especificação Suplementar se aplica ao sistema de comércio eletrônico Wikalendário FGA, um aplicativo que fornece um calendário colaborativo relacionado às disciplinas da Faculdade UnB - Campus Gama. A aplicação contará com a criação de eventos no calendário que são compartilhados com todos os cadastrados na disciplina em questão. Haverá, também, a possibilidade de definir datas específicas a um grupo fechado de trabalho em cada disciplina.

1.4 Referências

Supplementary Specification, Sistema de Mensagens do Collegiate Sports. Disponível em: http://www.funpar.ufpr.br:8080/rup/examples/csports/ex_suppspc1.htm. Acesso em 01 set. 2016.

[Documento de Visão do Wikalendário]. Disponível em https://github.com/Time5-Desenho/Wikalendario/wiki/Documento-de-Vis%C3%A3o. Acesso em 01 set. 2016.

1.5 Visão Geral

Abaixo estão listados um grande conjunto de requisitos não-funcionais, bem como características que se fazem necessárias na elaboração do site, como usabilidade, confiabilidade, desempenho, suportabilidade e restrições de design.

2. Usabilidade

2.1. Estética e Design

O sistema deve apresentar uma interface simples focada na apresentação do calendário com eventos, sendo as outras atividades circundantes a isso.

2.2. Mensagens ao Usuário

O sistema deve apresentar mensagem de erro e sucesso de acordo com as ações do usuário.

2.3. Pedidos de Confirmação

O sistema deve apresentar pedidos de confirmação em operações críticas, como exclusão de eventos e comentários.

3. Confiabilidade

3.1. Disponibilidade

O sistema deve estar disponível durante 24 horas por dia.

3.2. Tempo Médio para Reparo

Após uma falha, o sistema deve ficar, no máximo, quatro horas sem funcionar.

4. Desempenho

4.1. Tempo de resposta de uma transação

O sistema deve responder a uma transação de criação, edição e exclusão de evento em, no máximo, 10 segundos. E deve responder a uma transação de criação, edição e exclusão de comentário em, no máximo, 5 segundos.

5. Suportabilidade

5.1 Compatibilidade

O site deve ser compatível com smartphones Android com versão 4.4 (KitKat) ou superior.

5.2 Adaptabilidade

O sistema deve ter sua interface adaptada de acordo com a resolução de tela de cada dispositivo.

6. Restrições de Design

6.1. Ferramenta de Desenvolvimento

O sistema deve ser desenvolvido para Android utilizando a API padrão deste, por meio do software Android Studio.

6.2. Paradigma de Programação

O sistema deve ser desenvolvido sob o paradigma da Programação Orientada a Objetos.