1. Introduction

1.1. Overall Description

Het HR portaal die voor JDI Smart Web Applications gerealiseerd wordt, dient het huidige verlof-, bezetting- en reiskostendeclaratie systeem efficiënter te maken. Het hoofddoel van de beoogde software is om over te stappen van losse documenten, naar een centraal systeem dat al deze werknemersinformatie zal bijhouden. Het voordeel van een centraal systeem is dat de huidige processen automatisch worden, waardoor de developers niet zelf de product owner en hr hoeven te e-mailen. Het gaat hierbij om informatie voor ongeveer 20 werknemers, en 10 documenten. Team Perlman gaat het nieuwe portaal volledig bouwen, aangezien er nog geen systeem bestaat (alleen losse spreadsheats met de hr informatie erop). De grootste prioriteit van het HR portaal ligt bij het registreren van de bezetting en declaraties, en er zouden in de toekomst nieuwe flows toegevoegd moeten kunnen worden. Lagere prioriteit ligt bij de implementatie van Slack omdat dit ook door een ander ontwikkelteam wordt onderzocht.

1.2. User Classes and Characteristics

Hier volgen de actors/user classes die een rol hebben binnen het hr portaal.

1.2.1.1. Werknemer

De werknemer is de hoofdgebruiker van het nieuwe portaal. Werknemers gebruiken het portaal om verlof aan te vragen, om hun werkplek aan te geven en om hun reiskostenvergoeding te declareren. Voor het verlof kan een aanvraag worden ingediend die terechtkomt bij de werkgever.

1.2.1.2. Werkgever

De werkgever heeft alle rechten en mogelijkheden die van toepassing zijn op de werknemer, en daarbij kan de werkgever ook het portaal beheren. De werkgever kan de werkplekken en reiskosten inzien, en heeft een overzicht van alle werknemers. Ook kan de werkgever verlofaanvragen van werknemers goed- of afkeuren. De werkgever heeft ook toegang tot alle CRUD operaties in het portaal.

1.3. Operating Environment

Vue.js, mysql en spring boot ondersteunen allemaal de meest gebruikte operating systems zoals Windows en Linux. Het doel is hierdoor om het portaal op alle moderne operating systems en versies (vanaf 2012) te ondersteunen, zodat werknemers en werkgevers het portaal vanuit hun eigen devices kunnen bereiken. Het portaal heeft verder ook geen externe afhankelijkheden en is niet afhankelijk van de bestaande JDI website. De enige limitatie is dat het portaal alleen op desktop wordt ondersteund, dit betekent dat het niet goed bestuurbaar zal zijn op mobiele apparaten. Tijdens de duur van het project is alles locaal gedraait op de systemen van de developers, dit bestaat uit een mix van windows 10, 11 en mac os. De backend heeft gedraait via inteliJ, aangezien het een springboot applicatie is, is het erg makkelijk om deze te te runnen.

1.4. Design and Implementation Constraints

Het portaal zal gebruikmaken van vue.js en java springboot, dus alle Perlman developers moeten deze tools beheersen. Voor de achterliggende database wordt gebruikgemaakt van MySQL. Het portaal zal niet speciaal voor mobiele apparaten beschikbaar worden dus de developers mogen geen functionaliteit implementeren die afhankelijk is van een mobiele OS.

1.5. Product Functions

Het HR-portaal dient de huidige handmatige documentatie van JDI te vervangen. De hoofd functionaliteit van de applicatie is: het reserveren van een beschikbare werkplek; een declaratie kunnen maken op basis van de afstand tussen de gebruikers huis adres en het kantoor, welke berekend wordt met een API; en verlof aanvragen doen en deze goed laten keuren door een product owner en lead link.

2. Domain Model

Voor het HR-portaal is er een domein model opgesteld om het domein waarin we werken in kaart te brengen, deze ziet er uit als volgt:

2.1. Glossary

In deze glossary volgt een beschrijving van alle concepten in bovenstaand model.

2.1.1. Werkplek

Een werkplek is een plek binnen JDI waar werknemers hun werk kunnen doen. Een werkplek heeft een code ter identificatie. Ook heeft de werkplek een grootte, dit geeft aan hoeveel werknemers er in de plek passen.

De werkplek heeft een locatie, waarmee aangegeven wordt waar de werkplek zich bevindt.

2.1.2. Locatie

Zoals de naam al zegt, is een locatie een locatie. Een locatie heeft een naam en een locatie bevindt zich in een stad.

2.1.3. Route

Een route is een route tussen twee locaties. Van een route wordt een afstand bijgehouden, deze afstand wordt berekend door een API.

2.1.4. Werknemer

Een werknemer heeft een set van inloggegevens (bestaande uit een gebruikersnaam en een wachtwoord) waarmee hij/zij bij het HR portaal kan inloggen. Een werknemer heeft ook nog NAW (naam, adres, woonplaats) gegevens. Verder heeft een werknemer ook een aantal uren verlof tot zich. Ook heeft de werknemer 3 waardes om bij te houden of ze wel of niet een beheerder, lead link of product owner zijn.

2.1.5. Werktijden

Werktijden houdt bij op welke tijden een werknemer werkt en op welke dag dit is. 

2.1.6. Werknemer op werkplek

Werknemer op werkplek houdt bij op welke werkplek een werknemer zich bevind op een datum.

2.1.7. Tokens

Tokens houden de tokens bij van een geslaagde inlog poging van een gebruiker. Hiervan wordt ook een expires bijgehouden.

2.1.8. Reiskosten declaratie

Reiskosten declaratie hoort bij een werknemer die een declaratie heeft aangemaakt. Hiervan word bijgehouden voor welke datum deze declaratie geld, voor welke afstand dit was, het bedrag dat vergode wordt, een eventuele opmerking en een optionele bijlage die geupload kan worden. De afstand van een declaratie wordt berekend door een API en het bedrag wordt berekend aan de hand van de afstand en het type declaratie dat is aangemaakt.

2.1.9. Tarief

Tarief houdt bij welk bedrag hoort bij welk type.

2.1.10. Afstand bereken systeem

Voor de reiskosten declaratie is een systeem beschikbaar om de afstand van een reis te berekenen. De reiskosten declaratie maakt gebruik van dit systeem om de afstand berekening door de externe API uit te laten voeren.

2.1.11. Afstand API

Het bovenstaande afstand bereken systeem is gekoppeld aan een externe API die de afstanden terug kan geven. Deze API heeft route informatie om op die manier de afstand te kunnen bepalen.

2.1.12. Verlof aanvraag

Een verlof aanvraag is een manier voor werknemers om verlof aan te vragen. Iedere aanvraag is door 1 werknemer ingediend. Bij een aanvraag hoort een aanvraag code, waarmee de aanvraag geïdentificeerd kan worden. De aanvraag zelf wordt opgenomen als 'aanvraag'. Na het indienen van de aanvraag gaat deze naar Slack, voor de beoordeling.

3. Use-case Model

Na overleg met de opdrachtgever zijn er een aantal use cases opgesteld en fully dressed uitgewerkt in het volgende hoofdstuk. Hierin is bij iedere use case de happy flow en alternative flows opgenomen. De CRUD use cases zijn niet opgenomen in de fully dressed uitwerkingen van de use cases aangezien dit alleen maar gaat over het beheren van bepaalde aspecten in de applicatie. 

4. Use-case Descriptions 

4.1. Use case 1: Handmatig declareren reiskosten

4.1.1. Fully-dressed use case description

4.1.2. System Sequence Diagram

4.2. Use case 2: Invullen flexwerkplek schema

4.2.1. Fully-dressed use case description

4.2.2. System Sequence Diagram

4.3. Use case 3: Aanvragen verlof

4.3.1. Fully-dressed use case description

4.4. Use case 4: Beoordelen verlof

4.4.1. Fully-dressed use case description

5. Other functional requirements

6. User stories

7. Non-functional Requirements

Uitgaand van de FURPS+ methode, zijn er een aantal categorieën waaronder de non-functionele requirements opgedeeld kunnen worden. Het gaat om;

• Usability
• Reliability
• Performance
• Supportability
• Security

De F van functionality is hierbij expres weggelaten, omdat dit functionele requirements zijn, dus deze horen niet in dit onderdeel. Hieronder volgen overzichten met per categorie de requirements die daarbij horen.

7.1. Usability

7.2. Reliability

7.3. Performance

7.4. Supportability

7.5. Security

8. User interface sketches

Bij het uitmeten en overeenkomen van bepaalde functionaliteit wilden we dat er zo realistisch mogelijke interface schetsen gemaakt werden. Hierbij hielden we rekening met het feit dat de schetsen zo snel mogelijk gemaakt moesten worden.

De schetsen zijn ontworpen in Figma, een ontwerptool die snel prototypen mogelijk maakt. Ook heeft het een functie om minimale routing toe te laten, zodat je bepaalde pagina's kan doorlopen op de schetsen.

Er zijn uiteindelijk schetsen gemaakt voor alle grote user stories, en hier zijn meerdere ideeën voor uitgewerkt zodat er gekozen kan worden uit de beste ontwerpen.

Hieronder hebben we een paar van onze schetsen meegenomen. De rest is te vinden op onze figma pagina: https://www.figma.com/file/bZ1V3uCUNXimto2wN58CuT/JDI-Oose