Especificação Suplementar

Histórico de Revisão

Data	Versão	Descrição	Autor(es)
09/09/2015	0.1	Criação do Documento	Jonathan Rufino
11/09/2015	1.0	Restrições de Design, Padrões aplicáveis	Jonathan Rufino

---

1 Introdução

Este documento apresenta os requisitos não funcionais do SisCOT.

1.1 Finalidade

Como os requisitos não funcionais não são capturados na descrição de caso de uso, mas ainda são de extrema importância ao projeto, este documento tem como objetivo documentar tais requisitos.

1.2 Visão Geral

Este documento apresenta, inicialmente, uma descrição das categorias de requisitos suplementates. Em seguida são descritos os requisitos suplementares relativos ao SisCOT, também conhecidos como FURPS+. Estes estão divididos em categorias como se segue, em usabilidade, confiabilidade, desempenho, suportabilidade, restrições de design, entre outros.

1.3 Referências

http://www.wthreex.com/rup/webtmpl/templates/req/rup_sspec.htm

---

2 Usabilidade

2.1 Facilidade de Uso

O sistema deve ser de fácil utilização para os usuários, de forma que não seja necessário treinamento, e que as funcionalidades possam ser aprendidas em um período de tempo curto de aproximadamente 20 minutos. Para as funçoes mais complexas, dicas devem orientar o usuário durante a navegação.

2.2 Consistência e Padronização

O sistema seguirá padrões já consolidados no desenvolvimento de aplicações Web, para que desta forma o usuário se sinta familiarizado com a navegação. Com a utilização de padrões e associações ao mundo real o usuário sentirá mais facilidade na utilização da ferramenta.

---

3 Confiabilidade

3.1 Disponibilidade

O sistema estará disponível 24h por dia para que os fornecedores possam solicitar o seu cadastro. Durante a realização de um pregão, caso haja uma falha que impossibilite o uso do sistema, ele deverá voltar a operação em no máximo 4h.

3.2 Recuperabilidade

Qualquer informação preenchida pelos usuários será armazenada localmente, para que caso haja alguma falha no sistema, os usuários possam recuperar estas informações e continuar a utilização do sistema.

---

4 Desempenho

4.1 Tempo de Resposta

O sistema será capaz de atender às requisições em um intervalo de tempo médio de 3-7 segundos.

4.2 Capacidade

O sistema suportará o acesso de pelo menos 15 usuários simultaneamente, para que seja possível realizar um pregão com um número satisfatório de fornecedores.

---

5 Suportabilidade

5.1 Padrão de Codificação

O sistema será implementado seguindo os padrões de codificação definidos pela equipe, baseado nos padrões utilizados pela comunidade Java e pela Oracle.

5.2 Facilidade de Manutenção

A linguagem de programação utilizada deve ser portátil.

---

6 Restrições de Design

6.1 Linguagem de Programação

O sistema será desenvolvido utilizando a linguagem de programação Java, versão 1.8.0

6.2 Persistência de Dados

O sistema utilizará o SGBD MySQL, versão 5.5.44, para a persistência de dados

---

7 Padrões Aplicáveis

O sistema será desenvolvido utilizando o padrão MVC, que é um padrão de projeto arquitetural onde as classes são divididas em 3 camadas:

Model: é a camada que representa os seus dados, provendo meios de acesso (leitura e escrita) à esses dados. Tudo que diz respeito à escrita, validação e leitura dos dados está dentro da camada model, não necessariamente dentro do model em si, mas dentro da camada model.

View: é na view que o sistema interage com o usuário. Tudo que ele ver (HTML / XML / RSS / CSV) deve ser gerado e exibido através dessa camada. A view, por sua vez, tem como responsabilidade manipular os dados para - e apenas para - exibição; exibir os dados.

Controller: No controller é onde temos os métodos públicos que são chamados de actions, cada action é responsável por uma página do sistema. É a controller quem decide qual model usar; quais pedidos fazer para a model; qual combinação de views será usada para exibir os dados retornados pelo model.