Brontekst bekijken van Requirements Engineering/het werk/werkstuk/2013-14/Groep 10

{{RE/Titelpagina
|titel=Thalia App
|auteurs=Luuk Arts, Lars Behrens, Ivo Jehee, Redouan Koubaa, Mees Neijenhuis
}} 

= Introduction =

Dit requirements document is gemaakt voor de studievereniging Thalia. <br>
<br>
Het bestuur van studievereniging Thalia heeft ons de opdracht gegeven een applicatie te ontwikkelen voor smartphones. Deze applicatie moet ervoor zorgen dat de informatie die Thalia verschaft, onder andere via de website en facebook, makkelijker te bekijken is vanaf een smartphone.<br>
Het doel van dit document is om u duidelijk te maken hoe het product er uit ziet en hoe het een en ander in elkaar steekt. Dit zal enige misverstanden met betrekking tot het eindproduct voorkomen.

'''Leeswijzer'''

In deze beknopte leeswijzer wordt vermeld wat er in dit rapport aan bod zal komen. Om te beginnen zal er in de eerste paragraaf, ''Problem Statement'', worden beschreven wat het doel is van dit project en wordt er een indicatie gegeven van de huidige situatie. Vervolgens zal in de tweede paragraaf worden beschreven wie de belanghebbenden zijn van het systeem. Deze 'stakeholders' en hun rol worden weergegeven in de ''Stakeholders analysis''. Het fundament van dit project zal worden beschreven in de ''Mission and Vision Statement''. Hierin staat een omschrijving van het doel van dit project en het resultaat dat het nieuwe systeem zal opleveren. Tevens worden de voortgang en de bereikte mijlpalen opgenomen in de ''Statement of work''. Hier is het onderdeel ''Risk analysis'', waarin de risico's voor het project worden vermeld, nauw aan verbonden. De kern van de zaak staat beschreven in het onderdeel ''Use Cases''. De requirements van het systeem komen hier aan bod. Deze paragraaf kent een aantal subonderdelen. Zo is er in de ''Use Case Survey'' inzichtelijk gemaakt welke Use Cases van toepassing zijn bij het nieuwe systeem. Dit zal visueel worden gemaakt in het onderdeel ''Use Case Diagram''. De Use Cases zullen uiteraard ook individueel, maar nog niet in detail, worden uitgewerkt in het onderdeel ''Individual Use Cases''. In het onderdeel "Scenarios" worden de Use Cases in detail uitgewerkt in de vorm van voorbeeld situaties die zich voor kunnen doen. Tenslotte wordt bij het laatste onderdeel, ''Non-functional Requirements'', beschreven welke requirements niet direct met het systeem te maken hebben, maar wel van belang zijn voor een juiste werking van het systeem. 

== Problem statement ==

Het bestuur van Thalia wil een smartphone applicatie hebben die alle informatie van hun website, hun Facebook pagina en de e-mails die ze aan hun leden versturen op één plek toegankelijk maakt. <br>
De problemen met de huidige middelen zijn:<br>
* De website wordt niet vaak bezocht en werkt niet goed op mobiele telefoons.<br>
* Communicatie via e-mail is niet zo persoonlijk als het bestuur wenst.<br>
* Facebook is onoverzichtelijk omdat ieder evenement een eigen pagina heeft. <br> 
* Er zijn klachten over de snelheid en de lay-out van de Facebook app en over bugs die er in voorkomen.<br>
* Omdat informatie via drie verschillende platformen (de Thalia website, de Thalia Facebook pagina en e-mail) wordt verspreid, is het voor de leden erg onoverzichtelijk.<br>

= Case analysis =
== Stakeholder analysis ==

{| class="wikitable" border="0" width="50%"
! Stakeholder !! Rol !! Omschrijving
|-
|W. van der Linde, <br> M. Ghering, <br> J. van de Molengraft
|
Bestuurslid
|
* De bestuursleden beheren de app en kunnen dus alle functionaliteiten van het systeem gebruiken. 
|-
|Studentlid
|
Gebruiker
|
* Profiel aanmaken
* Introductie profiel aanmaken
* Activiteit bijwonen
* Nieuwsberichten bekijken
* Agenda bekijken
* Pushberichten ontvangen
|-
|}

== Mission and vision statement ==
'''3.4.1. Missie'''

Het vergroten en vergemakkelijken van interactie tussen leden en het bestuur van de studievereniging Thalia.

'''3.4.2. Visie'''

Met behulp van de Thalia app wordt getracht de interactie te vergroten tussen de leden en studentenverenging Thalia. De Thalia app dient voor de gebruiker overzichtelijk en snel te zijn.

== Statement of work ==
=== Deadlines ===

* Filled iteratie: 14 maart 2014
* Focused iteratie: 4 april 2014

== Statement of work ==

{| class="wikitable" border="0" width="100%"
! Deliverable !! DeliverbleType !! Façade !! Filled !! Focused !! Comment
|-
| Introduction
| ROWSPAN=2 | Contextual
| Preliminary version
| Preliminary version
| Complete
| Keep it short at first, only a sketch; nice, clear and complete at the end.
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Problem statement
| ROWSPAN=2 | '''Key deliverable'''
| As good as possible
| As good as possible
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Stakeholder list/analysis
| ROWSPAN=2 | Contextual
| As good as possible
| As good as possible
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Mission-Vision-(Values)
| ROWSPAN=2 | Contextual
| Complete
| Complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Statement of Work
| ROWSPAN=2 | Contextual
| Complete, and up-to-date
| Complete, and up-to-date
| Complete, and up-to-date
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Risk Analysis
| ROWSPAN=2 | Contextual
| Complete, and up-to-date
| Complete, and up-to-date
| Complete, and up-to-date
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Use Case Survey
| ROWSPAN=2 | '''Key deliverable'''
| As good as possible
| Nearly complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Integrated UC Diagram
| ROWSPAN=2 | '''Key deliverable'''
| Complete (though preliminary)
| Complete
| Complete
| One for whole project
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Use Cases
| ROWSPAN=2 | '''Key deliverable'''
| ROWSPAN=2 | Not yet!
| "Filled" level
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Scenarios
| ROWSPAN=2 | '''Key deliverable'''
| ROWSPAN=2 | Not yet!
| Several for each UC
| Complete ("focused" level)
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Domain Models
| ROWSPAN=2 | '''Key deliverable'''
| ROWSPAN=2 | Not yet!
| Partially complete
| Complete
| One for each UC
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Business rules per UC
| ROWSPAN=2 | '''Key Deliverable'''
| ROWSPAN=2 | Not yet!
| Partially complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Integrated Domain Model
| ROWSPAN=2 | '''Key deliverable'''
| ROWSPAN=2 | Not yet!
| First draft
| Complete
| One for whole project
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Busines Rules Catalogue
| ROWSPAN=2 | '''Key deliverable'''
| ROWSPAN=2 | Not yet!
| Partially complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| -
|-
| Non-functional Requirements
| ROWSPAN=2 | '''Key deliverable'''
| Notes
| Partially complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Terminological Definitions
| ROWSPAN=2 | '''Key deliverable'''
| Notes
| Partially complete
| Complete
|
|-
| '''Status:'''
| '''100%'''
| '''100%'''
| '''100%'''
| -
|-
| Executive sponsor viewpoint
| ROWSPAN=2 | Implicit deliverable
| Complete
| Complete
| Complete
| Integrated in M-V-(V)!
|-
| '''Status:'''
| '''0%'''
| '''0%'''
| '''0%'''
| -
|-
| Use case tests
| ROWSPAN=2 | Implicit deliverable
| Notes
| As good as possible
| Complete
| Integrated in scenarios; to be done, but not written down explicitly as a separate item
|-
| '''Status:'''
| '''0%'''
| '''0%'''
| '''0%'''
| -
|-
| Busienss process definitions
| ROWSPAN=2 | Optional appendix
| If available / relevant
| If relevant
| If relevant
| Use existing definitions/models or make them yourself: optional!
|-
| '''Status:'''
| '''0%'''
| '''0%'''
| '''0%'''
| -
|-
| GUI metaphors / storyboards
| ROWSPAN=2 | Optional appendix
| If relevant
| If relevant
| If relevant
|
|-
| '''Status:'''
| '''0%'''
| '''0%'''
| '''0%'''
| -
|}

== Risk analysis ==

{|class="wikitable"
! # !! Categorie !! Risico !! Oplossing vereist voor: !! Status !! Dagen kwijt !! Verwachtingsfactor !! Risicofactor
|-
| 1 || Personeel || Uitval groepslid || Direct || Taakverdeling is aangepast || 20% van de tijd || 5% || 6
|-
| 2 || Personeel || Iemand houdt zich niet aan de planning || Direct || n.v.t. || 1 || 35% || 3
|-
| 3 || Communicatie || Miscommunicatie tussen groepsleden || Direct || n.v.t. || 10 || 10% || 6
|-
| 4 || Data || Dataverlies || Direct || n.v.t. || Zoveel als er aan de verloren data gewerkt was || 20% || 10
|-
| 5 || Personeel || Groepslid wordt ziek || Direct || n.v.t. || Zoveel dagen als de persoon ziek is || 20% || 3
|-
| 6 || Communicatie || Miscommunicatie tussen groep en stakeholder || De deadline || n.v.t. || 1 || 10% || 2
|-
| 7 || Werkplaats || Problemen met elektronishe werkplaats || Direct || n.v.t. || 30 min || 50% || 2
|}

= Requirements =
== Use cases ==

=== Use case survey ===
{|class="wikitable"
! # !! Name !! Description !! Initiating actor !! Wie maakt:
|-
|01 || Bekijk en beheer nieuwsberichten || De gebruiker kan nieuwsberichten op de app bekijken, bestuursleden kunnen nieuwsberichten beheren. || Gebruiker, Bestuurslid || Mees
|-
|02 || Bekijk en beheer agenda || De gebruiker kan de agenda bekijken, bestuursleden kunnen de agenda beheren. || Gebruiker, Bestuurslid || Redouan
|-
|03 || Ontvang en bekijk pushbericht || De gebruiker kan de pushberichten ontvangen en bekijken || Gebruiker, Bestuurslid || Luuk
|-
|04 || Bijwonen activiteit || De gebruiker kan aangeven of hij een activiteit wilt bijwonen || Gebruiker || Ivo
|-
|05 || Aanmaken van (introductie) profiel || De gebruiker kan een persoonlijk profiel aanmaken || Gebruiker || Lars
|-

|}

=== Integrated use case diagram ===



[[Bestand:RE_Integrated_Diagram.jpg]]

=== Individual use cases ===

==== Use Case 01 ====
{|class="wikitable"
! Use Case: !! Bekijk en beheer nieuwsberichten.
|-
| Use case number: 
| 1
|-
| Description:
| De gebruiker kan nieuwsberichten in de app bekijken en het bestuurslid kan ook nog nieuwsberichten plaatsen.
|-
| Version: 
| 1.0
|-
| Initiating Actor:
| Gebruiker of bestuurslid
|-
| Trigger:
| Gebruiker wil een nieuwsbericht bekijken.
|-
| Basic course of events:
| 1. Gebruiker geeft aan een nieuwsbericht te willen bekijken.

2. Systeem toont alle nieuwsberichten.

3. Gebruiker kiest een nieuwsbericht.

4. Systeem toont nieuwsbericht.

|-
| Alternate paths:
| 3a. Gebruiker annuleert.

4a. Systeem breekt af.


5b. Gebruiker geeft aan een ander nieuwsbericht te willen bekijken.

Systeem gaat verder met 2.


1c. Bestuurslid geeft aan een nieuwsbericht toe te willen voegen.

2c. Systeem vraagt om een nieuwsbericht in te voeren.

3c. Bestuurslid voert een nieuwsbericht in.

4c. Systeem plaatst het nieuwsbericht en zendt pushbericht naar gebruikers.

|-
| Exception paths:
| Geen exception paths aanwezig.
|-
| Preconditions:
| 
* Gebruiker is ingelogd in de app.
|-
| Postconditions: 
| 
* Nieuwsbericht is getoond of geplaatst.
|-
| Related business rules:
|
*Gebruiker kan maar één nieuwsbericht tegelijk lezen.
*Gebruiker kan geen nieuwsberichten verwijderen.
|}

[[Bestand:RE_ORM_1.jpg]]

==== Use Case 02 ====
{|class="wikitable"
! Use Case: !! Bekijk en beheer agenda.
|-
| Use case number: 
| 2
|-
| Description:
| De gebruiker kan de agenda bekijken, bestuursleden kunnen de agenda beheren.
|-
| Version: 
| 1.0
|-
| Initiating Actor:
| Bestuurslid of gebruiker.
|-
| Trigger:
| Bestuurslid wil een entry toevoegen of gebruiker wil agenda bekijken.
|-
| Basic course of events beheer agenda:
| 1. Bestuurslid geeft aan een entry toe te willen voegen.

2. Systeem vraagt om een entry in te voeren.

3. Bestuurslid voert een entry in.

4. Systeem vraagt om bevestiging.

5. Bestuurslid gaat akkoord.

6. Systeem plaatst het item in de agenda.
|-
| Basic course of events bekijk agenda:
| 1a. Gebruiker geeft aan de agenda te willen bekijken.

2a. Systeem toont agenda.

3a. Gebruiker kiest een entry om te bekijken.

4a. Systeem toont entry.
|-
| Alternate paths beheer agenda:
| 3a. Bestuurslid geeft aan af te willen breken.

4a. Systeem breekt af.


5b. Bestuurslid gaat niet akkoord.

6b. Systeem vraagt of bestuurslid opnieuw wil proberen.

7b. Bestuurslid geeft aan opnieuw te willen proberen.

Systeem gaat verder met 2.


7c. Bestuurslid geeft aan niet opnieuw te willen proberen.

8c. Systeem breekt af.
|-
| Alternate paths bekijk agenda:
| 3b. Gebruiker annuleert.

4b. Systeem breekt af.


5c. Gebruiker geeft aan een andere entry te willen bekijken.

Systeem gaat verder met 2.
|-
| Exception paths beheer agenda:
| 3d. Bestuurslid voert entry in.

4d. Het systeem geeft een foutmelding dat er al een andere entry is ingevoerd en geeft de mogelijkheid om de entry aan te passen.
 
5d. Bestuurslid voert opnieuw entry in. 

6d. Systeem vraagt om bevestiging. 

7d. Bestuurslid gaat akkoord.

8d. Systeem plaatst het item in de agenda.

|-
| Exception paths bekijk agenda:
| Geen exception paths aanwezig.
|-
| Preconditions:
| 
* Gebruiker is ingelogd in de app.
* Bestuurslid heeft status 'Bestuurslid'.
|-
| Postconditions: 
| 
* Entry is geplaatst en/of wordt getoond in de agenda.
|-
| Related business rules:
|
*Beheren van de agenda is alleen mogelijk door de beheerder.
*Beheerder mag niet meerdere entries op hetzelfde tijdstip invoeren.
*Gebruiker kan maar één agenda item tegelijk lezen.
|}

[[Bestand:ORM_2.jpg]]

==== Use Case 03 ====
{|class="wikitable"
! Use Case: !! Ontvang en bekijk pushbericht.
|-
| Use case number: 
| 3
|-
| Description:
| De gebruiker kan de pushberichten ontvangen en bekijken.
|-
| Version: 
| 1.0
|-
| Initiating Actor:
| Bestuurslid of Gebruiker. 
|-
| Trigger:
| Bestuurslid plaatst een nieuwsbericht
of Gebruiker geeft aan een pushbericht ter herinnering aan een activiteit die hij bijwoont te willen ontvangen.
|-
| Basic course of events:
| 1. Bestuurslid plaatst een nieuwsbericht. 

2. Systeem verstuurt pushbericht. 

3. Gebruiker ontvangt pushbericht. 

4. Systeem toont pushbericht.

5. Gebruiker geeft aan het nieuwsbericht te willen bekijken.

6. Systeem toont nieuwsbericht.
|-
| Alternate paths:
| 1a. Gebruiker geeft aan een pushbericht ter herinnering aan een activiteit die hij bijwoont te willen ontvangen.

5a. Gebruiker geeft aan de activiteit te willen bekijken.

6a. Systeem opent de agenda en toont de entry horend bij de activiteit.


5b. Gebruiker geeft aan het pushbericht te willen negeren.
|-
| Exception paths:
| 
6c. Het systeem geeft aan dat het nieuwsbericht niet beschikbaar is.

6d. Het systeem geeft aan dat de agenda niet beschikbaar is.
|-
| Preconditions:
| 
* Gebruiker is ingelogd in de app.
|-
| Postconditions: 
| 
* Het nieuwsbericht of de activiteit is getoond. 
|-
| Related business rules:
|      
|}

[[Bestand:ORM_3.jpg]]

==== Use Case 04 ====
{|class="wikitable"
! Use Case: !! Bijwonen activiteit.
|-
| Use case number: 
| 4
|-
| Description:
| De gebruiker kan aangeven of hij een activiteit wil bijwonen.
|-
| Version: 
| 1.0
|-
| Initiating Actor:
| Gebruiker.
|-
| Trigger:
| Gebruiker wil een activiteit bijwonen.
|-
| Basic course of events:
| 1. Gebruiker geeft aan de agenda te willen bekijken.

2. Systeem toont agenda.

3. Gebruiker kiest een entry om te bekijken.

4. Systeem toont entry.

5. Gebruiker geeft aan de activiteit horend bij de entry bij te willen wonen.

6. Systeem vraagt of gebruiker een pushbericht wil ontvangen ter herinnering.

7. Gebruiker geeft aan een pushbericht te willen ontvangen.

8. Systeem bevestigd.

|-
| Alternate paths:
| 5a. Gebruiker geeft aan een andere entry te willen bekijken.

Systeem gaat verder met 2.


5b. Gebruiker geeft aan misschien aanwezig te zijn

Systeem gaat verder met 6.


5c. Gebruiker geeft aan niet aanwezig te zijn.

Systeem gaat verder met 8.


7d. Gebruiker geeft aan geen pushbericht te willen ontvangen.

Systeem gaat verder met 8.
|-
| Exception paths:
| Geen exception paths aanwezig.
|-
| Preconditions:
| 
* De server van Thalia is beschikbaar.
* Gebruiker is ingelogd in de app.
* De agenda is beschikbaar.
|-
| Postconditions: 
| 
* Gebruiker heeft aangegeven aanwezig te zijn bij een activiteit.
* Het systeem verstuurt een uur voor de activiteit een pushbericht.
|-
| Related business rules:
|
|}

[[Bestand:ORM_4.jpg]]

==== Use Case 05 ====
{|class="wikitable"
! Use Case: !! Aanmaken profiel.
|-
| Use case number: 
| 5
|-
| Description:
| De gebruiker kan een persoonlijk profiel aanmaken
|-
| Version: 
| 1.0
|-
| Initiating Actor:
| Gebruiker.
|-
| Trigger:
| Gebruiker wil een persoonlijk profiel aanmaken.
|-
| Basic course of events:
| 1. Gebruiker geeft aan een profiel aan te willen maken

2. Systeem vraagt om gegevens

3. Gebruiker voert gegevens in.

4. Systeem vraagt om bevestiging.

5. Gebruiker gaat akkoord.
|-
| Alternate paths:
| 1a. Gebruiker geeft aan een introductie profiel aan te willen maken.

Systeem gaat verder met 2.

3a. Gebruiker geeft aan af te willen breken.

4a. Systeem breekt af.


5b. Gebruiker gaat niet akkoord.

6b. Systeem breekt af.

7c. Gebruiker gaat niet akkoord.
|-
| Exception paths:
| 
4. Gebruiker voert ongeldige gegevens in.

Systeem gaat terug naar 2.
|-
| Preconditions:
| 
* De registratie database is bereikbaar.
|-
| Postconditions: 
| 
* Gebruiker heeft een account aangemaakt.
|-
| Related business rules:
| 
* Bij het aanmaken van een profiel moet de gebruiker het account bevestigen waarvan een e-mailbevestiging wordt verstuurd.
|}

[[Bestand:ORM_5.jpg]]

== Scenarios ==

==== Use Case 01 ====

{|class="wikitable"
! Scenario: !! Bekijk en beheer nieuwsberichten.
|-
| Basic course of events:
| 1. Henk drukt op de knop nieuwsberichten bekijken.

2. Hij krijgt een mooi overzicht te zien met alle nieuwsberichten.

3. Hij drukt op het nieuwsbericht “Borrel”.

4. Hij ziet nu het volledige nieuwsbericht over de borrel.
|-
| Alternate paths:
| 

1a. Henk drukt per ongeluk op de knop nieuwsberichten bekijken.

2a. Henk krijgt een overzicht te zien met alle nieuwsberichten.

3a. Henk drukt op annuleren.

4a. De app brengt Henk terug naar de vorige pagina.


5b. Henk drukt op de knop ander nieuwsbericht bekijken en krijgt weer het overzicht van nieuwsberichten te zien.


1c. Jaap is een bestuurslid en drukt op de knop nieuwsbericht toevoegen.

2c. Jaap ziet een scherm waar hij zijn nieuwsbericht in kan voeren.

3c. Jaap voert een bericht over de eerstvolgende borrel in en drukt op bevestigen.

4c. Het nieuwsbericht staat nu in de lijst met alle nieuwsberichten en alle gebruikers krijgen een pushbericht.

|-
| Exception paths:
|

Geen exception path aanwezig.
|}

==== Use Case 02 ====

{|class="wikitable"
! Scenario: !! Bekijk en beheer agenda
|-
| Basic course of events beheer agenda:
| 1. Ernst-Jan drukt op de knop ''activiteit toevoegen'' om de ''Nieuwjaarsreceptie'' in de agenda te zetten.

2. De app toont aan Ernst-Jan een scherm waarin Ernst-Jan de activiteit of borrel in de agenda kan zetten en vraagt om: ''locatie, datum, tijd, omschrijving''.

3. Ernst-Jan zet in de agenda de activiteit ''Nieuwjaarsreceptie'', ''Huygensgebouw'', ''1 januari 2015'', ''09.00 uur''.

4. De app toont een scherm waarin Ernst-Jan op ''akkoord'' kan klikken of op ''niet akkoord''.

5. Ernst-Jan drukt op de knop ''akkoord'' om de activiteit ''Nieuwjaarsreceptie'' te bevestigen in de agenda.

6. De app zal het item ''Nieuwjaarsreceptie'' in de agenda zetten.
|-
| Basic course of events bekijk agenda:
|1a. Obi-Wan drukt op de knop ''open agenda'' om de agenda te zien.

2a. De app toont aan Obi-Wan een scherm waarin de agenda staat.

3a. Obi-Wan kiest ''5 april 2014'' om te zien wat er gepland staat.

4a. De app toont een scherm met een overzicht van ''5 april 2014'' en wat er gepland staat.
|-
| Alternate paths beheer agenda:
| 

3a. Ernst-Jan heeft het scherm voor zich waar hij een activiteit of borrel in kan vullen maar besluit om af te breken en drukt op afsluiten.

4a. De app sluit de agenda af.


5b. Ernst-Jan heeft zich bedacht en zet de activiteit ''Nieuwjaarsreceptie'' liever niet in de agenda en drukt op de knop ''niet akkoord''.

6b. De app vraagt aan Ernst-Jan of hij nogmaals een activiteit of borrel in wil vullen.

7b. Ernst-Jan wil nogmaals een activiteit of borrel invoeren en drukt hiervoor op de knop ''opnieuw invoeren''.

De app gaat wederom naar stap 2 en laat een scherm zien waarin Ernst-Jan de activiteit of borrel in de agenda kan zetten.


7c. Ernst-Jan wil niet nogmaals een activiteit of borrel invoeren en drukt hiervoor op de knop ''niet opnieuw proberen''.

8c. De app sluit de agenda af.

|-
| Alternate paths bekijk agenda:
| 3b. Obi-Wan wil toch geen dagen in de agenda meer bekijken en drukt op de knop annuleren.

4b. De app sluit de agenda af.

5c. Obi-Wan wil kijken wat er op andere dagen te doen is en drukt op de knop ''bekijk andere dag''

De app laat Obi-Wan terugkeren naar het agendaoverzicht, stap 2.

|-

| Exception paths beheer agenda:
|

3d. Ernst-Jan zet in de agenda de activiteit ''Nieuwjaarsduik'', ''De Waal'', ''1 januari 2015'', ''09.00 uur''.

4d. De app geeft een foutmelding dat er al een andere activiteit staat ingepland op 1 januari 2015 om 09.00 uur en vraagt Ernst-Jan een ander tijdstip te kiezen.

5d. Ernst-Jan kiest een ander tijdstip. 

6d. De app toont een scherm waarin Ernst-Jan op ''akoord'' kan klikken of op ''niet akkoord''.

7d. Ernst-Jan drukt op de knop ''akkoord'' om de activiteit ''Nieuwjaarsduik'' te bevestigen in de agenda.

8d. De app zal het item ''Nieuwjaarsduik'' in de agenda zetten.
|-

| Exception paths bekijk agenda:
|Geen exception path aanwezig.

|}

==== Use Case 03 ====
{|class="wikitable"

! Scenario: !! Ontvang en bekijk pushbericht.

|-

| Basic course of events:
| 1. Bestuurslid Jan plaatst een nieuwsbericht over de Paasborrel.

2. De app verstuurt een pushbericht.

3. Studentlid Karel ontvangt het pushbericht.

4. De app toont een pushbericht met als titel Paasborrel en een korte omschrijving en geeft de gebruiker de keuze om het nieuwsbericht te negeren of te bekijken.

5. Karel geeft aan het nieuwsbericht over de Paasborrel te willen bekijken.

6. De app toont het nieuwsbericht aan Karel.

|-

| Alternate paths:

| 1a. Studentlid Karel geeft aan een pushbericht als herinnering aan de Paasborrel te willen ontvangen.
2. De app verstuurt een pushbericht.

3. Karel ontvangt het pushbericht.

4. De app toont een pushbericht met als titel Paasborrel en een korte omschrijving en geeft de gebruiker de keuze om de herinnering aan de Paasborrel te negeren of de Paasborrel te bekijken.

5a. Karel geeft aan de Paasborrel te willen bekijken.

6a. De app opent de agenda en toont de entry horend bij de activiteit.

|-

| Exception paths:

|1. Bestuurslid Jan plaatst een nieuwsbericht over de Paasborrel.

2. De app verstuurt een pushbericht.

3. Studentlid Karel ontvangt het pushbericht.

4. De app toont een pushbericht met als titel Paasborrel en een korte omschrijving en geeft de gebruiker de keuze om het nieuwsbericht te negeren of te bekijken.

5. Karel geeft aan het nieuwsbericht te willen bekijken.

6c. De app toont de tekst “Het gekozen nieuwsbericht is niet beschikbaar”.  

|}

==== Use Case 04 ====

{|class="wikitable"
! Scenario: !! Bijwonen activiteit.
|-
| Basic course of events:
| 1. Student Hans geeft aan een activiteit bij te willen wonen.

2. De app toont de agenda met alle activiteiten.

3. Student Hans kiest de borrel van 28 maart 2013.

4. De app toont informatie over de borrel van 28 maart 2013.

5. Student Hans geeft aan bij de borrel aanwezig te willen zijn.

6. De app vraagt of Hans een pushbericht wil ontvangen.

7. Student Hans geeft aan een pushbericht te willen ontvangen.

8. De app geeft bevestiging van Hans zijn aanwezigheid en dat Hans een pushbericht wil ontvangen.

|-
| Alternate paths:
| 
5a. Student Hans geeft aan een andere entry te willen bekijken.

2. De app toont de agenda met alle activiteiten.


5b. Student Hans geeft aan misschien aanwezig te zijn bij de borrel van 28 maart 2013.

8. De app geeft bevestiging dat Hans misschien aanwezig is bij de borrel van 28 maart 2013.


5c. Student Hans geeft aan niet aanwezig te willen zijn bij de borrel van 28 maart 2013.

8. De app geeft bevestiging dat Hans niet aanwezig wil zijn bij de borrel van 28 maart 2013.


7d. Student Hans geeft aan geen pushbericht te willen ontvangen.

8. De app bevestigt de keuze van Hans.

|-
| Exception paths:
|

Geen exception path aanwezig.
|}

==== Use Case 05 ====

{|class="wikitable"
! Scenario: !! Aanmaken profiel.
|-
| Basic course of events:
| 1. Student Michiel geeft aan een profiel te willen aanmaken

2. App vraagt om de gegevens:<br>
''Voer uw gebruikersnaam in''<br>
''Voer uw wachtwoord in''<br>
''Voer nogmaals uw wachtwoord in ter controle''<br>
''Voer uw e-mailadres in''<br>
''Kies voor een normaal of introductie profiel''<br>

3. Gebruiker voert de volgende gegevens in: <br>
''MichielBleys''<br>
''Michiel010''<br>
''MichielBleys@gmail.com''<br>
''Normaal profiel''<br>

4. App vraagt om bevestiging.<br>
''Weet u zeker dat u dit profiel met deze gegevens wilt aanmaken?''<br>
''Ja of Nee''<br>

5. Gebruiker gaat akkoord.<br>
''Michiel kiest voor Ja''<br>

|-
| Alternate paths:
| 

3a. Gebruiker geeft aan af te willen breken.<br>
''Michiel klikt op annuleren bij het aanmaken van een profiel''<br>
3b. Gebruiker kiest voor introductie profiel i.p.v. een normaal profiel<br>
''MichielBleys''<br>
''Michiel010''<br>
''MichielBleys@gmail.com''<br>
''Introductie profiel''<br>

4a. App breekt af.

5b. Gebruiker gaat niet akkoord.<br>
''Michiel kiest voor Nee''<br>
6b. App breekt af.<br>


|-
| Exception paths:
| 

3. Gebruiker voert de volgende gegevens in:<br>
''Mi''<br>
''Mi''<br>
''MichielBleys''<br>
''Normaal profiel''<br>

4. App geeft aan dat er ongeldige gegevens zijn ingevoerd<br>
''De gebruikersnaam "Mi" is te kort''<br>
''Het wachtwoord "Mi" is te kort en mag niet hetzelfde zijn als de gebruikersnaam''<br>
''"MichielBleys" is geen correct e-mailadres''<br>
|-
|}

== Non-functional Requirements ==

;Veiligheid: 
Om toegang te krijgen tot het systeem moet ingelogd worden met een gebruikersaccount. Bestuursleden hebben toegang tot alle functionaliteiten van het systeem. Studentleden hebben beperkte toegang, ze mogen namelijk de agenda niet aanpassen en geen nieuwsberichten plaatsen. Gebruikersgegevens mogen alleen door de gebruiker zelf bekeken worden.

;Snelheid:
Het systeem mag niet te traag werken om de efficiëntie in stand te houden. Bewerkingen, bijvoorbeeld aangeven van aanwezigheid bij de agenda, mogen niet te lang duren.

;Verenigbaarheid:
Het systeem moet op dusdanige manier gemaakt worden dat het kan communiceren met de systemen die nu al gebruikt worden.

;Bruikbaarheid:
Het systeem moet gebruiksvriendelijk zijn en moet er voor zorgen dat er efficiënt gebruik van kan worden gemaakt. Zodra dit niet het geval is, zullen mensen er geen gebruik van maken en gewoon op de oude manier te werk gaan.

;Actualiteit: 
De agenda en het overzicht van nieuwsberichten moeten voor iedere gebruiker van het systeem de nieuwste versie zijn of ge-update worden wanneer de gebruiker inlogt.

;Beschikbaarheid: 
Het systeem moet 24 uur per dag en 7 dagen per week beschikbaar zijn. Het mag eventueel wel offline worden gehaald om werkzaamheden te verrichten.

= Addendum =
== Integrated Domainmodel ==

[[Bestand:RE_Integrated_ORM.jpg]]

== Business Rules Catalogue ==

'''Algemene business rules'''

*Gebruikers dienen een account te hebben aangemaakt om gebruik te maken van de app.
*Gebruikers dienen  de gebruiksvoorwaarden te hebben geaccepteerd alvorens akkoord te gaan met de installatie van de app.
*Gebruikers dienen de privacy statement te hebben gelezen alvorens akkoord te gaan met de installatie van de app.
*Gebruikers dienen verplicht een update van de app uit te voeren zodra deze beschikbaar is.
*Een wachtwoord mag niet meer dan drie keer foutief zijn ingetypt.
*Het wachtwoord moet ieder jaar gewijzigd worden.


'''Use case gespecificeerde business rules'''

''Bekijk en beheer nieuwsberichten''

*Gebruiker kan maar één nieuwsbericht tegelijk lezen.
*Gebruiker kan geen nieuwsberichten verwijderen.


''Bekijk en beheer agenda''

*Beheren van de agenda is alleen mogelijk door de beheerder.
*Beheerder mag niet meerdere entries op hetzelfde tijdstip invoeren.
*Gebruiker kan maar één agenda item tegelijk lezen.



''Aanmaken van (introductie) profiel''

*Bij het aanmaken van een profiel moet de gebruiker het account bevestigen waarvan een e-mailbevestiging wordt verstuurd.

== Terminological Definitions ==

;Studievereniging Thalia: De studievereniging voor Informatica en Informatiekunde studenten van de Radboud Universiteit te Nijmegen.

;Studentlid: Een student Informatica of Informatiekunde die lid is van studievereniging Thalia.

;Introductielid: Een deelnemer aan de introductieperiode van studievereniging Thalia.

;Gebruiker: Een studentlid of introductielid die gebruik kan maken van de app.

;Bestuurslid: Een lid van de studievereniging Thalia met een functie binnen het bestuur. Huidige bestuursleden: W. van der Linde, M. Ghering, J. van de Molengraft.

;Nieuwsbericht: Een bericht met nieuws over studievereniging Thalia dat je in de app kan bekijken. Het nieuwsbericht heeft een titel, inhoud en datum waarop het geplaatst is.

;Agenda: Een agenda die je in de app kan bekijken. In de agenda staan alle komende activiteiten van de studievereniging.

;Entry: Een punt in de agenda (activiteit). Een entry bevat een datum, tijdstip en locatie waarop het plaats gaat vinden en een omschrijving van de activiteit.

;Pushbericht: Een bericht gestuurd door de app die als pop-up wordt weergegeven op het scherm van het mobiele apparaat, waardoor de gebruiker op de hoogte gesteld kan worden van nieuwe nieuwsberichten of een activiteit zonder dat de gebruiker de app opent. Het pushbericht bestaat uit een titel en een omschrijving. De gebruiker heeft de keuze om het nieuwsbericht horend bij het pushbericht in de app te bekijken, of om het pushbericht te negeren.

;Aanwezigheid: Dit wordt gebruikt om aan te geven of je aanwezig bent bij een activiteit. Er is keuze tussen aanwezig, niet aanwezig en misschien aanwezig.

;Profiel: Elke gebruiker heeft een eigen profiel. Dit profiel bestaat uit een gebruikersnaam, wachtwoord, email adres en een type (normaal profiel of introductieprofiel)
	
;Systeem breekt af: Het systeem brengt de gebruiker terug naar de hoofdpagina van de app.