Especificação Suplementar

Histórico de Revisões

Data	Versão	Descrição	Autor
03/10/2017	0.1	Criação do documento	Pedro Kelvin
03/10/2017	0.2	Iniciando Introdução, Confiabilidade e Usabilidade	Pedro Kelvin
04/10/2017	0.3	Restrição de Design e Alterabilidade	Pedro Kelvin
05/10/2017	0.4	Escrita: introdução, escopo, visão geral, Funcionalidade, desempenho, suportabilidade	Adrianne Alves
06/10/2017	0.5	Edição finalidade, usabilidade,confiabilidade, Linguagem de programação	Adrianne Alves

1.Introdução

A especificação suplementar, tema deste documento, aborda os requisitos do sistema Falko que não foram identificados de maneira imediata na documentação dos Casos de Uso. Entre eles encontram-se requisitos legais e de qualidade, referente à usabilidade, confiabilidade, desempenho e suportabilidade. Além disso, trata-se também de requisitos de compatibilidade e restrições referentes ao design da plataforma.

1.1.Finalidade

Este documento tem como objetivo determinar os requisitos não funcionais para a aplicação Falko, voltada para o gerenciamento de projetos ágeis. Dessa maneira, a união das especificações suplementares e o Modelo de Casos de Usos fornecido compõem, com plenitude, a relação de Requisitos necessários para descrevê-la.

1.2.Escopo

As especificações suplementares aqui relatadas aplicam-se ao projeto de desenvolvimento da aplicação Falko, de modo que definem os requisitos não funcionais para a mesma como : requisitos de usabilidade, desempenho, suportabilidade e confiabilidade, além de requisitos comuns a alguns casos de uso, ou seja, requisitos de funcionalidade.

1.3.Definições, Acrônimos e Abreviações

SPA - Single Page Aplication

1.4.Referências

1.5.Visão Geral

O documento está organizado de acordo com as áreas de classificação principal dos requisitos não funcionais, conforme descrito anteriormente, assim, abrange os tópicos de requisitos de usabilidade, confiabilidade, desempenho, suportabilidade, compatibilidade e referente ao design da aplicação. Entretanto, inicialmente expõe-se um tópico de funcionalidade que relaciona-se diretamente com requisitos não funcionais que são essenciais para o funcionamento dos funcionais listados no documento de visão e arquitetura deste projeto.

2.Funcionalidade

Dentre as funcionalidades a serem abordadas temos a integração com o GitHub por meio do consumo de informações da API do mesmo, e além disso, deve estar disponível para o usuário a possibilidade de vincular a sua conta na plataforma com o github. Essas funcionalidades são essenciais para o correto funcionamento dos demais requisitos funcionais expressos nos demais documentos que descrevem a aplicação.

2.1. O sistema deve consumir informações da API do GitHub

Para que o sistema funcione da maneira correta, utilizando dados e métricas reais sobre um projeto a ser analisado na plataforma, é necessário que o sistema esteja integrado ao GitHub, utilizando a sua API para a recuperação dos dados a serem expostos pela aplicação

2.2. O usuário deve ser capaz de vincular sua conta com o GitHub

O usuário poderá realizar o vínculo entre a sua conta na aplicação e a conta do GitHub ao qual os seus projetos estejam interligados facilitando a sua visualização da relação entre as duas plataformas.

3. Usabilidade

O usuário não necessitará de um treinamento para utilizar a aplicação. Logo após o cadastro e realização do login, o mesmo contará com uma aplicação de funcionamento simples, cujas ações e atividades serão intuitivas.

3.1. Navegador Web

O usuário precisará de um navegador web de sua preferência e domínio do seu uso a fim de acessar a aplicação.

3.2. Acesso à internet

A aplicação não funcionará offline, dessa forma, o usuário precisará de acesso à internet para acessá-la.

4.Confiabilidade

4.1 Disponibilidade

O sistema estará disponível no mínimo de 18 horas por dia para que o usuário possa utilizá-lo durante os 7 dias por semana. As seis horas restantes dedicam-se à manutenção de urgência na aplicação, caso necessário.

4.2 Alterabilidade

O sistema não poderá alterar os dados obtidos do Github no caso de uso Integrar Github descrito pelo documento de especificação de casos de uso. Ou seja, os dados recebidos pelo sistema só poderão ser lidos, jamais alterados.

4.3 Segurança das informações dos usuários

O sistema deverá fornecer a segurança necessária aos dados pessoais fornecidos pelos usuários de maneira que seja possível apenas ao dono realizar modificações ou exclusões de seus dados. Dessa maneira, apenas o dono de um projeto pode editá-lo, ou excluí-lo e o mesmo acontece com as demais funcionalidades que dependam do usuário.

5.Desempenho

5.1

6.Suportabilidade

A aplicação será de fácil uso, sem necessidade de instalação de ferramentas adicionais para que seja possível atingir o seu correto funcionamento. Além disso, possuirá uma política de organização de código e nomeação de componentes padronizada a fim de facilitar a manutenção por outros.

6.1. Uso de versões atuais das tecnologias

A aplicação utilizará versões das tecnologias de desenvolvimento compatíveis com os principais brownsers: google chrome, firefox e internet explorer.

6.2. Boas Práticas

O código da aplicação contará com uma boa indentação, assim como nomes significativos para os componentes e identificadores obedecendo convenções, nesse caso, os nomes dos componentes terão as primeiras letras maiúsculas.

7.Restrições de Design

Para garantir maior suportabilidade da aplicação a mesma se comprometerá com a implementação de responsividade entre os componentes. Assim, não irá restringir o uso de ferramentas por limitação básica de hardware, como tamanho da tela e disposição ruim dos componentes.

7.1 Linguagem de programação

Será utilizada a linguagem de programação Javascript, com o framework Veu.js para fazer todo o design do sistema, contando com as composições do bootstrap e css para deixá-lo amigável para o usuário.

7.2 Responsividade

O sistema deverá apresentar um design responsivo ao hardware utilizado pelo usuário.

7.3 Padrão SPA

A aplicação deverá seguir um padrão SPA de modo a tornar a aplicação mais agradável e fluida para o usuário.

8.Requisitos Legais

8.1 Código Open Source

O código da aplicação deverá ser open source e gratuito de maneira que outros contribuidores possam auxiliar no seu posterior desenvolvimento ou manutenção, isso será expresso através da licença MIT