Você está na página 1de 10

Samuel Andrade de Araújo

João Victor Rocha de Souza


José Anderson Ferraz de Arruda
José Sicupira Neto de Morais

PRD - AstroLab

Cajazeiras, Paraíba
2023
Sumário

Introdução e objetivos..............................................................................................................2
Stakeholders..............................................................................................................................2
Requisitos funcionais................................................................................................................2
User stories........................................................................................................................... 2
Requisitos não funcionais........................................................................................................ 4
Critérios de aceitação............................................................................................................5
Gerenciamento de riscos.......................................................................................................... 6

1
Introdução e objetivos

O presente documento descreve os requisitos para uma rede social para


comunicação/observação de eventos astronômicos, intitulado de AstroLab. Como tal, se
descreve os detalhes de como se dará sua implementação e os critérios a serem levados em
consideração por cada stakeholder, tanto os desenvolvedores como clientes.
O AstroLab é uma rede social para interessados em eventos astronômicos, onde o
público geral pode saber com antecedẽcia de eventos próximos e também compartilhar seus
próprios conteúdos (sejam comentários ou compartilhar informações sobre outros eventos
astronômicos) para os demais usuários.

Stakeholders

Os stakeholders (termo do inglês que significa literalmente partes “interessadas”) se


refere a cada indivíduo envolvido com o projeto que deve estar envolvido de alguma forma
com o desenvolvimento da aplicação. Aqui serão descritos todos os stakeholders relacionados
ao projeto.
Os usuários finais do produto serão indivíduos interessados em tópicos relacionados a
astronomia como um todo, independente de fatores externos como idade ou localização.
Além disso, entidades e organizações poderão ter acesso às funcionalidades do sistema, não
apenas indivíduos. Para isso, as funcionalidades padrão devem ser desenvolvidas focando nas
necessidades deste público alvo.

Requisitos funcionais

User stories

Publicação
O usuário, ao clicar em um botão, deve ser capaz de poder enviar um texto para a aplicação,
para que a mesma seja vista por todos dentro da aplicação.

No momento de adicionar, deve ser possível acrescentar uma ou várias fotos, que serão
exibidas em conjunto com o texto.

Também, é fundamental que os usuários tenham a capacidade de acessar facilmente as


publicações compartilhadas por outros membros da aplicação.

Além disso, deve ser capaz de poder apagar fotos que já publiquei, para que a mesma não
seja mais acessível dentro da aplicação.

2
Ao clicar em um botão da publicação, deve ser possível adicionar um comentário a mesma,
que deverá ser visível a todos os usuários que acessem ela.

Calendário de eventos astronômicos

Todo usuário da aplicação deve conseguir acessar um calendário de eventos astronômicos,


padrão para todos os usuários.

Esse calendário não poderá ser editado pelos usuários, os mesmos só poderão visualizar os
eventos mostrados.

Ao clicar em um referente dia da semana, do qual possui algum tipo de evento, será aberto
uma janela onde os usuários poderão visualizar uma descrição sobre do que se trata e na
mesma janela, terá a opção de clicar em um ícone de sino, para criar uma notificação de
lembrete para ser enviado por e-mail na data programada. Ao clicar fora da janela, ela fecha e
o calendário voltará a ser exibido novamente.

Sistema de compartilhamento de publicações e perfil

Deve ser possível clicar em um botão em determinada publicação, para que o usuário escolha
como ele quer compartilhar ela, dentre essas opções, devem estar: redes sociais em destaque,
e uma opção de criar um link que redireciona para essa publicação.

Sistema de cadastro de usuários

Todo interessado que deseja utilizar todas as funcionalidades deverá obrigatoriamente fazer
um cadastro no AstroLab.

Usuário que não possui cadastro, só poderá visualizar as publicações de outras pessoas, mas
não terão permissão para acessar o perfil de outros usuários, o calendário de eventos, e não
poderão fazer nenhum tipo de interação em publicações. Onde ficará restringido somente a
visualizar e a compartilhar o link da postagem.

O usuário ao entrar na tela de cadastro terá duas opções, clicar no botão de login caso o
mesmo já possua uma conta, ou poderá preencher o formulário de cadastro, que solicitará um
e-mail, nome de usuário, nome e sobrenome, data de nascimento, senha e confirmar senha.
Caso o usuário não queira realizar um cadastro, ele terá uma opção encima do formulário, ao
qual ele poderá se conectar com uma conta do Google, ao clicar na opção, irá aparecer uma
janela em que ele poderá escolher um e-mail, em seguida ele poderá alterar o nome de
usuário ou permanecer com o que foi gerado ao logar na conta do Google.

3
Requisitos não funcionais

Desempenho
O sistema deve permitir a execução dos requisitos funcionais de forma rápida, leve e suave,
porém, com qualidade, eficiência e satisfação, como retorno e atualização de dados. Tendo
em mente que toda funcionalidade que envolva manipulação de dados acessíveis pelo
usuário, haja meio de confirmação das ações. As notificações de eventos devem ser enviadas
o mais breve possível.
Critérios:
● Tempo de carregamento de novas páginas 2-3 segundos, taxa de erro de até 90% dos
casos;
● Suportar até 10.000 usuários simultâneos;
● Supondo uma quantidade de 200 GB por dia de dados transferidos, deve possuir ao
menos 400 GB de banda de rede por dia;

Acessibilidade
O sistema deve possuir inclusão acessível a todos os usuários, sendo compatíveis com
múltiplos dispositivos, com versões específicas para usuários com necessidades especiais e
possuir conteúdo acessível a todos.
Critérios:
● Atender as especificações do nível A da WCAG, tanto para fatores perceptíveis,
operáveis, compreensíveis ou robustos;

Segurança
O sistema deve garantir a segurança dos dados pessoais dos usuários e das informações que
serão publicadas. Além de buscar a segurança de estado emocional e autoral dos mesmos,
enquanto estiverem conectados na rede.
Critérios:
● Ameaças críticas ao banco de dados devem ser tratadas em até 30 minutos desde o
início da detecção do problema, sem falhas em 100% dos casos;
● Informações de usuários devem ser criptografadas no banco de dados (protocolo
TLS/SSL é uma opção), sem falhas em 100% dos casos;
● Comunicações devem ser criptografadas com algoritmos de chave de 256 bits, sem
falha em 100% dos casos;

Confiabilidade
O conteúdo do sistema deve possuir informações, como notícias, eventos e matérias
confiáveis, podendo deixar aberto apenas as publicações e interações inter-usuários, porém
sempre havendo a verificação de conduta das contas, desde que haja estabilidade no conteúdo
exibido. Além de verificações de contas organizacionais e a autenticidade de suas publicações
(cada publicação deve estar associada a quem a publicou, outros indivíduos não podem estar
associados a publicações sem nenhum relacionamento).
Critérios:

4
● Tempo de acesso a publicações recentes de até 1 minuto depois da publicação, sem
falhas em 70% dos casos;
● Tempo de atualização de respostas de mensagens pessoais de até 5 segundos, sem
falhas em até 90% dos casos;
● Tempo de acesso a fotos ou vídeos de 10 segundos no mínimo, sem falhas em até
80% dos casos;

Usabilidade
Os usuários cadastrados devem ter a liberdade de realizar publicações, interagir com outros
usuários por meio de comentários e acesso ao calendário de eventos. Usuários que não
possuírem cadastro no sistema, não poderão interagir na plataforma de forma direta e não
terão acesso ao calendário, já que não possuirão acesso ao sistema, porém, poderão visualizar
as publicações e compartilhá-las em outras plataformas através de links.
Critérios:
● Banco de dados deve receber solicitações quanto aos dados em 100% dos casos;
● Novos usuários devem ser cadastrados sem falhas em 100% dos casos e com no
mínimo 5-10 segundos da solicitação até o atendimento;

Manutenibilidade
O sistema deve ser mantido constantemente para resoluções de possíveis bugs e
aprimoramento com implementações futuras. Monitoramento de desempenho, gerenciamento
de acessibilidade, atualização e monitoramento constante dos dados e armazenamento dos
mesmos e aperfeiçoamento da segurança dos dados e das informações que circulam nos entre
os usuários.
Critérios:
● Cada nova versão deve manter-se estável (passível de ser utilizado) por minimamente
2 meses antes de cada nova versão;
● Em até 100% dos casos, bugs não devem afetar informações pessoais, conversas ou
publicações dos usuários de forma grave;

Tecnologias
As tecnologias a serem utilizadas para a aplicação, levando em consideração que o projeto é
uma aplicação mobile, são frameworks como React Native para o front-end, e Spring Boot
com Hibernate para o back-end, e postgresql como banco de dados.
Critérios:
● Deve ser compatível com tecnologias utilizadas na stack selecionada no desenvolvimento,
desde que sejam tecnologias ainda continuadas;

Critérios de aceitação
1. Requisito: O usuário deve ser capaz de realizar publicações.
Critério de aceitação: a taxa de falha no processo de publicação não deve exceder 5%.

2. Requisito: O usuário deve ser capaz de realizar login no sistema.


Critério de aceitação: a taxa de falha no processo de login não deve exceder 10%.

5
3. Requisito: O usuário deve receber notificação de determinado evento
Critério de aceitação: o usuário deve receber a notificação em 100% dos casos.

4. Requisito: O usuário deve conseguir compartilhar as publicações da aplicação.


Critério de aceitação: 100% o usuário deve ser capaz de gerar link para
compartilhamento, e em pelo menos 90% dos casos, deve ser possível compartilhar para
outras redes sociais.

Gerenciamento de riscos

Os riscos durante o desenvolvimento do projeto serão divididos em: financeiros,


técnicos, de escopo, de recursos humanos e riscos legais. Estes serão descritos à frente de
acordo com as especificações do projeto, as estratégias citadas serão tanto de prevenção como
de mitigação dos danos.

Riscos financeiros

Tipo de risco Descrição Estratégia

Durante as etapas de
O orçamento repentinamente
planejamento, frisar bem as
pode sofrer uma queda
Mudança no orçamento necessidades para a equipe
quanto ao que estava
financeira e evitar custos
previsto
desnecessários

Durante as etapas de
planejamento, deixar claro
Pode haver solicitações para
as etapas que demorarão
mudanças nos prazos de
mais tempo para serem
entrega estabelecidos, pode
Mudança na data limite concluídas, as que serão
afetar também os recursos
mais rápidas, e planejar a
financeiros de acordo com
gestão do tempo e
os custos previstos
orçamento visando a
flexibilidade

Durante o desenvolvimento,
Durante as etapas de
é possível que faltem
planejamento, realizar
recursos financeiros de
Falta de recursos análise de custos de acordo
maneira inesperada. Quase
inesperada com cada etapa do projeto
certo de acontecer caso haja
para evitar falta inesperada
uma mudança no orçamento
de recursos
e na data limite
Tabela 1: Riscos financeiros

6
Riscos técnicos

Tipo de risco Descrição Estratégia

Buscar durante a etapa de


planejamento uma stack
Pode ocorrer de membros da com a qual a equipe de
Equipe não acostumada equipe não conseguirem se desenvolvimento esteja
com stack de tecnologias adaptar a stack de melhor acostumada e
tecnologias escolhida realizar treinamentos para as
tecnologias menos
conhecidas

Os diferentes subprodutos
Realizar testes
desenvolvidos por cada
periodicamente entre as
Dificuldade na integração equipe (back end, front end,
diferentes etapas de criação
do sistema etc.) podem não estar bem
do produto para garantir a
integrados, recursos podem
integração
estar em falta

Alguma das tecnologias Utilizar tecnologias com


utilizadas pode ser menos risco de serem
Código legado por
descontinuada durante a descontinuadas e buscar
tecnologia descontinuada
produção ou mesmo depois opções viáveis para
de o produto ser lançado substituição

Tabela 2: Riscos técnicos

Riscos de escopo

Tipo de risco Descrição Estratégia

Pesquisar os interesses dos


usuários finais para garantir
Pode haver erros com o
que as necessidades serão
Definição inadequada do planejamento do escopo,
bem atendidas e realizar
escopo do projeto algo pode não ser bem
reuniões específicas com os
compreendido
stakeholders para garantir
que não haja erros

Pode haver erros na


implementação das Reuniões regulares devem
Erros na implementação funcionalidades por parte de ser realizadas para garantir a
do escopo algum dos envolvidos no boa compreensão por cada
processo de uma das partes
desenvolvimento

Mudanças inesperadas no Podem ocorrer mudanças no Definir bem quais as


escopo escopo do projeto durante o possíveis mudanças e se

7
desenvolvimento planejar caso ocorram, além
de manter o
desenvolvimento aberto às
mudanças, flexível. Também
definir os aspectos que não
podem sofrer mudanças
Tabela 3: Riscos de escopo

Riscos de recursos humanos

Tipo de risco Descrição Estratégia

Planejar a divisão de tarefas


e verificar as demandas
individuais para garantir que
A equipe pode não ser não haverá sobrecarga de
Falta de pessoal grande o bastante para lidar pessoas. Em caso de falta de
com as demandas pessoal é possível repensar
a data limite ou realizar
contratações (alterando o
planejamento financeiro)

Solicitar aviso prévio para


os que planejaram isto e
tentar renegociar a
demissão, buscar substitutos
Demissão de membros da Membros podem abandonar
se necessário for mas
equipe a equipe
primariamente treinar
membros menos experientes
para substituir os que
abandonarem a equipe

Para casos mais simples e


menos duradouros, dividir as
Algum membro pode ter que
Problemas de saúde demandas entre os demais
se ausentar por questões não
inesperado membros da equipe, para
previstas de saúde
casos mais sérios contratar
um substituto temporário
Tabela 4: Riscos de recursos humanos

Riscos legais

Tipo de risco Descrição Estratégia

Principalmente referente ao Realizar consultorias para


Problemas de
manejo de dados dos buscar estar em
conformidade com
usuários, podem haver conformidade com a
legislação vigente
inconformidades com a legislação

8
legislação vigente

Podem ocorrer mudanças Buscar consultorias para


com a legislação, saber acerca da
Mudanças na legislação necessitando alterar partes possibilidade de mudanças
vigente do projeto, principalmente na legislação e revisar os
referentes ao manejo de impactos que podem ser
dados dos usuários causados para gerenciar
Tabela 5: Riscos legais

Você também pode gostar