Case description
Description of the municipality's requirements and wishes for the service.
TL;DR: Below is a description of the fictitious case we will use in this course - a service that Sogndal
municipality can use to gather information about people moving into the municipality.
You can read through the descriptions below to get an overview of the requirements. For each module we will repeat
the relevant requirements to make it clear what the goal of the module is.
Sogndal is in need of more young residents and wishes to become a desirable
municipality for young adults and others who wish to settle down.
That is why they wish to create a service in Altinn aimed at people
who are moving to Sogndal over the next six months.
By collecting data about newcomers at an early point, the municipality may facilitate
and customize the services to the newcomers before the first moving box has even been packed.
Sogndal has a few requirements for the services described in the sections below.
Requirements from the municipality
The application must have a sensible name that makes it easy to find it again among the large number
of repositories, Sogndal keeps in Altinn Studio.
There are currently no plans for yearly revisions of the app,
so the year does not need to be taken into account.
There is a wish that one or more of the words “newcomer” and “Sogndal” is included in the name.
- Name and age of the person who is a newcomer
- First name
- Middle name (optional)
- Last name
- Age
- Address of the person who is a newcomer
- Street address
- Postal code
- Postal city
- Contact information of the person who is a newcomer
- All input fields should have descriptive labels that clarify what should be filled in.
- The application must be available in bokmål, nynorsk and english.
For the first edition it is sufficient that only one of these languages is available.
- It is important that the title of the application sounds good and is descriptive of the service.
Someone in the municipality has created a sketch of the information page.
The following is desirable to be similar in the application:
- Placing of pictures
- Text size
- Formatting of text
Sketch of information page
Dynamic tracks
A user who does not meet the requirements for the form should be stopped as early as possible in the process.
On the information page the user should be able to select whether or not the form applies to them.
How this is done is optional, the field Innflytter.KanBrukeSkjema in the datamodel can be used for this purpose.
Based on the answer, the user will be sent to either Track 1 or Track 2.
Track 1
- The user has stated that the form does not apply to them
- The user should then be sent to a page with the following text:
Dette skjemaet er ikke for deg.
Se en oversikt over andre tilbud i kommunen her.
- Line 2 in the text should be a link directing to https://www.sogndal.kommune.no/
Track 2
- The user has confirmed that the form does apply to them.
- The user is sent to the data collecting pages.
Different data for public and private sector
We want the user to be presented with a different set of options for the industry choice
based on which sector they are in.
Tailored offer for IT competence
If the user chooses IKT (data/it) under industry, a text with a link to our overview of vacant positions should appear.
- Below the industry choice, the following text should appear:
Vi ser at du besitter kompetanse vi trenger i kommunen.
Se en oversikt over våre ledige stillinger her.
- Line 2 in the text should be a link that directs to https://sogndal.easycruit.com/index.html.
The text and link should only be visible if the user has chosen IKT (data/it). In all other cases,
this will be hidden.
Confirmation before submission
The user should be presented with the data that will be used and consents (indirectly) to this
by submitting the form.
Possible operations
At this point in the workflow the user should be able to
- View an overview of the data entered
- Exit the workflow without submitting the form
- Exit the workflow and submit the form
Authorization
- The same role requirements should apply to both fill out and confirm an instance.
Validation
- It should only be possible for the user who owns the instance to submit the form, even if others may hold the necessary roles.
Texts
The user should be presented with the following text before submitting the form.
Du er nå klar for å sende inn melding om tilflytting til Sogndal kommune.
Ved å sende inn dette skjemaet samtykker du til at dataen du har fylt ut kan lagres og benyttes
til å tilpasse kommunens tilbud til deg de neste 18 månedene.
Før du sender inn vil vi anbefale å se over svarene dine. Du kan ikke endre svarene etter at du har sendt inn.
Obtaining previous residential addresses
To be able to tailor the best possible offers to newcomers we wish to obtain an overview of former residences of the newcomer.
On the data page there should be an option to enter previous residences.
Previous residences should contain following fields:
- Street address
- Postal code
- Postal city
It should be possible to enter up to 10 former residences.
Validation of previous residential addresses
Due to a personal vendetta among one of the employees in the municipality of Sogndal, a user who enters
postal code 4619 as a previous residence should NOT be allowed to move to Sogndal.
In this case, an error message should appear at the field in question with the following text:
Du er ikke velkommen til vår kommune. Beklager!
Data processing of invalid street address
There is an address in Sogndal which is often misspelled by newcomers which leads to case workers having to spend a lot of time manually correcting it.
Therefore, we want the app to automatically fix this mistake when the misspelled address is detected.
If the user enters Sesame Street 1 in the field Innflytter.Adresse.Gateadresse, it should automatically be corrected to Sesamsgate 1.
For all other addresses the field should remain the same.
