G17 G13 Fase3 Relatório 2

Licenciatura em Engenharia Informática e Licenciatura
em Informática e Gestão de Empresas
Conceção e Desenvolvimento de Sistemas de Informação
Relatório de Projeto Super Despensa - Recrutamento
Catarina Ferreira da Silva
Francisco Santana Guimarães
João Filipe Marques Costa
Bernardo Teixeira
Nuno Geada
Zózimo Junior
@2022-2023
CDSI Projecto -V1.2-2023.03.09 - Relatório – Pág.
Índice
<<Antes da entrega de cada fase do projecto/relatório, têm de actualizar
este índice geral>
1. Instruções a considerar...................................................................................................13
2. Gestão de projeto...........................................................................................................14
2.1 Identificação dos grupos.............................................................................................14
2.1.1 Identificação do grupo analista, autor da especificação (Fase 1): 17..............14
2.1.2 Identificação do grupo autor da implementação (Fase 2): ___________.......15
2.1.3 Identificação do grupo autor da execucação dos testes (Fase 3): ___________
16
2.2 Planeamento dos entregáveis.....................................................................................17
3. Identificações de eventuais dificuldades........................................................................18
3.1 Maiores dificuldades encontradas na fase 1..............................................................18
3.4 Sugestões de melhoria para a unidade curricular......................................................20
4. Conceção da solução – FASE 1........................................................................................20
4.1 Diagrama de classes....................................................................................................20
4.2 Modelo de dados e validações....................................................................................24
4.3 Gestão de definição, análise, aprovação e publicação de vaga..................................66
4.3.1 Diagrama(s) de modelização do(s) processo(s)...............................................66
4.3.2 Diagrama de transição de estados...................................................................69
4.3.3 Diagrama de casos de uso................................................................................70

4.3.4 Especificação de requisitos..............................................................................72
4.3.4.1 Resumo executivo do grupo de funcionalidades.......................................72
4.3.4.2 Especificação do grupo de funcionalidades do Candidato........................73
4.3.4.2.1 Especificação das funcionalidades do Candidato para o Front-End.......73
4.3.4.2.2 Funcionalidades para o Front-End do grupo de funcionalidades de

Candidato...............................................................................................................74
4.3.4.2.3 Especificação da Funcionalidade “Login” de Candidato.........................75
4.3.4.2.4 Especificação da Funcionalidade “Criar Registo Dados Pessoais” de

Candidato...............................................................................................................75
4.3.4.2.5 Mockup dos ecrãs de Front-End.............................................................76
4.3.4.3 Especificação do grupo de funcionalidades da Vaga.................................78
4.3.4.3.1 Especificação das funcionalidades de Vaga para o Front-End..............78
Especificação da Funcionalidade “A” de <G_func.1> (substituir pelo nome

da funcionalidade)..............................................................................................79
Especificação da Funcionalidade “A” de <G_func.1> (substituir pelo nome

da funcionalidade)..............................................................................................80
Especificação da Funcionalidade “B” de <G_func.1> (substituir pelo nome da

funcionalidade) 81
Especificação da Funcionalidade “C” de <G_func.1> (substituir pelo nome da

funcionalidade) 82
4.3.4.3.2 Mockup dos ecrãs de Front-End.............................................................82
4.3.4.3.3 Especificação das funcionalidades de <G_func.1> para o Back-End.83
Especificação da Funcionalidade “Publicar Vaga” da Vaga...............................86
Especificação da Funcionalidade “Fecho automático da Vaga” da Vaga..........87
4.3.4.3.4 Mockup dos ecrãs de Back-End..............................................................87
4.3.5 Especificação de testes....................................................................................89

4.3.5.1 Condições de execução dos testes.............................................................89
4.3.5.2 Especificação dos Testes do Grupo de Funcionalidades <G_func.1>

(substituir pelo nome da funcionalidade).....................................90
4.4 Gestão de seleção e avaliação de candidaturas.........................................................91
4.4.1 Diagrama(s) de modelização do(s) processo(s)...............................................91
4.4.2 Diagrama de transição de estados...................................................................93
4.4.3 Diagrama de casos de uso................................................................................94
4.4.4 Especificação de requisitos..............................................................................97
4.4.4.1 Resumo executivo do grupo de funcionalidades.......................................97
4.4.4.2 Especificação do grupo de funcionalidades de Avaliação Candidatura.....98
4.4.4.2.1 Especificação das funcionalidades de Avaliação Candidatura para o

Front-End................................................................................................................98
4.4.4.2.2 Funcionalidades para o Front-End do grupo de funcionalidades de

Avaliação Candidatura..........................................................................................99
4.4.4.3 Especificação do grupo de funcionalidades de Candidatura.....................99
4.4.4.3.1 Especificação da Funcionalidade “Consultar Candidatura” de

Candidatura..........................................................................................................100
4.4.4.3.2 Especificação das funcionalidades de Avaliação Candidatura para o

Back-End103
4.4.4.3.3 Especificação da Funcionalidade “Avaliação de Candidatura” de

Avaliação Candidatura.........................................................................................104
4.4.4.3.4 Especificação da Funcionalidade “Adicionar Avaliação” de

Avaliação Candidatura.........................................................................................106
4.4.4.3.5 Mockup dos ecrãs de Back-End............................................................107
4.4.4.3.6 Especificação das funcionalidades de Contacto para o Back-End........109
4.4.4.3.7 Especificação da Funcionalidade “Contactos” de Contacto.......110

4.4.4.3.9 Especificação das funcionalidades de Candidatura para o Back-End...112
4.4.4.3.10 Especificação da Funcionalidade “Consultar Candidatura” de

Candidatura 112
4.4.4.3.11 Mockup dos ecrãs de Back-End........................................................114
4.4.5 Especificação de testes..................................................................................114
4.4.5.1 Condições de execução dos testes...........................................................114
Especificação dos Testes do Grupo de Funcionalidades <G_func.1>

(substituir pelo nome da funcionalidade)...................................115
4.5 Gestão de apresentação, negociação e contratação................................................115
4.5.1 Diagrama(s) de modelização do(s) processo(s).............................................115
4.5.2 Diagrama de transição de estados.................................................................117
4.5.3 Diagrama de Casos de uso.............................................................................118
4.5.4 Especificação de requisitos............................................................................119
4.5.4.1 Resumo executivo do grupo de funcionalidades.....................................120
4.5.4.2 Especificação do grupo de funcionalidades de Contrato.........................120
4.5.4.2.1 Especificação das funcionalidades de <G_func.1> para o Front-End

120
Especificação da Funcionalidade “X” de <G_func.1> (substituir pelo nome da

funcionalidade) 122
Especificação da Funcionalidade “Y” de <G_func.1> (substituir pelo nome da

funcionalidade) 123
Especificação da Funcionalidade “Z” de <G_func.1> (substituir pelo nome da

funcionalidade) 123
4.5.4.2.2 Mockup dos ecrãs de Front-End...........................................................124
4.5.4.2.3 Especificação das funcionalidades de Contrato para o Back-End. . .125
Especificação da Funcionalidade “Contactar Candidato” de Contrato............126

Especificação da Funcionalidade “Analisar Resposta” de Contrato................127
Especificação da Funcionalidade “Gerar Contrato” de Contrato....................128
Especificação da Funcionalidade “Gerar Contrato” de Contrato (substituir pelo

nome da funcionalidade).................................................................................130
4.5.5.1 Condições de execução dos testes...........................................................132
4.5.5.2 Especificação dos Testes do Grupo de Funcionalidades <G_func.1>

(substituir pelo nome da funcionalidade)...................................133
5. Apreciação crítica da conceção da solução – FASE 1....................................................133
5.1 Diagrama de classes..................................................................................................134
5.2 Gestão de definição, análise, aprovação e publicação de vaga................................135
5.2.1 Modelização do(s) processo(s).......................................................................135
5.2.2 Diagrama(s) de transição de estados.............................................................136
5.2.3 Diagrama(s) de casos de uso..........................................................................137
5.3 Gestão de seleção e avaliação de candidaturas.......................................................140
5.4 Gestão de apresentação, negociação e contratação................................................145

5.5 Avaliação global da especificação face ao implementado........................................150
6. Desenvolvimento da solução - FASE 2..........................................................................153
6.1 Modelo de dados......................................................................................................153
6.2 Ecrãs em OutSystems................................................................................................154
6.3 Manual de utilizador.................................................................................................154
6.4 Perfil de utilizadores..................................................................................................155
6.5 Serviço API REST........................................................................................................155
6.6 Lista de procedimentos Batch...................................................................................156
7. Apreciação auto-crítica do desenvolvimento da solução – FASE 2..............................157
7.1 Modelo de dados implementado..............................................................................157
7.2 Software implementado...........................................................................................158
8. Execução dos testes – FASE 3.......................................................................................159
8.1 Testes do grupo de funcionalidades “<G_func.1>” (substituir pelo nome da

funcionalidade)....................................................................................................................159

funcionalidade)....................................................................................................................160
9. Apreciação crítica dos Resultados dos Testes..............................................................161

Índice de figuras
<Antes da entrega de cada fase do projecto/relatório têm de actualizar
este índice das figuras>
Figura 1. Diagrama de classes................................................................................................21
Figura 2. Diagrama de processos de <completar... >.............................................................23
Figura 3. Diagrama de transição de estados do processo de <completar... >.......................24
Figura 4. Diagrama de casos de uso do processo de <completar... >....................................25
Figura 5. Enquadramento das classes respeitante às funcionalidades <completar ... >.......28
Figura 6. Enquadramento dos casos de uso respeitante às funcionalidades <completar ... >
................................................................................................................................................28
Figura 7. Enquadramento das classes respeitante às funcionalidades <completar ... >.......32
................................................................................................................................................32
Figura 9. Diagrama do processo de <completar... >..............................................................39
Figura 10. Diagrama de transição de estados do processo de <completar... >.....................40
Figura 11. Diagrama de casos de uso do processo de <completar... >..................................41
Figura 12. Enquadramento das classes respeitante às funcionalidades <completar ... >.....43
................................................................................................................................................43
................................................................................................................................................48
Figura 16. Diagrama do processo de <completar... >............................................................53
Figura 17. Diagrama de transição de estados do processo de <completar... >.....................53
CDSI Projecto-V2.1-2022.03.18 - Relatório – Pág.

Figura 18. Diagrama de casos de uso do processo de <completar... >..................................54
................................................................................................................................................57
................................................................................................................................................61
Figura 23. Esquema relacional da base de dados implementada..........................................86

Índice de tabelas
<Antes da entrega de cada fase do projecto/relatório têm de actualizar
este índice de tabelas>
Tabela 1. Identificação dos membros do grupo analista, autor da especificação.................13
Tabela 2. Identificação dos membros do grupo autor da implementação............................14
Tabela 3. Identificação dos membros do grupo autor da execução dos testes....................15
Tabela 4. Identificação dos entregáveis por fase...................................................................16
Tabela 5. Identificação e classificação do motivo das eventuais dificuldades encontradas na

fase 1......................................................................................................................................17

fase 2......................................................................................................................................18

fase 3......................................................................................................................................18
Tabela 8. Descrição geral dos campos do modelo de dados.................................................23
Tabela 9. Grupo de funcionalidades do processo de gestão de gestão de definição, análise,

aprovação e publicação de vaga............................................................................................72
Tabela . Regras de funcionamento das sub-funcionalidades de “A” do módulo de Back-End.

................................................................................................................................................78
Tabela . Regras de funcionamento das sub-funcionalidades de “A” do módulo de Back-End.

................................................................................................................................................79
Tabela 16. Regras de funcionamento das sub-funcionalidades de “B” do módulo de Back-

End..........................................................................................................................................80
Tabela 17. Regras de funcionamento da Funcionalidade “C”...............................................81
Tabela 14. Funcionalidades para Back-End do grupo de funcionalidades da Vaga.............83
Tabela 18. Especificação dos testes a realizar para o grupo de funcionalidades

<G_func.1>.......................................................................................................................89
Tabela 19. Grupo de funcionalidades do processo de gestão de seleção e avaliação de

candidaturas...........................................................................................................................97
<G_func.1>.....................................................................................................................114
Tabela 29. Grupo de funcionalidades do processo de gestão de apresentação, negociação e

contratação..........................................................................................................................119
Tabela 30. Funcionalidades para o Front-End do grupo de funcionalidades de

<G_func.1>....................................................................................................................120
Tabela 31. Regras de funcionamento das sub-funcionalidades de “X” do módulo de Front-

End........................................................................................................................................121
Tabela 32. Regras de funcionamento das sub-funcionalidades de “Y” do módulo de Front-

End........................................................................................................................................122
Tabela 33. Regras de funcionamento da Funcionalidade “Z”..............................................123
Tabela 34. Funcionalidades para Back-End do grupo de funcionalidades de Contrato......125
Tabela 35. Regras de funcionamento das sub-funcionalidades de “Contactar Candidato” do

módulo de Back-End............................................................................................................126
Tabela 36. Regras de funcionamento das sub-funcionalidades de “Y” do módulo de Back-

End........................................................................................................................................126
Tabela 35. Regras de funcionamento das sub-funcionalidades de “Enviar Processo de

Assinatura” do módulo de Back-End...................................................................................127
Tabela 37. Regras de funcionamento da Funcionalidade “Z”..............................................129

<G_func.1>.....................................................................................................................132
Tabela 39. Descrição geral dos campos do modelo de dados.............................................152
Tabela 40. informação sobre os ecrãs implementados.......................................................153
Tabela 41. Lista dos serviços externos chamados...............................................................155
Tabela 42. Lista dos procedimentos Batch..........................................................................155
Tabela 43. Testes realizados para o grupo de funcionalidades “<G_func.1>” (substituir

pelo nome da funcionalidade)............................................................................................158

Tabela 44. Testes realizados para o grupo de funcionalidades ”<G_func.2>” (substituir
pelo nome da funcionalidade)............................................................................................159
1. Instruções a considerar
Estas instruções são de cumprimento obrigatório. Os estudantes dos grupos cujos
relatórios não cumpram as indicações serão penalizados na nota final:
 Podem (e em várias situações será necessário) ser adicionadas novas páginas ao

relatório, mas não podem ser removidas páginas. Se uma secção não for relevante,
fica em branco - indicando que não é necessária para o vosso projecto - e não pode
ser removida;
 O texto que está neste template não pode ser apagado, a não ser quando tal
estiver indicado. Se algo não for relevante para o grupo, devem escrever isso
mesmo ou deixar em branco;
 Todas as secções têm de iniciar-se no topo de página (colocar uma quebra de
página antes);
 A paginação tem de ser sequencial e não ter falhas;
 Os índices têm de ser actualizado antes da entrega do relatório;
 No capítulo de gestão do projecto da unidade curricular (capítulo 2), tem de constar
toda a informação solicitada, nomeadamente todas as fotografias de todos os
elementos dos dois grupos; a tabela de cada grupo deve caber numa única página,
pelo que as fotos dos estudantes devem ser dimensionadas de forma a cumprir
este requisito;
 A formatação das cores das “zonas” (umas sombreadas, outras não sombreadas)
não pode ser alterada;
 Na fase 1, o grupo que primeiro edita o documento deverá preencher os capítulos
2.1.1, 2.2, 3.1 e 4 deste template do relatório de projeto Super Despensa.
 Na fase 2, o grupo que irá desenvolver a solução deverá preencher os capítulos
2.1.2, 2.2, 3.2, 5, 6 e 7.
 Na fase 3, o grupo que executa os testes deve preencher os capítulos 2.1.3, 2.2. 3.3,
3.4, 8 e 9.

2. Gestão de projeto
2.1 Identificação dos grupos
A tabela de cada grupo deve caber numa única página, pelo que as fotos dos estudantes
devem ser dimensionadas de forma a cumprir este requisito.
2.1.1 Identificação do grupo analista, autor da especificação (Fase 1): 17
Tabela 1. Identificação dos membros do grupo analista, autor da especificação.
Tempo total dedicado à

Nº especificação e ao
Nome Foto
Estudante preenchimento deste
relatório (em minutos)
66996 Priyal Jivan 2095
100533 Ivo Rodrigues 2040
100744 Filipa Romão 4505
103697 Filipe Almeida 2210
103708 Alexandre Silva 1920

104637 Inês Oliveira 2630
104759 Catarina Belo 3785

2.1.2 Identificação do grupo autor da implementação (Fase 2): 13
Tabela 2. Identificação dos membros do grupo autor da implementação.

especificação
e ao
Nº Estudante Nome Foto preenchiment
o deste
relatório (em
minutos)
105567 João Sequeira 2684 minutos
103974 Rafael Guedes 2692 minutos
104836 Tiago Ferreira 2793 minutos
105373 Bernardo Vasconcelos 2672 minutos
105404 Tiago Lopes 2803 minutos
105893 Vasco Araújo 2634 minutos

2.1.3 Identificação do grupo autor da execucação dos testes (Fase 3):
___________
Tabela 3. Identificação dos membros do grupo autor da execução dos testes.

Nº especificação e ao
Nome Foto
Estudante preenchimento deste
relatório (em minutos)
66996 Priyal Jivan
100533 Ivo Rodrigues
100744 Filipa Romão
103697 Filipe Almeida
103708 Alexandre Silva
104637 Inês Oliveira
104759 Catarina Belo

2.2 Planeamento dos entregáveis
Na Tabela 4 devem inserir as datas de início e de fim de cada atividade, à medida que são
realizados. As atividades correspondem à sequência de trabalho que cada grupo planear
realizar para concretizar cada fase (e.g. Analisar Caderno de Encargos, Modelizar BPM do
processo de vagas, Especificar Funcionalidades de Fron-End do processo de vagas).
Tabela 4. Identificação dos entregáveis por fase.
Fase Atividade Entregáveis Data Início Data Fim

Capítulo 2.1.1 o Capítulos 2.1.1, 2.2, 26/03/2023 26/03/2023
Capítulo 2.2 3.1 e 4 do relatório 26/03/2023 26/03/2023
Capítulo 3.1 de projeto 25/03/2023 25/03/2023
Fase 1 - Capítulo 4 18/03/2023 26/03/2023
o Modelos Signavio
Especificação Modelos 26/02/2023 26/03/2023
com modelação do
Signavio
projeto
Capítulo 2.1.1  Capítulos 2.1.2, 2.2, 30/03/2023 3/04/2023

Capítulo 2.2 3.2, 5, 6 e 7 do 3/04/2023 6/04/2023
Capítulo 5 relatório de projecto 6/04/2023 9/04/2023
Fase 2 - Capítulo 6 e 7 9/04/2023 12/04/2023
 Acesso a OutSystems
Implementação Acesso a 12/04/2023 27/05/2023
com implementação
OutSystems
do projeto
o Capítulos 2.1.3, 2.2.

3.3, 3.4, 8 e 9 do
Fase 3 – relatório de projecto
Execucação de o Relatório do
testes resultado dos testes
executados

3. Identificações de eventuais dificuldades
3.1 Maiores dificuldades encontradas na fase 1
Caso seja necessário, a Tabela 5 deve ser preenchida até ao final da fase 1, pelo grupo
autor da especificação, antes de entregar o relatório.
Tabela 5. Identificação e classificação do motivo das eventuais dificuldades encontradas na fase 1.
Classificação da
Dimensão de análise dificuldade (Baixa, Motivo
Média ou Alta)
Complexidade do caso de estudo Média Apesar de ser um processo
que na teoria é relativamente
simples, este revelou-se
confuso em alguns aspetos,
tendo várias nuances e casos
muito específicos que
dificultou o entendimento.
Adicionalmente, e dado que
os elementos do grupo já têm
uma perceção da realidade,
existiu um distanciamento em
relação ao enunciado;
Coordenação entre elementos da Baixa Sempre tentámos chegar a
equipa acordos, ouvindo a opinião de
todos e respeitando as nossas
particularidades, sendo que
conseguimos sempre chegar a
uma solução final validada por
todos os elementos. Nem
sempre é fácil fazer reuniões
gerais por isso decidimos
subdividir o grupo para tornar
mais fácil esta coordenação.
No entanto, existiu sempre,
pelo menos uma vez por
semana, uma reunião geral
para ponto de situação.
Preparação do relatório da Média Por ser um relatório muito
especificação extenso e complexo, existiram
algumas dificuldades no
raciocínio. Pelo facto de nos

termos dividido em
subgrupos, foi necessária uma
revisão final para ajustes de
formatação do documento.
Modelação de UML em Signavio Média A modelação UML foi, no
(mencionar os diagramas específicos) geral, simples de implementar,
no entanto, quando foram
feitos os mockup’s, foram
identificadas várias
alterações/melhorias a efetuar
no diagrama.
Modelação de BPM em Signavio Média/Alta A modelação BPM foi revista
várias vezes em conta para
chegarmos à solução ideal. Foi
também necessário aprender
técnicas de modelação no
decorrer da elaboração dos
diagramas. No entanto,
quando foram feitos os
mockup’s, foram identificadas
várias alterações/melhorias a
efetuar nos diagramas.
Template de Especificação de Média/Alta Inicialmente as especificações
Requisitos eram um tema confuso para
nós, mas após algumas horas
conseguimos entender a
lógica e a partir daí o trabalho
fluiu mais rapidamente.
Template de Especificação de Casos Média/Alta Inicialmente as especificações
de Testes eram um tema confuso para
nós, mas após algumas horas
conseguimos entender a
lógica e a partir daí o trabalho
fluiu mais rapidamente.
autor da implementação, antes de entregar o relatório.
Classificação da
Dimensão da análise dificuldade (Baixa, Motivo
Média ou Alta)
Criação da Base de dados em OutSystems Baixa Após a visualização e
estudos do curso de
Outsystems , a criação
da bd tornou-se um
processo muito fluído.
Inicialmente tivemos
um problema pois
tentámos criar as
tabelas todas através
de excel, no entanto
ocorriam erros pois
estas não estavam
populadas. No
entanto, assim que
começamos a criar a
BD manualmente
correu tudo direito.
Desenvolvimento da interface gráfica de Média Parte que ocupou
utilizador (GUI) em OutSystems provavelmente dois
terços do tempo que
dedicámos nesta fase
2.
Validação de campos em OutSystems Fácil As validações , como
formato de e-mail
válido ou campos
obrigatórios foram
simples. Também
utilizámos recursos
para exibir mensagens
de erro e orientar os
users na correção dos
dados.
Implementação de perfis de utilizadores Baixa Embora envolva
alguma lógica e
tempo, foi bastante
simples
Implementação de programas batch Média-baixa Embora a
implementação de
programas batch em
OutSystems possa
exigir um pouco mais
de trabalho em
comparação com o
desenvolvimento de
aplicações

tradicionais,
acábamos por
conseguir fazer em
algumas horas.
Integração do serviço API REST Baixa Não nos suscitou
nenhuns problemas ,
sendo que
recorremos aos
cursos outsystems
para perceber melhor
esta área
Complexidade da implementação Média Ao trabalhar com uma
boa equipa do outro
lado, o nosso papel na
parte da
implementação
tornou-se mais fácil,
no entanto houve
muitas dores de
cabeça na realização
desta implementação.
Coordenação entre elementos da equipa Baixa Comunicação ativa,
disponibilidade e
esforço foram as
características que
definiram o nosso
grupo. Podendo
sempre contar com o
nosso colega do lado,
estes projeto tornou-
se muito mais
acessível e
enriquecedor
Preparação do relatório da implementação Média/Baixa Relativamente à fase
1 do projeto, o
relatório é menos
extenso e está mais
em conta
relativamente ao
trabalho e tempo
dedicado à
implementação.
autor da execução dos testes, antes de entregar o relatório.
Classificação da
Dimensão análise dificuldade (Baixa, Motivo
Média ou Alta)
Teste da funcionalidade <substituir
pelo nome da funcionalidade>
Teste da funcionalidade ... <repetir
tantas vezes quantas
necessárias>
...
...
Complexidade da execução dos testes
Coordenação entre elementos da
equipa
Preparação do relatório de testes
<Adicionar linhas caso
necessário e substituir por
outras dimensões eventuais,
podem apagar este texto>
3.4 Sugestões de melhoria para a unidade curricular
No final do projecto, isto é, na fase 3, se pretenderem apresentar sugestões de melhorias

para o futuro desta unidade curricular podem fazê-lo nesta secção.
4. Conceção da solução – FASE 1

Nesta secção devem especificar a vossa solução do projecto da Super Despensa, de acordo
com documento do Caderno de Encargos que descreve os requisitos do projecto Super
Despensa – secção de recrutamento. Esta especificação é complementada com os
diagramas de modelização da solução que são solicitados em cada uma das secções
seguintes.
Os diagramas que vos são pedidos, completados com a vossa explicação, servirão aos
membros do outro grupo, na etapa da implementação, para saberem o que devem
implementar. Quanto mais claro e detalhado apresentarem este relatório, mais fácil será a

tarefa do grupo que fará a implementação. Da mesma forma, quanto mais clara e
detalhada for a especificação que irão receber do outro grupo, mais fácil será fazerem a
implementação da especificação do outro grupo. Assim, o presente relatório tem a
importante função de comunicação entre o grupo que especifica/modeliza a solução e o
grupo que irá implementar.
4.1 Diagrama de classes
<Têm de incluir uma imagem do diagrama UML de classes e escrever uma

explicação do diagrama que justifique as opções tomadas. Devem colocar a
imagem do diagrama de classes na totalidade para se entender a relação
entre as classes de suporte aos processos de:
o definição, análise, aprovação e publicação de vaga,

o seleção e avaliação de candidaturas,
o apresentação, negociação e contratação.
De seguida devem colocar um parágrafo que explique por palavras vossas o

que está representado no caso específico das classes de suporte a estes
processos. Devem igualmente juntar um parágrafo adicional que explique
opções de modelação>
A Figura 1 representa o conceito geral do processo da Super Despensa. No diagrama estão

representadas as classes de suporte aos processos de definição, análise, aprovação e publicação da
vaga, de seleção e avaliação de candidaturas e de apresentação, negociação e contratação.
As classes Vaga e Candidatura correspondem aos conceitos centrais dos processos de gestão de
vaga e de contratação, sendo que existem outros grupos de classes complementares.
Figura 1. Diagrama de Classes Super Despensa
Na Figura 2, as classes correspondem a tabelas de descrição da classe Pessoa que

representam chaves estrangeiras na implementação desta, enquanto tabela da base de dados.

Figura 2. Diagrama de classes simplificado da Pessoa
• Classes de caracterização associadas à Pessoa: correspondem às classes Género, Estado Civil,

Distrito e País. Estas classes correspondem a tabelas de descrições sendo que representam chaves
estrangeiras na implementação da classe Pessoa enquanto tabela da base de dados;
• Classe de relação entre pessoa e documentação: corresponde à classe Documentação, que por
sua vez está associada à classe Tipo Documento. Estas representam toda a documentação que cada
pessoa terá a fim de concretizar em qualquer processo de candidatura.
• Classe de relação entre pessoa e experiência: corresponde à classe Experiência, que por sua vez
está associada à classe Pessoa. Uma pessoa pode acumular várias experiências de trabalho em
várias entidades. A cada experiência, apenas é correspondida uma única pessoa. De notar também
que, associada a uma experiência, existe um Perfil por Categoria Profissional.
Na Figura 3, as classes representam a associação entre um colaborador e uma loja, sendo

que a classe Colaborador será a classe absorvente das chaves estrangeiras a esta associadas.
Figura 3. Diagrama de classes simplificado do Colaborador
• Classes de caracterização associadas ao Colaborador: corresponde à classe Categoria

Profissional. Esta classe representa uma chave estrangeira na implementação da Classe
Colaborador enquanto tabela da base de dados;
• Classe de relação entre Colaborador e restantes classes: a classe Categoria Profissional é a única
associação existente à classe Colaborador, no entanto, existem outras associações à primeira. A
Loja, Área Funcional, e Perfil, Perfil por Categoria Profissional, para além das relações entre ambas,
respetivamente, estão também associadas à classe Categoria Profissional, estando indiretamente
associadas à classe Colaborador.
Na Figura 4, as classes correspondem a tabelas de descrição das classes Candidatura e

Vaga, que representam chaves estrangeiras na implementação destas mesmas classes enquanto
tabelas da base de dados.

Figura 4. Diagrama de classes simplificado da Candidatura e da Vaga
• Classes de caracterização associadas à Candidatura: corresponde às classes Estado Candidatura,

Candidato, Motivo Fecho Candidatura e Vaga. Estas classes representam uma chave estrangeira na
implementação da Classe Candidatura enquanto tabela da base de dados;
• Classes de caracterização associadas à Vaga: corresponde às classes Estado Vaga, Colaborador e
Perfil por Categoria Profissional. Estas classe representam uma chave estrangeira na
implementação da Classe Vaga enquanto tabela da base de dados;
• Classe de relação entre Candidatura, Vaga e restantes classes: nas tabelas das classes Contacto,
Avaliação Entrevista e Contrato apenas poderão ser inseridos dados caso uma candidatura chegue
a determinado estado. Neste sentido, e para que tal aconteça, é necessário que:
o Para existir um registo na tabela Contacto, a candidatura deverá estar no estado “Pendente
de Contacto” ou “Para Contratação”;
o Para existir um registo na tabela Entrevista, a candidatura deverá estar no estado
“Pendente de Avaliação” ou “Pendente de Entrevista Final”;
o Para existir um registo na tabela Contrato, a candidatura deverá estar no estado “Em
Contratação”.
• Opções de Modelação: No âmbito da modelação dos diagramas BPMN, foi identificada a

necessidade de adicionar 11 classes, nomeadamente: Tipo Documento, Colaborador, Estado Vaga,
Alteração Estado Vaga, Contacto, Motivo Fecho Candidatura, Avaliação Estado Candidatura, Estado
Candidatura, Avaliação Entrevista, Candidato e User.
No que diz respeito à Vaga, podem, ou não, existir candidaturas, no entanto, existe um “Estado”
que tem obrigatoriamente “Alterações de Estado” durante o processo. A cada Vaga pertence um
único “Perfil por Categoria Profissional”.
Já a “Candidatura” só faz sentido perante a existência de uma “Vaga”, e, por isso, obriga a uma
única associação entre estas. Conforme descrito anteriormente, poderão, ou não, existir até 3
“Contactos” do tipo “Entrevista”, até 3 “Entrevistas”, mas apenas 1 “Contrato”, sendo que, os
“Contactos” e o “Contrato” estão associados a uma “Candidatura”, mas a “Avaliação Entrevista” só
pode estar associada a uma “Candidatura”. A “Candidatura” têm obrigatoriamente um “Estado”
que por sua vez poderá ter várias “Alterações Estado”. Relativamente ao “Motivo Fecho
Candidatura” aquando da abertura da “Candidatura”, não será preenchido, no entanto quando
ocorre o fecho existe a obrigatoriedade de preenchimento do mesmo. A “Avaliação Candidatura”
terá, no entanto, obrigatoriamente, um “Candidato”.
Cada classe/tabela contém os campos Criador Registo, Modificador Registo, Início Registo,
Alteração Registo e Estado Registo, para identificar a alteração a determinado registo, associar
uma data, o utilizador que criou ou atualizou esse registo dessa tabela, assim como o estado ativo
(A) ou inativo (I) desse registo, por forma a implementar o conceito de eliminação lógica,
respetivamente.
4.2 Modelo de dados e validações
A Tabela 8 deve descrever os campos do modelo de dados face às propriedades definidas

para as classes.
<O nome do campo corresponde ao nome do atributo da classe e o nome da

tabela corresponde ao nome da classe. Na descrição devem indicar o
significado do campo caso o nome do campo não seja explicito, além de que
devem indicar os campos sugeridos como chaves primárias e chaves
estrangeiras. Caso seja necessário dar uma indicação de restrições a
implementar na base de dados devem igualmente indicá-las na coluna
Descrição>.
Tabela 8. Descrição geral dos campos do modelo de dados.
Nome do campo Descrição Nome da Validações

tabela a
que
pertence o
campo
Loja  Único e Obrigatório (Chave
Código Identificador
Código Primária)
da Loja
 Obrigatório
Designação Nome da Loja
 Obrigatório
Distrito Distrito da Loja
 Obrigatório
Localidade Localidade da Loja
Morada Morada da Loja  Obrigatório

Data de Abertura da  Obrigatório
Data de Abertura
Loja
 Obrigatório
Estado Estado da Loja
 Obrigatório
 Deve ser preenchido pelo
Utilizador que realizou
Criador Registo sistema com o utilizador
a operação de criar
autenticado que criou o
registo
 Obrigatório
Utilizador que realizou  Deve ser preenchido pelo
a operação de sistema com o utilizador
Modificador Registo alteração
autenticado que alterou o
registo
 Obrigatório
Data de início da  Deve ser preenchido pelo
Início Registo criação do registo sistema com a data e hora da
criação do registo
 Obrigatório
Data de alteração do  Deve ser preenchido pelo
Alteração Registo registo sistema com a data e hora da
alteração do registo
 Obrigatório
 Deve ser preenchido com “A”
para “Ativo” ou “I” para
Estado do registo
Estado Registo “Inativo”, como suporte à
estratégia de eliminação
lógica

tabela a
que
pertence o
campo
Código Código Identificador  Único e Obrigatório (Chave
da Área Funcional Primária)
 Obrigatório (Chave
Código Loja Estrangeira da tabela Loja)
da Loja
Nome da Área  Obrigatório

Designação
Funcional
Data de abertura da  Obrigatório
Data Abertura
Área Funcional
Estado da Área  Obrigatório
Estado
Funcional
Código Empregado Estrangeira da tabela
do Código Empregado
Colaborador)
 Obrigatório
registo
 Obrigatório
Modificador Registo a operação de sistema com o utilizador
alteração autenticado que alterou o
registo
 Obrigatório
Área  Deve ser preenchido pelo
Data de início da
Início Registo Funcional sistema com a data e hora da
 Obrigatório
 Obrigatório
Estado do registo
lógica

tabela a

que
pertence o
campo
 Único e Obrigatório (Chave
Código Primária)
do Perfil
 Campo numérico
 Obrigatório
Tipo de Perfil (Técnico
Tipo Perfil  Apenas será possível
ou Comportamental)
selecionar um de cada vez
Descrição associada ao  Obrigatório
Designação
Tipo Perfil
 Permite NULL
Observação Observações
 Obrigatório
registo
 Obrigatório

registo
 Obrigatório

Início Registo
criação do registo sistema com a data e hora da
Perfil
 Obrigatório

Alteração Registo
registo sistema com a data e hora da
 Obrigatório

Estado Registo Estado do registo
“Inativo”, como suporte à
lógica
tabela a que
pertence o
campo
Código Indentificador  Obrigatório (Chave
Perfil
do Perfil Estrangeira da tabela Perfil)
Comportamental
Comportamental
Perfil Técnico
do Perfil Técnico Estrangeira da tabela Perfil)
Código Categoria
da Categoria Estrangeira da tabela
Profissional
Profissional Categoria Profissional)
 Obrigatório

Utilizador que realizou sistema com o utilizador
Criador Registo
registo
 Obrigatório
a operação de  Deve ser preenchido pelo
Modificador Registo alteração sistema com o utilizador
registo
 Obrigatório

Início Registo
criação do registo sistema com a data e hora
da criação do registo
 Obrigatório
Data de alteração do Perfil  Deve ser preenchido pelo

Alteração Registo por
registo Categoria sistema com a data e hora
Profissional da alteração do registo
 Obrigatório
 Deve ser preenchido com

“A” para “Ativo” ou “I” para

lógica

tabela a
que
pertence o
campo
Código Indentificador  Único e Obrigatório (Chave
Código
da Experiência Primária)
Nome da Entidade  Obrigatório
Nome Entidade cuja experiência foi
adquirida
Código Identificador  Obrigatório
Código Perfil por
do Perfil por Categoria  Chave Estrangeira da tabela
Categoria Profissional
Profissional Categoria Profissional
Código Indentificador  Obrigatório
Código Pessoa
da Pessoa
Data de Entrada na  Obrigatório
Data Entrada
Entidade  Formato Date
Data de Saída na  Obrigatório
Data Saída
 Obrigatório

Criador Registo
registo
 Obrigatório

registo
Experiência
 Obrigatório

Início Registo
Alteração Registo Data de alteração do  Obrigatório

 Obrigatório

lógica

tabela a
que
pertence o
campo
Código Identificador  Único e Obrigatório (Chave
Código
do Género Primária)
Descrição Nome do Género  Obrigatório
 Obrigatório

Criador Registo
Género registo
 Obrigatório

registo
Início Registo Data de início da  Obrigatório


sistema com a data e hora da
 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Código
da Pessoa Primária)
 Obrigatório
Nome abreviado da
Nome Curto  Assume-se o preenchimento
pessoa
de 2/3 nomes no máximo
Nome completo da  Obrigatório
Nome Longo
Pessoa
Morada Morada da Pessoa  Obrigatório
Distrito onde a Pessoa  Obrigatório
Distrito
mora
Estado Estado da Pessoa  Obrigatório
Código Género Estrangeira da tabela
do Género
Género)
Estado Civil Estrangeira da tabela Estado
do Estado Civil
Pessoa Civil)
Email Email da Pessoa  Obrigatório
Data de Nascimento Data de nascimento da  Obrigatório
Pessoa  Formato Date
 Obrigatório
Contacto Telefónico da  Formato Numérico com 9

Contacto
Pessoa
dígitos
 Obrigatório

Criador Registo
registo
 Obrigatório

registo
 Obrigatório

Início Registo
 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a que
pertence o
campo
Código Identificador Documentaçã  Único e Obrigatório (Chave
Código
da Documentação o Primária)
 Obrigatório
Código Tipo Código Identificador
 Chave Estrangeira da tabela
Documento do Tipo Documento
Tipo Documento
 Obrigatório
Código Pessoa  Chave Estrangeira da tabela
da Pessoa
Pessoa
URL com a  Obrigatório
HyperLink
documentação
Observação Observações  Permite NULL
 Obrigatório
Utilizador que  Deve ser preenchido pelo

Criador Registo realizou a operação sistema com o utilizador
de criar autenticado que criou o
registo
 Obrigatório

Modificador Registo realizou a operação sistema com o utilizador
de alteração autenticado que alterou o
registo
 Obrigatório

Início Registo
 Obrigatório

Alteração Registo
registo sistema com a data e hora
da alteração do registo
Estado Registo Estado do registo  Obrigatório

lógica

tabela a
que
pertence o
campo
Código
do Tipo Documento Primária)
Designação do Tipo  Obrigatório
Tipo Documento
Documento
 Obrigatório

Criador Registo
registo
 Obrigatório
Tipo autenticado que alterou o
Documento
registo
 Obrigatório

Início Registo
 Obrigatório

Alteração Registo

lógica

tabela a
que
pertence o
campo
Código Identificador Estado Civil  Único e Obrigatório (Chave
Código
do Estado Civil Primária)
Designação do Estado  Obrigatório
Designação
Civil
 Obrigatório
registo
 Obrigatório
registo
 Obrigatório

Início Registo
 Obrigatório

Alteração Registo

lógica

tabela a
que
pertence o
campo
Identificação do  Obrigatório
Código
Distrito  Este é um valor numérico
 Obrigatório, pelo que deverá
Designação Nome do Distrito estar preenchido quando um
Distrito é criado
 Obrigatório
Código Identificado do
Código País  Chave estrangeira da tabela
País
País
 Obrigatório
registo
Utilizador que realizou  Obrigatório
Distrito autenticado que alterou o
registo
 Obrigatório
Início Registo
 Obrigatório
Alteração Registo
 Obrigatório
lógica

tabela a
que
pertence
o campo
País  Único e Obrigatório
Identificação do (Chave Primária)
Código
 Obrigatório
Código Identificação
 Este é um valor numérico
Internacional Internacional do País
 Obrigatório
Designação Nome do País
Continente a que o  Obrigatório

Continente
País pertence
 Obrigatório
Utilizador que
sistema com o utilizador
Criador Registo realizou a operação
registo
 Obrigatório
Utilizador que
realizou a operação
Modificador sistema com o utilizador
de alteração
Registo autenticado que alterou o
registo

criação do registo  Deve ser preenchido pelo
sistema com a data e hora
 Obrigatório
Data de alteração do
Alteração Registo sistema com a data e hora
registo
 Obrigatório
“A” para “Ativo” ou “I”
Estado Registo Estado do registo para “Inativo”, como
suporte à estratégia de
eliminação lógica

tabela a que
pertence o
campo
Código da  Único e Obrigatório –
Código Avaliação Chave Primária
Candidatura
Avaliação  Obrigatório
Código Candidatura  Chave estrangeira na
Código Candidatura Identificador da
Candidatura tabela Candidatura
 Obrigatório
Data em que é
Data Avaliação  Formato Date
dada a nota final
 Permite NULL
Código  Chave estrangeira na
Código Teste
Identificador do tabela Avaliação
Individual
Teste Individual Entrevista
Código Entrevista Código  Permite NULL

de Grupo Identificador da  Chave estrangeira na
Entrevista de tabela Avaliação
Grupo
Entrevista

 Só pode ser preenchido
caso o campo Código
Entrevista Individual não
esteja preenchido
 Permite NULL
 Chave estrangeira na
tabela Avaliação
Código Entrevista
Código Entrevista Identificador da  Só pode ser preenchido
Individual Entrevista caso o campo Código
Individual Entrevista de Grupo não
esteja preenchido
 Permite NULL
tabela Avaliação
Entrevista
Código
Código Entrevista Teste Individual esteja
Identificador da
Final preenchido, bem
Entrevista Final
como, uma das duas
entre Código
Entrevista de Grupo e
Código Entrevista
Individual
Cálculo dos  Permite NULL

Cálculo resultados de cada  É um valor numérico
teste e entrevista
 Obrigatório
Utilizador que
Criador Registo realizou a
operação de criar autenticado que criou o
registo
Modificador Registo Utilizador que  Obrigatório

realizou a  Deve ser preenchido pelo
operação de
alteração
registo
 Obrigatório
Data de início da
Início Registo sistema com a data e
hora da criação do registo
 Obrigatório
Data de alteração sistema com a data e
Alteração Registo
do registo hora da alteração do
registo
 Obrigatório

tabela a que
pertence o
campo
Candidatura  Único e
Obrigatório –
Identificação da Chave Primária
Código
Candidatura  Este é um valor
numérico
Código Candidato Código  Obrigatório

Identificador do  Chave
Candidato estrangeira na
tabela

Candidato
 Permite NULL
 Chave
Código estrangeira na
Código Motivo Fecho Identificador do tabela Motivo
Candidatura Motivo Fecho Fecho
Candidatura Candidatura
 Obrigatório
Código
 Chave
Identificador da
Código Vaga estrangeira na
vaga a que
pertence tabela Vaga
 Obrigatório
 Deve ser
preenchido com a
Data da
Data Candidatura data de
Candidatura
submissão da
Candidatura
Observação  Obrigatório
Observação relacionada à
candidatura
 Obrigatório
Código  Chave
Código Estado Identificador do estrangeira da
Candidatura Estado tabela Estado
 Obrigatório
 Deve ser
preenchido pelo
Utilizador que
sistema com o
Criador Registo realizou a
operação de criar utilizador
autenticado que
criou o registo

realizou a  Deve ser
preenchido pelo
operação de sistema com o
alteração utilizador
autenticado que
alterou o registo
 Obrigatório
 Deve ser
preenchido pelo
Data de início da
Início Registo sistema com a
data e hora da
 Obrigatório
 Deve ser
preenchido pelo
Data de alteração sistema com a
Alteração Registo
do registo data e hora da
alteração do
registo
 Obrigatório
 Deve ser
preenchido com
“A” para “Ativo”
ou “I” para
“Inativo”, como
suporte à
estratégia de

tabela a
que
pertence
o campo
Código Identificação do Contrato  Único e Obrigatório –

Chave Primária
Contrato  Este é um valor numérico
 Obrigatório
Código
tabela Candidatura
Candidatura
 Obrigatório
Data Início do
Data Início  Formato Date
contrato
 Obrigatório
 Formato Date
Data expiração  Deve ser preenchido com
Data Fim
do contrato uma data superior à data
de início do contrato
 Obrigatório
Salário base do
Valor Base  Formato numérico
contrato
 Obrigatório
 Representa um Enum,
“Sim” caso o colaborador
Direito a viatura Direito a viatura
tenha direito a viatura e
“Não” caso não tenha
 Obrigatório
Direito a seguro
Direito a Seguro Saúde tenha direito a seguro de
de saúde
saúde e “Não” caso não
tenha
 Obrigatório
 Formato numérico
Valor
 Caso o candidato não
monetário de
Valor Outros Benefícios tenha direito a mais
outros
benefícios nenhum benefício,
colocar 0.
Criador Registo Utilizador que  Obrigatório

realizou a
operação de
criar
registo
Utilizador que  Obrigatório

operação de sistema com o utilizador
Modificador Registo
registo
 Obrigatório
Data de início  Deve ser preenchido pelo
Início Registo da criação do sistema com a data e hora
registo da criação do registo
 Obrigatório
Data de  Deve ser preenchido pelo
Alteração Registo alteração do sistema com a data e hora
registo da alteração do registo
 Obrigatório
Estado do
Estado Registo para “Inativo”, como
registo

tabela a que
pertence o
campo
Código Identificação do Estado  Único e Obrigatório –
Estado da Candidatura Chave Primária
numérico

 Obrigatório, pelo que
deverá estar preenchido
Nome Estado Nome do Estado quando um estado da
candidatura é criado
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
Modificador Registo de alteração
autenticado que alterou
o registo
 Obrigatório
Data de início da sistema com a data e
Início Registo
criação do registo hora da criação do
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório
tabela a
que
pertence o
campo
Categoria  Único e Obrigatório –
Identificação da Profissional Chave Primária
Código Categoria  Este é um valor
Profissional numérico
 Obrigatório
Código Área Código Identificador  Chave estrangeira na
Funcional da Área Funcional tabela Área Funcional
 Obrigatório, pelo que terá

de estar preenchido
Nome da Categoria
Designação quando uma Categoria
Profissional
Profissional é criada
 Obrigatório
 Formato Datetime
Data de criação da
Data Criação Categoria
Profissional a data e hora da criação
da Categoria Profissional
 Obrigatório
Utilizador que
registo
Modificador Utilizador que  Obrigatório

Registo realizou a operação  Deve ser preenchido pelo
de alteração sistema com o utilizador

registo
 Obrigatório
Data de início da
Início Registo sistema com a data e hora
 Obrigatório
Data de alteração
do registo
 Obrigatório

tabela a que
pertence o
campo
 Único e Obrigatório –
Chave Primária
Identificação do
Código  Este é um valor
Colaborador
numérico
 Obrigatório
Identificador da
Código Categoria tabela Categoria
Categoria
Profissional Profissional
Profissional
Código Pessoa Código  Obrigatório
Identificador da  Chave estrangeira na
Pessoa tabela Pessoa
 Obrigatório
 Deve ser preenchido
Utilizador que
pelo sistema com o
de criar utilizador autenticado
que criou o registo
 Obrigatório
Utilizador que
pelo sistema com o
utilizador autenticado
que alterou o registo
 Obrigatório
Colaborador
Data de início da pelo sistema com a data
Início Registo
criação do registo e hora da criação do
registo
 Obrigatório
Data de alteração pelo sistema com a data
Alteração Registo
do registo e hora da alteração do
registo
 Obrigatório

tabela a que
pertence o
campo

Estado  Único e Obrigatório –
Vaga Chave Primária
Identificação do
Estado Vaga
numérico

terá de estar
Nome do Estado da
Nome Estado preenchido quando um
Vaga
Estado de Vaga é criado
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo

para “Inativo”, como

tabela a que
pertence o
campo
Alteração  Único e Obrigatório –
Identificação da Estado Chave Primária
Código Alteração Estado Vaga  Este é um valor
Vaga numérico
 Obrigatório
Código Identificador  Chave estrangeira da
Código Vaga
da Vaga tabela Vaga
 Obrigatório
Código Estado correspondente ao tabela Estado Vaga
Antigo Vaga Estado de Vaga  Respeitar o Diagrama
antigo de Estados da Vaga
 Obrigatório
Código Estado Novo correspondente ao tabela Estado Vaga
Vaga Estado de Vaga  Respeitar o Diagrama
novo de Estados da Vaga
 Obrigatório
Utilizador que
registo

realizou a operação  Deve ser preenchido pelo

o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação da
Vaga
numérico
 Obrigatório
Código Perfil Código Identificador  Chave estrangeira da
Categoria do Perfil Categoria tabela Perfil Categoria
Profissional Profissional Profissional
Código Estado Vaga Código Identificador  Obrigatório

do Estado Vaga
 Chave estrangeira da
tabela Estado Vaga
 Permite NULL
 Preenchida
automaticamente
Data de Abertura da
Data Abertura quando é colocada no
Vaga
estado “Publicada”
 Formate Datetime
Vaga  Permite NULL

 Preenchida
automaticamente
quando é colocada no
Data de
estado “Arquivado” ou
Data Encerramento Encerramento da
Vaga “Fechado sem Sucesso”
ou “Fechado com
Sucesso”
 Obrigatório
Código Identificador tabela Colaborador
Código Colaborador correspondente ao  Preenchida
Criador Colaborador que automaticamente com
abriu o processo o código Colaborador
que cria o pedido
 Permite NULL
Aprovador Colaborador que automaticamente com
aprovou o processo o código Colaborador
que aprova o pedido
Descrição do Descrição do  Obrigatório

Pedido Pedido de vaga
Notas Notas adicionais  Permite NULL

 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Código Identificação da Alteração  Único e Obrigatório –
Estado Chave Primária
alteração de estado Candidatura  Este é um valor
de candidatura numérico
 Obrigatório
Código
 Obrigatório
Código  Chave estrangeira da
Identificador tabela Estado
Código Estado
correspondente ao Candidatura
Antigo Candidatura
Estado de  Respeitar o Diagrama de
Candidatura antigo Estados da Candidatura
 Obrigatório
Código Estado Novo
Candidatura
Candidatura novo Estados da Candidatura
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo

sistema com a data e
hora da criação do

registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Motivo  Único e Obrigatório –
Identificação do Fecho Chave Primária
Código Motivo de Fecho da Candidatura  Este é um valor
Candidatura numérico
Descrição sobre o  Obrigatório

motivo da alteração
Descrição
do estado da
candidatura
 Obrigatório
da Candidatura
tabela Candidatura
de criar sistema com o utilizador
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Contacto  Único e Obrigatório –
Chave Primária
Identificação do
Contacto
numérico
Código Candidatura Código Identificador  Obrigatório

da Candidatura tabela Candidatura
 Obrigatório
Data em que foi  Deve ser preenchido
Data
efetuado o contacto com a data e hora da
ligação telefónica
 Obrigatório
Tipo de contacto  Enumerado com as
Tipo Contacto efetuado com o opções “Entrevista” ou
candidato “Contratação”
 Obrigatório
Valida se o
 Enumerado com as
Atendeu candidato atendeu
o Técnico RH opções “Sim” e “Não”
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
Alteração Registo Data de alteração  Obrigatório

do registo  Deve ser preenchido pelo
hora da alteração do
registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação do
Contacto
numérico
 Obrigatório
Código Pessoa
da Pessoa tabela Pessoa
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
Candidato  Deve ser preenchido pelo
o registo


hora da criação do
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação do
Id  Este é um valor
User
numérico
 Obrigatório
User
 Assegurar a
correspondência com o
atributo “Nome Curto”
Name Nome do Utilizador
da Pessoa (sendo ela
um Colaborador ou um
Candidato)
Nome codificado do  Obrigatório

Utilizador  Obrigatório ter
UserName caracteres
alfanuméricos
 Obrigatório
 Tem que ter no mínimo
8 caracteres, podendo
Código secreto do
Password conter caracteres
Utilizador
alfanuméricos e/ou
caracteres especiais
 Obrigatório
 Formato email
Email Email do utilizador
 Obrigatório
Contacto de  Valor numérico com 9
Mobile Phone telefónico do dígitos
utilizador
 Permite NULL
 Só é preenchido caso
este utilizador não seja
Identificador do
colaborador
External_Id número de
utilizador externo  Este é um valor
numérico de auto-
preenchimento
 Obrigatório
Data da criação da  Formato Date
Creation_Date
conta
 Obrigatório
Data do último  Formato Datetime
Last_Login
login
 Obrigatório
Is_Active Se o acesso se com True caso esteja
contra ativo ou
ativo e Falso caso esteja
inativo
inativo

 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Código Identificação da  Único e Obrigatório –
Avaliação Entrevista Chave Primária
 Obrigatório
opções “Teste
Individual” ou
Descrição do tipo
Tipo de Entrevista “Entrevista de Grupo”
de Entrevista
ou “Entrevista
Individual” ou
“Entrevista Final”
 Obrigatório
Código Candidatura tabela Candidatura
da Candidatura
 Obrigatório
Nota numérica da  Obrigatório ter
Nota Avaliação
Entrevista caracteres numéricos
 Permite NULL
Comentários
Comentários sobre
a Entrevista
 Obrigatório
Avaliação
Código Identificador  Chave Estrangeira da
Código Colaborador Entrevista
do Colaborador tabela Colaborador
 Obrigatório
Data Data da entrevista  Formato Date

Código Avaliação
da Avaliação
Candidatura
Candidatura
de criar sistema com o utilizador

registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório
4.3 Gestão de definição, análise, aprovação e publicação de vaga
4.3.1 Diagrama(s) de modelização do(s) processo(s)
O diagrama de processo de negócio é representado através da linguagem gráfica Business

Process Modeling (BPM) e utilizam a notação Business Process Model and Notation
(BPMN), utilizando a ferramenta Signavio.
<Têm de incluir uma imagem do(s) diagrama(s) de modelização do processo de

em BPMN e escrever uma explicação do diagrama que justifique as opções
tomadas. Devem começar por um parágrafo que indique que subprocessos
fizeram e qual o objetivo de cada um deles. De seguida devem colocar a
imagem de cada subprocesso seguido de um parágrafo que explique por
palavras vossas o que está representado e um parágrafo adicional que
explique as opções de modelação ou melhorias que introduziram no
subprocesso>.
Tal como é descrito no caderno de encargos, o recrutamento da empresa Super Despensa

é dividido em três grandes áreas: Área de gestão de definição, análise, aprovação e
publicação de vaga, Área de gestão de seleção e de avaliação de candidaturas e Área de
gestão de apresentação, negociação e contratação.
O processo relativo à Área de Gestão e Aprovação de Vaga acompanha a identificação da

necessidade de recrutar alguém. A avaliação dessa necessidade é realizada por parte da
Direção e de um técnico especialista, destacado pela Direção de Recursos Humanos. A
tomada de decisão após a avaliação será de publicar em caso de decisão decisão positiva,
ou arquivar em caso de decisão negativa.
Figura 5. Diagrama de processos de gestão de definição, análise, aprovação e publicação de vaga
Figura 6. Diagrama de processos de candidato
Consideramos que existem dois fluxos diferentes na composição deste processo: o fluxo de
funcionamento do Back-end (Backoffice), onde é submetido o pedido e estudada a
necessidade de abertura ou não de uma vaga por parte da empresa, e o fluxo de Front-end
onde o cliente se regista, caso ainda não tenha um perfil ativo, no portal de recrutamento
da empresa e decide quais as vagas a que pretende candidatar-se.

Após identificar a necessidade e o número de vagas a preencher, o Gestor de Loja submete
o pedido no portal de recrutamento, para avaliação da Direção de Recursos Humanos.
Este abre tantos pedidos de necessidade de vaga quanto o número de colaboradores
necessários.
A direção analisa e avalia a proposta tendo em conta diversos fatores (ex: características
da população num raio de proximidade, concorrência, faturação) e toma uma decisão.
Se a Direção não aprovar a proposta, comunica a decisão ao Gestor de Loja que arquiva a
proposta e o processo é terminado.
Se, por outro lado, a Direção considerar que a proposta necessita de ser revista novamente
pelo Gestor de Loja, é comunicada essa decisão e a proposta é submetida para revisão.
O Gestor de Loja revê a proposta e decide se a quer manter ou não. Caso não queira, a
proposta é arquivada e o processo termina, caso contrário volta a submeter novo pedido à
Direção de Recursos Humanos para nova avaliação.
Caso a Direção aprove a proposta, a mesma é enviada para um Técnico Especialista de
Recursos Humanos para posterior análise e avaliação.
Se porventura, o Técnico Especialista considerar que existem alterações a fazer à proposta
(ainda que esta tenha sido aprovada pela Direção), envia-a novamente para o Gestor de
Loja que irá proceder em conformidade. Após as alterações terem sido efetuadas, a
proposta é novamente enviada para o Técnico Especialista para nova análise.
Se o Técnico Especialista considerar que não existem mais alterações a realizar, a proposta
é transcrita para o sistema informático, onde são disponibilizadas opções de
preenchimento em competências comportamentais e técnicas associadas à vaga em
questão, que a empresa considere importantes. Depois de ter sido transcrita (entende-se
que o Técnico de RH preencha apenas os dados em falta), a vaga é então publicada pelo
Técnico Especialista no Portal de Recrutamento da empresa que continua com o processo
de seleção após terem sido submetidas candidaturas para a vaga em causa.
Caso a Direção decida terminar a vaga, a vaga é fechada (manualmente) e o processo

termina. Isto pode acontecer em qualquer altura caso a vaga se encontre aberta.
Cada vaga tem um período de publicação associado, que é definido de acordo com a
urgência da necessidade pelo Técnico de RH e, caso este período termine, a vaga é fechada
(automaticamente) e o processo termina.
Após a vaga ter sido publicada, um possível candidato à mesma, terá de aceder ao Portal
de Recrutamento da Super Despensa.
Se ainda não tiver conta de utilizador, terá de a criar, bem como, um registo com os seus
dados pessoais para poder ter acesso aos detalhes das vagas em aberto.
Caso já tenha um registo criado, poderá consultar os detalhes da vaga em questão.
Depois de consultar a vaga, se pretender candidatar-se, tem de preencher um campo

descritivo disponibilizado pelo sistema para o efeito.
Se não quiser candidatar-se, o processo termina.
Após ter preenchido o campo descritivo, e se o candidato pretender submeter a
candidatura, a candidatura é registada em sistema e passa para o estado de “submetida”.
O candidato pode consultar a candidatura em qualquer altura através do seu perfil. Caso
este pretenda cancelar a candidatura após ter sido submetida pode fazê-lo em qualquer
altura e o processo termina no estado “Terminado sem Sucessos”. Caso contrário continua
para o processo de gestão de seleção e de avaliação de candidaturas.

4.3.2 Diagrama de transição de estados
<Têm de incluir uma imagem do diagrama de transição de estados (modelizado

em BPM) e escrever uma explicação do diagrama que justifique as opções
tomadas. Devem começar por um parágrafo que indique que diagrama(s) de
transição de estados fizeram e qual o objetivo de cada um deles. De
seguida devem colocar a imagem de cada diagrama de estados seguido de um
parágrafo que explique por palavras vossas o que está representado e um
parágrafo adicional que explique as opções de modelação que assumiram,
caso necessário>.
O Diagrama de transição de estados, é um fluxo que representa os diversos estados de um

objeto. Esta é uma forma de visualizar o ciclo de vida do objeto e perceber como é que
este se move de um estado para outro. Neste caso, o primeiro fluxo representa o ciclo de
vida de uma Vaga.
Figura 7. Diagrama de transição de estados do processo da Vaga
Uma vaga é gerada quando existe uma necessidade por parte do gerente de loja de
contratar mais colaboradores. Esta necessidade é submetida para a Direção de RH. Este
ato abre um pedido no estado “Pedido Vaga Submetido”. Quando a submissão está a ser
analisada pela Direção de RH, o estado avança para “Em Análise e Avaliação”, e conforme o
resultado da análise, a Direção de RH muda o Estado da possível vaga para “Para arquivo”,
“Para Revisão” ou “Aprovado”:
· “Para arquivo” indica que a Direção não aprovou o pedido da nova vaga. Desta
forma, é da responsabilidade do Gestor de Loja arquivar o processo passando a
vaga para o estado “Arquivado”.
· “Para Revisão” quando a direção solicita a revisão da necessidade ao Gestor de loja.
Enquanto o Gestor avalia o motivo da revisão, o estado avança para “Em Revisão”.
O Gestor, depois da análise pode tomar duas decisões, ou desiste de submeter a
vaga e o processo passa para “Arquivado”, ou é feita uma revisão e retificação e a
vaga volta para “Pedido Vaga Submetido”.
· É “Aprovado” quando a direção aceita a necessidade submetida, passando assim
processo para os Técnicos de RH no estado “Para análise”. Os técnicos passam o
processo para o estado “Em análise”. Se a análise for positiva, o Técnico avança o
processo no estado “Transcrição” e preenche os detalhes adicionais da vaga. Uma
vez feita esta ação, a vaga é Publicada e o estado muda para “Vaga Publicada”.
Neste estado a vaga fica visível para o candidato. A Fase de Gestão de definição,
análise, aprovação e publicação de vaga termina aqui.
Figura 8. Diagrama de transição de estados do processo de Vaga (Continuação)
4.3.3 Diagrama de casos de uso
<Têm de incluir uma imagem do(s) diagrama(s) UML de Use Cases e escrever
uma explicação do diagrama que justifique as opções tomadas>
Figura 9. Diagrama de Casos de Uso no Processo de Definição, Análise e Aprovação na posição de

Candidato.

No processo de Definição, Análise e Aprovação da necessidade analisamos as seguintes
funcionalidades a nível de Front-End na posição de Candidato:
· Aceder à plataforma de Vagas – O candidato para se candidatar ou consultar uma

candidatura futura poderá a qualquer momento aceder à plataforma.
· Criar Perfil – O candidato para se poder candidatar e visualizar vagas deverá criar
um perfil na plataforma.
· Consultar Candidatura – O candidato, durante qualquer passo da candidatura,
poderá consultar o estado e as suas características.
· Preencher Candidatura – Para o candidato poder concorrer no respetivo processo
de recrutamento deverá preencher o campo descritivo da candidatura.
· Submeter Candidatura – Após o preenchimento da candidatura deverá submete-la
de modo a poder entrar no respetivo processo de recrutamento.
· Cancelar a Candidatura – A qualquer momento o candidato poderá cancelar a sua
candidatura.
Figura 10. Diagrama de Casos de Uso no Processo de Definição, Análise e Aprovação

funcionalidades a nível de Back – End na posição de Técnico de Recursos Humanos:
· Publicar a(s) vaga(s) – Após aprovação o Técnico de Recursos Humanos pode

publicar a vaga na plataforma.
· Transcrever a Proposta – Poderá ser necessário transcrever a proposta de vaga no
caso de serem necessárias retificações.
· Fechar a vaga manualmente – A qualquer momento o Técnico de Recursos
Humanos poderá fechar a vaga manualmente.
funcionalidades a nível de Back-End na posição de Gestor de Loja:
· Submeter pedido de Necessidade de Vaga – O Gestor de Loja ao enfrentar uma

necessidade de Recursos Humanos, necessita de submeter o pedido de necessidade
de vaga.
· Rever a necessidade – O Gestor de Loja após parecer negativo da Direção de
Recursos Humanos terá de rever o pedido de necessidade de modo a corresponder
aos requisitos apresentados.
· Arquivar a Necessidade – O Gestor de Loja poderá arquivar o processo, se a Direção
recusar o pedido ou caso o próprio assim o entenda.

funcionalidades a nível de Back-End na posição de Direção de Recursos Humanos:
· Análise e Avaliação de Necessidade – Faz parte das funções da Direção de Recursos

Humanos aprovar o pedido de Análise e Aprovação da Necessidade da Vaga
realizada acima pelo Gestor de Loja.
4.3.4 Especificação de requisitos
Para cada tabela de base de dados deverão ser especificados os requisitos que determinam
as regras a aplicar para inserir, alterar, consultar ou eliminar os dados para cada classe,
além de aplicação de outras regras de negócio que sejam necessárias. O conjunto destas
tarefas é designado por grupo de funcionalidades que devem ser detalhadas de acordo
com a estrutura indicada nesta secção.
Um Grupo de funcionalidades corresponde a uma classe para a qual é necessário terem-se

várias funcionalidades para se trabalhar com a informação que a classe representa. Daí
chamar-se grupo de funcionalidade que tem depois várias funcionalidades.
Uma Funcionalidade corresponde aos casos de uso derivados de user tasks de processos
(ex.: listar, consultar, alterar, dar parecer = alterar estado) ou script tasks de processos (ex.:
atualizar estados massivamente). De notar que uma service task de processos é
normalmente uma subfuncionalidade, pois é executada a partir de uma user task ou script
task.
Uma Subfuncionalidade (só existe para funcionalidades que são ecrãs): quando se está a
especificar uma funcionalidade (ex.: formulário para criar uma vaga) temos várias ações
que podem ser botões (ex.: gravar, criar/alterar dados). É nestas subfuncionalidades que
devem ser indicadas as regras de funcionamento. De notar que as funcionalidades
derivadas de script tasks não têm subfuncionalidades.

4.3.4.1 Resumo executivo do grupo de funcionalidades
A Tabela 9 Error: Reference source not foundapresenta as funcionalidades da área de

gestão de definição, análise, aprovação e publicação de vaga, devendo indicar:
 quais as tabelas de base de dados que utiliza,

 o nível de complexidade esperado para a implementação e
 se são usados serviços externos, isto é, indicar se é necessário chamar serviços
externos ao Portal de recrutamento.
Esta tabela funciona como um resumo executivo das funcionalidades que vão especificar
em detalhe nas secções seguintes. Deve, portanto, ser completado e revisto depois de
completarem as secções que se seguem, relativas às funcionalidades da gestão de
definição, análise, aprovação e publicação de vaga.
Tabela 9. Grupo de funcionalidades do processo de gestão de gestão de definição, análise, aprovação e

publicação de vaga.
Número Complexidade de
Nome do grupo Quais as Caso utilize,
identificador do implementação
de classes/tabel indicar quais os
grupo de (baixa, média,
funcionalidades as que utiliza serviços externos
funcionalidades alta) e justificação
1 Candidato Candidato, Baixa – N/A
Corresponde à
User, validação e
registo de dados
Candidatura do candidato na
base de dados.
2 Vaga Estado Vaga, Média - Não Aplicável
Corresponde a (N/A)
Alteração criação de dados
Estado Vaga, com validações.
Candidatura,
Categoria
Profissional,
Vaga
Notem que deverão repetir a secção tantas vezes quantos as classes a especificar e
implementar para responderem aos requisitos expostos no caderno de encargos para a
gestão de definição, análise, aprovação e publicação de vaga. Para cada funcionalidade
deverão salientar/enquadrar os casos de uso (a partir do diagrama de casos de uso) e as
tabelas (a partir do diagrama de classes) a que pertencem. Terão, assim, de replicar os
diagramas de casos de uso e de classes, e enquadrar os respetivos casos de uso e classes
desses diagramas, para cada funcionalidade a especificar.
No caso de uma classe que é para ser utilizada quer no Back-End quer no Front-End, esta
deve ser especificada uma única vez, indicando as particularidades de funcionamento para
o Back-End e o Front-End.
4.3.4.2 Especificação do grupo de funcionalidades do Candidato
4.3.4.2.1 Especificação das funcionalidades do Candidato para o

Front-End
<Identificação de cada funcionalidade (Tabela ), quais as classes que

utiliza, o nível de complexidade esperado para a implementação e caso seja
necessário, se serão chamados serviços externos ao Portal. Caso seja
pertinente deverão ser adicionados comentários a explicar as decisões
efectuadas ou sugestões a serem seguidas na fase de implementação.
Devem isolar o enquadramento dos casos de uso, relativos a estas

funcionalidades, do diagrama geral de casos de uso que apresentaram na
secção 4.3.3 e colocar aqui a figura desse enquadramento. Ver
enquadramento exemplo na figura 5 do documento Exemplo Especificação
Requisitos e de Casos de Teste. Devem também copiar o enquadramento das
classes a que respeitam. Ver enquadramento na figura 1 do documento
Exemplo>.
Figura 11. Enquadramento das classes respeitante às funcionalidades de Gestão de definição, análise,
aprovação e publicação da vaga

Figura 12. Enquadramento dos casos de uso respeitante às funcionalidades de Gestão de definição, análise,
aprovação e publicação da vaga
 Ver figura 10 referente ao diagrama de use cases de Gestão de definição, análise,

aprovação e publicação da vaga.
Funcionalidades para o Front-End do grupo de

funcionalidades de Candidato
Tabela 10. Funcionalidades para o Front-End do grupo de funcionalidades de Candidato
Tipo (Batch,
Nome da Quais as Complexidade de Caso utilize, indicar
Serviço, Ecrã) implementação
classes/tabelas
(baixa, média, quais os serviços
Funcionalidade da base de dados
alta) e externos
que utiliza
justificação
Login Ecrã User Baixa –
Apenas verifica Não aplicável

se os dados
inseridos são do (N/A)
candidato ou de
um colaborador
Criar Registo Ecrã User, Candidato Média – N/A
Dados Pessoais
Insere e cria o
registo de um
candidato
inserindo os seus
dados na base de
dados
<As secções seguintes dizem respeito a template a preencherem. Devem criar

secções equivalentes para as restantes funcionalidades>.
Especificação da Funcionalidade “Login” de Candidato
<Devem adequar o título e o texto da secção ao vosso caso específico>.
A funcionalidade “Login” permite que o candidato tenha acesso à página das vagas disponíveis, e
por isso, valida se os dados inseridos são referentes a um candidato ou a um colaborador.
Esta funcionalidade compreende um conjunto de sub-funcionalidades associadas, especificadas na

Error: Reference source not found11.
Tabela 11. Regras de funcionamento das sub-funcionalidades de “Login” do módulo de Front-End.
Integração
externa (isto é,
indicar se é
Sub-funcionalidades Regra de funcionamento
necessário
chamar
serviços)

Sign In  Permite que o user entre na página N/A
inicial tendo acesso às vagas
disponíveis
Sign Up  Caso o user não tenha conta ainda N/A

registada, encaminha para a página de
Criar Registo Dados Pessoais onde se
pode registar
Especificação da Funcionalidade “Criar Registo Dados

Pessoais” de Candidato
A funcionalidade “Criar Registo Dados Pessoais” permite que o candidato se registe e tenha os seus
dados salvos na base de dados, podendo ter acesso às vagas disponíveis na página principal, e
candidatar-se se assim o entender.

Error: Reference source not found12.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Registar  Permite que o candidato se registe, N/A
guardando os seus dados num user na
base de dados
Cancelar  Permite cancelar o preenchimento N/A

dos dados realizado no pop-up dos
documentos
Adicionar  No pop-up dos Documentos, permite N/A

adicionar os dados inseridos, como os
anexos dos documentos, ao seu
registo
Tabela 12. Regras de funcionamento das sub-funcionalidades de “Criar Registo Dados Pessoais” do módulo
de Front-End.
4.3.4.2.2 Mockup dos ecrãs de Front-End
Figura 13 -Mockup da funcionalidade "Login"

Figura 14 -Mockup da funcionalidade "Criar Registo”
Figura 15-Mockup da funcionalidade "Criar Registo Dados Pessoais"

Figura 16-Mockup da funcionalidade "Criar Registo Dados Pessoais" com o pop-up dos documentos e as
pestanas
4.3.4.3 Especificação do grupo de funcionalidades da Vaga
O grupo de funcionalidades da Vaga é semelhante ao conjunto de operações CRUD (create,

read, update, delete) usuais nas bases de dados conforme apresentado na Tabela 9Grupo
de funcionalidades do processo de gestão de gestão de definição, análise, aprovação e
publicação de vaga.
4.3.4.3.1 Especificação das funcionalidades de Vaga para o

Front-End

Tabela 13. Funcionalidades para o Front - End do grupo de funcionalidades da Vaga.
Caso utilize,
Complexidade de
indicar
Quais as classes/tabelas da base implementação
Funcionalidades quais os
de dados que utiliza (baixa, média, alta)
serviços
e justificação
externos
<A, a
substituir
pelo nome
adequado.
Podem apagar
este texto>
<B, a
substituir
pelo nome
adequado.
Podem apagar
este texto>
<C, a
substituir
pelo nome
adequado.
Podem apagar
este texto>
<adicionar
tantas linhas
quantas as
funcionalidade
s necessárias.
Podem apagar
este texto>
4.3.4.3.2 Especificação da Funcionalidade “A” de

<G_func.1> (substituir pelo nome da funcionalidade)
A funcionalidade “A” (substituir pelo nome da funcionalidade) permite... <completar a

descrição>.
Esta funcionalidade compreende um conjunto de sub-funcionalidades associadas especificadas na

Tabela 134.
Tabela 14 10. Regras de funcionamento das sub-funcionalidades de “A” do módulo de Back-End.

Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
<1ª
subfuncionalidad
e de A, a
substituir pelo
nome adequado.
Podem apagar este
texto>
<adicionar tantas
linhas quantas as
subfuncionalidade
s necessárias.
Podem apagar este
texto>
4.3.4.3.3 Especificação da Funcionalidade “A” de

<G_func.1> (substituir pelo nome da funcionalidade)
A funcionalidade “A” (substituir pelo nome da funcionalidade) permite... <completar a

descrição>.

Tabela 135.
Tabela 1511. Regras de funcionamento das sub-funcionalidades de “A” do módulo de Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
<1ª
subfuncionalidad
e de A, a
substituir pelo
nome adequado.
Podem apagar este
texto>
<adicionar tantas
linhas quantas as
subfuncionalidade
s necessárias.
Podem apagar este
texto>
Especificação da Funcionalidade “B” de <G_func.1>

(substituir pelo nome da funcionalidade)
<Devem adequar o título e o texto da secção ao vosso caso específico de

grupo de funcionalidade>.
A funcionalidade “B” (substituir pelo nome da funcionalidade) permite... <completar a

descrição>.

Tabela 14.
Tabela 12. Regras de funcionamento das sub-funcionalidades de “B” do módulo de Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
<1ª
subfuncionalidade
de B, a
substituir pelo
nome adequado.
Podem apagar este
texto>
<adicionar tantas
linhas quantas as
subfuncionalidade
s necessárias.
Podem apagar este
texto>

Especificação da Funcionalidade “C” de <G_func.1>
(substituir pelo nome da funcionalidade)
A estrutura da Tabela 17 é diferente das anteriores tabelas relativas à especificação de

funcionalidades, por se tratar de um exemplo de funcionalidade que deriva de uma script task e
como tal origina a execução de um procedimento batch. Devem identificar se existe a necessidade
ou não de tarefa(s) de script neste grupo de funcionalidades que estão a especificar. Caso não seja
necessário, indiquem isso mesmo textualmente e deixem em branco a Tabela 17.
A funcionalidade “C” (substituir pelo nome da funcionalidade) permite... <completar a

descrição>.
Esta funcionalidade está especificada na Tabela 17.
Tabela 13. Regras de funcionamento da Funcionalidade “C”.
Parâmetros Parâmetros Descrição

Classe/Tabela Procedimento
Entrada Saída
<Isto é um <Isto é um <Isto é um <Isto é um
exemplo, exemplo, que exemplo, que exemplo, que
que devem devem devem adaptar devem adaptar ao
adaptar ao adaptar ao ao vosso vosso caso.
vosso vosso caso. caso. Podem Podem apagar este
caso. Podem apagar apagar este
texto>
Podem este texto> texto> Estado
apagar Actualizar estado actual do cliente,
este do cliente data do registo Para todas os clientes
texto> no estado « Registado »
Cliente há mais de 1 dias até à
data atual deve-e
alterar o estado para
« Activo »
Podem utilizar qualquer ferramenta que prefiram para especificar um esquisso dos ecrãs de
interface utilizador, considerando a representação das funcionalidades que estão a especificar. O
conteúdo desses ecrãs será tomado em consideração por aproximação e não por escala. Devem
identificar e explicar cada ecrã.
4.3.4.3.5 Especificação das funcionalidades de VAGA para o
Back-End
Figura 17. Enquadramento das classes respeitante às funcionalidades da Vaga

Figura 18. Enquadramento dos casos de uso respeitante às funcionalidades da Vaga
Tabela 18. Funcionalidades para Back-End do grupo de funcionalidades da Vaga
Caso utilize,
Complexidade de
indicar
Nome da Quais as classes/tabelas da base implementação
quais os
Funcionalidade de dados que utiliza (baixa, média, alta)
serviços
e justificação
externos
Listar Vaga Baixa – N/A
Necessidades Corresponde a
uma consulta em
lista no ecrã.
Submeter Vaga, Média – N/A
Necessidade Corresponde à
Estado Vaga, criação de dados
com validações.
Alteração Estado Vaga
Avaliação Pedido Vaga Média – N/A
alteração de dados
Estado Vaga com validações.

Rever Vaga Média – N/A
Estado Vaga alteração de dados
com validações.
Publicar Vaga Vaga Média – N/A
Corresponde à
Estado Vaga criação de dados
com validações.
Gestão de Dados Categoria Profissional, Perfil, Média – N/A
Loja, Área Funcional, Tipo Corresponde à
Documento, Género, Estado criação, alteração
Civil, País, Distrito, Estado Vaga, e remoção de
Motivo Fecho Candidatura, dados na Base de
Estado Candidatura Dados.
<As secções seguintes são templates a preencherem. Devem criar secções

equivalentes para as restantes funcionalidades, em função da necessidade
da vossa especificação>.
Especificação da Funcionalidade “Listar Necessidades” da Vaga
A funcionalidade “Listar Necessidade” permite ao Gestor de loja, visualizar as necessidades já

submetidas anteriormente e o seu respetivo estado, assim como iniciar o processo de criar uma
nova necessidade. A mesma funcionalidade permite aos Técnicos de RH serem redirecionados para
a Gestão de Dados.
Esta funcionalidade compreende um conjunto de subfuncionalidades associadas, especificadas na

Tabela 19.
Tabela 19. Regras de funcionamento das subfuncionalidades de “Listar Necessidade” do módulo de Back-
End.

Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Consultar Pedido  Deverá permitir consultar pedidos de N/A
necessidade efetuados
anteriormente.
Listar Pendentes  Listará todos os pedidos de N/A

necessidades que se encontram
pendentes do Gestor de Loja. Neste
caso no estado “Em Revisão” ou “Para
Arquivo”.
Submeter Novo  Deverá abrir o ecrã de “Submeter N/A

Pedido Necessidade” explicado abaixo, onde
poderá preencher a informação
necessária sobre o pedido de
Necessidade de Vaga.
 Esta Opção só é visível para o Gestor
de Loja.
Gestão de dados  Deve permitir abrir uma nova Janela

Estáticos para a funcionalidade “Gestão de
Dados”.
 Esta opção só é visível para os
técnicos de RH.
Vagas  Deve permitir mudar de ecrã e

Publicadas/Pedido de processos para as vagas publicadas ou
Vagas pedidos de vagas ainda não
submetidas.
Esta opção esta disponível para os

Técnicos e Direção de RH.
Logout  Deverá terminar a sessão do atual N/A
utilizador e redirecionar para o ecrã
de Login
Especificação da Funcionalidade “Submeter Necessidade” da Vaga
A funcionalidade “Submeter Necessidade” permite ao Gestor de loja submeter uma nova

necessidade para a Direção de RH.
Esta funcionalidade compreende um conjunto de subfuncionalidades associadas especificadas na

Tabela 20.
Tabela 20. Regras de funcionamento das subfuncionalidades de “Submeter Necessidades” do módulo de

Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Submeter Deverá previamente preencher o formulário de N/A
Pedido de Necessidade. Ao pressionar o botão
“Submeter” deverá retornar à página inicial e
submeter na base de dados a informação
relativamente ao Pedido de Necessidade, sendo
reencaminhado para a Direção de RH.
Altera o estado da Vaga para “Em análise e

avaliação”.
Voltar Deverá retornar à página Inicial. N/A
Especificação da Funcionalidade “Avaliação Pedido Necessidade” da Vaga
A funcionalidade “Avaliação Pedido Necessidade” permite à Direção de RH avaliar o pedido de

necessidade submetido pelo Gestor de Loja.
A Direção de RH tem acesso a estes pedidos através de dois ecrãs, sendo o primeiro a Página Inicial,
e o segundo uma sub-funcionalidade da Página Inicial, a “Lista de Pendentes”.
Esta funcionalidade compreende um conjunto de subfuncionalidades associadas especificadas na

Tabela 21.
Tabela 21. Regras de funcionamento das subfuncionalidades de “Avaliação Pedido Necessidade” do

módulo de Back-End.
Sub-funcionalidades Regra de funcionamento Integração

externa (isto é,
indicar se é
necessário
chamar
serviços)
Aceitar A Direção de RH aprova o Pedido de Necessidade N/A
alterando o estado do mesmo para “Aprovado”.
Posteriormente o técnico dará seguimento ao
pedido, retornando à Página Inicial.
Recusar A Direção de RH não aprova o Pedido de N/A
Necessidade alterando o estado do mesmo “Para
Arquivo”. O Gestor de Loja irá posteriormente
arquivar o pedido, encerrando o processo,
retornando à Página Inicial.
Pedir Revisão A Direção de RH solicita a revisão do Pedido de N/A
Necessidade ao Gestor de Loja alterando o
estado do mesmo para “Para Revisão”,
retornando à Página Inicial.
Especificação da Funcionalidade “Publicar Vaga” da Vaga
A funcionalidade “Publicar Vaga” permite ao Técnico de RH submeter uma nova vaga na

plataforma após aprovação da Direção de RH e da sua própria análise. Esta funcionalidade
compreende um conjunto de subfuncionalidades associadas especificadas na Tabela .
Tabela 22. Regras de funcionamento das subfuncionalidades de “Publicar Vagas” do módulo de Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Publicar Esta subfuncionalidade deverá submeter na base N/A
de dados a informação relativamente à Vaga.
Deverá estar disponível para receber
candidaturas. E deverá retornar à página Inicial.
Pedir Revisão O Técnico de RH solicita a revisão do Pedido de N/A
Necessidade ao Gestor de Loja alterando o
estado do mesmo para “Em Revisão”, retornando
à Página Inicial.
Guardar Esta subfuncionalidade deverá guardar alterações N/A
efetuadas na Vaga, alterando a base de dados.
Deverá retornar à página Inicial.
Especificação da Funcionalidade “Gestão de Dados” da Vaga
A funcionalidade “Gestão de Dados” permite ao Técnico de RH inserir, alterar ou remover dados

das seguintes tabelas da Base de Dados:
 Categoria Profissional
 Perfil
 Loja
 Área Funcional
 Tipo Documento
 Género
 Estado Civil
 País
 Distrito
 Estado Vaga
 Motivo Fecho Candidatura
 Estado Candidatura
Permitindo assim uma gestão mais autónoma das escolhas nos drop-downs que existem no
processo de recrutamento.
Esta funcionalidade compreende um conjunto de subfuncionalidades associadas, especificadas na

tabela 23.
Tabela 23. Regras de funcionamento das subfuncionalidades de “Gestão de Dados” do módulo de Back-
End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Inserir Dados  Deve permitir, ao selecionar uma das N/A
opções da coluna “Inserir Dados”,
abrir uma nova janela com todos os
dados da tabela selecionada com uma
opção de inserção de uma nova linha.
Alterar Dados  Deve permitir, ao selecionar uma das N/A

opções da coluna “Alterar Dados”,

abrir uma nova janela para fazer uma
pesquisa dos dados a alterar, fazer a
alteração, e a mesma ficar refletida
diretamente na BD.
Eliminar Dados  Deve permitir, ao selecionar uma das N/A

opções da coluna “Eliminar dados”
abrir uma nova janela para fazer uma
pesquisa dos dados a eliminar, a
mesma remoção deve se refletir na
BD.
Voltar  Retorna para a página Inicial do N/A

Técnico de RH.
Especificação da Funcionalidade “Fecho automático da Vaga” da Vaga
A estrutura da Error: Reference source not found é diferente das tabelas anteriores relativas à
especificação de funcionalidades por se tratar de um exemplo de funcionalidade que deriva de uma
script task e como tal origina a execução de um procedimento batch. Devem identificar se existe a
necessidade ou não de tarefa(s) de script neste grupo de funcionalidades que estão a especificar.
Caso não seja necessário, indiquem isso mesmo textualmente e deixem em branco a Error:
Reference source not found.
A funcionalidade Fecho Automático da Vaga permite assegurar o fecho de uma vaga com base
numa data de encerramento, sem ser necessária intervenção humana. Desta forma, é necessária
uma script task, que vai comparar a data atual (data de execução do script) com a data de
encerramento de todas as vagas. Quando estas datas forem iguais, o script vai fechar
automaticamente a vaga. De referir que uma vaga pode ser fechada manualmente a qualquer
momento do processo, desde que, devidamente justificado.
Tabela 24. Regras de funcionamento da Funcionalidade do “Fecho Automático da Vaga”.
Parâmetros Parâmetros Descrição

Classe/Tabela Procedimento
Entrada Saída
Vaga Fecho (Estado da Vaga Para todas as Vagas que
Automático “Publicada”, Data cheguem à data de
Vaga de encerramento deverão
Encerramento) ser automaticamente
colocadas no Estado
“Fechado”.
4.3.4.3.6 Mockup dos ecrãs de Back-End
Podem utilizar qualquer ferramenta que prefiram para especificar um esquisso dos ecrãs de
interface utilizador, considerando a representação das funcionalidades que estão a especificar. O
conteúdo desses ecrãs será tomado em consideração por aproximação e não por escala. Devem
identificar e explicar cada ecrã.

Figura 19-Mockup da funcionalidade "Listar Necessidades" com o respetivo Estado e Lista de Pendentes na
ótica do Gerente de Loja.
Figura 20-Mockup da funcionalidade "Listar Necessidades" com o respetivo Estado e Lista de Pendentes na
ótica do Técnico de RH.
Figura 21-Mockup da funcionalidade "Submeter Pedido de Necessidade" com a respetiva Descrição com a
possibilidade de submeter e Voltar (Gestor de Loja).

Figura 22-Mockup da funcionalidade “Consultar Pedido de Necessidade” com a respetiva Descrição com a
possibilidade de Aceitar e Recusar na perspetiva da Direção de Recursos Humanos.
Figura 23-Mockup da funcionalidade “Consultar Pedido de Necessidade” com a respetiva Descrição com a
possibilidade de submeter e Voltar na perspetiva do Técnico de Recursos Humanos.
Figura 24-Mockup da funcionalidade "Gestão de Dados" com as 3 colunas e as suas diversas opções de
gestão de dados estáticos (Técnico de RH).

Figura 25-Mockup da funcionalidade "Consultar Detalhes Vaga Publicada".
Figura 20-Mockup da funcionalidade "Consultar Pedido".

Figura 21-Mockup da funcionalidade "Publicar Vaga".
4.3.5 Especificação de testes
4.3.5.1 Condições de execução dos testes
Para a execução dos testes das funcionalidades é necessário garantir o seguinte:
• Implementação e testes das funcionalidades de Área de gestão de definição, análise,

aprovação e publicação de vaga, associadas às tabelas de Vaga, Estado da Vaga, Alteração Estado
Vaga, Categoria Profissional, Colaborador, Pessoa, Estado Civil, Género, Documentação,
Experiência, Perfil, Loja, Área Funcional, Perfil por Categoria Profissional, Estado Civil,Tipo
Documento, Distrito, País.
• Implementação completa dos ecrãs em OutSystems;
• Base de dados implementada com as necessárias restrições para a validação de dados que
dependam de regras em base de dados;
• Acesso à base de dados em modelo de leitura e escrita para se poderem executar queries
para a verificação do registo de dados em base de dados;
• Acesso à versão final do desenvolvimento do projeto do grupo de implementação.
Os testes exigem o envolvimento das seguintes equipas:
• Analistas de sistemas que realizaram a especificação de requisitos e dos testes;
• Programadores que realizaram a implementação e que testam a implementação de acordo

com os testes especificados pelo outro grupo.

4.3.5.2 Especificação dos Testes do Grupo de Funcionalidades Vaga
Esta secção deve ser repetida para cada grupo de funcionalidades que especificaram enquanto
requisitos. Como tal, devem criar secções com este template para cada grupo de funcionalidades.
Para cada funcionalidade devem indicar o que deve ser testado (Tabela 18).
Tabela 14. Especificação dos testes a realizar para o grupo de funcionalidades Vaga.
Funcionalidad sub-
Teste a realizar
e funcionalidades
Página Inicial Consultar Pedido Deve-se testar se ao carregar no botão “Consultar
(Back-end) pedido” o utilizador é redirecionado para o ecrã
“Consultar Pedido” onde se encontram os detalhes
do pedido correspondente.
Página Inicial Lista Pendentes Deve-se testar se ao carregar botão “Listar
(Back-end) Pendentes” o utilizador é redirecionado para o ecrã
“Lista Pendentes”
Página Inicial Submeter Novo Deve-se testar se ao carregar no botão “Submeter
(Back-end) Pedido Novo Pedido”, o utilizador é redirecionado para o
ecrã “Submeter Necessidade”.
Este botão só deve estar visível caso o utilizador
tenha a função de Gestor de Loja.
Página Inicial Vagas Publicadas Deve-se testar se ao carregar no botão “Vagas
(Back-end) Publicadas”, o utilizador é redirecionado para o ecrã
“Vagas Publicadas”.
Página Inicial Logout Deve-se testar se ao carregar no botão “Logout” a

(Back-end) sessão é corretamente terminada e o utilizador é
redirecionado para o ecrã de Login
Página Inicial Procurar Pedido Testar se as pesquisas pelo estado do pedido e
(Back-end) categoria profissional funcionam.
Página Inicial Gestão de dados Deve-se testar se o botão “Gestão de dados
(Back-end) estáticos estáticos” apenas está visível caso o utilizador tenha
a função de Técnico de Recursos Humanos.
Ao carregar no botão “Gestão de dados estáticos”, o
utilizador é redirecionado para o ecrã “Gerir Dados
BD”.
Submeter Submeter Testar se todas as informações colocadas nos

Necessidades campos do formulário estão corretamente inseridas
(Back-end) na base de dados, verificar se a obrigatoriedade de
preencher os campos está corretamente definida, e
se o campo de input Quantidade de Colaboradores
só aceita inteiros maiores do que 0.
Testar se ao carregar no botão “Submeter” o estado
do pedido é alterado para “Submetido” na base de
dados e utilizador é redirecionado para o ecrã de
“Página Inicial”.
Submeter Voltar Deve-se testar se ao carregar no botão “Voltar” o
Necessidades utilizador é redirecionado para o ecrã “Página
(Back-end) Inicial”
Submeter Ecrã Testar se ecrã é apenas acessível a utilizadores com
Necessidades a função de Gestor de Loja.
(Back-end)
Consultar Rever Proposta Testar se todas as informações colocadas nos
Pedido (Back- campos do formulário estão corretamente inseridas
End) na base de dados, verifica se a obrigatoriedade de
preencher os campos está corretamente definida e
Testar se este botão só aparece caso o pedido em
questão esteja no estado “Em revisão”.
Testar se ao carregar no botão “Rever Proposta” o
estado do pedido é alterado para “Submetido” na
base de dados e utilizador é redirecionado para o
ecrã de “Página Inicial”.
Consultar Arquivado Testar se todas as informações colocadas nos

Testar se ao carregar no botão “Arquivado” o
estado do pedido é alterado para “Arquivado” na
base de dados e utilizador é redirecionado para o
ecrã de “Página Inicial”.
Consultar Recusar Testar se todas as informações colocadas nos
Testar se ao carregar no botão “Recusar” o estado
do pedido é alterado para “Arquivado” na base de
questão esteja no estado “Submetido”.
pertença à Direção RH.

Consultar Aceitar Testar se todas as informações colocadas nos
Este botão pode estar visível caso o utilizador
pertença à Direção RH ou se tiver a função de
Técnico de RH, contudo se pertencer à Direção RH o
botão só deverá estar visível caso o pedido esteja no
estado “Submetido” e ao carregar no botão deve
testar-se se o estado do pedido é alterado para
“Aprovado” na base de dados e se o utilizador é
redirecionado para o ecrã “Página Inicial”.
Por outro lado, se o utilizador for um Técnico de RH,
o botão só deverá estar visível caso o pedido esteja
no estado “Para análise” e ao carregar no botão
deve testar se o estado do pedido é alterado para
“Transcrição” na base de dados e o utilizador é
redirecionado para o ecrã “Publicar”.
Consultar Pedir Revisão Testar se todas as informações colocadas nos

Este botão pode estar visível caso o utilizador
pertença à Direção RH ou se tiver a função de
Técnico de RH, contudo se pertencer à Direção RH o
botão só deverá estar visível caso o pedido esteja no
estado “Submetido” e ao carregar no botão deve
testar-se se o estado do pedido é alterado para “Em
Revisão” na base de dados.
Por outro lado, se o utilizador for um Técnico de RH,
o botão só deverá estar visível caso o pedido esteja
no estado “Para análise” e ao carregar no botão
deve testar se o estado do pedido é alterado para
“Em revisão” na base de dados.
Em ambos os casos, o utilizador tem de ser
redirecionado para o ecrã “Página Inicial” após ter
carregado no botão.
Consultar Voltar Deve-se testar se ao carregar no botão “Voltar” o

Pedido (Back- utilizador é redirecionado para o ecrã “Página
End) Inicial”
Lista de Ecrã Verificar se os pedidos que se encontram na tabela
Pendentes deste ecrã se encontram pendentes do lado do
(Back-End) utilizador que está a consultar.
(Ex: Se for um utilizador pertencente à Direção RH o
pedido tem de se encontrar no estado em análise)
Lista de Consultar Pedido Deve-se testar se ao carregar no botão “Consultar
Pendentes pedido” o utilizador é redirecionado para o ecrã
(Back-End) “Consultar Pedido” onde se encontram os detalhes
Publicar Vaga Publicar Testar se todas as informações colocadas nos
(Back-End) campos do formulário estão corretamente inseridas
na base de dados, verifica se a obrigatoriedade de
preencher os campos está corretamente definida.
Deve respeitar-se as seguintes validações:
- Campo de input ‘Quantidade de Colaboradores’ só
aceita inteiros maiores do que 0.
- Campo de input ‘Data de Fecho de Vaga’ só deverá
aceitar datas posteriores à data atual.
Testar se ao carregar no botão o utilizador é
redirecionado para o ecrã “Página Inicial”.
Testar se o estado do pedido é alterado para “Vaga
Publicada” na base de dados.
Publicar Vaga Guardar Testar se todas as informações colocadas nos

(Back-End) campos do formulário estão corretamente inseridas
na base de dados, verifica se a obrigatoriedade de
preencher os campos está corretamente definida.
Deve respeitar-se as seguintes validações:
- Campo de input ‘Quantidade de Colaboradores’ só
- Testar se ao a carregar no botão o estado do
pedido se mantém inalteado na base de dados e o
utilizador é redirecionado para o ecrã “Página
Inicial”.
Publicar Vaga Voltar Deve-se testar se ao carregar no botão “Voltar” o

(Back-End) utilizador é redirecionado para o ecrã “Listar
Necessidades”
Publicar Vaga Ecrã Testar se ecrã é apenas acessível a utilizadores com
(Back-End) a função de Técnico de Recursos Humanos.
Vagas Consultar Vaga Deve-se testar se ao carregar no botão “Consultar
Publicadas vaga publicada” o utilizador é redirecionado para o
(Back-End) ecrã “Consultar Vaga Publicada” onde se encontram
os detalhes da vaga correspondente.
Vagas Pedidos de Vagas Deve-se testar se ao carregar no botão “Pedidos de
Publicadas Vagas” o utilizador é redirecionado para o ecrã
(Back-End) “Listar Necessidades de Pedidos”.
Vagas Fecho Automático da Testar se quando chega ao dia definido na data
Publicadas Vaga limite para a vaga o fecho automático gera o script
(Back-End) implementado e a vaga fecha automaticamente.

Consultar Vaga Consultar Deve-se testar se ao carregar no botão “Consultar
Publicada candidatura Candidatura” o utilizador é redirecionado para o
(Back-End) ecrã “Consultar detalhe de Candidatura” onde se
encontram os detalhes da candidatura
correspondente.
Consultar Vaga Consultar detalhe da Deve-se testar se ao carregar no botão “Consultar
Publicada vaga detalhe de vaga” o utilizador é redirecionado para o
(Back-End) ecrã “Consultar detalhe vaga publicada” onde se
encontram os detalhes da vaga em questão.
Consultar Vaga Procurar Vaga Testar se as pesquisas pelos vários campos pedidos
Publicada funcionam.
(Back-End)
Consultar Cancelar Vaga Testar se ao carregar no botão “Cancelar vaga” o
Detalhe Vaga estado do pedido é alterado para “Fechada Sem
Publicada Sucesso” na base de dados e utilizador é
(Back-End) redirecionado para o ecrã de “Listar Necessidades”.
questão esteja no estado “Vaga Publicada”.
seja um Técnico de Recursos Humanos.
4.4 Gestão de seleção e avaliação de candidaturas
O diagrama de processo de negócio é representado através da linguagem gráfica Business

Process Modeling (BPM) e utilizam a notação Business Process Model and Notation
(BPMN), utilizando a ferramenta Signavio.
<Têm de incluir uma imagem do diagrama de modelização do processo e

escrever uma explicação do diagrama que justifique as opções tomadas.
Devem começar por um parágrafo que indique que subprocessos fizeram e qual
o objetivo de cada um deles. De seguida devem colocar a imagem de cada
subprocesso seguido de um parágrafo que explique por palavras vossas o que
está representado e um parágrafo adicional que explique as opções de
modelação ou melhorias que introduziram no subprocesso>.
O processo de escolha de um candidato para uma vaga é descrito em baixo por um processo
principal que contém um subprocesso.
O processo principal é descrito por “Área de gestão de seleção e de avaliação de candidaturas” e

pretende acompanhar o processo de uma candidatura, desde o momento em que é submetida até
ao fecho de uma vaga, podendo este processo culminar num preenchimento bem-sucedido em que
a candidatura termina numa contratação ou num candidato a ser excluído em que a candidatura é
terminada sem sucesso.
Como descrito, o processo começa quando um candidato, após criar um perfil na nossa plataforma,
submete uma candidatura em resposta a uma determinada vaga. Após a submissão ser realizada, a

vaga passa ao estado de “Em Revisão” e, através da execução de um script usando uma REST API, é
validado se o candidato tem algum registo criminal. Caso o mesmo esteja limpo, a candidatura é
aprovada automaticamente e passa ao passo seguinte. Caso o registo criminal não esteja limpo, o
mesmo carece de uma validação por parte de um Técnico Especializado de RH que irá dar o seu
parecer e, consoante esta decisão, irá cancelar a submissão da candidatura, terminando a
candidatura sem sucesso, ou dar continuidade á mesma.
No próximo passo da avaliação da candidatura, caso o ponto anterior não tenha sido o suficiente
para excluir o candidato, ir-se-á dar início á analise manual do CV do candidato. Análise esta que,
como no ponto anterior, poderá resultar na exclusão do candidato caso o parecer seja negativo, ou
na possibilidade de este passar á triagem telefónica caso o parecer seja positivo.
A triagem telefónica é exclusiva, ou seja, serão feitas três tentativas telefónicas ao candidato e se
este não atender, será automaticamente excluído do processo. Mesmo que atenda, o candidato
poderá manifestar falta de interesse na vaga e assim, dar azos ao término da sua candidatura.
Ambos os casos resultam no fecho da candidatura sem sucesso.
Ao efetuar um contacto telefónico é registado na candidatura, pelo Técnico de RH, se foi bem-
sucedido ou não.
Caso responda a uma das três tentativas de contacto e caso manifeste interesse em seguir com o
processo, dar-se-á início ao processo de avaliação, apresentado pelo subprocesso “Tipos de
Avaliação”.
Figura 15. Diagrama do Processos de Gestão e Seleção de Candidaturas
No Subprocesso “Tipos de Avaliação” é feito um detalhe sobre todo o processo de avaliação de um

candidato sendo que o mesmo apenas culmina quando o candidato obtém uma avaliação final,
independente da quantidade e tipos de avaliações de que for alvo.
O primeiro momento avaliativo é sempre um teste individual sobre o qual o candidato recebe uma
avaliação. Após este momento é tomada uma decisão pelo Técnico Especializado de RH, tendo em
conta a urgência e necessidade da vaga sobre qual o próximo teste a ser efetuado.
Este segundo momento avaliativo é exclusivo, ou seja, caso o técnico de RH opte por um, ou outro,
este será solicitado ao candidato.
Caso o candidato seja convidado a fazer a avaliação do tipo “Entrevista Individual” esta terá de ser
avaliada e também autoavaliada pelo candidato. Caso o tipo de avaliação escolhido seja a
“entrevista em grupo” esta será avaliada e registada.
Ambos os momentos serão comentados pelo Técnico de RH (opcionalemente) e avaliados sendo

que, disto, surgirá uma avaliação final ponderada por todos os momentos avaliativos.
Se o candidato não reunir os requisitos mínimos será, tal como a sua candidatura, excluído.
Caso o candidato reúna os requisitos mínimos será feita uma entrevista final que, após ser avaliada,
poderá resultar num processo de recrutamento, fechando a vaga com sucesso, senão será excluído
e dar-se-á fim ao seu processo de candidatura.
O ciclo de vida de uma candidatura pode ter 11 Estados diferentes. Uma candidatura nasce
quando é submetida pelo candidato, mas também altera o estado da vaga
simultaneamente em alguns dos momentos.
Figura 16. Diagrama de transição de estados do processo de Gestão e Seleção de Candidaturas
Quando se recebe candidaturas a Vaga entra no estado “Vaga em análise.” Nesta altura o
processo da Candidatura estará a decorrer. Após esta fase, a vaga tem dois possíveis
cenários, ou é “ Vaga fechada sem sucesso” se o processo da candidatura falhar em algum

momento, e para voltar a abrir a mesma vaga o processo precisa de recomeçar com uma
nova necessidade, ou no caso de uma contração a vaga fica “Vaga Preenchida” e,
consequentemente, é fechada com o motivo “Vaga Fechada com Sucesso”.
Figura 16. Diagrama de transição de estados do processo da Vaga
Em relação à Candidatura, após a submissão, esta é “Assignada” a um Técnico que irá

realizar as devidas análises e avaliações necessárias. Se a avaliação não for positiva o
processo é “terminada sem sucesso”.
Caso contrário, o Estado do muda para “Pendente de Contacto”. O técnico tentará entrar
em contacto com o candidato para avaliar o interesse deste para o cargo. Se o candidato
não atender ou atender e não mostrar interesse, o processo é terminado. Caso ele mostre
interesse o processo passa para “Pendente de Avaliação”. Nesta fase decorrem os vários
tipos de avaliação que foram indicadas pelo técnico.
Uma vez que o Técnico adiciona a classificação final na candidatura, o estado avança para
“Avaliação Concluída” de seguida este processo pode ter duas saídas: ou termina porque o
candidato não atingiu os requisitos necessários para a vaga e o processo é fechado no
estado “terminado sem sucesso”, ou passa para “Pendente de Entrevista final”. Mantem se
neste estado até o Responsável de Setor realizar uma avaliação final do candidato. Se a
avaliação foi negativa a Candidatura é fechada e fica no estado “Terminado sem sucesso”.
4.4.3 Diagrama de casos de uso
<Têm de incluir uma imagem do diagrama UML de Use Cases e escrever uma
explicação do diagrama que justifique as opções tomadas. Devem começar por
um parágrafo que indique que diagramas de casos de uso fizeram e qual o
objetivo de cada um deles. De seguida devem colocar a imagem de cada
diagrama de casos de uso seguido de um parágrafo que explique por palavras
vossas o que está representado e um parágrafo adicional que explique
Figura 17. Diagrama de Casos de Uso do processo de Seleção e Avaliação das Candidaturas
No processo de Seleção e de Avaliação das Candidaturas analisamos as seguintes funcionalidades a

nível de Front-End na posição de Candidato:
· Submeter Candidatura – O candidato deverá submeter a respetiva candidatura, para

avançar com o processo de recrutamento.

No processo de Seleção e de Avaliação das Candidaturas analisamos as seguintes

funcionalidades a nível de Back - End na posição de Técnico de Recursos Humanos :
· Terminar processo de recrutamento – A qualquer momento o Técnico de Recursos

Humanos poderá fechar o respetivo processo de recrutamento.
· Convocar para Entrevista – O técnico de Recursos Humanos deverá contactar o
candidato para a Entrevista através da plataforma.
· Avaliar entrevista Individual – Colocação da classificação da entrevista do candidato
na plataforma.
· Avaliar Teste Individual – Colocação da classificação do teste individual do
candidato na plataforma.
· Avaliar e Registar Prova (Entrevista de Grupo) – O técnico de Recursos Humanos
adicionará a classificação da Entrevista de Grupo.
· Associar Comentários – O técnico de RH poderá associar comentários a qualquer
método de avaliação associado ao candidato.
· Transcrever Proposta – O técnico de RH transcreve a proposta com base nas
retificações necessárias.
· Selecionar tipo de avaliação – O técnico de RH decide internamente qual o melhor
processo para avaliar um candidato no nivel de entrevistas individual ou de grupo.
· Assignar Candidatura – Quando recebida uma nova candidatura deverá ser
assignada a um Técnico de RH específico através da plataforma, ao qual terá a
responsabilidade de avançar com o processo de recrutamento.
É de salientar que quaisquer adição de classificações ou comentários têm implicações a

nível da classificação final. A classificação final alterará obrigatoriamente o estado da
candidatura de cada candidato individualmente.
No processo de Seleção e de Avaliação das Candidaturas analisamos as seguintes

funcionalidades a nível de Back - End na posição de Responsável de Setor:
· Avaliar Entrevista Final – O Responsável de Setor terá de colocar a classificação do

candidato na plataforma de modo a avaliar a candidatura.

além de aplicação de outras regras de negócio. O conjunto destas tarefas é designado por
grupo de funcionalidades que devem ser detalhadas de acordo com a estrutura indicada
nesta secção.

(ex: listar, consultar, alterar, dar parecer = alterar estado) ou script tasks de processos (ex:
actualizar estados massivamente). De notar que uma service task de processos é
normalmente uma funcionalidade para especificação, mas é invocada a partir de
subfuncionalidade, pois é executada a partir de uma user task.
especificar uma funcionalidade (ex: formulário para criar um produto) temos várias acções
que podem ser botões (ex: gravar, criar/alterar dados). É nestas subfuncionalidades que
A Error: Reference source not found apresenta as funcionalidades da simulação, indicando

quais as tabelas de base de dados que utiliza, o nível de complexidade estimado para a
implementação e se são usados serviços externos, isto é, indicar se é necessário invocar
serviços externos ao Portal. Esta tabela funciona como um resumo executivo das classes
que vão especificar em detalhe nas secções seguintes.
Tabela 15. Grupo de funcionalidades do processo de gestão de seleção e avaliação de candidaturas.
Número Complexidade
identificador do de
grupo de implementação
de classes/tabelas indicar quais os
funcionalidades (baixa, média,
funcionalidades que utiliza serviços externos
alta) e
justificação
1 Candidatura Avaliação Alta – O API de Registo
Candidatura, candidato pode Criminal
Contacto, se candidatar a
Candidato, uma vaga, a
Motivo Fecho candidatura é
Candidatura, analisada através
Estado de uma API para
Candidatura, verificar o registo
Alteração Estado criminal, as
Candidatura, candidaturas
Avaliação alteram os seus
Entrevista, estados
Candidatura
2 Avaliação Colaborador, Média – Guarda
Candidatura Avaliação os dados de
Entrevista, cada avaliação
Candidatura, registada pelo
Avaliação
Técnico de RH
Candidatura
3 Contacto Contacto, Baixa – Apenas

Candidatura regista se o
contacto foi
realizado
4.4.4.2 Especificação do grupo de funcionalidades de Avaliação

Candidatura
4.4.4.2.1 Especificação das funcionalidades de Avaliação

Candidatura para o Front-End
Figura 20. Enquadramento das classes respeitante às funcionalidades de Gestão de seleção e avaliação de
candidaturas

Figura 21. Enquadramento dos casos de uso respeitante às funcionalidades de Gestão de seleção e
avaliação de candidaturas
4.4.4.2.2 Funcionalidades para o Front-End do grupo de

funcionalidades de Avaliação Candidatura
O grupo de funcionalidades de Avaliação Candidatura para o Front-End não existe, pois, os

candidatos não têm permissões de avaliar candidaturas nem de submissões de pareceres.
Sendo assim, não existem também subfuncionalidades adjacentes ao Front-End.
4.4.4.3 Especificação do grupo de funcionalidades de Candidatura
candidaturas
 Ver figura 21 referente ao diagrama de use cases de Gestão de seleção e avaliação

de candidaturas.
Tabela 24. Funcionalidades para o Front-End do grupo de funcionalidades de Candidatura
Tipo (Batch, Complexidade de

Quais as
Serviço, Ecrã) implementação Caso utilize, indicar
Nome da classes/tabelas
alta) e externos
que utiliza
justificação

Consultar Ecrã Candidatura Baixa – apenas
Não aplicável
Candidatura consulta os
dados da
(N/A)
candidatura
Candidatar Ecrã Candidatura, N/A
Candidato,
Média – regista
Estado
os dados de uma
Candidatura,
nova candidatura
Alteração Estado
Candidatura
4.4.4.3.1 Especificação da Funcionalidade “Consultar

Candidatura” de Candidatura
A funcionalidade “Consultar Candidatura” permite consultar a candidatura submetida a

determinada vaga e permite cancelar esta candidatura.

Error: Reference source not found.
Tabela 25. Regras de funcionamento das sub-funcionalidades de “Consultar Candidatura” do módulo de

Front-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Cancelar  Permite cancelar a candidatura N/A
submetida, fazendo com que esta seja
apagada dos registos da vaga
Voltar  Permite voltar à funcionalidade N/A

anterior, a “Página Inicial Candidato”
Especificação da Funcionalidade “Candidatar” de Candidatura
A funcionalidade “Candidatar” permite Submeter uma candidatura a uma vaga, ou seja, permite a
aplicação a uma vaga.

Tabela 26. Regras de funcionamento das sub-funcionalidades de “Candidatar” do módulo de Front-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Guardar  Permite guardar os dados da nova N/A
candidatura
Submeter  Após guardados os dados da nova N/A

candidatura, podemos submetê-la
para ficar registada na vaga

anterior, a “Página Inicial Candidato”
Mockup dos ecrãs de Front-End

Figura 25 1-Mockup da funcionalidade "Consultar Candidatura" (Candidato)
Figura 26 2-Mockup da funcionalidade "Candidatar" (Candidato)

4.4.4.3.2 Especificação das funcionalidades de Avaliação
Candidatura para o Back-End
candidaturas
 Ver anexo 1 referente ao diagrama de classes.

de candidaturas.
Tabela 24. Funcionalidades para o Back-End do grupo de funcionalidades de Avaliação

Candidatura

Quais as
alta) e externos
que utiliza
justificação
Avaliação de Ecrã Avaliação Baixa - Apenas
Candidatura Candidatura, mostra a
Colaborador avaliação da
Não aplicável
candidatura e a
avaliação dos
(N/A)
testes e
entrevistas
realizados
Adicionar Ecrã Avaliação Média – Adiciona N/A
Avaliação Entrevista, uma nova
Colaborador, avaliação feita
Estado por um
Candidatura colaborador
(Técnico RH)

4.4.4.3.3 Especificação da Funcionalidade “Avaliação de
Candidatura” de Avaliação Candidatura
A funcionalidade “Avaliação Candidatura” permite adicionar novas avaliações e permite

voltar à funcionalidade anterior, que é “Consultar Candidatura”.
Esta funcionalidade compreende um conjunto de sub-funcionalidades associadas,

especificadas na 25.
Tabela 25. Regras de funcionamento das sub-funcionalidades de “Avaliação de Candidatura” do módulo de

Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Adicionar Avaliação  Permite abrir uma nova N/A
funcionalidade a “Adicionar
Avaliação”. Apenas disponível para o
Técnico de RH

anterior “Consultar Candidatura”
Terminar  Permite ao Técnico de RH terminar a N/A

candidatura, ou seja, cancelar a
candidatura de um certo candidato a
qualquer momento da avaliação. É
sempre necessário indicar o motivo
do término
Aprovar  Permite aprovar a candidatura caso N/A

esta tenha os requisitos mínimos, se
tal acontecer é dado o “ok” para o
responsável de setor realizar a
entrevista final ao candidato. Esta
subfuncionalidade apenas é visível
para o Técnico de RH
Selecionar para  Permite selecionar o candidato para N/A

Contratação contratação, colocando a candidatura
no estado “Para contratação”, esta
opção apenas se torna disponível
quando todas as entrevistas foram
realizadas com sucesso e nota
positiva. Esta subfuncionalidade só
está visível para o Técnico de RH
Contrato  Abre a funcionalidade “Contratar” e N/A

apenas surge após a candidatura estar
no estado “Em contratação”. Esta
subfuncionalidade apenas está
disponível para o Diretor de RH
Resposta Candidato  Permite selecionar qual foi a resposta N/A

dada pelo candidato após o envio da
proposta de contrato, estas podem
ser “Proposta Aceite”, “Proposta
Recusada” ou “Sem Resposta”. Só
quando o candidato é selecionado é
que estas opções ficam disponíveis. Só
está visível para o Diretor de RH
4.4.4.3.4 Especificação da Funcionalidade “Adicionar

Avaliação” de Avaliação Candidatura
A funcionalidade “Adicionar Avaliação” apenas permite submeter uma nova avaliação com
as notas referentes aos testes ou entrevistas realizadas e adicionar comentários às
avaliações, se a opção de teste individual estiver marcada, caso contrário não deverá ser
possível preencher os restantes campos.
Esta funcionalidade compreende um conjunto de sub-funcionalidades associadas

especificadas na Error: Reference source not found.
Tabela 26. Regras de funcionamento das sub-funcionalidades de “Adicionar Avaliação” do módulo de

Back-End.
Sub-funcionalidades Regra de funcionamento Integração

externa (isto é,
indicar se é
necessário
chamar
serviços)
Submeter  Permite submeter a nova avaliação N/A
depois de preenchidos os campos
referentes a essa nova avaliação
Voltar  Permite regressar à funcionalidade N/A

anterior a “Avaliação de Candidatura”

Figura 27 3- Mockup da funcionalidade "Consultar Avaliação da Candidatura" disponível para o
Técnico de RH

Figura 28 4- Mockup da funcionalidade "Consultar Avaliação de Candidatura" disponível para o
Diretor de RH (O botão de Selecionar para Contratação apenas visível para o Técnico de RH)
Figura 29 5- Mockup da funcionalidade "Adicionar Avaliação"
4.4.4.3.6 Especificação das funcionalidades de Contacto para o

Back-End
candidaturas

 Ver anexo 1 referente ao diagrama de classes.

de candidaturas.
Tabela 24. Funcionalidades para o Back-End do grupo de funcionalidades de Contacto

Quais as
alta) e externos
que utiliza
justificação
Contactos Ecrã Candidatura, Baixa – Verifica
Não aplicável
Contacto se o candidato
atendeu o
(N/A)
telefonema
4.4.4.3.7 Especificação da Funcionalidade “Contactos” de

Contacto
A funcionalidade “Contactos” permite registar a triagem telefónica feita pelo Técnico de RH ao

candidato, registando no sistema se este atendeu ou não.

Tabela 26. Regras de funcionamento das sub-funcionalidades de “Adicionar Avaliação” do módulo de

Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Registar Contacto  Ao clicar no Registar Contacto será N/A
aberto um pop-up onde o Técnico de
RH clica na opção que se encaixa
naquele caso, ou o candidato atendeu
ou não atendeu
Voltar  Permite regressar à funcionalidade N/A

anterior a “Consultar Candidatura”
Figura 32 6-Mockup da funcionalidade "Contactos"

4.4.4.3.9 Especificação das funcionalidades de Candidatura para
o Back-End
Tabela 24. Funcionalidades para o Back-End do grupo de funcionalidades de Candidatura

Quais as
alta) e externos
que utiliza
justificação
Consultar Ecrã Avaliação Média – Permite
Candidatura Candidatura, assinar o
Colaborador processo de
avaliação da
candidatura a um
Não aplicável
Técnico de RH, e
é possível
(N/A)
transferir o
documento, um
relatório, gerado
pela API registo
criminal
4.4.4.3.10 Especificação da Funcionalidade “Consultar

Candidatura” de Candidatura
A funcionalidade “Consultar Candidatura” permite consultar a candidatura de um certo candidato,

alterar o estado da candidatura e aceder à avaliação da candidatura.

Tabela 25.
Tabela 25. Regras de funcionamento das sub-funcionalidades de “Consultar Candidatura” do módulo de
Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Assigar a mim  Permite atribuir uma candidatura a N/A
um Técnico de RH, permitindo que
este fique responsável por ela
Avaliação  Subfuncionalidade que permite N/A

Candidatura aceder à funcionalidade “Avaliação
Candidatura”

anterior “Consultar Vaga Publicada”
Contactos  Permite fazer a ligação à N/A

funcionalidade “Contactos” do grupo
de funcionalidades Contacto
Download  Permite obter o ficheiro com o É necessário,

relatório proveniente da API do chama-se a API
registo criminal de registo
criminal

Figura 33 7-Mockup da funcionalidade "Consultar Candidatura"

• Implementação e testes das funcionalidades de Área de gestão de seleção e de avaliação
de candidaturas associadas às tabelas de Candidatura, Avaliação Candidatura, Avaliação Entrevista,
Estado Candidatura, Alteração Estado Candidatura, Motivo Fecho Candidatura, Contacto.


Especificação dos Testes do Grupo de Funcionalidade
Candidatura
Esta secção deve ser repetida para cada grupo de funcionalidades que especificaram como
requisitos para a área de gestão de seleção e avaliação de candidaturas, pelo que devem criar uma
secção por grupo de funcionalidades. Para cada funcionalidade devem indicar o que deve ser
testado (Tabela 16).
Tabela 16. Especificação dos testes a realizar para o grupo de funcionalidades Candidatura.
Funcionalidad sub-
Teste a realizar
e funcionalidades
Login (Front- Sign in Testar se as credenciais correspondem a credenciais
End) associados a um utilizador na Base de Dados.
Caso não exista, deverá apresentar uma mensagem

de erro.
Caso o login seja feito com sucesso, validar se é feito

o redireccionamento com sucesso para a “Pagina
Inicial Candidato “e se é estabelecida uma sessão
para o utilizador em questão.
Login (Front- Sign up Deve-se testar se ao carregar no botão Sign-up é
End) feito o redirecionado para a página “Criar registo”.
Criar registo Registar Testar se todas as informações colocadas nos
(Front-End) campos do formulário são corretamente inseridas na
base de dados.
Deve se verificar se a obrigatoriedade de preencher

os campos está corretamente definida e se os
campos de input “First name” e “Last name” apenas
podem aceitar caracteres alfabéticos Maiúsculos ou
minúsculos.
Testar se ao carregar no botão “Registar é feito o
reencaminhamento para o ecrã “Criar Registo de
dados pessoais”.
Criar Registo de Registar Testar se todas as informações colocadas nos
dados pessoais campos do formulário são corretamente inseridas na
(Front-End) base de dados.
Verifica se a obrigatoriedade de preencher os

campos está corretamente definida.
Devem respeitar-se as seguintes imposições:
- Os campos de input “Nome Completo” e “Nome

Curto” apenas podem aceitar caracteres alfabéticos
Maiúsculos ou minúsculos.
- A idade está deve estar compreendida entre os

16 e os 100 anos.
Testar se ao carregar no botão “Registar” é feito o

reencaminhamento para o ecrã “Pagina Inicial
Candidato”.
Criar Registo de Adicionar Testar se o URL para o documento foi corretamente
dados pessoais inserido na Base de dados e á lista de Documentos
(Front-End) na pestana associado ao ecrã “Criar Registo de dados
pessoais”.
Criar Registo de Cancelar Testar se o pop-up é fechado com sucesso.
dados pessoais
(Front-End)
Página Inicial Logout Deve-se testar se ao carregar no botão “Logout” a
Candidato sessão é corretamente terminada e o utilizador é
(Front-End) redirecionado para o ecrã de Login
Consultar Terminar Testar se ao carregar no botão “Terminar” aparece
Candidatura um Pop up onde é pedido para selecionar o motivo
(Back-End) de terminar a candidatura.
Testar se ao escolher o motivo e carregar fechar o

estado da candidatura é alterado para “Terminado
Sem Sucesso” na base de dados.
Testar se este botão só é visível para utilizadores

com a função de técnico de recursos humanos.
Consultar Assignar a mim Testar se ao carregar no botão “Assignar a mim” o
Candidatura colaborador associado à vaga é alterado, para o
(Back-End) utilizador que carregou no botão, na base de dados
Testar se o botão só é visível para utilizador com a

função de técnico de recursos humanos.
Consultar Dropdown Estado Testar se o dropdown contém os estados presentes

Candidatura candidatura na base de dados na tabela Estado Candidatura.
(Back-End)
Consultar Download Testar se ao carregar no botão “Download” é feito
Candidatura um download do Registo Criminal do Candidato em
(Back-End) formato PDF.
Testar se o botão só é visível para utilizador com a
função de técnico de recursos humanos.

Avaliação da Voltar Deve-se testar se o reencaminhamento para a
Candidatura página da “Candidatura” é feito corretamente.
(Back-end)
Avaliação da Terminar Deve-se testar se ao carregar no botão “Terminar” é
Candidatura despoletado um popup a questionar o motivo do
(Back-end) fecho da Candidatura.
Este motivo está discriminado em formato Drop-

Down e deverá ser testado se os motivos estão de
acordo com o implementado.
Esta subfuncionalidade apenas pode estar disponível

quando estiverem publicadas as três avaliações e
apenas visível ao técnico de RH.
Avaliação da Aprovar Avaliar se o botão de Aprovar apenas está visível ao
Candidatura técnico de RH e se só após as notas de todas as
(Back-end) entrevistas estarem publicadas e haver uma nota
final.
Avaliação da Adicionar Avaliação Deve-se validar se se consegue submeter uma
Candidatura avaliação. Esta avaliação será discriminada, ou seja,
(Back-end) o Responsável de Setor só poderá submeter uma
avaliação referente ao seu teste e o mesmo deve ser
validado para o Técnico de RH.
Deverá ser testado se a nota está compreendida

entre um intervalo de 0 a 20.
Avaliação da Resposta do Deverá ser validado se o botão “Resposta do
Candidatura Candidato Candidato” apenas é visível ao Técnico de RH e se
(Back-end) todos os candidatos estiverem selecionados.
Avaliação da Contrato Deverá validar se existe um reencaminhamento para
Candidatura o ecrã “Contrato” apenas e só para o utilizador de
(Back-end) Direção de RH e só quando as três avaliações
estiverem preenchidas.
Avaliação da Selecionar para Deverá ser avaliado se esta opção está apenas visível
Candidatura contratação para o técnico de RH e só quando as três notas
(Back-end) forem atribuídas.
Adicionar Ecrã Deve-se testar se o acesso ao ecrã está limitado aos
Avaliação Responsáveis de Sector ou Técnicos de Recursos
(Back-end) Humanos.
Adicionar Selecionar Opção de Deve-se testar se o utilizador for Responsável de
Avaliação Avaliação Sector a única opção disponível de escolher é
(Back-end) “Entrevista Final”
Adicionar Submeter Testar se todas as informações colocadas nos
Avaliação campos do formulário estão corretamente inseridas
(Back-end) na base de dados, verificar se a obrigatoriedade de
se o campo de input Nota só aceita inteiros maiores
ou igual a 0 (>=0) e menores ou igual a 20 (<=20)
Testar se ao carregar no botão “Submeter” a
informação colocada é guardada na base de dados
corretamente.
4.5 Gestão de apresentação, negociação e contratação
O diagrama de processo de negócio é representado através da linguagem gráfica Business Process

Modeling (BPM) e utilizam a notação Business Process Model and Notation (BPMN), utilizando a
ferramenta Signavio.

Figura 3. Diagrama de Processos da área de Apresentação, Negociação e Contratação
Este subprocesso detalha o fluxo desde do momento em que o candidato é selecionado

pelo Técnico de Recursos Humanos até ao envio da informação do processo de assinatura
de contrato.

Desta forma, o diagrama retrata em primeiro lugar as tentativas de contacto ao candidato
selecionado que deverão ser registadas na plataforma, caso a Direção de Recursos
Humanos não obtenha resposta, o processo de candidatura é fechado por inatividade e a
mesma vaga não poderá ser reaberta, terminando desta forma o processo. A vaga termina
com o estado “Fechada Sem Sucesso” e a candidatura com o respetivo estado “Processo
Fechado por Inatividade”.
No caso do candidato responder e exigir retificações à contraproposta, a Direção de RH

analisa se avança com uma contraproposta. Caso não decida avançar, o candidato deverá
ser informado através da plataforma, através das funcionalidades de Front-End, onde
poderá consultar o novo estado da candidatura, ficando a vaga com o Estado “Fechada
Sem Sucesso” e a respetiva candidatura “Fechada por Recusa de Contraproposta”.
No caso de o candidato aceitar a proposta ou até a contraproposta deverá ser informado

do processo de assinatura do contrato, terminando o processo de candidatura e fechando
a vaga com o Estado “Fechada com sucesso” com a data de ingresso do funcionário. De
notar que, em todos os casos referidos acima, o processo fica concluído.
De salientar que qualquer alteração do estado da vaga e da própria candidatura criará um

log de quem a alterou, a mudança de estado como o respetivo motivo de alteração.

<Têm de incluir uma imagem do diagrama de transição de estados (modelizado

em BPM) e escrever uma explicação do diagrama que justifique as opções
tomadas. Devem começar por um parágrafo que indique que diagrama(s) de
transição de estados fizeram e qual o objetivo de cada um deles. De
seguida devem colocar a imagem de cada diagrama de estados seguido de um
parágrafo que explique por palavras vossas o que está representado e um
parágrafo adicional que explique as opções de modelação que assumiram,
caso necessário>.
O processo de contratação, começa no decorrer do ciclo de vida da Candidatura. Após a

entrevista final com avaliação positiva, o estado da candidatura muda para “Em
Contratação”.
Figura 34. Diagrama de transição de estados do processo da Área de Apresentação, Negociação e

Contratação
Neste momento é feito uma proposta ao candidato ao qual ele pode pedir retificações e ai
passamos de “Em contratação” para “Em reavaliação”. Se a retificação for considerada é
lançado uma contraproposta e o estado da candidatura volta para o estado “Em
Contratação”. Se a contra proposta não for aceite pela direção, a candidatura é colocada
no estado “Terminado sem sucesso”. Uma vez ambas as partes estão de acordo com os
termos da contratação, e todas as devidas burocracias são feitas, a candidatura pode ser
fechada como “Candidatura Fechada”.
Figura 35. Diagrama de transição de estados do processo da Área de Apresentação, Negociação e

Contratação
Tanto para um fecho com sucesso ou não, a o estado da vaga também é impactado. A vaga
nesta fase encontrasse em “Vaga em Analise”, Se a Candidatura não ficar preenchida a
vaga muda para “Vaga fechada sem sucesso.” Caso contrário se a vaga ficar preenchida,,
então assim que o candidato aceita a proposta a vaga é fechada como “Vaga preenchida”,
o técnico de RH tem depois a responsabilidade de fechar a vaga como “Vaga Fechada com
sucesso”
4.5.3 Diagrama de Casos de uso
<Têm de incluir uma imagem do diagrama UML de Use Cases e escrever uma
explicação do diagrama que justifique as opções tomadas. Devem começar por
um parágrafo que indique que diagramas de casos de uso fizeram e qual o
objetivo de cada um deles. De seguida devem colocar a imagem de cada
diagrama de casos de uso seguido de um parágrafo que explique por palavras
vossas o que está representado e um parágrafo adicional que explique

Figura 36. Diagrama de casos de uso do processo de Gestão de Apresentação, Negociação e Contratação
No processo de Área de gestão de Apresentação, Negociação e Contratação analisamos as

seguintes funcionalidades a nível de Back-End na posição de Direção de Recursos
Humanos:
· Fechar Vaga – A Direção de RH pode a qualquer momento fechar a vaga alterando

subsequentemente a vaga.
· Selecionar Candidato para Contratação – Deverá ser da responsabilidade da
Direção de Recursos Humanos depois da aprovação do Responsável de Setor.
· Fechar Candidatura – A direção perante a falta de contactos ou a falha na
apresentação da contraproposta, poderá fechar a candidatura.
· Analisar Resposta do Candidato – Quando o candidato responde à proposta, será
da responsabilidade da Direção de Recursos Humanos analisar a resposta e
perceber quais os próximos passos a tomar.
· Realizar Contrato – Após o candidato aceitar a proposta deverá ser da
responsabilidade da Direção de Recuros Humanos encaminhar o processo para
assinatura de documentos para o ingresso do candidato.
além de aplicação de outras regras de negócio. O conjunto destas tarefas é designado por
grupo de funcionalidades que devem ser detalhadas de acordo com a estrutura indicada
nesta secção.

(ex: listar, consultar, alterar, dar parecer = alterar estado) ou script tasks de processos (ex:
actualizar estados massivamente). De notar que uma service task de processos é
normalmente uma funcionalidade para especificação, mas é invocada a partir de
subfuncionalidade, pois é executada a partir de uma user task.
especificar uma funcionalidade (ex: formulário para criar um produto) temos várias acções
que podem ser botões (ex: gravar, criar/alterar dados). É nestas subfuncionalidades que

A Tabela 17 apresenta as funcionalidades da simulação, indicando quais as tabelas de base de

dados que utiliza, o nível de complexidade estimado para a implementação e se são usados
serviços externos, isto é, indicar se é necessário chamar serviços externos ao Portal. Esta tabela
funciona como um resumo executivo das classes que vão especificar em detalhe nas secções
seguintes.
Tabela 17. Grupo de funcionalidades do processo de gestão de apresentação, negociação e contratação.
Número Complexidade de
identificador do implementação
de classes/tabel indicar quais os
grupo de (baixa, média,
funcionalidades as que utiliza serviços externos
funcionalidades alta) e justificação
1 Contrato Candidatura, Média – Criação N/A
Contrato, de dados com
Estado da Validações
Candi
Notem que deverão repetir a secção 4.5.4.2 tantas vezes quantos as classes a especificar e
implementar para responderem aos requisitos expostos no caderno de encargos para a
área de gestão de apresentação, negociação e contratação. Para cada funcionalidade
deverão salientar/enquadrar os casos de uso (a partir do diagrama de casos de uso) e as
tabelas (a partir do diagrama de classes) a que pertencem. Terão, assim, de replicar os
diagramas de casos de uso e de classes, e enquadrar os respectivos casos de uso e classes
desses diagramas, para cada funcionalidade a especificar.
No caso de uma classe que é para ser utilizada quer no Back-End quer no Front-End, esta
deve ser especificada uma única vez, indicando a particularidades de funcionamento para
o Back-End e o Front-End.
4.5.4.2 Especificação do grupo de funcionalidades de Contrato
Para o preenchimento destas secções podem inspirar-se da organização do documento

relativo à especificação da gestão de produtos, intitulado Exemplo Especificação Requisitos
e de Casos de Teste.
Notem que cada título de secção <G_func.1> é um template que deve ser substituído
pelo nome dos vossos grupos de funcionalidades que devem estar listadas na Tabela 18.
4.5.4.2.1 Especificação das funcionalidades de <G_func.1>

para o Front-End
Tabela 18. Funcionalidades para o Front-End do grupo de funcionalidades de <G_func.1>.
Especificação da Funcionalidade “X” de <G_func.1> (substituir pelo nome da

funcionalidade)
Tabela 19. Regras de funcionamento das sub-funcionalidades de “X” do módulo de Front-End.
Especificação da Funcionalidade “Y” de <G_func.1> (substituir pelo nome da
Tabela 20. Regras de funcionamento das sub-funcionalidades de “Y” do módulo de Front-End.
Especificação da Funcionalidade “Z” de <G_func.1> (substituir pelo nome da

funcionalidade)

funcionalidades por se tratar de um exemplo de funcionalidade que deriva de uma script task ou
service task e como tal origina a execução de um procedimento batch. Devem identificar se existe
a necessidade ou não de tarefa(s) de script neste grupo de funcionalidades que estão a especificar.
Caso não seja necessário, indiquem isso mesmo textualmente e deixem em branco a Tabela 21.
A funcionalidade “Z” (substituir pelo nome da funcionalidade) permite... <completar a

descrição>.

Tabela 21. Regras de funcionamento da Funcionalidade “Z”.
Classe/ Parâmetros Parâmetros Descrição

Procedimento
Tabela Entrada Saída
Contratação Actualizar Estado actual Para todas as
estado da da contratação, contratações no
contratação data do registo estado « Assinado »
há mais de 2 dias até
à data atual deve-se
alterar o estado para
« Activo »
O grupo de funcionalidades de Gestão de Apresentação, Negociação e Contratação para o

Front-End não existe, pois, os candidatos não têm permissões de avaliar candidaturas nem
de submissões de pareceres. Sendo assim, não existem também subfuncionalidades
adjacentes ao Front-End.
4.5.4.2.3 Especificação das funcionalidades de Contrato para o

Back-End
<Identificação de cada funcionalidade (Tabela 22), quais as classes que
utiliza, o nível de complexidade esperado para a implementação e caso seja
necessário, se serão chamados serviços externos ao Portal. Caso seja
pertinente deverão ser adicionados comentários a explicar as decisões
efectuadas ou sugestões a serem seguidas na fase de implementação.
Devem isolar o enquadramento dos casos de uso, relativos a estas

funcionalidades, do diagrama geral de casos de uso que apresentaram na
secção 4.5.3 e colocar aqui a figura desse enquadramento. Ver
enquadramento exemplo na figura 5 do documento Exemplo Especificação
Requisitos e de Casos de Teste. Devem também copiar o enquadramento das
classes a que respeitam. Ver enquadramento na figura 1 do documento
Exemplo>.
Figura 1. Enquadramento das classes respeitante às funcionalidades de Contrato
Figura 39. Enquadramento dos casos de uso respeitante às funcionalidades de Contrato

Tabela 22. Funcionalidades para Back-End do grupo de funcionalidades de Contrato
Tipo (Batch, Complexidade Caso

Serviço, Quais as de utilize,
Ecrã) classes/tabelas da implementação indicar
Funcionalidades
base de dados que (baixa, média, quais os
utiliza alta) e serviços
justificação externos
Contactar Ecrã Contrato, Média - N/A
Candidato Candidatura, Alteração de
Contacto dados com
Validações
Analisar Resposta Ecrã Contrato Baixa – Consulta N/A
de Dados
Gerar Contrato Ecrã Contrato, Média – Adição N/A
Candidatura, Pessoa, de dados com
Vaga Validações
Especificação da Funcionalidade “Contactar Candidato” de Contrato
A funcionalidade “Contactar Candidato” permite registar o número de tentativas de contacto ao

Candidato e o resultado das mesmas – se respondeu ou se não respondeu. Esta ação aciona outras
sub-funcionalidades representadas na próxima funcionalidade.

Tabela 23.
Tabela 23. Regras de funcionamento das sub-funcionalidades de “Contactar Candidato” do módulo de

Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Registar Contacto Através da candidatura, a Direção pode N/A
registar os contactos efetuados ao candidato.
Quando se carrega neste botao, deve
apareces um pop up para o user indicar se o
contacto ocorreu ou não.
Voltar Este botão permite voltar para a pagina da N/A
Candidatura selecionada.
Especificação da Funcionalidade “Analisar Resposta” de Contrato
A funcionalidade “Analisar Resposta” permite identificar no sistema o parecer da proposta dado

pelo Candidato na funcionalidade “Contactar Candidato”. Consoante o resultado do contacto, e as
seleções de botões neste ecrã, ativam-se novos botões de ação. Esta funcionalidade encontra-se no
ecrã de Avaliação Candidatura.

Tabela 24.

Tabela 24. Regras de funcionamento das sub-funcionalidades de “Y” do módulo de Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Proposta Aceite Deve permitir acionar o botão Contrato e N/A
muda o estado da Candidatura para “Em
Contratação”.
Proposta Recusada Esta ação muda o Estado da Candidatura N/A
para “Em Reavaliação”. E pode tomar 2
ações, Terminar ou recomeçar o processo de
Contactar o Candidato com nova proposta.
Se recomeçar, o estado da candidatura muda
para “Para Contratação” outra vez.
Sem Resposta Quando o candidato não responde até ao N/A
prazo estipulado, o DRH pode carregar em
“Sem Resposta” que lhe permite depois
Terminar.
Terminar Este botão só está ativo quando a DRH N/A
carrega em “Sem Resposta” ou “ Proposta
Recusada”. Aciona um pop-up que permite
dar um motivo (obrigatório).
Motivos:
Sem Resposta- “Fecho por Inatividade”
Proposta Recusada – “Recusa de

Contraproposta”
Deve permitir guardar a informação na base

de dados.
Contrato Deve permitir aceder ao Ecrã de que N/A
pertence à funcionalidade “Gerar Contrato”.
Voltar Deve permitir retroceder para os detalhes da N/A
Candidatura.
Especificação da Funcionalidade “Gerar Contrato” de Contrato
A funcionalidade “Gerar Contrato” permite gerar um contrato com todas as informações para o
candidato assinar. Deverá permitir fazer download do template do contrato e enviar ao candidato
selecionado.

Tabela 23.
Tabela 25. Regras de funcionamento das sub-funcionalidades de “Enviar Processo de Assinatura” do

módulo de Back-End.
Integração
externa (isto é,
indicar se é
necessário
chamar
serviços)
Gerar Contrato Deve permitir, após a inserção correta dos N/A
dados de contratação gerar 2 documentos,
um em PDF e outro em DOCX editável.
Estes documentos contêm um template do

contrato e é automaticamente preenchido
com base nos campos preenchidos e os dados
submetidos pelo Candidato.
Este documento é partilhado de forma

independente pela DRH.
Voltar Deve permitir retroceder á pagina de detalhe N/A
da Candidatura.
Especificação da Funcionalidade “Gerar Contrato” de Contrato

funcionalidades por se tratar de um exemplo de funcionalidade que deriva de uma script task ou
service task e como tal origina a execução de um procedimento batch. Devem identificar se existe
a necessidade ou não de tarefa(s) de script neste grupo de funcionalidades que estão a especificar.
Caso não seja necessário, indiquem isso mesmo textualmente e deixem em branco a Tabela 26.
A funcionalidade “Gerar Contrato” permite gerar

Tabela 26. Regras de funcionamento da Funcionalidade “Z”.
Classe/ Parâmetros Parâmetros Descrição

Procedimento
Tabela Entrada Saída
Contrato Gerar (Nome, Nº PDF e DOCX Gerar Contrato em
Contrato formato PDF ou em
Documento, formato Word com
Morada, Nome os parâmetros do
da Vaga, Data contrato
previamente
Inicio, Data
preenchidos em
Fim, Valor Base, sistema.
Outros
beneficios,
Direito a
viatura, Direito
a seguro de
saúde)

Este ecrã permite registar os contatos aos candidato selecionado, registar contacto. Deverá
aparecer um pop-up a confirmar se o candidato atendeu ao respetivo contato.
Este ecrã permite à Direção de RH gerir as contratações. Sendo que as opções disponiveis,
após o candidato ser selecionado. Neste caso se o candidato aceita ou recusa a Proposta.
Apenas com uma resposta positiva a subfuncionalidade “Contrato” fica disponivel.
Caso pretenda terminar deverá selecionar o motivo no pop-up que deverá aparecer no
ecrã.
Dependendo da resposta do candidato, caso seja negativa e não se avance com a

Contraproposta, a candidatura deverá fechar com “Fecho Processo – Recusa de
Contraproposta”, caso contrário deverá ficar com o Estado “Fechar Processo –
Recrutamento Completo”.
Caso o candidato não responda dentro do tempo estipulado deverá ficar com o Estado
“Fechado por Inatividade”.

Após a resposta positiva do candidato, deverá preencher este formulário que deverá
preencher toda a informação sobre o candidato e sobre o tempo de contrato e tipo de
vaga que deverá ser colocada automaticamente no template do contrato. Ao pressionar o
Gerar Contrato deverá fazer download de dois formatos de documento, em PDF ou DOCX
editável.
Podem utilizar qualquer ferramenta que prefiram para especificar um esquisso dos ecrãs
de interface utilizador, considerando a representação das funcionalidades que estão a
especificar. O conteúdo desses ecrãs será tomado em consideração por aproximação e não
por escala. Devem identificar e explicar cada ecrã.
• Implementação e testes das funcionalidades de Área de gestão de apresentação,

negociação e contratação associadas às tabelas de Candidatura, Contrato, Estado da Candidatura

4.5.5.2 Especificação dos Testes do Grupo de Funcionalidades

Contrato
Esta secção deve ser repetida para cada grupo de funcionalidades que especificaram como
requisitos relativos à área de gestão de apresentação, negociação e contratação, pelo que devem
criar uma secção por grupo de funcionalidades. Para cada funcionalidade devem indicar o que deve
ser testado (Tabela 27).
Tabela 27. Especificação dos testes a realizar para o grupo de funcionalidades Contrato.
Funcionalidad sub-
Teste a realizar
e funcionalidades
Gerar Contrato Gerar Contrato Deve-se validar se a data de início é anterior á de fim
(Back-end) e que a data de início não se encontra numa data
anterior á presente.
O botão “Gerar Contrato” deve gerar, de acordo

com o formulário na página, um PDF e um DOCX.
Deve-se testar e validar se os documentos são

gerados de acordo com o especificado e se a
formatação segue os parâmetros descritos.
Gerar Contrato Voltar Deve-se testar se o reencaminhamento para a

(Back-end) página “Avaliações” é feito com sucesso.
Contactar Ecrã Deve-se testar se o acesso ao ecrã está limitado à
Candidato Direção de Recursos Humanos ou Técnicos de
(Back-end) Recursos Humanos.
Contactar Registar Contacto Deve-se testar se ao carregar no botão “Registar

Candidato Contacto” surge um Pop Up com duas opções de
(Back-end Escolha (Sim ou Não).
Testar se for selecionado a opção “Sim” é

adicionado uma opção à tabela do ecrã, com a
checkbox da coluna atendido preenchido.
Caso contrário, a checkbox fica vazia.
Testar se ao adicionar a 3 chamadas não atendida, o

estado da candidatura é alterado para “Terminada
sem Sucesso” na base de dados.
Contactar Voltar Deve-se testar se ao carregar no botão “Voltar” o
Candidato utilizador é redirecionado para o ecrã “Consultar
(Back-end Candidatura”
5. Apreciação crítica da conceção da solução – FASE 1

Nesta secção devem efetuar uma apreciação crítica do que é apresentado pelo grupo que
concebeu a solução de acordo com o capítulo 4. Como tal, este capítulo deve ser
preenchido pelo que grupo que vai desenvolver/implementar a solução.
5.1 Diagrama de classes
Qualidade (Fraca, Razoável, Boa ou Muito Boa): Muito Boa
Breve Justificação (por exemplo face à análise que fazem do

caderno de encargos): Notamos que o diagrama de classes
proposto preenche todos os checkboxs necessários para a
implementação deste projeto em outSystems. Pequenos toques
tiveram que ser dados, no entanto foram minor details.
A modelização que propõem é diferente? (Sim/Não): Não
No caso afirmativo, expliquem as diferenças:

5.2 Gestão de definição, análise, aprovação e publicação de vaga
5.2.1 Modelização do(s) processo(s)
Qualidade (Fraca, Razoável, Boa ou Muito Boa): Boa

caderno de encargos): Todo o processo segue uma lógica boa,
há um pormenor quando se aplica mudanças na proposta pelo
técnico, na nossa perspetiva deveria ser aprovado também
pelos RH.
A modelização que propõem é diferente? (Sim/Não): Não

5.2.2 Diagrama(s) de transição de estados

caderno de encargos): Surgem algumas questões face a haver
estados Em revisão repetidos , sendo que por vezes são
diferentes utilizadores que terão que fazer essa “Revisão”.
A modelização que propõem é diferente? (Sim/Não): Sim
No caso afirmativo, expliquem as diferenças: Retirámos alguns estados que não

faziam sentido na implementação.

5.2.3 Diagrama(s) de casos de uso
Breve Justificação (por exemplo, face à análise que fazem

do caderno de encargos): Tendo uma organização delicada, de
partir em dois os diagramas , um para os candidatos e outro
para o staff da empresa torna a leitura dos mesmos mais
eficaz.
O caso de uso que propõem é diferente? (Sim/Não): Não

Qualidade (Fraca, Razoável, Boa ou Muito Boa): Muito boa

caderno de encargos): Grande foco no detalhe, todo e
qualquer pormenor foi coberto, o que torna o trabalho da
equipa implementadora muito mais acessível.
A Especificação que propõem é diferente? (Sim/Não): não


caderno de encargos): Esta primeiro etapa da gestão de vaga
, termina com grande foco na especificação de testes, que
faz justiça à complexidade desta implementação.
A Especificação que propõem é diferente? (Sim/Não): Não

5.3 Gestão de seleção e avaliação de candidaturas
Qualidade (Fraca, Razoável, Boa ou Muito Boa): ____________

caderno de encargos):
A modelização que propõem é diferente? (Sim/Não): _______


do caderno de encargos):
O caso de uso que propõem é diferente? (Sim/Não): _______



A Especificação que propõem é diferente? (Sim/Não): _______



5.4 Gestão de apresentação, negociação e contratação






do caderno de encargos):
O caso de uso que propõem é diferente? (Sim/Não): _______






5.5 Avaliação global da especificação face ao implementado
Quem escreve: grupo que realizou a implementação.
<Texto avaliativo da qualidade e clareza das especificações recebidas.

Referir a coerência, completude, nível de rigor e detalhe. Convém
exemplificar afirmações>.
Gostávamos de destacar a excelente qualidade e clareza das especificações

recebidas da nossa equipa. As especificações foram consistentes em todos os detalhes,
mostrando um alto nível de coerência e lógica. Cada requisito foi definido com rigor e
detalhe, proporcionando uma base sólida para as nossas implementações.
Além disso, a outra equipa demonstrou um elevado grau de profissionalismo e brio

ao executar as implementações. Todas as tarefas foram realizadas de forma precisa e
correta, atendendo perfeitamente aos requisitos estabelecidos. A atenção aos detalhes e o
compromisso com a qualidade foram evidentes em cada entrega.
O trabalho da nossa equipa parceira foi exemplar, mostrando um profundo

conhecimento técnico e um comprometimento inegável com o sucesso do projeto. As
implementações foram realizadas de forma eficiente, demonstrando uma compreensão
completa das especificações e entregando soluções de alta qualidade.
Em resumo, estamos extremamente satisfeitos com a qualidade das especificações

recebidas e com o trabalho realizado pela outra equipa. O profissionalismo, dedicação e
competência foram fundamentais para o sucesso do projeto, e estamos orgulhosos em tê-los
como colegas.
Avaliação global da qualidade das especificações recebidas
Avaliação (A, B, C, D, E): A
Utilizem a seguinte escala:
E: - 1 – 5 valores D: 6 – 9 valores C: 10 – 13 Valores B: 14 – 17 valores A: 18 – 20 valores
Explique as três principais deficiências de especificação que

tiveram impacto mais negativo na qualidade da implementação.
Grande complexidade que acaba por confundir no momento da

implementação, sendo o seguimento pouco linear.
Transições de estados, que refletiam muitos estados que no

papel têm o seu significado, mas que para implementação não
têm necessidade de existir.
Complicações na implementação da base de dados, pois algumas

tabelas estavam com minor details que precisavam de se
alterar.

Resumo de avaliações de qualidade da especificação face à
implementação (para cada linha assinalar com x em célula
correspondente)
Fraco Razoável Bom Muito Bom
Diagrama de Casos x
de Uso
Modelização de x
Processos
Diagrama de Classes x
Diagrama de x
Transição de
Estados
Especificação das x
funcionalidades
Especificação dos
testes
Justificação:
6. Desenvolvimento da solução - FASE 2

6.1 Modelo de dados
<Inserir uma imagem do esquema relacional da base de dados criada em

OutSystems. Devem tentar implementar a especificação proposta pelo grupo
analista. Apenas em caso de impossibilidade ou de o resto do projecto
ficar comprometido, devem alterar o esquema e neste caso justificar as
opções tomadas, caso tenham feito alterações às especificações do grupo
analista. Devem complementar o esquema com uma descrição textual da
relação entre as tabelas>.
Figura 2. Esquema relacional da base de dados implementada.

A Tabela 28 deve descrever os campos do modelo de dados.
Tabela 28. Descrição geral dos campos do modelo de dados.
Nome do campo Descrição Nome da Formato do campo

tabela a
que
pertence o
campo
Código Identificador Loja  Int
Código
da Loja
 Obrigatório
Designação Nome da Loja
 Obrigatório
Distrito Distrito da Loja
 Obrigatório
Localidade Localidade da Loja
 Obrigatório
Morada Morada da Loja
Data de Abertura da  Obrigatório

Data de Abertura
Loja
 Obrigatório
Estado Estado da Loja
 Obrigatório
registo
 Obrigatório
a operação de sistema com o utilizador
Modificador Registo alteração
registo
 Obrigatório
Início Registo criação do registo sistema com a data e hora da

registo
 Obrigatório
Estado do registo
lógica

tabela a
que
pertence o
campo
Código Primária)
da Área Funcional
Código Loja Estrangeira da tabela Loja)
da Loja
Nome da Área  Obrigatório

Designação
Funcional
Data de abertura da  Obrigatório
Data Abertura
Área Funcional
Estado da Área  Obrigatório
Estado Área
Funcional
Funcional  Obrigatório (Chave
Código Empregado Estrangeira da tabela
do Código Empregado
Colaborador)
 Obrigatório
registo
Modificador Registo Utilizador que realizou  Obrigatório
alteração sistema com o utilizador
registo

 Obrigatório
Data de início da
Início Registo sistema com a data e hora da
 Obrigatório
 Obrigatório
Estado do registo
lógica

tabela a
que
pertence o
campo
Código Primária)
do Perfil
 Campo numérico
 Obrigatório
Tipo de Perfil (Técnico
Tipo Perfil  Apenas será possível
ou Comportamental)
selecionar um de cada vez
Descrição associada ao  Obrigatório
Designação
Tipo Perfil
 Permite NULL
Observação Observações
 Obrigatório
Criador Registo Perfil sistema com o utilizador
registo
 Obrigatório

registo

 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a que
pertence o
campo
Perfil
do Perfil Estrangeira da tabela Perfil)
Comportamental
Comportamental
Perfil Técnico
do Perfil Técnico Estrangeira da tabela Perfil)
Código Categoria
da Categoria Estrangeira da tabela
Profissional
Profissional Categoria Profissional)
 Obrigatório

Criador Registo
registo
Modificador Registo Utilizador que realizou  Obrigatório

a operação de
alteração  Deve ser preenchido pelo

registo
 Obrigatório

Início Registo
 Obrigatório

Alteração Registo
 Obrigatório
Perfil por
Categoria
Estado Registo Estado do registo Profissional
lógica

tabela a
que
pertence o
campo
Código Indentificador  Único e Obrigatório (Chave
Código
da Experiência Primária)
Nome da Entidade  Obrigatório
Nome Entidade cuja experiência foi
adquirida
Código Perfil por
do Perfil por Categoria  Chave Estrangeira da tabela
Categoria Profissional
Profissional Categoria Profissional
Código Indentificador  Obrigatório
Código Pessoa
da Pessoa
Data de Entrada na  Obrigatório
Data Entrada
Data de Saída na  Obrigatório
Data Saída
Criador Registo Utilizador que realizou  Obrigatório
registo
 Obrigatório

registo
 Obrigatório

Início Registo
 Obrigatório
Experiência
Alteração Registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Código Código Identificador  Único e Obrigatório (Chave

do Género Primária)
Descrição Nome do Género  Obrigatório
 Obrigatório

Criador Registo
registo
 Obrigatório

registo
 Obrigatório

Início Registo
Género
 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Código
da Pessoa Primária)
Nome Curto Nome abreviado da  Obrigatório
pessoa  Assume-se o preenchimento
de 2/3 nomes no máximo
Nome completo da  Obrigatório
Nome Longo
Pessoa
Morada Morada da Pessoa  Obrigatório
Distrito onde a Pessoa  Obrigatório
Distrito
mora
Estado Estado da Pessoa  Obrigatório
Código Género Estrangeira da tabela
do Género
Género)
Estado Civil Estrangeira da tabela Estado
do Estado Civil
Civil)
Email Email da Pessoa  Obrigatório
 Obrigatório
Data de nascimento da
Data de Nascimento
Pessoa  Formato Date
 Obrigatório
Contacto Telefónico da  Formato Numérico com 9

Contacto
Pessoa
dígitos
 Obrigatório

Criador Registo
registo
 Obrigatório

Pessoa registo
 Obrigatório

Início Registo

 Obrigatório

lógica

tabela a que
pertence o
campo
Código Identificador Documentaçã  Único e Obrigatório (Chave
Código
da Documentação o Primária)
 Obrigatório
Código Tipo Código Identificador
 Chave Estrangeira da tabela
Documento do Tipo Documento
Tipo Documento
 Obrigatório
Código Pessoa  Chave Estrangeira da tabela
da Pessoa
Pessoa
URL com a  Obrigatório
HyperLink
documentação
Observação Observações  Permite NULL
 Obrigatório

Criador Registo realizou a operação sistema com o utilizador
registo
 Obrigatório

Modificador Registo realizou a operação sistema com o utilizador
de alteração autenticado que alterou o
registo

 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Código
do Tipo Documento Primária)
Designação do Tipo  Obrigatório
Tipo Documento
Documento
 Obrigatório

Criador Registo
Tipo registo
Documento
 Obrigatório
registo

 Obrigatório

Alteração Registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Código Identificador Estado Civil  Único e Obrigatório (Chave
Código
do Estado Civil Primária)
Designação do Estado  Obrigatório
Designação
Civil
 Obrigatório
registo
 Obrigatório
registo
 Obrigatório

Início Registo

registo
 Obrigatório

lógica

tabela a
que
pertence o
campo
Identificação do Distrito  Obrigatório
Código
 Obrigatório, pelo que deverá
Designação Nome do Distrito estar preenchido quando um
Distrito é criado
 Obrigatório
Código Identificado do
Código País  Chave estrangeira da tabela
País
País
 Obrigatório
registo
Utilizador que realizou  Obrigatório
registo
 Obrigatório
Início Registo
registo  Deve ser preenchido pelo

 Obrigatório
lógica

tabela a
que
pertence
o campo
País  Único e Obrigatório
Identificação do (Chave Primária)
Código
 Obrigatório
Código Identificação
Internacional Internacional do País
 Obrigatório
Designação Nome do País
Continente a que o  Obrigatório

Continente
País pertence
 Obrigatório
Utilizador que
registo
Modificador Utilizador que  Obrigatório

Registo realizou a operação  Deve ser preenchido pelo
registo
 Obrigatório
Data de início da
Início Registo sistema com a data e hora
 Obrigatório
Data de alteração do
registo
 Obrigatório

tabela a que
pertence o
campo
Código da  Único e Obrigatório –
Código Avaliação Chave Primária
Candidatura
Avaliação  Obrigatório
 Obrigatório
Data em que é
Data Avaliação  Formato Date
dada a nota final
Código Teste Código  Permite NULL

Individual Identificador do
Teste Individual

tabela Avaliação
Entrevista
 Permite NULL
tabela Avaliação
Código Entrevista
Código Entrevista Identificador da
de Grupo Entrevista de
Grupo caso o campo Código
Entrevista Individual não
esteja preenchido
 Permite NULL
tabela Avaliação
Código Entrevista
Código Entrevista Identificador da  Só pode ser preenchido
Individual Entrevista caso o campo Código
Individual Entrevista de Grupo não
esteja preenchido
 Permite NULL
tabela Avaliação
Entrevista
Código
Código Entrevista Teste Individual esteja
Identificador da
Final preenchido, bem
Entrevista Final
como, uma das duas
entre Código
Entrevista de Grupo e
Código Entrevista
Individual
Cálculo dos  Permite NULL

Cálculo resultados de cada  É um valor numérico
teste e entrevista
operação de criar sistema com o utilizador
registo

Modificador Registo
registo
 Obrigatório
Data de início da
Início Registo sistema com a data e
hora da criação do registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Código Identificação da Candidatura  Único e
Candidatura Obrigatório –
Chave Primária
 Este é um valor
numérico

 Obrigatório
 Chave
Código
estrangeira na
Código Candidato Identificador do
tabela
Candidato
Candidato
 Permite NULL
 Chave
Código estrangeira na
Código Motivo Fecho Identificador do tabela Motivo
Candidatura Motivo Fecho Fecho
 Obrigatório
Código
 Chave
Identificador da
Código Vaga estrangeira na
vaga a que
pertence tabela Vaga
 Obrigatório
 Deve ser
preenchido com a
Data da
Data Candidatura data de
Candidatura
submissão da
Candidatura
Observação  Obrigatório
Observação relacionada à
candidatura
 Obrigatório
Código  Chave
Código Estado Identificador do estrangeira da
Candidatura Estado tabela Estado

realizou a  Deve ser
operação de criar preenchido pelo
sistema com o
utilizador
autenticado que
criou o registo
 Obrigatório
Utilizador que  Deve ser
realizou a preenchido pelo
operação de sistema com o
Modificador Registo
alteração utilizador
autenticado que
alterou o registo
 Obrigatório
 Deve ser
preenchido pelo
Data de início da
Início Registo sistema com a
data e hora da
 Obrigatório
 Deve ser
preenchido pelo
Data de alteração sistema com a
Alteração Registo
do registo data e hora da
alteração do
registo
 Obrigatório
 Deve ser
preenchido com
“A” para “Ativo”
ou “I” para
“Inativo”, como
suporte à
estratégia de

tabela a
que
pertence

o campo
Contrato  Único e Obrigatório –
Identificação do Chave Primária
Código
Contrato  Este é um valor numérico
 Obrigatório
Código
tabela Candidatura
Candidatura
 Obrigatório
Data Início do
Data Início  Formato Date
contrato
 Obrigatório
 Formato Date
Data expiração  Deve ser preenchido com
Data Fim
do contrato uma data superior à data
de início do contrato
 Obrigatório
Salário base do
Valor Base  Formato numérico
contrato
 Obrigatório
Direito a viatura Direito a viatura
tenha direito a viatura e
“Não” caso não tenha
 Obrigatório
Direito a seguro
Direito a Seguro Saúde tenha direito a seguro de
de saúde
saúde e “Não” caso não
tenha
 Obrigatório
 Formato numérico
Valor
 Caso o candidato não
monetário de
Valor Outros Benefícios tenha direito a mais
outros
benefícios nenhum benefício,
colocar 0.

realizou a
operação de
criar
registo

Modificador Registo
registo
 Obrigatório
Data de início  Deve ser preenchido pelo
Início Registo da criação do sistema com a data e hora
registo da criação do registo
 Obrigatório
Data de  Deve ser preenchido pelo
Alteração Registo alteração do sistema com a data e hora
registo da alteração do registo
 Obrigatório
Estado do
Estado Registo para “Inativo”, como
registo

tabela a que
pertence o
campo
Código Identificação do Estado  Único e Obrigatório –
Estado da Candidatura Chave Primária
numérico

deverá estar preenchido
Nome Estado Nome do Estado quando um estado da
candidatura é criado
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório
tabela a
que
pertence o
campo
Categoria  Único e Obrigatório –
Identificação da Profissional Chave Primária
Código Categoria  Este é um valor
Profissional numérico
 Obrigatório
Código Área Código Identificador  Chave estrangeira na
Funcional da Área Funcional tabela Área Funcional
 Obrigatório, pelo que terá

de estar preenchido
Nome da Categoria
Designação quando uma Categoria
Profissional
Profissional é criada
 Obrigatório
Data de criação da
Data Criação Categoria
Profissional a data e hora da criação
da Categoria Profissional
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
Modificador sistema com o utilizador
de alteração
Registo autenticado que alterou o
registo

 Obrigatório
Data de alteração
do registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação do
Colaborador
numérico
 Obrigatório
Identificador da
Código Categoria tabela Categoria
Categoria
Profissional Profissional
Profissional
 Obrigatório
Código
Código Pessoa Identificador da
Pessoa tabela Pessoa
 Obrigatório
Utilizador que
pelo sistema com o
de criar utilizador autenticado
que criou o registo

pelo sistema com o
de alteração
utilizador autenticado
que alterou o registo
 Obrigatório
Data de início da pelo sistema com a data
Início Registo
criação do registo Colaborador e hora da criação do
registo
 Obrigatório
Data de alteração pelo sistema com a data
Alteração Registo
do registo e hora da alteração do
registo
 Obrigatório

tabela a que
pertence o
campo
Estado  Único e Obrigatório –
Vaga Chave Primária
Identificação do
Estado Vaga
numérico
Nome do Estado da  Obrigatório, pelo que

Vaga terá de estar

preenchido quando um
Nome Estado Estado de Vaga é criado
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Código Identificação da Alteração  Único e Obrigatório –
Alteração Estado Estado Chave Primária
Vaga
Vaga  Este é um valor
numérico
 Obrigatório
Código Vaga
da Vaga tabela Vaga
 Obrigatório
Código Estado correspondente ao tabela Estado Vaga
Antigo Vaga Estado de Vaga  Respeitar o Diagrama
antigo de Estados da Vaga
 Obrigatório
Código Estado Novo correspondente ao tabela Estado Vaga
Vaga Estado de Vaga  Respeitar o Diagrama
novo de Estados da Vaga
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo

do registo

registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação da
Vaga
numérico
 Obrigatório
Código Perfil Código Identificador  Chave estrangeira da
Categoria do Perfil Categoria tabela Perfil Categoria
Profissional Profissional Profissional
 Obrigatório
Código Estado Vaga
do Estado Vaga tabela Estado Vaga
 Permite NULL
 Preenchida
automaticamente
Data de Abertura da
Data Abertura quando é colocada no
Vaga
estado “Publicada”
 Formate Datetime
Data de  Permite NULL

Encerramento da Vaga
 Preenchida
automaticamente
quando é colocada no
estado “Arquivado” ou
Data Encerramento “Fechado sem Sucesso”
Vaga
ou “Fechado com
Sucesso”
 Obrigatório
Criador Colaborador que automaticamente com
abriu o processo o código Colaborador
que cria o pedido
 Permite NULL
Aprovador Colaborador que automaticamente com
aprovou o processo o código Colaborador
que aprova o pedido
Descrição do Descrição do  Obrigatório

Pedido Pedido de vaga
 Permite NULL
Notas Notas adicionais
 Obrigatório
Utilizador que
registo


o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Alteração  Único e Obrigatório –
Identificação da Estado Chave Primária
Código alteração de estado Candidatura  Este é um valor
de candidatura numérico
 Obrigatório
Código
Código  Obrigatório
Identificador  Chave estrangeira da
Código Estado correspondente ao tabela Estado
Antigo Candidatura Estado de
Candidatura
Candidatura antigo
 Respeitar o Diagrama de
Estados da Candidatura
 Obrigatório
Código Estado Novo
Candidatura
Candidatura novo Estados da Candidatura
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Motivo  Único e Obrigatório –
Identificação do Fecho Chave Primária
Código Motivo de Fecho da Candidatura  Este é um valor
Candidatura numérico
Descrição sobre o  Obrigatório

motivo da alteração
Descrição
do estado da
candidatura
 Obrigatório
da Candidatura
tabela Candidatura
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo

registo
 Obrigatório

tabela a que
pertence o
campo
Contacto  Único e Obrigatório –
Chave Primária
Identificação do
Contacto
numérico
 Obrigatório
Código Candidatura
da Candidatura tabela Candidatura
 Obrigatório
Data em que foi  Deve ser preenchido
Data
efetuado o contacto com a data e hora da
ligação telefónica
 Obrigatório
Tipo de contacto  Enumerado com as
Tipo Contacto efetuado com o opções “Entrevista” ou
candidato “Contratação”
 Obrigatório
Valida se o
Atendeu candidato atendeu
o Técnico RH opções “Sim” e “Não”


registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
 Obrigatório

tabela a que
pertence o
campo
Chave Primária
Identificação do
Contacto
numérico
Código Pessoa Código Identificador  Obrigatório

da Pessoa
tabela Pessoa
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo
Candidato  Obrigatório

tabela a que
pertence o

campo
Chave Primária
Identificação do
Id  Este é um valor
User
numérico
 Obrigatório
User
 Assegurar a
correspondência com o
atributo “Nome Curto”
Name Nome do Utilizador
da Pessoa (sendo ela
um Colaborador ou um
Candidato)
 Obrigatório
 Obrigatório ter
Nome codificado do
UserName caracteres
Utilizador
alfanuméricos
 Obrigatório
 Tem que ter no mínimo
8 caracteres, podendo
Código secreto do
Password conter caracteres
Utilizador
alfanuméricos e/ou
caracteres especiais
 Obrigatório
 Formato email
Email Email do utilizador
 Obrigatório
Contacto de  Valor numérico com 9
Mobile Phone telefónico do dígitos
utilizador
Identificador do  Permite NULL

número de  Só é preenchido caso
External_Id utilizador externo este utilizador não seja
colaborador
 Este é um valor
numérico de auto-
preenchimento
 Obrigatório
Data da criação da  Formato Date
Creation_Date
conta
 Obrigatório
Data do último  Formato Datetime
Last_Login
login
 Obrigatório
Se o acesso se com True caso esteja
Is_Active contra ativo ou
ativo e Falso caso esteja
inativo
inativo
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo

registo

 Obrigatório

tabela a que
pertence o
campo
Identificação da Chave Primária
Código
Avaliação Entrevista  Este é um valor numérico
 Obrigatório
opções “Teste
Individual” ou
Descrição do tipo
Tipo de Entrevista “Entrevista de Grupo”
de Entrevista
ou “Entrevista
Individual” ou
“Entrevista Final”
 Obrigatório
Código Candidatura tabela Candidatura
da Candidatura
 Obrigatório
Nota numérica da  Obrigatório ter
Nota Avaliação
Entrevista caracteres numéricos
 Permite NULL
Comentários
Comentários sobre
a Entrevista
Avaliação
Entrevista
do Colaborador
 Chave Estrangeira da
Código Colaborador tabela Colaborador
 Obrigatório
Data Data da entrevista  Formato Date

Código Avaliação
da Avaliação
Candidatura
Candidatura
 Obrigatório
Utilizador que
registo
 Obrigatório
Utilizador que
o registo
 Obrigatório
Início Registo
registo
 Obrigatório
Alteração Registo
registo

para “Inativo”, como

6.2 Ecrãs em OutSystems
A Tabela 29 deverá listar a informação sobre os ecrãs implementados.
Tabela 29. informação sobre os ecrãs implementados.
Nome do Grupo de
Nome das tabelas de
funcionalidades e
Ecrã base de dados que
Funcionalidades que
utiliza
implementa
Login Candidato : Sign In e User,

Sign Up
Criar Registo Candidato: Registar, User, Candidato

Dados Pessoais cancelar e adicionar
Nota: Temos as
funcionalidades bem
implementadas mas
estamos a ter
problemas quando
criamos uma entrada
numa tabela que
contenha um fk.
Listar Vaga : Consultar Vaga
Necessidades Pedido, Listar
Pendentes, Submeter
Novo Pedido, Gestão
de dados Estáticos,
Vagas
Publicadas/Pedido de
Vagas, Logout
Submeter Vaga : Submeter, Vaga, Estado Vaga,
Necessidade Voltar Alteração Estado
Vaga
Avaliação Pedido Vaga : Aceitar, Vaga
Necessidade Recusar, Pedir
Revisão, Voltar Estado Vaga
Alteração Estado
Vaga
Rever Necessidade Vaga : rever Vaga
Estado Vaga
Publicar Vaga Vaga :Publicar, Voltar Vaga
Pedir Revisão Estado Vaga
Guardar Alteração Estado

Vaga
Gestão de Dados Vaga :Inserir Dados Categoria
Profissional, Perfil,
Alterar Dados Loja, Área
Funcional, Tipo
Eliminar Dados Documento,
Género, Estado
Voltar
Civil, País, Distrito,
Estado Vaga,
Motivo Fecho
Candidatura,
Estado
Candidatura
Consultar Candidatura: Avaliação
Candidatura Cancelar, Voltar Candidatura,
Back-end : Assigar a Contacto,
mim, Avaliação Candidato, Motivo
Candidatura, Voltar, Fecho
Contactos, Download Candidatura,
Estado
Candidatura,
Alteração Estado
Candidatura,
Avaliação
Entrevista,
Candidatura
Candidatar Candidatura: Colaborador,

Guardar, Submeter, Avaliação
Voltar Entrevista,
Candidatura,
Avaliação
Candidatura
Avaliação de Avaliação Colaborador,
Candidatura Candidatura:Adiciona Avaliação
r Avaliação, Voltar, Entrevista,
Terminar, Aprovar, Candidatura,
Selecionar para, Avaliação
Contratação, Candidatura
Contrato, Resposta
Candidato
Adicionar Avaliação Avaliação
Avaliação Candidatura:Submet Candidatura,
er Contacto,
Candidato, Motivo
Voltar Fecho
Candidatura,
Estado
Candidatura
Contactos Contacto: Registar Alteração Estado
Contacto, Voltar Candidatura,
Avaliação
Entrevista,
Candidatura
Contactar Contrato:Registar Contrato,
Candidato Contacto Candidatura,
Contacto
Voltar
Analisar Resposta Contrato:Proposta Contrato
Aceite
Proposta Recusada
Sem Resposta
Terminar
Contrato
Voltar
Gerar Contrato Contrato: Gerar Contrato,
Contrato Candidatura,
Pessoa, Vaga
Voltar
6.3 Manual de utilizador
<Criar uma subsecção por cada ecrã que criaram, onde colocam uma cópia do
ecrã criado (screnshot) e explicam o que é possível fazer através desse
ecrã, como um manual de utilizador>.
1ºecrã – Área Funcional

Este é o ecrã da lista das áreas funcionais, onde é possível ver a lista de todas as áreas que existem,
incluindo qual a sua designação (nome da área funcional), data de abertura da mesa, o estado em
que se encontra esta mesma área funcional, o código do empregado e um botão de editar (caso o
utilizador que estiver o ecrã tenha permissões para editar uma área funcional). Neste ecrã é
também possível observar um botão para adicionar uma área funcional (caso tenhamos permissões
para tal e uma barra de procura.
2ºecrã – Área Funcional Detail
Este é o ecrã da Área Funcional Detail, onde caso queiramos editar ou criar (dependendo se no ecrã
anterior clicámos no botão de adicionar nova área funcional ou se clicámos no botão de editar uma
certa área funcional), visualizamos os campos: Designação (nome da área funcional), data de
abertura da mesma, código do empregado, O estado de registo que se encontra (se ativo ou
inativo), e por fim o código da loja para o qual será esta área funcional. Existe ainda o botão Back
(para voltar para o ecrã anterior) e um botão save onde podemos guardar as alterações que
fizemos ou criar uma nova área funcional.
3ºecrã – Lista das Categorias Profissionais
Este é o ecrã da lista das Categorias Profissionais, onde é possível ver a lista de todas as categorias
profissionais que existem, incluindo qual a sua designação (nome da categoria profissional), data
de criação da mesma, o criador do registo (a pessoa que criou o registo da categoria profissional), o
modificador do registo (a pessoa que editou alguma categoria profissional) e um botão de editar
(caso o utilizador que estiver o ecrã tenha permissões para editar uma área funcional). Neste ecrã é
também possível observar um botão para adicionar uma área funcional (caso tenhamos permissões
para tal e uma barra de procura.
4ºecrã – Categorias Profissionais Detail

Este é o ecrã Categorias Profissionais Detail, onde caso queiramos editar ou criar (dependendo se
no ecrã anterior clicámos no botão de adicionar nova categoria profissional ou se clicámos no
botão de editar uma certa categoria profissional), visualizamos os campos: Designação (nome da
categoria profissional), data de criação da mesma, o estado do registo em que se encontra, e qual o
código da área funcional que está associada a esta categoria profissional. Por fim, existe ainda o
botão Back (para voltar para o ecrã anterior) e um botão save onde podemos guardar as alterações
que fizemos ou criar uma nova categoria profissionall.
5ºecrã – Perfil
Este é o ecrã da lista de perfis, onde é possível ver a lista de todas os perfis que existem, incluindo
qual o seu tipo de perfil, qual a sua designação (nome da do perfil), uma observação do perfil, o
criador do registo (a pessoa que criou o registo do perfil), e um botão de editar (caso o utilizador
que estiver o ecrã tenha permissões para editar um perfill). Neste ecrã é também possível observar
um botão para adicionar um perfil (caso tenhamos permissões para tal) e uma barra de procura.
6ºecrã – Perfil Detail
Este é o ecrã perfil detail, onde caso queiramos editar ou criar (dependendo se no ecrã anterior
clicámos no botão de adicionar um perfil ou se clicámos no botão de editar um perfil), visualizamos
os campos: Tipo de perfil, Designação (nome do perfil), uma observação do perfil, e o estado do
registo em que se encontra este mesmo perfil. Por fim, existe ainda o botão Back (para voltar para
o ecrã anterior) e um botão save onde podemos guardar as alterações que fizemos ou criar um
novo perfill.
7ºecrã – Estado da Vaga

Este ecrã Estado da Vaga tem a lista dos estados das vagas já criados. É possível visualizar que
cada estado tem o nome, o criador do registo (quem criou este estado da vaga), o modificador de
registo (para se saber quem editou uma vaga caso tenha acontecido), e um inicio de registo. Tem
ainda um botão de editar (caso o utilizador que estiver no ecrã tenha permissões para editar o
estado de uma vaga) e um botão para eliminar este estado da vaga. Neste ecrã é também possível
observar um botão para adicionar um estado de vaga (caso tenhamos permissões para tal) e uma
barra de procura.
8ºecrã – Estado da Vaga Detail
Este é o ecrã Estado da Vaga Detail, que é visualizado que cliquemos no ecrã anterior no botão
editar ou adicionar novo ecrã, tendo este novo ecrã um único campo nome de estado para alterar
ou criar um novo estado da vaga.
9ºecrã – Vaga
Este é o ecrã da lista de vagas, onde é possível ver a lista de todas as vagas que existem, incluindo
qual o perfil da categoria profissional que se idealiza para esta vaga, a data de abertura da mesma,
a data de encerramento, qual o estado atual da vaga, um botão onde se vai para o ecrã Vaga
Consulta(11ºecrã), onde é possível ver os detalhes da vaga e alterar o estado da vaga, existe ainda
um botão de editar (caso o utilizador que estiver o ecrã tenha permissões para editar uma vaga),
indo para o ecrã Vada Detail (10ºecrã). Neste ecrã é também possível observar um botão para
adicionar uma vaga (caso tenhamos permissões para tal) e uma barra de procura.
10ºecrã – Vaga Detail
Este é o ecrã vaga detail, onde caso queiramos editar ou criar (dependendo se no ecrã anterior
clicámos no botão de adicionar uma vaga ou se clicámos no botão de editar uma vaga),
visualizamos os campos: qual o perfil da categoria profissional que se idealiza para esta vaga, a
data de abertura da mesma, a data de encerramento, qual o estado atual da vaga, uma descrição
da vaga pretendida, e umas notas da mesma. Por fim, existe ainda o botão Back (para voltar para o
ecrã anterior) e um botão save onde podemos guardar as alterações que fizemos ou criar uma nova
vaga.

11ºecrã – Vaga Consulta
Este é o ecrã Vaga Consulta, com todos os detalhes anteriormente referidos no ecrã vaga consulta,
com a adição de qual o tipo de perfil comportamental e técnico pretendidos. Todos estes botões
que é possível visualizar no fim do ecrã, não serão, obviamente, todos mostrados em conjunto, uma
vez que estes servem para alterar o estado da vaga. Cada um deles altera o estado da vaga e só
pode ser acedido dependendo das roles definidas.
12ºecrã -


6.4 Perfil de utilizadores
Explicar que perfis de utilizadores criaram, como e a que funcionalidades eles acedem.
Nome do perfil de
Objetivo Funcionalidades a que tem acesso
utilizador
TécnicoRH Publicar a vaga; transcrever a proposta; fechar
a vaga manualmente; alterar a vaga
Candidatura – Terminar processo; Convocar

para entrevista; Selecionar tipo de avaliação;
Associar comentários; Classificação final;
Avaliar e registar prova; Avaliar entrevista;
Iniciar processo de contratação; Avaliar teste;
Assinar a candidatura; Alterar a candidatura
DireçãoRH Vaga - Analise e avaliação da necessidade
Contratação – Fechar a vaga; Alterar a vaga;

Fechar candidatura; Alterar candidatura;
Analisar resposta do candidato; Realizar
contrato; Selecionar o candidato para
contratação; Contratar candidato
Candidato Vaga - Aceder à plataforma de vagas; criar
perfil; consultar a vaga;
Candidatura -Submeter a candidatura; alterar

candidatura
Gestor de Loja Vaga - Arquivar necessidade; rever a
necessidade; submeter pedido de necessidade
de vaga
Responsável de Candidatura: Avaliar entrevista final; Alterar
Setor candidatura
6.5 Serviço API REST
<Inserir a informação de chamada do serviço externos na Tabela 30>.
Tabela 30. Lista dos serviços externos chamados.
Nome do EndPoint Nome do

serviço programa
que faz a

chamada
do
serviço
Rest API https://edulab04.outsystemsenterprise.com/SuperDespensa_API/rest/CheckRegistoCriminal
/TemRegistoCriminal?NomeCandidato={NomeCandidato}&NIF={NIF}
6.6 Lista de procedimentos Batch
<Inserir a lista dos serviços invocados na Tabela 31>.
Tabela 31. Lista dos procedimentos Batch.
Nome do
Objetivo Periodicidade execução
procedimento
7. Apreciação auto-crítica do desenvolvimento da
solução – FASE 2
7.1 Modelo de dados implementado
Quem escreve: grupo que realizou a implementação.

caderno de encargos): Implementação feita nos limites da perfeição, horas e
horas que resultaram numa implementação á prova de erros. Gostaria de destacar a
nossa excelente implementação em OutSystems. Fomos capazes de entregar um projeto
de alta qualidade, cumprindo os requisitos e superando as expectativas. A nossa equipa
demonstrou um elevado nível de profissionalismo, competência e empenho durante todo
o processo.
Conseguimos desenvolver funcionalidades complexas de forma eficiente, utilizando as

melhores práticas e seguindo os padrões recomendados pela plataforma. A arquitetura
do nosso projeto foi bem planeada e estruturada, permitindo uma manutenção fácil e
futuras expansões.
Além disso, a nossa equipa mostrou um bom domínio das funcionalidades do

OutSystems, utilizando recursos avançados como integrações com sistemas externos,
otimização de desempenho e segurança. O resultado final foi um produto robusto,
intuitivo e de alta qualidade.
A comunicação e colaboração entre os membros da equipa também foi exemplar,

trabalhando em conjunto para superar desafios e encontrar soluções criativas.
Mantivemos um bom alinhamento com as necessidades do cliente, garantindo que as
suas expectativas foram atendidas e até mesmo superadas.
Foram feitas alterações? (Sim/Não): Não
Apreciação e Novo Esquema (assinale e justifique as

alterações) <A preencher caso tenham procedido a
alterações>

7.2 Software implementado
Breve Justificação (por exemplo face à qualidade do desenho

dos ecrãs, navegação, mensagens de erro resultantes de
validações): Gostaria de destacar a nossa excelente implementação de uma REST
API em OutSystems. Conseguimos criar uma API robusta, escalável e altamente
funcional, que atendeu às necessidades do projeto de forma eficiente.
Durante o processo de implementação, seguimos as melhores práticas e diretrizes

recomendadas pelo OutSystems para garantir a qualidade e o desempenho da API.
Fomos capazes de modelar adequadamente as entidades e atributos, definindo uma
estrutura coesa e intuitiva para os endpoints da API.
Utilizamos o Service Studio para criar as ações necessárias, implementando de forma

clara e concisa as operações de leitura, escrita e atualização dos dados. Além disso,
utilizamos técnicas avançadas de segurança, como autenticação e autorização, para
proteger a API e garantir a confidencialidade e integridade dos dados.
A documentação da API foi cuidadosamente elaborada, fornecendo informações

detalhadas sobre os endpoints disponíveis, os parâmetros aceitos e as respostas
retornadas. Isso facilitou a integração da API com outras aplicações e permitiu que os
desenvolvedores externos entendessem facilmente como utilizar os serviços
disponibilizados.
Durante os testes e a validação da API, identificamos e corrigimos prontamente

quaisquer problemas ou falhas, garantindo que a API funcionasse de forma consistente e
confiável.
Estamos satisfeitos com o resultado final da nossa implementação da REST API em

OutSystems. Acreditamos que construímos uma solução de alta qualidade, que oferece
flexibilidade e facilidade de uso aos consumidores da API. Estamos confiantes de que a
nossa implementação irá proporcionar um excelente suporte para as necessidades de
integração e comunicação do projeto.
Foram feitas alterações face à especificação? (Sim/Não): Não
Apreciação das alterações <A preencher caso tenham

procedido a alterações indicando se foram positivas ou
negativas face ao que foi especificado>

8. Execução dos testes – FASE 3
<Copiar para as tabelas seguintes os testes especificados para cada
funcionalidade e replicar as tabelas tantas vezes quantos os grupos de
funcionalidades, respectivas funcionalidades e sub-funcionalidades
especificadas>.
8.1 Testes do grupo de funcionalidades “Gestão de definição, análise, aprovação e

publicação de vaga” (substituir pelo nome da funcionalidade)
A Tabela 32 apresenta o resultado dos testes realizados para o grupo de funcionalidades

“Gestão de definição, análise, aprovação e publicação de vaga ” (substituir pelo nome da
funcionalidade)
Tabela 32. Testes realizados para o grupo de funcionalidades “Gestão de definição, análise, aprovação e
publicação de vaga” (substituir pelo nome da funcionalidade).
Funcionalida
de e sub-
Teste realizado Resultado do teste
funcionalidad
es
Teste sem efeito.
Consultar Pedido
Funcionalidade
Página inicial
Necessidades não foi
(Back-End) Foi feito o teste se ao carregar no botão “Consultar
implementada. Botão
pedido” o utilizador é redirecionado para o ecrã
"Consultar Pedido" não
“Consultar Pedido” onde se encontram os detalhes
existe.
Teste sem efeito.
Funcionalidade
Página inicial
Foi feito o teste se ao carregar botão “Listar Necessidades não foi
(Back-End)
Pendentes” o utilizador é redirecionado para o ecrã implementada. Botão
“Lista Pendentes” "Listar Pendentes" não
existe.
Teste sem efeito.

Funcionalidade
Foi feito o teste se ao carregar no botão “Submeter
implementada. Não
Página inicial Novo Pedido”, o utilizador é redirecionado para o
existe botão "Submeter
(Back-End) ecrã “Submeter Necessidade”.
novo Pedido" nem o
consequente
redireccionamento para
o ecrã "Submeter
Necessidade".
Página inicial Foi feito o teste se ao carregar no botão “Vagas Passou. O ecrã de vagas
(Back-End) Publicadas”, o utilizador é redirecionado para o ecrã publicadas é a
HomePage do BackEnd
logo não existe um
botão "vagas
Publicadas". O botão
“Vagas Publicadas”. "Vagas" está repetido,
contudo faz o
redireccionamento com
sucesso para a lista de
vagas.
Passou. O botão de
"Logout" funciona
Página inicial
Foi feito o teste se ao carregar no botão “Logout” a corretamente e existe
(Back-End)
sessão é corretamente terminada e o utilizador é um redireccionamento
redirecionado para o ecrã de Login com sucesso para a
página de login.
Teste sem efeito.

Funcionalidade
Página inicial
implementada. Foi feito
(Back-End) Foi feito o teste se as pesquisas pelo estado do
um teste ao "Search" e
pedido e categoria profissional funcionam.
concluiu-se que apenas
é possível pesquisar por
data.
Falhou. Botão "Gestão

de dados estáticos" não
Foi feito o teste se o botão “Gestão de dados existe, contudo existem
estáticos” apenas está visível caso o utilizador tenha ecrãs adicionais que
Página inicial
a função de Técnico de Recursos Humanos. permitem fazer esta
(Back-End)
gestão.
Ao carregar no botão “Gestão de dados estáticos”, o
utilizador é redirecionado para o ecrã “Gerir Dados Estes ecrãs estão
BD”. disponíveis para todos
os utilizadores.
Testar se todas as informações colocadas nos

campos do formulário estão corretamente inseridas
na base de dados, verificar se a obrigatoriedade de
Teste sem efeito.
Página inicial Funcionalidades
(Back-End) associadas ás
"Necessidades" não
foram implementadas.
Testar se ao carregar no botão “Submeter” o estado
do pedido é alterado para “Submetido” na base de

Teste sem efeito.
Submeter
Funcionalidades
Necessidades Deve-se testar se ao carregar no botão “Voltar” o
associadas ás
(Back-End) utilizador é redirecionado para o ecrã “Página
"Necessidades" não
Inicial”
Teste sem efeito..

Submeter
Funcionalidades
Necessidades
Testar se ecrã é apenas acessível a utilizadores com associadas ás
(Back-End)
a função de Gestor de Loja. "Necessidades" não
Publicar Vaga - Testar se todas as informações colocadas nos Falhou: - Não existe
Publicar campos do formulário estão corretamente inseridas campo ‘Quantidade
na base de dados, verifica se a obrigatoriedade de Colaboradores’; - O
campo de input ‘Data
preencher os campos está corretamente definida. Encerramento’ aceita
Deve respeitar-se as seguintes validações: datas anteriores à data
- Campo de input ‘Quantidade de Colaboradores’ só atual;
aceita inteiros maiores do que 0. Aprovado: - Ao clicar no
- Campo de input ‘Data de Fecho de Vaga’ só deverá botão ‘Save’, este
aceitar datas posteriores à data atual. redireciona para o ecrã
inicial; - O estado da
Testar se ao carregar no botão o utilizador é vaga é alterado para
redirecionado para o ecrã “Página Inicial”. ‘Vaga Publicada’.
Testar se o estado do pedido é alterado para “Vaga
Publicada” na base de dados.
Publicar Vaga - Testar se todas as informações colocadas nos Falhou: - Não existe
Guardar campos do formulário estão corretamente inseridas uma opção de apenas
na base de dados, verifica se a obrigatoriedade de guardar a vaga e não a
preencher os campos está corretamente definida. publicar de imediato, o
Deve respeitar-se as seguintes validações: botão ‘Save’ cria
- Campo de input ‘Quantidade de Colaboradores’ só imediatamente a vaga.
- Testar se ao a carregar no botão o estado do
pedido se mantém inalterado na base de dados e o
utilizador é redirecionado para o ecrã “Página
Inicial”.
Publicar Vaga - Deve-se testar se ao carregar no botão “Voltar” o Passou: - O botão ‘Back’
Voltar utilizador é redirecionado para o ecrã “Listar redireciona o utilizador
Necessidades” para o ecrã ‘Vaga List’.
Publicar Vaga - Testar se ecrã é apenas acessível a utilizadores com Falhou: - Todos os
Ecrã a função de Técnico de Recursos Humanos. utilizadores têm acesso
ao ecrã de publicar uma
vaga, ‘New Vaga’.
Vagas Deve-se testar se ao carregar no botão “Consultar Passou: - Ao clicar no
Publicadas – vaga publicada” o utilizador é redirecionado para o botão ‘Consultar Vaga’
Consultar ecrã “Consultar Vaga Publicada” onde se encontram o utilizador é
Vaga os detalhes da vaga correspondente. redirecionado para o
ecrã ‘Consulta da Vaga’
onde vemos os detalhes
da vaga
correspondente.
Vagas Deve-se testar se ao carregar no botão “Pedidos de Falhou: - Não existe
Publicadas – Vagas” o utilizador é redirecionado para o ecrã qualquer tipo de botão
Pedidos de “Listar Necessidades de Pedidos”. ‘Listar Necessidades de
Vagas Pedidos’.
Vagas Testar se quando chega ao dia definido na data Passou: - Quando chega
Publicadas – limite para a vaga o fecho automático gera o script a data de encerramento
Fecho implementado e a vaga fecha automaticamente. da vaga, esta passa para
automático da o estado ‘Arquivado’.
vaga
Consultar Deve-se testar se ao carregar no botão “Consultar Passou: - Quando
Detalhes Vaga Candidatura” o utilizador é redirecionado para o clicamos no botão
Publicada – ecrã “Consultar detalhe de Candidatura” onde se ‘Consultar
Consultar encontram os detalhes da candidatura Candidaturas’ este
Candidatura correspondente. reencaminha para um
ecrã com a listagem das
candidaturas dessa
vaga.
Consultar Deve-se testar se ao carregar no botão “Consultar Passou: - Ao clicar no
Detalhes Vaga detalhe de vaga” o utilizador é redirecionado para o botão ‘Consultar Vaga’
Publicada – ecrã “Consultar detalhe vaga publicada” onde se o utilizador é
Consultar encontram os detalhes da vaga em questão. redirecionado para o
detalhe da ecrã ‘Consulta da Vaga’
vaga onde vemos os detalhes
da vaga
correspondente.
Consultar Testar se as pesquisas pelos vários campos pedidos Falhou: - A pesquisa
Detalhes Vaga funcionam. pelos estados da vaga
Publicada – não está funcional;
Procurar vaga Testar se ao carregar no botão “Cancelar vaga” o
estado do pedido é alterado para “Fechada Sem Passou: - Ao carregar
Sucesso” na base de dados e utilizador é no botão ‘Vaga Fechada
redirecionado para o ecrã de “Listar Necessidades”. S/Sucesso’ o estado da
vaga é alterado para
‘Fechada sem Sucesso’,
e o utilizador é
redirecionado para o
ecrã da listagem das
vagas.
Consultar Testar se este botão só aparece caso o pedido em Passou: - Este botão só
Detalhes Vaga questão esteja no estado “Vaga Publicada”. aparece caso a vaga
Publicada – esteja no estado ‘Vaga
Cancelar vaga Este botão só deve estar visível caso o utilizador seja Publicada’; - Apenas os

utilizadores com role de
um Técnico de Recursos Humanos. Técnico de RH é que
têm acesso a este
botão.
funcionalidade)
A Tabela 33 apresenta o resultado dos testes realizados para o grupo de funcionalidades

“<G_func.2>” (substituir pelo nome da funcionalidade)
Tabela 33. Testes realizados para o grupo de funcionalidades processo de gestão de seleção e avaliação de
candidaturas.
Funcionalidade e
sub- Teste a realizar Resultado do teste
funcionalidades
Utilizador Não
Registado –
Passou.
Não permite entrar

e dá mensagem de
erro.
Testar se as credenciais correspondem a
credenciais associados a um utilizador na Base
Utilizador
de Dados.
Registado –
Passou.
Caso não exista, deverá apresentar uma
Login (Front-End) - mensagem de erro.
Login e sessão
Sign in 
estabelecidos
Caso o login seja feito com sucesso, validar se
com sucesso (para
é feito o redireccionamento com sucesso para
qualquer role),
a “Pagina Inicial Candidato “e se é
após o log in,
estabelecida uma sessão para o utilizador em
utilizador é
questão.
redirecionado para
página inicial do
candidato.
Deve-se testar se ao carregar no botão Sign-up Passou.

é feito o redirecionado para a página “Criar
Login (Front-End) - registo”. Ao carregar no
Sign Up  botão de registar,
utilizador é

redirecionado para
a página de criação
de registo.
Testar se todas as informações colocadas nos

Falhou.
campos do formulário são corretamente
O campo de nome
inseridas na base de dados.
aceita números.
Deve se verificar se a obrigatoriedade de
Ao carregar no
preencher os campos está corretamente
Criar registo (Front- botão “Registar”,
definida e se os campos de input “First name”
End) - Registar utilizador é criado
e “Last name” apenas podem aceitar
na base de dados,
caracteres alfabéticos Maiúsculos ou
contudo user não é
minúsculos.
redirecionado para
Testar se ao carregar no botão “Registar é
ecrã criar registo
feito o reencaminhamento para o ecrã “Criar
de dados pessoais.
Registo de dados pessoais”.
Testar se todas as informações colocadas nos Falhou.

campos do formulário são corretamente
inseridas na base de dados. Este ecrã não foi
criado pelos
Verifica se a obrigatoriedade de preencher os programadores,
campos está corretamente definida. optaram por juntar
tudo num, o que
Devem respeitar-se as seguintes imposições: também é válido.
Criar Registo de Contudo existem
dados pessoais - Os campos de input “Nome Completo” e alguns campos
(Front-End) - “Nome Curto” apenas podem aceitar obrigatórios em
Registar caracteres alfabéticos Maiúsculos ou falta:
minúsculos.
- Data Nascimento
- A idade está deve estar compreendida
entre os 16 e os 100 anos. - Género
- Estado Civil
Testar se ao carregar no botão “Registar” é
feito o reencaminhamento para o ecrã “Pagina - Distrito
Inicial Candidato”.
- Morada
- Nome Curto
Após o Log in é
possível ver que os
ecrãs para a
criação do estado
civil, distrito e
género foram
criados, mas não
ficam associados a
uma pessoa.
Passou.
É possível adicionar
o documento e
associar a um
candidato, contudo
o tipo do campo é
Testar se o URL para o documento foi texto, o que não
corretamente inserido na Base de dados e á permite associar
lista de Documentos na pestana associado ao um URL ou um
Criar Registo de ecrã “Criar Registo de dados pessoais”. ficheiro (Ex jpeg,
dados pessoais txt, etc).
(Front-End) - Apesar disso a
Adicionar funcionalidade cria
e associa
corretamente à
pessoa.
Teste sem efeito.
Equipa de
Criar Registo de programadores
dados pessoais optou por não
Testar se o pop-up é fechado com sucesso.
(Front-End) - implementar o
Cancelar pop-up. Fizeram
um ecrã, tal como
explicado em cima.
Passou.
Deve-se testar se ao carregar no botão Ao carregar na
Página Inicial
“Logout” a sessão é corretamente terminada e opção de Logout,
Candidato (Front-
o utilizador é redirecionado para o ecrã de utilizador é
End) - Logout
Login redirecionado para
o ecrã de Login.

Passou.
A equipa de
programadores
optou por não
implementar um
Pop up para esta
funcionalidade, em
vez disso
implementaram
um ecrã que
também
consideramos
válido e ao
terminar a
Testar se ao carregar no botão “Terminar” candidatura é
aparece um Pop up onde é pedido para possível escrever
selecionar o motivo de terminar a candidatura. um motivo de
fecho e associar a
Consultar candidatura ao
Candidatura Testar se ao escolher o motivo e carregar motivo através de
(Back-End) - fechar o estado da candidatura é alterado para um dropdown.
Terminar “Terminado Sem Sucesso” na base de dados. Também está
correcto.
Testar se este botão só é visível para
utilizadores com a função de técnico de Ao carregar na
recursos humanos. opção “Terminar
sem Sucesso” o
estado da
candidatura é
alterado para
“Terminada Sem
sucesso” na base
de dados
correctamente.
Botão também só é
visível para o role
Técnico de
Recursos
Humanos.
Consultar Testar se ao carregar no botão “Assignar a Passou.

Candidatura mim” o colaborador associado à vaga é
(Back-End) - alterado, para o utilizador que carregou no Botão de
Assignar a mim botão, na base de dados “Assignar” é visível
e ao carregar no
mesmo a
candidatura é
associado
automaticamente
ao colaborador que

carregou no botão,
Testar se o botão só é visível para utilizador
aparecendo
com a função de técnico de recursos
automaticamente
humanos.
opções para gerir a
candidatura.
Botão também só
é visível para o role
Técnico de
Recursos
Humanos.
Teste sem Efeito.
Equipa de
programadores
optou por não
implementar um
dropdown para o
estado da tabela
candidatura, em
vez disso criaram
botões (que só são
Consultar
visíveis para
Candidatura
determinados roles
(Back-End) - Testar se o dropdown contém os estados
e de acordo com o
Dropdown Estado presentes na base de dados na tabela Estado
estado em que a
candidatura Candidatura.
candidatura se
encontra no
momento,
respeitando o
diagrama de
estados da
candidatura).
Estados aparecem
na lista de
candidaturas
correctamente.
Consultar Testar se ao carregar no botão “Download” é Teste sem Efeito.

Para o download
do registo criminal,
iria ser necessário
uma opção para o
candidato
submeter o
ficheiro, neste caso
feito um download do Registo Criminal do
a equipa de
Candidatura Candidato em formato PDF.
programadores
(Back-End) - Testar se o botão só é visível para utilizador
optou por fazer
Download com a função de técnico de recursos
apenas uma
humanos.
verificação do
registo e indicar se
tem cadastro ou
não.
Posto isto esta
opção fica sem
efeito.
9. Apreciação crítica dos Resultados dos Testes
Quem escreve: grupo que executou os testes, e que em pricípio é o
mesmo que efectuou a especificação.
Breve Justificação (face às eventuais omissões que o grupo

fez na sua própria especificação e face à implementação
realizada pelo outro grupo):

G17 G13 Fase3 Relatório 2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

G17 G13 Fase3 Relatório 2

Enviado por

Direitos autorais:

Formatos disponíveis

Licenciatura em Engenharia Informática e Licenciatura

em Informática e Gestão de Empresas

Conceção e Desenvolvimento de Sistemas de Informação

Relatório de Projeto Super Despensa - Recrutamento

Catarina Ferreira da Silva

Francisco Santana Guimarães

João Filipe Marques Costa

2.1 Identificação dos grupos.............................................................................................14

2.1.1 Identificação do grupo analista, autor da especificação (Fase 1): 17..............14

2.1.2 Identificação do grupo autor da implementação (Fase 2): ___________.......15

2.2 Planeamento dos entregáveis.....................................................................................17

3. Identificações de eventuais dificuldades........................................................................18

3.1 Maiores dificuldades encontradas na fase 1..............................................................18

3.2 Maiores dificuldades encontradas na fase 2..............................................................19

3.3 Maiores dificuldades encontradas na fase 3..............................................................19

3.4 Sugestões de melhoria para a unidade curricular......................................................20

4. Conceção da solução – FASE 1........................................................................................20

4.1 Diagrama de classes....................................................................................................20

4.2 Modelo de dados e validações....................................................................................24

4.3 Gestão de definição, análise, aprovação e publicação de vaga..................................66

4.3.1 Diagrama(s) de modelização do(s) processo(s)...............................................66

4.3.2 Diagrama de transição de estados...................................................................69

4.3.3 Diagrama de casos de uso................................................................................70

4.3.4.1 Resumo executivo do grupo de funcionalidades.......................................72

4.3.4.2 Especificação do grupo de funcionalidades do Candidato........................73

4.3.4.2.1 Especificação das funcionalidades do Candidato para o Front-End.......73

4.3.4.2.2 Funcionalidades para o Front-End do grupo de funcionalidades de

4.3.4.2.3 Especificação da Funcionalidade “Login” de Candidato.........................75

4.3.4.2.4 Especificação da Funcionalidade “Criar Registo Dados Pessoais” de

4.3.4.2.5 Mockup dos ecrãs de Front-End.............................................................76

4.3.4.3 Especificação do grupo de funcionalidades da Vaga.................................78

4.3.4.3.1 Especificação das funcionalidades de Vaga para o Front-End..............78

Especificação da Funcionalidade “A” de <G_func.1> (substituir pelo nome

Especificação da Funcionalidade “A” de <G_func.1> (substituir pelo nome

Especificação da Funcionalidade “B” de <G_func.1> (substituir pelo nome da

Especificação da Funcionalidade “C” de <G_func.1> (substituir pelo nome da

4.3.4.3.2 Mockup dos ecrãs de Front-End.............................................................82

4.3.4.3.3 Especificação das funcionalidades de <G_func.1> para o Back-End.83

Especificação da Funcionalidade “Publicar Vaga” da Vaga...............................86

Especificação da Funcionalidade “Fecho automático da Vaga” da Vaga..........87

4.3.4.3.4 Mockup dos ecrãs de Back-End..............................................................87

4.3.5 Especificação de testes....................................................................................89

CDSI Projecto -V1.2-2023.03.09 - Relatório – Pág.

4.3.5.2 Especificação dos Testes do Grupo de Funcionalidades <G_func.1>

4.4 Gestão de seleção e avaliação de candidaturas.........................................................91

4.4.1 Diagrama(s) de modelização do(s) processo(s)...............................................91

4.4.2 Diagrama de transição de estados...................................................................93

4.4.3 Diagrama de casos de uso................................................................................94

4.4.4 Especificação de requisitos..............................................................................97

4.4.4.1 Resumo executivo do grupo de funcionalidades.......................................97

4.4.4.2 Especificação do grupo de funcionalidades de Avaliação Candidatura.....98

4.4.4.2.1 Especificação das funcionalidades de Avaliação Candidatura para o

4.4.4.2.2 Funcionalidades para o Front-End do grupo de funcionalidades de

4.4.4.3 Especificação do grupo de funcionalidades de Candidatura.....................99

4.4.4.3.1 Especificação da Funcionalidade “Consultar Candidatura” de

4.4.4.3.2 Especificação das funcionalidades de Avaliação Candidatura para o

4.4.4.3.3 Especificação da Funcionalidade “Avaliação de Candidatura” de

4.4.4.3.4 Especificação da Funcionalidade “Adicionar Avaliação” de

4.4.4.3.5 Mockup dos ecrãs de Back-End............................................................107

4.4.4.3.6 Especificação das funcionalidades de Contacto para o Back-End........109

4.4.4.3.7 Especificação da Funcionalidade “Contactos” de Contacto.......110

4.4.4.3.8 Mockup dos ecrãs de Back-End............................................................111

4.4.4.3.10 Especificação da Funcionalidade “Consultar Candidatura” de