Especificação dos requisitos

1. Introdução

A organização desse documento baseia-se no padrão proposto por Wiegers e Beatty (2013)

1.1 Propósito

A especificação dos requisitos aborda os requisitos funcionais e principalmente os não funcionais do sistema, basicamente se aliando com outras técnicas de requisitos como a modelagem e a elicitação possibilitando ter uma margem mais robusta de alcançar os requisitos do sistema.

1.2 Convenções do documento

Não será utilizado nenhum padrão de escrita e/ou notação, será prezada a convenção proposta no documento de padrões dos requisitos.

1.3 Escopo do projeto

O gXchange, assim como já definido anteriormente nos seguintes documentos:

1.4 Referências

Documentos e recursos utilizados referenciados nesse documento:

2. Descrição geral

2.1 Pespectiva de produto

As características de pespectiva do produto podem ser encontradas no documento 5W2H.

2.2 Classes e características dos usuários

As características e perfis de usuário estão definidos no documento de personas.

2.3 Ambiente operacional

O ambiente operacional principal do produto serão os navegadores, seja mobile ou web, no caso dos mobiles é pensado o ambiente de PWA (Progressive Web Application), sendo que está pode coexistir com Android e IOS.

Seguindo os padrões de DevOps tanto o Front-end quanto a API serão fornecidas para executarem dentro de containeres Docker e utilizando o orquestrador de container Docker Compose. Não foi decidido ainda qual servidores hospedarão o aplicativo.

2.4 Limitações de design e implementação

Dada as condições e o conhecimento dos integrantes as linguagens de programação que serão utilizadas são: Typescript e Python, utilizando React e Django como respectivos frameworks.

Será utilizada a biblioteca material-ui/core para a padronização dos componentes e seu reuso. Será utilizada também para realização de requisições a biblioteca Axios

Para o contexto da API no back-end, será utilizado o Django REST framework e o pacote REST framework JWT Auth.

2.5 Dependências e suposições

Para o sistema de email, será utilizado o sendgrip.

3. Funcionalidades do Sistema

Será convencionado os graus de granularidade do sistema como sendo:

User Story (História de usuário): algo que pode ser desenvolvido em uma iteração (Sprint)
Epic (Épico): pode ser um conjunto de histórias de usuário ou um conjunto de épicos menores
Feature (funcionalidade): Grupo de capacidades do sistema que agregam valor ao usuário. Seja:
- Uma história de usuário
- Um conjunto de histórias de usuário
- Um épico
- Um conjunto de épicos

3.1 Controle de conta

3.1.1 Descrição

O usuário deve ser capaz de criar uma conta, editar as informações pessoais, desativar ou excluir a sua conta. Além de poder realizar login no sistema utilizando suas credenciais. Possui prioridade Alta.

3.1.2 Requisitos funcionais

RF-01
RF-02
RF-03
RF-24
RF-25
RF-29
RF-30
RF-31

3.2 Controle de anúncios

3.2.1 Descrição

O usuário, como vendedor, deve ser capaz de criar um anúncio, editar suas informações, excluir o anúncio e visualizar todos seus anúncios. Possui prioridade Alta.

3.2.2 Requisitos funcionais

RF-08
RF-12
RF-19
RF-20
RF-39

3.3 Feed de anúncios

3.3.1 Descrição

O usuário deve ser capaz de acessar, visualizar e filtrar o feed contendo os anúncios disponíveis e também visualizar um anúncio específico. Possui prioridade Alta.

3.3.2 Requisitos funcionais

RF-07
RF-17
RF-26
RF-27
RF-28
RF-36

3.4 Perfil de usuário

3.4.1 Descrição

O usuário deve ser capaz de visualizar o perfil de outros usuários. Possui prioridade Média.

3.4.2 Requisitos funcionais

RF-33

3.5 Avaliação de usuário

3.5.1 Descrição

Um usuário, seja vendedor ou comprador, após a interação, deve ser capaz de avaliar o outro usuário envolvido. Possui prioridade Média.

3.5.2 Requisitos funcionais

RF-05
RF-06
RF-41

3.6 Denúncias do usuário

3.6.1 Descrição

Um usuário, seja vendedor ou comprador, após a interação, deve ser capaz de reportar o outro usuário envolvido ou o anúncio em questão. Possui prioridade Média.

3.6.2 Requisitos funcionais

RF-04
RF-09
RF-10
RF-13
RF-14

3.7 Moderador do sistema

3.7.1 Descrição

Um usuário, como moderador, deve ser capaz de visualizar, remover denúncias, deve ser capaz de invalidar, validar e excluir anúncio, deve ser capaz de banir usuários. Possui prioridade Baixa.

3.7.2 Requisitos funcionais

RF-15
RF-22
RF-23
RF-34

3.8 Notificar usuário

3.8.1 Descrição

Um vendedor deve ser notificado das alterações de estado dos seus anúncios e de mensagens recebidas, um comprador deve ser notificado quando o anúncio que ele reportou foi invalidado. Possui prioridade Baixa.

3.8.2 Requisitos funcionais

RF-16
RF-18
RF-21

3.9 Chat de usuários

3.9.1 Descrição

Um usuário, como comprador, deve ser capaz de enviar mensagens para um vendedor por meio de um anúncio, visualizar as mensagens enviadas e receber mensagens. Um usuário, como vendedor, deve ser capaz de visualizar os chats de anúncios e as conversas de cada chat. Possui prioridade Alta.

3.9.2 Requisitos funcionais

RF-11
RF-35

3.10 Qualidade de mídia

3.10.1 Descrição

Um usuário deve ser garantido pelo sistema que a qualidade das mídias de um anúncio são boas. Possui prioridade baixíssima.

3.10.2 Requisitos funcionais

RF-37
RF-38

3.11.1 Descrição

Um usuário deve ser capaz de realizar login utilizando a impressão digital. Possui prioridade baixíssima.

3.11.2 Requisitos funcionais

RF-32

3.12 Ajuda e suporte

3.12.1 Descrição

Um usuário deve ser capaz de acessar a seção de ajuda e suporte do sistema. Possui prioridade baixa.

3.12.2 Requisitos funcionais

RF-40

4. Requisitos de dados

4.1 Modelo de dados lógicos

Posteriormente, será definido um diagrama entidade relacionamento. Será utilizado também o diagrama de classe.

4.2 Dicionário de dados

Posteriormente, será definido um dicionário de dados.

4.3 Relatórios

No momento, não há propósito de extrair relatórios da aplicação.

4.4 Aquisição, integridade, retenção e disposição dos dados

Os dados serão obtidos diretamente do usuário, por meio da aplicação. Os mesmos serão mantidos na base de dados de um sistema gerenciador de banco de dados (SGBD). A integridade dos dados é de responsabilidade do SGBD. Os dados serão dispostos pela API somente para uso dentro do contexto da aplicação. Não há pretensão de realizar backup desses dados.

5. Requisitos de interface externa

Esta seção refere-se aos requisitos de interface que os componentes sejam de software ou não precisam para que aconteça a comunicação.

5.1 Interface do usuário

Será criado um documento que serve como guia de estilos posteriormente.

5.2 Interfaces de software

A comunicação com o banco de dados é abstraída pelo Django. Enquanto que o padrão de comunicação, por meio de requisições, será o padrão de requisições JSON.

Outras interfaces de software, estados e comunicações podem ser visualizadas nos diagramas UML da aba de modelagem.

5.3 Interfaces de hardware

O sistema não depende de nenhum hardware externo.

5.4 Interfaces de software

Para o sistema de email, deverá ser utilizado o sistema sendgrip com a restrição de 100 emails por dia.

Sobre o protocolo de rede, será utilizado o smtp para email e o https como protocolo de rede.

6. Atributos de qualidade

Os atributos de qualidade e seus requisitos estão listados no documento de atributos de qualidade.

7. Requisitos de Internacionalização e Localização

O produto está sendo pensado para a comunidade brasileira de jogadores isso implica a linguagem padrão como sendo português brasieiro.

Referências bibliográficas

WIEGERS, Karl; BEATTY, Joy. "Software Requirements". Microsoft Press, 2013.

Versionamento

Versão	Data	Modificação	Motivo	Autor
1.0	05/03/2021	Criação do documento	Especificar os requisitos não funcionais	Igor Paiva, Rhuan Queiroz, Thiago Guilherme, Thiago Lopes e Washington Bispo