US20 - pedrocastrosousa/sem5pi-23-24-grupo59 GitHub Wiki

US 20 - Como potencial utente do sistema (ex., aluno, docente) pretendo registar-me como utente do sistema

1. Context

É a primeira vez que esta funcionalidade está a ser implementada. Está incluida no sprint C do projeto RobDroneGo

2. Requirements

US 20 Como potencial utente do sistema (ex., aluno, docente) pretendo registar-me como utente do sistema

2.1 Customer Specifications and Clarifications

From the client clarifications:

Question_1 (Thursday, 14 de December de 2023 às 15:20 --> Na Us de registo de um utente na aplicação deve ser apresentado a este a política de privacidade antes ou depois de ele preencher a sua informação? E caso o mesmo não a aceite como devo proceder, aviso que o registo não é possível sem aceitar a política de privacidade e retorno à home page ou pergunto se se quer registar de novo?

Response_1 --> No formulário de registo deve ser pedida toda a informação e apresentada uma checkbox para aceitação da política de privacidade. No texto dessa checkbox deve existir um link para a política de privacidade. O preenchimento da checkbox é obrigatório e se não for preenchido deve ser apresentada uma mensagem

Question_2 (Thursday, 14 de December de 2023 às 15:20 --> No âmbito desta US o objetivo é realizar o registo de um utente no sistema. Este registo irá criar um pedido de registo que, mais tarde será, ou não, aceite por um administrador de sistema. Em relação a este pedido de registo, para além da informação do utilizador em questão, que outra informação será relevante guardar? (ex: timestamp)

Response_2 --> no caso do pedido de registo apenas a data do pedido. se de um ponto de vista tecnico entenderem necessário guardar outra informação não haverá problema. no caso das aprovações/recusas dos pedidos de registo deve obviamente ser guardada informação sobre que utilizador e quando (data e hora) tomou a decisão

Question_3 (Tuesday, 5 de December de 2023 às 20:01--> O cliente em uma outra resposta relativamente às US 10 e 20 disse que para o registo de utentes, seriam necessarios o nome, email, telefone e numero de contribuinte. Então nós estamos na duvida como seria integrada a US 750 com a US 20 e 100. Nós pensamos em um registo por passos, basicamente o utente primeiramente se registaria com a sua conta google, por exemplo, e depois apareceria um form para completar o registo, onde então iria pedir os restantes dados mencionados. Gostavamos de saber a sua opinião/sugestão em relação a isto.

Response_3 --> no caso de usarem um fornecedor de IAM, ex., google, no registo de utentes, podem faze-lo por passos inciando pela autenticação no IAM e posteriormente pela recolha dos dados mencionados

Question_4 (Thursday, 30 de November de 2023 às 21:38--> Como pretende que a atribuição de um Role seja feito? 1. Durante o registo do utente pelo Administrator (US10) 2. Durante o registo do utente pelo próprio utente (US20) 3. Durante a aprovação do registo do utente pelo Administrator (US80)

Response_4 -->o administrador atribui o papel na criação de utilizadores. os utilizadores que utilizem a funcionalidade de registo serão sempre do tipo "utente"

Question_5 (Saturday, 2 de December de 2023 às 17:11--> Que dados são necessários para a criação/registo de um utilizador, para além do seu Role?

Response_5 -->o criação de utilizadores e registo de utilizadores são dois casos de uso diferentes e com necessidades distintas. a criação de utilizadores serve para os administradores de sistema criarem os diversos utilizadores de backoffice do sistema num dos papeis designados, ex., gestor de campus, gestor de frota, gestor de tarefas o registo de utentes serve para o registo de utilizadores com o papel utente em ambos os casos será necessário obter nome, email e telefone. no registo de utentes deve adicionalmente ser recolhido o número de contribuinte para faturação de serviços apenas serão aceites emails da organização, ex., isep.ipp.pt. NOTA: a parametrização do dominio de email aceite deve ser mantida fora do código fonte do projeto, ex., ficheiro de propriedades ou variavel de ambiente

2.3. Acceptance Criteria

NA

2.4. Dependencies

NA

3. Analysis

DoR:

Esta US pode ser iniciada quando:

For estudado o código de funcionamento dos users na aplicação e pensar numa solução para a resolução da user story.

DoD:

Esta US será dada como concluída quando:

O frontEnd dos utentes estiver implementado e adicionada a opção criação de uma conta escolhendo um role de utente ex Aluno, docente ou funcionário.

4. Design

Design

5. Implementation

NA

6. Integration/Demonstration

NA

7. Observations

NA

⚠️ **GitHub.com Fallback** ⚠️