Requirements Engineering/het werk/werkstuk/2013-14/Groep 04
De Nederlandse Post Service (NPS)
Werkstuk Requirements Engineering
Abdulkader Abdullah, Justin Mol, Thijs Broenink, Tom Sandmann, Timothy Kuhn, Stijn Meijer
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
Introduction
De Nederlandse Post Service (NPS) is een in Nederland gevestigd bedrijf dat zich bezighoudt met de bezorging van briefpost en het aannemen en bezorgen van pakketjes. Het bedrijf heeft een distributiecentrum, een warenhuis (voor de opslag van door een derde partij te koop aangeboden producten) en 200 servicepunten door Nederland.
De NPS wil haar efficiency en klantervaring verbeteren middels een te ontwikkelen ICT-systeem. Dit document vormt de specificatie van dat systeem. Allereerst zullen we de situatie en casus analyseren. We benoemen het doel van het systeem; de problemen die het op moet lossen. We tonen de voortgang in het ontwerpproces en bepalen risico's en belanghebbenden. Daarna zullen we iedere verschillende interactie tussen een gebruiker en het systeem uitgebreid analyseren in de vorm van zogenoemde Use Cases. Daarna volgen enkele scenario's die gebruikt kunnen worden om het systeem te testen en enkele non-functional requirements. Tot slot voegen we een geïntegreerd domeinmodel, business rule catalogus en definitielijst van terminologie bij.
Problem statement
De administratie van de post- en pakketjesdienst is momenteel gescheiden. Daardoor kunnen pakketjes en briefpost niet tegelijk vervoerd worden. De NPS wil om efficiencyredenen de logistieke stromen van pakketjes en post samenvoegen. Concreet betekent dit dat pakketjes en post met dezelfde vrachtwagen verplaatst kunnen worden tussen de faciliteiten van de NPS. Hiertoe is een nieuwe, gemeenschappelijke administratie nodig.
Daarnaast wil de NPS de ervaring voor haar klanten verbeteren. Klanten moeten de actuele status van hun pakketje kunnen bekijken door middel van een online tracking service: een (globale) indicatie van waar het pakketje zich bevindt, tot bezorging of tot het bereiken van de landsgrens. Dit geldt voor zowel te verzenden als te bezorgen pakketjes.
Tot slot wil de NPS de inhoud van haar warenhuis inzichtelijk maken in een webwinkel. Hiertoe dient bekend te zijn wat, en in welke kwantiteit, opgeslagen ligt in haar warenhuis en van welke derde partij dit eigendom is. Deze derde partij levert de overige data (zoals de prijs en productspecificatie) voor de webwinkel.
Case analysis
Stakeholder analysis
Wij interviewen met name personen uit het management. Deze personen zijn verantwoordelijk voor verschillende onderdelen en processen binnen het bedrijf, en omvatten gezamenlijk de belangrijkste bedrijfsprocessen. Daarnaast spreken we met eindgebruikers van de software (de medewerkers in het distributiecentrum en de servicepunten). Eindgebruikers zijn vooral belangrijk voor het waarborgen van gebruiksvriendelijkheid. Tot slot zullen we uitvoerige acceptatietesten afnemen.
De belangrijkste belanghebbenden hebben we hieronder per rol weergegeven.
| Rol | Belanghebbende(n) | Omschrijving |
|---|---|---|
| Provinciemanager | Rick Erkers (Gelderland), Sanne Boumans (Noord-Brabant) en Koen Basten (Utrecht) | Provinciemanagers houden toezicht op de servicepunten binnen hun provincie. Zij zijn verantwoordelijk voor de medewerkers binnen deze servicepunten. |
| Werknemer | Alle medewerkers die in een distributiecentrum of servicepunt werken | Deze medewerkers zijn eindgebruikers van het te ontwikkelen systeem. Zij hebben baat bij een gebruiksvriendelijk systeem. |
| Warenhuismanager | Jeftha Spunda | Verantwoordelijk voor het naar behoren functioneren van het warenhuis, waaronder ook het assortiment- en voorraadbeheer. Het is voor de heer Spunda erg belangrijk dat de administratie van het warenhuis goed wordt verzorgd in het nieuwe systeem. |
| Klant | Een ieder die een pakketje verstuurt of laat bezorgen | Voor deze groep is het erg belangrijk dat de Track and Trace functionaliteit naar behoren werkt, en in het bijzonder de juiste locatie aangeeft. |
Mission and vision statement
- Mission — Het te ontwikkelen systeem zal de NPS een efficiënter en klantgerichter bedrijf maken.
- Vision — Het eindproduct is een systeem waarbij briefpost en pakketpost in één systeem zijn geïntegreerd. Daarnaast kunnen klanten de status c.q. locatie van hun pakketje bekijken.
- Value — Bij het opstellen van deze specificatie zullen wij rekening houden met het gebruiksgemak voor de eindgebruikers. Zij zijn immers professionals in hun vakgebied, en moeten dan ook zoveel mogelijk tijd in dat vakgebied spenderen — niet in dat van de IT-ers.
Statement of work
Hieronder tonen we hoe ver we met het ontwerpproces zijn, aangegeven per onderdeel. Om ook binnen onze eigen organisatie efficiencywinst te behalen, hebben we voor een semi-grafische weergave van onze voortgang gekozen die gebaseerd is op het werk van enkele collega's van vorig jaar. Eerst volgt er een legenda voor de gebruikte statussen:
| Code | Betekenis | Uitleg |
|---|---|---|
| V | Voltooid | Onderdeel is nagekeken door minstens 1 teamlid en is klaar om ingeleverd te worden. |
| C | Controleren | Onderdeel is gemaakt door de (eind)verantwoordelijke en dient te worden gecontroleerd/verbeterd door een groepslid. |
| B | Bezig | Onderdeel is in de maak op de wiki. |
| NG | Niet gestart | De ontwikkeling van dit onderdeel is nog niet gestart. |
| NV | Niet vereist | Onderdeel is (in deze iteratie) niet vereist. |
Hierna volgt de voorgang per onderdeel.
| Onderdeel | Eindverantwoordelijke | Facade iteratie | Status | Filled iteratie | Status | Focused iteratie | Status | Gecontroleerd door |
|---|---|---|---|---|---|---|---|---|
| Introduction | Stijn | Preliminary version | V | Preliminary version | V | Complete | V | Thijs |
| Problem statement | Stijn | As good as possible | V | As good as possible | V | Complete | V | Thijs |
| Stakeholder analysis | Stijn | As good as possible | V | As good as possible | V | Complete | V | Thijs |
| Mission-vision statement | Stijn | Complete | V | Complete | V | Complete | V | Thijs |
| Statement of work | Stijn | Complete, and up-to-date | V | Complete, and up-to-date | V | Complete, and up-to-date | V | Thijs |
| Risk analysis | Timothy | Complete, and up-to-date | V | Complete, and up-to-date | V | Complete, and up-to-date | V | Stijn |
| Use case survey | Justin | As good as possible | V | Nearly complete | V | Complete, and up-to-date | V | Stijn |
| Integrated UC diagram | Justin | Complete (though preliminary) | V | Complete | V | Complete | V | Stijn |
| Use cases | Groep | Not yet! | NV | "Filled" level | V | Complete | V | Groep (van elkaar) |
| Scenarios | Justin | Not yet! | NV | Several for each UC | V | Complete ("focused" level) | V | Timothy |
| Domain models | Tom en Stijn | Not yet! | NV | Partially complete | V | Complete | V | Tom en Stijn (diagrammen van elkaar gecontroleerd) |
| Integrated domain model | Tom en Stijn | Not yet! | NV | Partially complete | V | Complete | V | Timothy |
| Business rules catalogue | Timothy | Not yet! | NV | Partially complete | V | Complete | V | Stijn |
| Non-functional requirements | Abdulkader | Notes | V | Partially complete | V | Complete | V | Timothy |
| Terminological definitions | Thijs | Notes | V | Partially complete | V | Complete | V | Timothy |
Risk analysis
| # | Category | Risk | Solution needed by | Status | Days lost | Expectancy factor | Risk factor |
|---|---|---|---|---|---|---|---|
| 01 | Team | Miscommunicatie of slechte/geen interne communicatie kan leiden tot werk wat niet of niet goed gedaan wordt, waardoor het achteraf of opnieuw gedaan moet worden. | Direct | n.v.t. | 2 | 17% | 0.34 |
| 02 | Team | Door ziekte of andere privéomstandigheden kan het zijn dat iemand zijn werk niet kan uitvoeren. | 1-2 dagen later | n.v.t. | 5 | 33% | 1.67 |
| 03 | Team | Iemand stopt met het vak. | Direct | n.v.t. | 5 | 1% | 0.05 |
| 04 | Team | Ondanks goede communicatie voert iemand zijn taak niet of niet goed uit. | Direct | n.v.t. | 2 | 17% | 0.34 |
| 05 | Contact | Geen of een late reactie van de contactpersonen van de andere partij, wat de voortgang van het project kan verhinderen door onzekerheid betreft eisen/wensen van de andere partij. | 1-2 dagen later | n.v.t. | 5 | 17% | 0.85 |
| 06 | Technisch | Storing van diensten waarvan gebruik wordt gemaakt voor dit project. Dat zijn voornamelijk Google Drive, de Werkplaats en verscheidene IM-diensten. | 1-2 dagen later | n.v.t. | 2 | 10% | 0.2 |
| 07 | Informatie | Het ontbreken van informatie wat voortgang van het project belemmert. | Direct | n.v.t. | 3 | 10% | 0.3 |
Requirements
Use cases
Use case survey
| # | Name | Description | Initiating actor |
|---|---|---|---|
| 01 | Brieven invoeren | Brieven worden bij het distributiecentrum in het systeem gevoerd om gesorteerd te worden. | Medewerker distributiecentrum |
| 02 | Pakketten invoeren | Pakketten worden bij het servicepunt in het systeem gevoerd. | Medewerker servicepunt |
| 03 | Voorraad aanpassen | Voorraden van producten in het systeem van het magazijn worden aangepast. | Medewerker magazijn |
| 04 | Assortiment aanpassen | Producten worden in het systeem van het magazijn toegevoegd. | Medewerker magazijn |
| 05 | Pakketgegevens opvragen | Tracing-gegevens van een te verzenden pakket worden opgevraagd. | Klant |
| 06 | Status bewerken | De status van een te verzenden pakket wordt in het systeem aangepast. | Medewerker |
Integrated use case diagram
Individual use cases
Use Case 1
| Use Case #01 | Brieven invoeren |
|---|---|
| Use case diagram | 
|
| Description | De brieven die door de postbodes zijn opgehaald worden in het distributiecentrum door een medewerker in het systeem ingevoerd. |
| Trigger | Er komt een brief binnen bij het distributiecentrum. |
| Actor | Medewerker distributiecentrum |
| Version | 1.1 |
| Basic course of events |
1. De medewerker geeft aan een brief te willen invoeren. |
| Alternate paths | Onvolledige Adresgegevens 11. De medewerker geeft aan dat niet alle Adresgegevens van de geadresseerde zijn ingevuld. Ongeldig postzegel |
| Exception paths | Onvolledige invoering Adresgegevens 3. De medewerker voert niet alle Adresgegevens van de geadresseerde in. |
| Preconditions |
|
| Postconditions |
|
| Related business rules | 01, 02 |
Het ORM-schema van Use Case 1 hebben we hieronder bijgevoegd.
Use Case 2
| Use Case #02 | Pakketten invoeren |
|---|---|
| Use case diagram | 
|
| Description | Een pakket bij het servicepunt wordt door een medewerker in het systeem gevoerd. |
| Trigger | Er komt een pakket binnen bij een servicepunt. |
| Actor | Medewerker servicepunt |
| Version | 1.1 |
| Basic course of events |
1. De medewerker geeft aan een pakket te willen invoeren. |
| Alternate paths | Onvolledige Adresgegevens 17. De medewerker geeft aan dat niet alle Adresgegevens van de geadresseerde zijn ingevuld. Ongeldig postzegel |
| Exception paths | Onvolledige invoering Adresgegevens 3. De medewerker voert niet alle Adresgegevens van de geadresseerde in. |
| Preconditions |
|
| Postconditions |
|
| Related business rules | 03, 04 |
Het ORM-schema van Use Case 2 hebben we hieronder bijgevoegd.
Use Case 3
| Use Case #03 | Voorraad aanpassen |
|---|---|
| Use case diagram | 
|
| Description | Voorraden van producten in het systeem van het magazijn worden aangepast. |
| Version | 1.2 |
| Triggers | Een bestelling van een bekend product wordt gedaan.
Een levering van een bekend product wordt gedaan. |
| Actor | Medewerker magazijn |
| Basic course of events | Voorraad verlagen
1. De medewerker geeft aan dat de voorraad van een product verlaagd moet worden. |
| Alternate paths | Voorraad verhogen
1. De medewerker geeft aan dat de voorraad van een product verhoogd moet worden. |
| Exception paths | Onbekend product
4. Het systeem geeft aan dat het ingevoerde product onbekend is. Verkeerd aantal |
| Preconditions |
|
| Postconditions |
|
| Related business rules | 05 |
Het ORM-schema van Use Case 3 hebben we hieronder bijgevoegd.
Use Case 4
| Use Case #04 | Assortiment aanpassen |
|---|---|
| Use case diagram | 
|
| Description |
Producten worden in het systeem van het magazijn toegevoegd of verwijderd. |
| Version |
1.1 |
| Triggers |
Medewerker ontvangt informatie betreft een nieuw product. |
| Actor |
Medewerker magazijn |
| Basic course of events |
Product toevoegen |
| Alternate paths |
Product verwijderen Ga terug Mutatie annuleren |
| Exception path |
Geen match |
| Preconditions |
|
| Postconditions |
1 - Er is een nieuw product toegevoegd aan de database. Product(barcode, naam, merk, type, aantal, leverancier) 2 - Er is een product verwijderd uit de database. |
| Related business rules | 05 |
Het ORM-schema van Use Case 4 hebben we hieronder bijgevoegd. Let op: dit schema is identiek aan het schema van Use Case 3.
Use Case 5
| Use Case #05 | Pakketgegevens opvragen |
|---|---|
| Use case diagram | 
|
| Description | Klant bekijkt status van verzending online. |
| Trigger | Klant opent de optie track and trace op de site. |
| Actor | Klant |
| Version | 1.1 |
| Basic course of events |
1. De klant voert het pakketnummer in en vinkt 1 van de volgende opties aan die betrekking hebben op het pakket:
2. Het systeem toont de status van de verzending. |
| Alternate paths | Geen optie aangevinkt 3. Het systeem vraagt de gebruiker om een optie aan te vinken. |
| Exception paths | Bijbehorende gegevens niet gevonden 2. Het systeem geeft een foutmelding en vraagt om controle van de ingevoerde gegevens. |
| Preconditions |
|
| Postconditions |
|
| Related business rules |
- |
Het ORM-schema van Use Case 5 hebben we hieronder bijgevoegd.
Use Case 6
| Use Case #06 | Pakketstatus bewerken |
|---|---|
| Use case diagram | 
|
| Description | De status van een te versturen pakket wordt aangepast. |
| Trigger | Er wordt een pakket afgeleverd bij het servicepunt om verstuurd te worden. |
| Actor | Medewerker |
| Version | 1.1 |
| Basic course of events |
1. Het systeem vraagt om identificatie van het pakket. |
| Alternate paths |
Klant niet thuis Pakket buiten Europa |
| Exception paths |
- |
| Preconditions |
|
| Postconditions |
|
| Related business rules | 06, 07 |
Het ORM-schema van Use Case 6 hebben we hieronder bijgevoegd. Let op: dit schema is identiek aan het schema van Use Case 5.
Scenarios
Scenario 1: Brief invoeren
1. De medewerker geeft aan een brief te willen invoeren.
2. Het systeem vraagt om Adresgegevens van de geadresseerde.
3. De medewerker voert de volgende Adresgegevens in:
Naam: Piet Paulusma Straat: C.F. Hengelhardstraat Nummer: 25 Postcode: 8802XV Datum: 01-04-2014 Woonplaats: Franeker Land: Nederland
4. Het systeem vraagt om het gewicht van de brief.
5. De medewerker voert 33 gram in.
6. Het systeem vraagt om Adresgegevens van de afzender
7. De medewerker vult de volgende Adresgegevens in:
Naam: Tom Sandmann Straat: Professor Uilenstraat Nummer: 151 Postcode: 6524ZZ Datum: 01-04-2014 Woonplaats: Nijmegen Land: Nederland
8. Het systeem vraagt of er een geldig postzegel opstaat of om een antwoordnummer.
9. De medewerker geeft aan dat er een geldig postzegel op zit.
10. Het systeem vraagt of de Adresgegevens van de geadresseerde goed zijn ingevuld.
11. De medewerker geeft aan dat de Adresgegevens van de geadresseerde goed zijn ingevuld.
Scenario 2: Pakketten invoeren
1. De medewerker geeft aan een pakket te willen invoeren.
2. Het systeem vraagt om de Adresgegevens van de geadresseerde.
3. De medewerker voert de volgende Adresgegevens in:
Naam: Jan Pietersen Straat: De Roskam Nummer: 20 Postcode: 5912JL Datum: 03-04-2014 Woonplaats: Venlo Land: Nederland
4. Het systeem vraagt om het gewicht van het pakket.
5. De medewerker voert het 2 kg in.
6. Het systeem vraagt om de afmetingen van het pakket.
7. De medewerker voert 60 x 40 x 40 cm in.
8. Het systeem vraagt om de Adresgegevens van de afzender.
9. De medewerker voert de volgende Adresgegevens in:
Naam: Piet Jansen Straat: Frielinkstraat Nummer: 18 Postcode: 7615NV Datum: 03-04-2014 Woonplaats: Harbrinkhoek Land: Nederland
10. Het systeem vraagt of er een geldig postzegel op zit of om een antwoordnummer.
11. De medewerker geeft aan dat er een geldig postzegel op zit.
12. Het systeem vraagt of voor het pakket betaald is.
13. De medewerker vult dat er voor het pakket betaald is.
14. Het systeem vraagt of het pakket aangetekend moet worden verzonden.
15. De medewerker voert in dat het pakket aangetekend is.
16. Het systeem vraagt of de Adresgegevens van de geadresseerde goed zijn ingevuld.
17. De medewerker geeft aan dat de Adresgegevens van de geadresseerde goed zijn ingevuld.
Scenario 3.1: Voorraad ophogen
1. De medewerker geeft aan dat de voorraad van een product verlaagd moet worden.
2. Het systeem vraagt om identificatie van het desbetreffende product.
3. De medewerker identificeert een Dell XPS 12 met productcode '583291'
4. Het systeem vraagt aan de medewerker hoeveel de voorraad verlaagd moet worden.
5. De medewerker voert het getal 2 in.
6. Het systeem laat zien dat het nieuwe aantal 14 bedraagt en vraagt om bevestiging van het nieuwe aantal.
7. De medewerker kijkt of het aantal klopt en bevestigt het aantal.
Scenario 3.2: Voorraad verlagen
1. De medewerker geeft aan dat de voorraad van een product verhoogd moet worden.
2. Het systeem vraagt om identificatie van het desbetreffende product.
3. De medewerker identificeert een iPod Touch 32GB met productcode '385910'.
4. Het systeem vraagt aan de medewerker hoeveel de voorraad verhoogd moet worden.
5. De medewerker vult het getal 20 in.
6. Het systeem laat zien dat het nieuwe aantal 23 bedraagt en vraagt om bevestiging van het nieuwe aantal.
7. De medewerker kijkt of het aantal klopt en bevestigt het aantal.
Scenario 3.3: Onbekend product
1. De medewerker geeft aan dat de voorraad van een product verlaagd moet worden.
2. Het systeem vraagt om identificatie van het desbetreffende product.
3. De medewerker probeert een Samsung Galaxy S4 te identificeren.
4. Het systeem geeft aan dat het ingevoerde product onbekend is.
5. Het systeem vraagt of de medewerker het product nog eens wil scannen.
6. De medewerker klikt op 'Ja'.
7. Het systeem vraagt om identificatie van het desbetreffende product.
8. De medewerker probeert nogmaals de Samsung Galaxy S4 te identificeren.
9. Het systeem geeft aan dat het ingevoerde product onbekend is.
10. Het systeem vraagt of de medewerker het product nog eens wil scannen.
11. De medewerker klikt op 'Nee'.
12. De use case termineert.
Scenario 3.4: Verkeerd aantal
1. De medewerker geeft aan dat de voorraad van een product verlaagd moet worden.
2. Het systeem vraagt om identificatie van het desbetreffende product.
3. De medewerker identificeert een Huawei Ascend P6 met productcode '839402'
4. Het systeem vraagt aan de medewerker hoeveel de voorraad verlaagd moet worden.
5. De medewerker voert het getal 1 in.
6. Het systeem laat zien dat het nieuwe aantal 7 bedraagt en vraagt om bevestiging van het nieuwe aantal.
7. De medewerker geeft aan dat het aantal verkeerd is.
8. Het systeem vraagt nogmaals aan de medewerker hoeveel de voorraad verlaagd moet worden.
9. De medewerker voert het getal 2 in.
10. Het systeem laat zien dat het nieuwe aantal 6 bedraagt en vraagt om bevestiging van het nieuwe aantal.
11. De medewerker kijkt of het aantal klopt en bevestigt het aantal.
Scenario 4.1: Assortiment aanpassen
1. De medewerker geeft aan dat hij een nieuw product wil toevoegen.
2. Het systeem vraagt om de barcode van het product.
3. De medewerker voert de barcode van het product in.
4. Het systeem vraagt om een merk.
5. De medewerker voert de naam 'Samsung' in.
6. Het systeem vraagt om een naam.
7. De medewerker voert de naam 'Galaxy S4 Mini i9195 Wit' in.
8. Het systeem vraagt om een type.
9. De medewerker voert het type 'Mobiel' in.
10. Het systeem vraagt om een aantal.
11. De medewerker voert volgens Use Case 03 het getal 20 in.
12. Het systeem vraagt om een leverancier.
13. De medewerker voert de leverancier '4Launch' in.
14. Het systeem vraagt om identificatie van de medewerker.
15. De medewerker voert zijn inloggegevens in en bevestigt de toevoeging van het nieuwe product.
Scenario 5.1: Pakketgegevens opvragen
1. Klant voert pakketnummer '38193' in en vinkt "verstuurd naar" aan.
2. Systeem toont de status van de verzending, namelijk: "Klaar voor verzending."
3. Klant sluit het venster waardoor de sessie beëindigt.
Scenario 6.1: Pakketstatus binnen Nederland
1. Systeem vraagt om identificatie van pakket.
2. Medewerker voert pakketnummer '61578' in.
3. Systeem zet status en laat huidige status van pakket zien: ‘Klaar voor verzending’.
4. Systeem vraagt om identificatie van pakket.
5. Medewerker voert pakketnummer '61578' in.
6. Systeem zet status en laat huidige status pakket zien: ‘Onderweg’.
7. Systeem vraagt om digitale handtekening.
8. Klant voert digitale handtekening in.
9. Systeem zet status en laat status van pakket zien: ‘afgeleverd’.
Scenario 6.2: Pakketstatus buiten Nederland
1. Systeem vraagt om identificatie van pakket.
2. Medewerker voert pakketnummer '82715' in.
3. Systeem zet status en laat huidige status van pakket zien: ‘Klaar voor verzending’.
4. Systeem vraagt om identificatie van pakket.
5. Medewerker voert pakketnummer '82715' in.
6. Systeem zet status en laat huidige status pakket zien: ‘Onderweg’.
7. Systeem vraagt om identificatie van pakket.
8. Medewerker voert pakketnummer '82715' in.
9. Systeem zet status en laat pakketstatus zien: ‘Afgeleverd op vliegveld’.
Non-functional Requirements
Usability:
Het systeem moet de medewerker door de vragenlijst heen kunnen leiden.
Actuality:
Het systeem moet met behulp van track and trace te volgen zijn vanaf het versturen tot het aankomen van de brief/het pakket.
Availability:
Het systeem mag tijdens een werkmaand hoogstens één keer offline zijn voor onderhoud.
Data integrity:
Het systeem moet een back-up hebben om data verlies tegen te gaan.
Installability:
Het systeem hoeft alleen te draaien onder Microsoft Windows.
Privacy:
Het systeem mag alleen laten zien waar het pakket/brief is met behulp van track en trace.
Security:
Het systeem mag alleen werken als ingelogd is. Voor wachtwoorden van de medewerkers geldt dat de SHA-256 hash wordt opgeslagen.
Addendum
Integrated Domainmodel
Hieronder hebben we het Integrated domainmodel bijgevoegd. Dat is het complete domeinmodel van het te ontwikkelen systeem.
Business Rules Catalogue
| No. | Rule Definition | Type of Rule | Static/Dynamic | Source |
|---|---|---|---|---|
| 01 | De medewerker mag de brief niet openen voordat deze verzonden wordt, tenzij het gaat om verboden goederen. | Action restricting | Static | Law |
| 02 | De medewerker mag de gegevens op de brief niet veranderen. | Structural facts | Static | Law |
| 03 | De medewerker mag het pakket niet openen voordat deze opgehaald wordt, tenzij het gaat om verboden goederen. | Action restricting | Static | Law |
| 04 | De medewerker mag de gegevens op het pakket niet veranderen. | Structural facts | Static | Law |
| 05 | De medewerker tast het te identificeren product niet aan. | Structural facts | Static | Management policy |
| 06 | Na aflevering bij het vliegveld is de NPS niet meer verantwoordelijk voor eventuele schade die het pakket oploopt gedurende de reis naar haar eindbestemming. | Structural facts | Dynamic; customer service may change | Management policy |
| 07 | Pakketten die worden onderschept door de douane omdat deze smokkelwaar bevatten kunnen niet worden geretourneerd. Dit moet door de klant worden afgehandeld met de betrokken instanties. | Inferences | Static | Law |
Terminological Definitions
- Adresgegevens: naam, straat, nummer, postcode, datum, woonplaats en land
- Brief: een poststuk dat bestaat uit een envelop dat door de brievenbus past. Dit kan papier met tekst/afbeeldingen bevatten, maar ook (kleine) voorwerpen.
- Klant: een ieder die een pakketje verstuurt of laat bezorgen
- Medewerker: de verzameling van medewerkers bij het magazijn, distributiecentra, servicepunten en overige. In essentie zijn dit alle functies binnen het bedrijf.
- Pakket: een poststuk dat niet door de brievenbus past en dus door het postbedrijf persoonlijk moet worden afgeleverd.
- Track and Trace: functionaliteit die het voor de klant mogelijk maakt zijn/haar pakketje tot de brievenbus of landgrens te volgen. Zo weet de klant altijd de precieze locatie van het bestelde product.
- Verboden goederen: een pakket of brief bestaande uit:
- ontplofbare stoffen en voorwerpen
- samengeperste, vloeibaar gemaakte of onder druk opgeloste gassen
- brandbare vloeistoffen
- brandbare vaste stoffen
- voor zelfontbranding vatbare stoffen
- alle vormen van vuurwerk
- stoffen die bij aanraking met water brandbare gassen ontwikkelen
- stoffen die de verbranding bevorderen
- organische peroxiden
- giftige stoffen
- infectueuze stoffen
- bijtende stoffen
- andere stoffen die voor de mens of het milieu gevaarlijk kunnen zijn
- Drugs
- Beschermde dieren (alsmede producten afkomstig hiervan)
