Versie : 1.0 Datum : 19 oktober 2010 Auteur : Slim geregeld, goed verbonden (www.sggv.nl) In licentie gegeven door het ministerie van Economische Zaken, Landbouw en Innovatie op grond van de Creative Commons licentie Naamsvermelding-NietCommercieel-GelijkDelen (http://creativecommons.org/licenses/by-nc-sa/3.0/nl/).
Inhoudsopgave 1 Inleiding... 5 1.1 Achtergrond van de... 5 1.2 Doel en doelgroepen van dit document... 6 1.3 Korte schets van de... 7 1.4 Groeipad van de... 10 1.5 Indeling van dit document... 10 1.6 Opmerkingen bij deze versie... 11 2 Belanghebbenden en behoeften... 12 3 Algemene eisen... 16 3.1 Bruikbaarheid... 16 3.2 Koppelbaarheid... 16 3.3 Beveiliging en Betrouwbaarheid... 17 4 Eisen aan de website... 19 5 Eisen aan het Forum... 20 6 Eisen aan... 21 6.1 Kwaliteitseisen... 21 6.2 Functionaliteit... 21 6.3 Betrouwbaarheid... 23 6.4 Bruikbaarheid... 24 6.5 Efficiëntie... 25 6.6 Onderhoudbaarheid... 25 6.7 Overdraagbaarheid... 26 7 Domeinmodel... 27 7.1 Deelname... 28 7.2 Bron... 29 7.3 Bron bij Vraag... 30 7.4 Document... 30 7.5 Fase... 31 7.6 Initiatief... 32 7.7 Opmerking... 33 7.8 Persoon... 33 7.9 Rol... 34 7.10 Thema... 37 Pagina 1
7.11 Verwijzing... 38 7.12 Vraag... 39 8 Use-case-model... 43 8.1 Inleiding... 43 8.2 Persoon registreert zich... 43 8.3 Persoon voltooit registratie... 44 8.4 Systeem verwijdert onvoltooide registraties... 45 8.5 Gebruiker beëindigt gebruikersaccount... 45 8.6 Systeem signaleert inactieve gebruikersaccounts... 46 8.7 Systeem verwijdert beëindigde en inactieve gebruikersaccounts... 46 8.8 Gebruiker logt in... 47 8.9 Gebruiker logt uit... 48 8.10 Gebruiker beheert accountgegevens... 48 8.11 Gebruiker beheert e-mail notificatie-instellingen... 49 8.12 Systeem verstuurt notificaties... 50 8.13 Gebruiker bewaart sjabloon... 50 8.14 Gebruiker beheert sjablonen... 51 8.15 Gebruiker beheert delen sjablonen met anderen... 52 8.16 Gebruiker draagt eigenaarschap sjablonen over... 53 8.17 Gebruiker start initiatief... 53 8.18 Gebruiker betaalt voor initiatief... 54 8.19 Systeem signaleert initiatieven waarvoor binnenkort betaling nodig is... 55 8.20 Systeem maakt niet-betaalde initiatieven 'alleen-lezen'... 55 8.21 Gebruiker beëindigt initiatief... 56 8.22 Gebruiker exporteert initiatieven... 57 8.23 Systeem signaleert binnenkort te verwijderen initiatieven... 58 8.24 Systeem verwijdert niet betaalde initiatieven... 58 8.25 Gebruiker beheert initiatiefgegevens... 59 8.26 Gebruiker beheert fasen en thema's van initiatief... 59 8.27 Gebruiker beëindigt fase van initiatief... 61 8.28 Gebruiker beheert deelnemers initiatief... 63 8.29 Gebruiker bekijkt overzicht initiatieven... 65 8.30 Gebruiker bekijkt toestand initiatief... 65 8.31 Gebruiker bekijkt initiatiefgegevens... 66 8.32 Gebruiker bekijkt recente gebeurtenissen initiatief... 66 8.33 Gebruiker zoekt binnen initiatief... 67 8.34 Gebruiker bekijkt overzicht fase... 67 Pagina 2
8.35 Gebruiker bekijkt overzicht thema binnen fase... 70 8.36 Gebruiker voegt vraag toe... 71 8.37 Gebruiker bekijkt en wijzigt vraag... 72 8.38 Gebruiker bekijkt en beantwoordt vraag... 73 8.39 Gebruiker voegt document toe... 74 8.40 Gebruiker wijzigt gegevens document... 75 8.41 Gebruiker voegt verwijzing toe... 75 8.42 Gebruiker wijzigt verwijzing... 76 8.43 Gebruiker beheert dossier... 76 8.44 Gebruiker definieert baseline... 78 8.45 Gebruiker voegt opmerking toe... 79 8.46 Beheerder... 79 9 Mogelijke uitbreidingen... 81 Bijlage A Prototype... 85 Lijst van afbeeldingen Afbeelding 1. Afbeelding 2. Afbeelding 3. Afbeelding 4. Afbeelding 5. Afbeelding 6. Afbeelding 7. Afbeelding 8. Afbeelding 9. Schematische weergave van de structuur van een initiatief... 9 Domeinmodel voor de.... 28 Schematische weergave van de relaties tussen een initiatief, rollen, deelnames en personen... 36 Schematische weergave van een initiatief, fasen, thema's, hoofdvragen en subvragen.... 38 Schematische weergave van een initiatief, fasen, thema's, hoofd- en subvragen. Subvraag A1.2.2 is niet-gereed... 41 Voorbeeld van een overzicht van de toestand van een initiatief.... 61 Schematische weergave van een initiatief, fasen, thema's, hoofd- en subvragen. Subvraag A1.2.2 is niet-gereed... 62 Voorbeeld van een overzicht op het niveau van één fase... 68 Voorbeeld van een overzicht op het niveau van één thema binnen één fase.... 71 Afbeelding 10. Positionering en Omgevingsloket online.... 82 Afbeelding 11. Inloggen... 86 Afbeelding 12. Mijn initiatieven.... 87 Afbeelding 13. Mijn profiel.... 88 Afbeelding 14. Nieuw initiatief.... 89 Afbeelding 15. Details... 91 Afbeelding 16. Mijn vragen.... 93 Pagina 3
Afbeelding 17. Mijn vragen.... 94 Afbeelding 18. Mijn vragen.... 95 Afbeelding 19. Mijn vragen.... 97 Afbeelding 20. Mijn vragen; details van één vraag... 99 Afbeelding 21. Mijn vragen; details van één vraag... 100 Afbeelding 22. Status... 101 Afbeelding 23. Dossier... 102 Pagina 4
1 Inleiding 1.1 Achtergrond van de De is een webapplicatie ter ondersteuning van het concept. Dit concept is ontwikkeld binnen de casus van het programma Slim geregeld, goed verbonden (Sggv), een programma van het Ministerie van Economische Zaken. De essentie van het Bouwen-met-Winst-concept is dat partijen betrokken bij een omgevingsinitiatief 1 vroegtijdig met elkaar in overleg gaan en op gestructureerde wijze de voorbereiding van het omgevingsinitiatief oppakken. De betrokken partijen komen zowel van de kant van het bedrijfsleven (initiatiefnemer, architect, adviseur, aannemer, enz.) als van de kant van de overheid (vergunningverstrekker en toezichthouder). Doel van het Bouwen-met-Winst-concept is het vroegtijdig en gestructureerd identificeren en afdekken van risico's van een omgevingsinitiatief. Een belangrijk onderdeel in de eerste fasen van een omgevingsinitiatief is het verkrijgen van een omgevingsvergunning. Deskundigen stellen dat 90% van de vergunningsaanvragen foutief, onjuist of onvolledig is. De gemeente kan deze aanvragen daardoor niet in behandeling nemen of wijst ze af. Het gevolg: dubbel werk, vertragingen en ergernissen bij indienende initiatiefnemers en beoordelende overheden. Het verhogen van het aantal aanvragen dat de eerste keer juist en volledig is levert een aanzienlijke besparing op. Alleen al voor de realisatie van nieuwbouwwoningen zijn aanzienlijke besparingen en rentevoordelen te verwachten 2. Een goede voorbereiding van een omgevingsinitiatief vraagt om het identificeren en inschatten van de risico s en het goed voorbereiden van de vergunningaanvraag. De biedt hier ondersteuning voor. Samengevat is het doel van het Bouwen-met-Winst-concept : het gestructureerd en gezamenlijk voorbereiden van bouwinitiatieven; het verschaffen van tijdig inzicht in de risico s behorende bij het initiatief; het afdekken van deze risico s; het bereiken van overeenstemming over interpretatie van regelgeving; het vastleggen van de in de voorbereiding gemaakte afspraken; 1 Met een omgevingsinitiatief wordt bedoeld een initiatief dat de fysieke leefomgeving raakt en valt onder de Wet algemene bepalingen omgevingsrecht (WABO). 2 Business case in het kader van het Programma Ketenherinrichting 'Slim geregeld, goed verbonden', Sjaak Vendrig, Michiel Linssen, Zoetermeer, 16 juli 2008 Pagina 5
het krijgen van duidelijkheid over de vereisten bij de vergunningaanvraag; dossiervorming ten behoeve van de vergunningaanvraag. Een belangrijk effect van het toepassen van het Bouwen-met-Winst-concept is dat wederzijds vertrouwen ontstaat tussen initiatiefnemer en beoordelende overheden door heldere communicatie en duidelijke verwachtingspatronen. Het Bouwen-met-Winst-concept wordt ondersteund door de. De is een applicatie met functionaliteit voor: het hanteren van check-lists met mogelijke risico's (in de vorm van te beantwoorden vragen); het toewijzen van deze vragen aan personen die de expertise hebben om ze te kunnen beantwoorden; het bewaken van de voortgang van het beantwoorden van de vragen; het inschatten van de hoogte van de risico s; het gefaseerd en gestructureerd afpellen van de risico's; het vastleggen van alle antwoorden en gemaakte afspraken; het vormen van een dossier van alle relevante documenten. Een essentiële eigenschap van de is dat deze voor alle betrokkenen op ieder moment en op iedere locatie beschikbaar is en altijd de laatste stand van zaken met betrekking tot het omgevingsinitiatief bevat. Omdat de betrokkenen bij een omgevingsinitiatief van verschillende organisaties zijn is een webapplicatie hiervoor een uitstekende oplossing. 1.2 Doel en doelgroepen van dit document Om het concept te beproeven is door het programma Sggv een prototype van de gerealiseerd. Dit prototype is gebruikt in elf praktijktesten om te beoordelen of het concept, ondersteund door het prototype, daadwerkelijk de verwachte verbeteringen in de voorbereiding van een omgevingsinitiatief oplevert. De uitkomsten van deze praktijktesten zijn positief. De conclusie is daarom dat een productierijpe versie van de gewenst is. Dit document bevat het programma van eisen (PvE) voor zo n productierijpe. Doel van dit PvE is om potentiële aanbieders van een te helpen bij het (laten) realiseren van een. Het PvE beschrijft hoe een kan werken. Het PvE beschrijft vooral wat de moet doen en niet hoe dat moet. Het PvE is gebaseerd op het prototype dat is gebruikt voor de praktijktesten, de uitkomsten van de evaluatie van de praktijktesten en overleg met partijen betrokken bij de totstandkoming van het concept. Pagina 6
Het PvE moet het mogelijk maken om: offertes voor de realisatie van een te vragen aan softwareontwikkelaars; bij deze offertes demonstratie-applicaties te ontwikkelen waarmee de softwareontwikkelaars hun visie op de laten zien; samen met een geselecteerde softwareontwikkelaar het ontwerp van de in te vullen en de te realiseren; het functioneel, applicatie- en technisch beheer van de in te richten, indien gewenst in samenwerking met één of meer andere partijen, zoals een helpdesk en een hosting provider. De doelgroepen van het document zijn daarom: potentiële aanbieders van een die dit programma van eisen kunnen gebruiken om een te (laten) ontwikkelen; potentiële ontwikkelaars van een die op basis van dit document een offerte op kunnen stellen, een demo-applicatie kunnen maken en na gunning mee kunnen werken aan het verder invullen, realiseren en uiteindelijk beheren van een. Dit PvE beschrijft de eisen aan de als applicatie. Deze applicatie moet geschikt zijn om initiatieven in aan te maken en deze te vullen met deelnemers, fasen, thema s, vragen, antwoorden, documenten en verwijzingen. Echter, deze vulling van initiatieven is niet beschreven in dit PvE. Dit PvE beschrijft met andere woorden een lege. Welke fasen, thema s en vragen specifiek voor bouwinitiatieven relevant zijn blijft buiten beschouwing. Dat betekent dat een aanbieder van de niet alleen een applicatie moet (laten) ontwikkelen maar ook standaard fasen, thema s en vragenlijsten moet ontwikkelen en aanbieden. Hetzelfde geldt voor inhoud van de website, indeling van het forum en helpteksten bij de. Deze vulling is in dit PvE niet beschreven. Het is aan de aanbieder van de om deze vulling te definiëren. 1.3 Korte schets van de De is een webapplicatie. Het idee is dat deze webapplicatie onderdeel is van een website die bestaat uit de volgende drie onderdelen: een algemene website met informatie over de en de organisatie erachter; een forum waar gebruikers en potentiële gebruikers van de met elkaar kunnen discussiëren over de en mogelijk ook het Bouwen-met-Winstconcept; Pagina 7
een webapplicatie die het Bouwen-met-Winst-concept ondersteunt: de daadwerkelijke. De algemene website verschaft informatie over de, zoals de ontstaansgeschiedenis, het doel ervan, de organisatie erachter, kosten van gebruik en veelgestelde vragen. De website is toegankelijk voor iedereen. Op het forum-deel kunnen gebruikers en potentiële gebruikers met elkaar discussiëren over het gebruik van de en het Bouwen-met-Winst-concept. Het forum is toegankelijk voor iedereen. Om bij te kunnen dragen aan discussies op het forum is een gebruikersaccount nodig. Deelname aan het forum is mogelijk zonder gebruik te maken van de applicatie. De -applicatie is de webapplicatie waarmee de voorbereiding van een omgevingsinitiatief gestructureerd en risicogericht aangepakt kan worden. Voor het gebruik van de is een gebruikersaccount nodig. Aan het gebruiken van de voor een initiatief zijn naar verwachting kosten verbonden. Om de te kunnen proberen lijkt het wenselijk dat voor een korte periode kosteloos gebruik mogelijk is. Een initiatiefnemer van een omgevingsinitiatief kan in de een initiatief starten. De initiatiefnemer is de eigenaar van het initiatief of handelt namens de eigenaar. De initiatiefnemer kan de relevante eigenschappen van het initiatief vastleggen en bepalen welke vragenlijsten, thema's en fasering voor het initiatief gebruikt worden. Ook kan de initiatiefnemer andere deelnemers toevoegen en zo toegang geven tot het initiatief. De andere deelnemers kunnen de rol van coördinator of specialist hebben. Een coördinator heeft ook de mogelijkheid om deelnemers toe te voegen. Een specialist heeft die mogelijkheid niet. Een initiatief bestaat uit één of meer fasen en kent één of meer thema s. Iedere fase bevat een lijst met te beantwoorden hoofdvragen. Iedere hoofdvraag behoort tot precies één thema. Een hoofdvraag kan zijn opgedeeld in een aantal subvragen die op hun beurt ook weer kunnen zijn opgedeeld in subvragen. De afbeelding hieronder toont hier een schematische weergave van. Pagina 8
Afbeelding 1. Schematische weergave van de structuur van een initiatief 1. De gehanteerde vragenlijsten zijn lijsten van mogelijke risico s die bij een initiatief op kunnen treden. Een voorbeeld van een te beantwoorden vraag is: 'Past het initiatief in het geldende bestemmingsplan?'. Het is mogelijk om standaard vragenlijsten te hanteren en om hier vragen aan toe te voegen, te verwijderen of te herformuleren. De initiatiefnemer en coördinatoren wijzen vragen toe aan deelnemers aan het initiatief. De deelnemer waaraan een vraag is toegewezen dient de vraag te beantwoorden en een advies voor een risicoinschatting te geven. De deelnemer kan tevens aangeven wat de voortgang van de beantwoording van de vraag is. Als de beantwoording van een vraag nieuwe vragen oproept dan kunnen deze worden toegevoegd. Als een vraag door verschillende deelnemers moet worden beantwoord is het mogelijk om de vraag op te delen in subvragen en de subvragen aan verschillende deelnemers toe te wijzen. Op deze manier ontstaat een hiërarchie van vragen zoals weergegeven in de afbeelding hiervoor. Met de is het mogelijk om het beantwoorden van de vragen gefaseerd aan te pakken. Op sommige vragen is vroeg in het initiatief een antwoord nodig. Andere vragen worden pas relevant als het initiatief verder is gevorderd. Een initiatief is daarom op te delen in een aantal fasen. 1 In de afbeelding zijn de thema s onderdeel van de hiërarchie om duidelijk te laten zien dat iedere vragentak tot precies één thema behoort. Echter, omdat iedere fase dezelfde thema s kent vormen de thema s feitelijk geen onderdeel van de hiërarchie. Pagina 9
Aan iedere fase zijn vragen toe te voegen. De vragen worden per fase beantwoord. Als voldoende vragen zijn beantwoord en het ingeschatte risico acceptabel is kan de initiatiefnemer besluiten een fase af te sluiten en naar de volgende fase te gaan. Bij het kiezen, formuleren en beantwoorden van vragen is het mogelijk om documenten als bijlagen toe te voegen. Ook is het mogelijk om basisdocumenten zoals een bestemmingsplan, tekeningen van het voorlopig ontwerp en berekening toe te voegen aan het initiatief. Op die manier ontstaat een dossier bij het initiatief met alle relevante gegevens en documenten. Ook verwijzingen naar externe bronnen van informatie, bijvoorbeeld andere websites, kunnen worden toegevoegd. De initiatiefnemer sluit het initiatief af als het risico te groot blijkt of als alle fasen van de voorbereiding zijn doorlopen en de benodigde vergunningen zijn aangevraagd en ook zijn verkregen. 1.4 Groeipad van de De eerste versie van de biedt minimaal de functionaliteit die vergelijkbaar is met de functionaliteit van het prototype. Op een aantal punten is uitbreiding of verbetering ten opzichte van het prototype nodig. Dit PvE beschrijft deze minimale functionaliteit. Volgende versies kunnen de functionaliteit verder uitbreiden, gebaseerd op de eisen en wensen van de aanbieder en de gebruikers van de. Dit PvE beschrijft een aantal mogelijke uitbreidingen in hoofdstuk 9. Het aantal gebruikers en initiatieven zal in het begin beperkt zijn maar kan, afhankelijk van de mate van adoptie, sterk groeien. Paragraaf 6.5 geeft een overzicht van de verwachte aantallen gebruikers en initiatieven. 1.5 Indeling van dit document Dit document beschrijft de eisen aan de drie onderdelen: de website, het forum en de -applicatie. Hoofdstuk 2 beschrijft de belanghebbenden en hun behoeften voor alle drie onderdelen samen. Hoofdstuk 3 beschrijft de algemene eisen die op alle drie de onderdelen van toepassing zijn. De hoofdstukken daarna beschrijven per onderdeel de eisen specifiek voor dat onderdeel. Voor de -applicatie zijn naast de eisen ook de use cases 1 benoemd en beschreven. 1 Een use case is een begrip uit de software-ontwikkeling. Een use-case-model beschrijft welke gebruikers op welke wijzen gebruik kunnen maken van een applicatie. Pagina 10
1.6 Opmerkingen bij deze versie Deze versie van het PvE bevat geen prioritering of weging van de eisen en use cases. Deze prioritering moet door de aanbieder van de worden toegevoegd aan het programma van eisen. Bijvoorbeeld, het is aan de aanbieder om te bepalen of functionaliteit nodig is om online te kunnen betalen en hoe belangrijk die functionaliteit is ten opzichte van andere functionaliteit. Pagina 11
2 Belanghebbenden en behoeften Dit hoofdstuk beschrijft de belanghebbenden bij de en hun belangrijkste behoeften. De volgende belanghebbenden zijn te onderscheiden: Aanbieder: de aanbieder is de organisatie die de laat ontwikkelen en aanbiedt voor gebruik; Gebruiker (zowel particulieren als vanuit het bedrijfsleven en vanuit de overheid). De aanbieder heeft de volgende behoeften: Een applicatie die voorziet in de behoeften van de gebruikers en voldoet aan hun eisen, waaronder beveiliging van de informatie die deze gebruikers vastleggen in de. Een applicatie die is te beheren met minimale inspanning. Een applicatie die is te onderhouden met minimale inspanning. Dit geldt voor alle vormen van onderhoud: correctief, preventief, adaptief, perfectief en functioneel. Een applicatie waarvan het onderhoud aan verschillende partijen kan worden uitbesteed. Een applicatie waarvan de hosting aan verschillende partijen kan worden uitbesteed. Een applicatie waarvan de gebruikersondersteuning aan verschillende partijen kan worden uitbesteed. De gebruikers hebben de volgende behoeften: Een applicatie die ondersteunt bij het gestructureerd behandelen van risico's. Fasen, thema s en vragenlijsten in de maken dit mogelijk. Een applicatie die het mogelijk maakt afspraken vast te leggen. Het vastleggen van antwoorden en het toevoegen van documenten in de maakt dit mogelijk. Een applicatie die het samenwerken en delen van informatie mogelijk maakt. De is een webapplicatie. Alle deelnemers kunnen op ieder moment vanaf iedere locatie toegang krijgen tot de informatie in een initiatief. Een applicatie die communicatie tussen betrokkenen ondersteunt (maar niet vervangt). In de kunnen de resultaten van communicatie, afstemming en afspraken worden vastgelegd. Pagina 12
Een applicatie die het mogelijk maakt een dossier te vormen. Aan een initiatief in de kunnen documenten worden toegevoegd. Een applicatie die onafhankelijk van organisatie, plaats, tijd en computerbesturingssysteem is te gebruiken. De is een webapplicatie die aan open webstandaarden voldoet. Alle deelnemers kunnen op ieder moment vanaf iedere locatie toegang krijgen tot de informatie in een initiatief. Een applicatie die makkelijk is te gebruiken en laagdrempelig is. De voldoet aan de webrichtlijnen. Daarnaast is er naar gestreefd om de eenvoudig te houden en geen complexe functionaliteit toe te voegen. Ook is er naar gestreefd om de te laten werken als andere webapplicaties. Bij de verdere invulling van het ontwerp van de dienen de gebruikersschermen gebruiksvriendelijk ontworpen te worden. Een applicatie die flexibel is en een eigen manier van werken toestaat. De dwingt zo min mogelijk een bepaalde manier van werken af en een bepaalde volgorde van activiteiten. Een applicatie waarin de gegevens van de gebruiker niet zijn 'opgesloten'. De biedt mogelijkheden om initiatiefgegevens en sjablonen voor initiatieven te exporteren. De geëxporteerde initiatiefgegevens kunnen los van bekeken worden. Een applicatie die ongeoorloofde toegang tot gebruikersgegevens en initiatiefgegevens voorkomt. Bij de realisatie van de en ook tijdens de exploitatie dienen adequate beveiligingsmaatregelen getroffen te worden. Een applicatie die is te gebruiken in samenhang met het Omgevingsloket online. De eerste versie van de heeft geen geautomatiseerde koppeling met het Omgevingsloket online. Wel is het mogelijk om een algemene verwijzing (een link) naar het Omgevingsloket online op te nemen. Het is ook mogelijk om een specifieke verwijzing naar een bij een initiatief behorende aanvraag in het Omgevingsloket online op te nemen in het initiatief in de. Pagina 13
Een applicatie die is te gebruiken in samenhang met de IT-systemen van de bedrijven en overheidsorganisaties die de gebruiken. De eerste versie van de bevat geen geautomatiseerde koppelingen met bedrijfseigen IT-systemen. Wel biedt de verschillende mogelijkheden om gegevens en documenten aan een initiatief toe toevoegen en ook om deze weer uit het initiatief te exporteren. Een applicatie die is te gebruiken in samenhang met De Nieuwe Regeling en de Standaard Taakbeschrijving, www.dnrstb.nl. De Nieuwe Regeling en de Standaard Taakbeschrijving is een geheel van een standaard rechtsverhouding, algemene financiële bepalingen en standaard werkpakketten voor de te onderscheiden disciplines in een bouwproces. Een belangrijk onderdeel van de Standaard Taak Beschrijving is de opbouw van taken en onderliggende activiteiten binnen het raamwerk van de standaard fasen van het bouwproces. Alle basiswerkzaamheden die doorgaans worden uitgevoerd door de gezamenlijke ontwerpende partijen, zijn ondergebracht in de DNR-STB. Participanten kunnen per project zelf bepalen welke taken daadwerkelijk dienen te worden uitgevoerd. Daarbinnen wordt per taak bepaald welke participant verantwoordelijk is voor de uitvoering ervan. 1 DNR-STB is een goede basis voor de rolverdeling tussen de deelnemers aan een initiatief in de. De eerste versie van de bevat geen geautomatiseerde koppeling met www.dnrstb.nl. Wel is het mogelijk om een taakverdeling in de te hanteren die is geïnspireerd door De Nieuwe Regeling en de Standaard Taakbeschrijving. De volgende primaire gebruikersrollen zijn te onderscheiden: Bezoeker van de website. De bezoeker is anoniem en niet geregistreerd. De bezoeker kan ook het forum bezoeken maar niet deelnemen aan de discussies. Forumdeelnemer. De forumdeelnemer heeft een gebruikersaccount. Gebruiker. De gebruiker van de heeft een gebruikersaccount. De gebruiker kan in verschillende initiatieven verschillende rollen hebben. De mogelijk rollen zijn: initiatiefnemer, coördinator en specialist. 1 Naar www.dnrstb.nl. Pagina 14
Naast de primaire gebruikersrollen zijn er ook beheerrollen te onderkennen. Dit PvE maakt geen onderscheid tussen de verschillende beheerrollen maar beschrijft de eisen vanuit beheer in het algemeen. Pagina 15
3 Algemene eisen De volgende eisen zijn op alle drie de onderdelen van toepassing. 3.1 Bruikbaarheid Een gebruiker kan met hetzelfde gebruikersaccount zowel deelnemen aan het forum als aan de. Een gebruikersaccount kan bestaan zonder dat het gebruikersaccount betrokken is bij een initiatief. De website, het forum en de zijn in het Nederlands. De website, het forum en de hebben vergelijkbare opmaak waardoor het voor de gebruiker duidelijk is dat ze bij elkaar horen. Bezoekers en gebruikers hebben op iedere plek op de website, het forum en de het gevoel te weten waar ze zijn, wat ze zien en waar ze naartoe kunnen. De website, het forum en de voldoen zo goed als mogelijk aan de actuele versie van de Webrichtlijnen. Zie ook: www.webrichtlijnen.nl, www.drempelvrij.nl. Er is een beperkt aantal content-management-systemen die volledig voldoen aan de Webrichtlijnen. Volledig voldoen aan de webrichtlijnen is daarom lastig te realiseren. Belangrijk elementen zijn browseronafhankelijkheid en goede toegankelijkheid, ook voor minder validen. Bij afwijkingen van de Webrichtlijnen dienen de website, het forum en de toch goed toegankelijk te zijn voor slechtzienden en minder validen die over standaard hulpmiddelen beschikken. 3.2 Koppelbaarheid De website maakt gebruik van actuele open standaarden, in het bijzonder die steun krijgen vanuit het W3C. Afwijking mag alleen met expliciete toestemming van de eigenaar. De overheid bevordert het gebruik van open standaarden. Open standaarden hebben voordelen met betrekking tot interoperabiliteit en leveranciersonafhankelijkheid. De overheid hanteert voor zichzelf het pas toe of leg uit principe. Gebruikers van dit PvE wordt geadviseerd om aan de ontwikkelaar te vragen om te rapporteren over het gebruik van standaarden en welke hiervan open zijn. Daar waar relevant verdient het de sterke voorkeur dat de aansluit bij de lijst van Pagina 16
gangbare standaarden en de lijst van standaarden voor pas toe of leg uit van het Forum en College Standaardisatie, www.open-standaarden.nl. De website, het forum en de zijn zonder problemen en verlies van functionaliteit te gebruiken in de volgende gangbare, moderne webbrowsers, minimaal in de laatste twee hoofdversies van: Firefox. Google Chrome Microsoft Internet Explorer Opera Safari E-mails afkomstig van de website, het forum of de -applicatie zijn duidelijk leesbaar in gangbare moderne email-clients, minimaal in de laatste twee hoofdversies van: Windows Mail Microsoft Outlook Express Microsoft Outlook Lotus Notes Thunderbird Apple Mail Gmail Statistieken van het gebruik van de website, het forum en de zijn met behulp van AWStats (of een functioneel vergelijkbare toepassing) inzichtelijk te maken. Zie ook: http://awstats.sourceforge.net/ 3.3 Beveiliging en Betrouwbaarheid Beveiliging dient een integraal onderdeel te zijn van de verschillende onderdelen (, forum en website) die betrouwbaar en veilig moeten functioneren. Zowel uit het perspectief van de gebruiker als van de beherende eigenaar. Deze moeten op de juistheid en volledigheid van het systeem aankunnen en informatie in vertrouwen kunnen delen. De ingang van beheer en het content-management-systeem is gescheiden van de publieke toegang en alleen bereikbaar vanaf specifieke IP adressen. De applicaties in combinatie met het onderliggende systeem moeten voorzien in logboeken om gebruik inzichtelijk te maken tot op het niveau van personen en IP-adressen. Onder het inzichtelijk te Pagina 17
maken gebruik vallen in het bijzonder applicatiefouten, autorisatiewijzigingen, betalingen, aanmelden, aanmeldpogingen en beheeracties. Het archiveren van de logbestanden moet periodiek voorzien zijn. Het is voor een gebruiker zichtbaar wanneer (datum en tijdstip) men zich in de afgelopen periode heeft aangemeld. Beheer heeft ook inzage in deze gegevens per gebruiker. Een aangemelde gebruiker kan zich afmelden, de sessie is daarmee beëindigd. Na een configureerbare periode van inactiviteit van de gebruiker meldt de applicatie een gebruiker automatisch af. Beveiliging van de omgevingscomponenten (bestaande uit huisvesting, infrastructuur, platform en applicaties) is op elkaar afgestemd. Zo lopen bijvoorbeeld de klokken van de verschillende apparaten gelijk. De omgeving is gesegmenteerd en voorziet in inbraakdetectie en preventie. Onder inbraakdetectie vallen bijvoorbeeld ook anti-virus software en alarmering. Er is actief veiligheidsbeheer op de omgeving voorzien; in het bijzonder moeten platform en infrastructuur naast het reguliere onderhoud beschikken over de meest recente patches en updates die relevant zijn uit het oogpunt van veiligheid. Naast de reguliere testen is een penetratietest door een onafhankelijke partij te voorzien bij grote wijzigingen in de omgeving of wanneer de laatste test meer dan een jaar geleden is. Wijzigingen in systemen of software moeten succesvol zijn getest voor het in productie nemen. Testen mag niet met productiegegevens of op productiesystemen, een productiesysteem mag geen testgegevens, testgebruikers of default gebruikers bevatten. Pagina 18
4 Eisen aan de website De website biedt de bezoeker algemene informatie over de en toegang tot het forum en de. De eisen aan de website zijn summier omdat het uitgangspunt is dat gebruikt wordt gemaakt van beschikbare oplossingen voor het opzetten en beheren van de website. De website bevat minimaal de volgende onderdelen en mogelijkheden voor de bezoeker: Informatie over de, inclusief nieuws. Informatie over de organisatie achter de. Informatie over het gebruik en de kosten van de. Mogelijkheden om in contact te komen met de organisatie achter de. De website bevat contactgegevens en mogelijkheden om vragen te stellen via e-mail of via een formulier. Een lijst met veelgestelde vragen en de antwoorden daarop. Toegang tot het forum en de. De mogelijkheid om een abonnement te nemen op één of meer newsfeeds gebaseerd op RSS of vergelijkbare gangbare standaarden. De beheerder stelt de volgende eisen aan de website. De indeling en inhoud van de website is te beheren door de eigenaar. De opmaak van de website is eenvoudig aan te passen. Veranderingen aan de website moeten kunnen worden getest voordat ze worden doorgevoerd. Veranderingen aan de website zijn terug te draaien. De inhoud van de website is eenvoudig te migreren naar een ander contentmanagementsysteem. Pagina 19
5 Eisen aan het Forum Het besloten forum biedt gebruikers de mogelijkheid te discussiëren over de, het Bouwen-met-Winst-concept en om informatie te delen. Het forum is opgedeeld in een aantal categorieën en subcategorieën. Binnen deze subcategorieën kunnen gebruikers discussies starten en deelnemen aan discussies. De eisen aan het forum zijn summier omdat het uitgangspunt is dat gebruikt wordt gemaakt van beschikbare oplossingen voor het opzetten en beheren van het forum. Het forum biedt minimaal de volgende mogelijkheden voor de gebruiker: Registreren: het maken van een gebruikersaccount op basis van een geldig e-mail adres. Beheren van het gebruikersaccount. Inloggen. Uitloggen. Starten van een discussie. Bijdragen aan een discussie. Zoeken op trefwoorden, binnen het forum en binnen categorieën en subcategorieën. Een abonnement nemen op newsfeeds voor het gehele forum, een categorie, subcategorie of discusssie gebaseerd op RSS of vergelijkbare gangbare standaarden. E-mail-notificaties instellen en beheren op forum, een categorie, subcategorie of discussie. De beheerder stelt de volgende eisen aan het forum. Het forum bevat alleen tekstuele bijdragen. De indeling in categorieën en subcategorieën is te beheren door de eigenaar. Veranderingen aan het forum moeten kunnen worden getest voordat ze worden doorgevoerd. Veranderingen aan het forum zijn terug te draaien. De beheerder kan: 1) een discussie verplaatsen naar een andere categorie, subcategorie of discussie, 2) een discussie verwijderen, 3) een discussie bewerken: bijdragen of delen van bijdragen verwijderen, 4) een discussie afsluiten voor nieuwe bijdragen. Pagina 20
6 Eisen aan 6.1 Kwaliteitseisen Voor de beschrijving van de kwaliteitseisen aan de Voorbereindingsmodule-applicatie is gebruik gemaakt van de indeling van het Extended ISO 9126 Model, ook wel het Quintmodel genoemd. Zie www.softwarekwaliteit.nl. Dit model onderscheidt de volgende kwaliteitseigenschappen: Functionaliteit: geschiktheid, accuraatheid, koppelbaarheid, compliance, beveiliging, traceerbaarheid. Betrouwbaarheid: volwassenheid, fouttolerantie, herstelbaarheid, beschikbaarheid, degradeerbaarheid. Bruikbaarheid: begrijpelijkheid, leerbaarheid, gebruiksgemak, explicietheid, aanpasbaarheid, aantrekkelijkheid, duidelijkheid, behulpzaamheid, gebruiksvriendelijkheid. Efficiëntie: tijdsgedrag, resourcegedrag. Onderhoudbaarheid: analyseerbaarheid, veranderbaarheid, stabiliteit, testbaarheid, beheerbaarheid, herbruikbaarheid. Overdraagbaarheid: aanpasbaarheid, installeerbaarheid, conformance, vervangbaarheid. 6.2 Functionaliteit De functionaliteit van de -applicatie is beschreven in het use-case-model. Hieronder volgt een aantal algemene eisen die bepalend zijn voor de invulling van de use cases. 6.2.1 Geschiktheid Self-service Om de beheerlast te beperken wordt gestreefd naar zoveel mogelijk self-service door de gebruikers. Voorbeelden hiervan zijn het zelf aanmaken van gebruikersaccounts, online betalen voor een initiatief en het zelf toevoegen van deelnemers aan een initiatief. Historie Wijzigingen in vragen, antwoorden en bronnen (documenten en verwijzingen) worden geregistreerd. Geregistreerd wordt welke gebruiker op welk moment welk gegeven heeft gecreëerd of gewijzigd en wat de waarde van het gegeven voor de wijziging was. Deze historie is door de deelnemers aan het initiatief te bekijken. Pagina 21
Betalen Voor het gebruik van de -applicatie dient betaald te worden. De betaling maakt gebruik voor een bepaalde periode mogelijk. Het te betalen bedrag is onafhankelijk van het aantal deelnemers aan het initiatief. De initiatiefnemer kan bij het starten van een initiatief online betalen via ideal, met een Creditcard en eventueel andere gangbare on-line betaalmogelijkheden. Andere on-line betaalmogelijkheden moeten eenvoudig toegevoegd kunnen worden. De initiatiefnemer kan bij betalen kiezen uit een aantal verschillende periodes, bijvoorbeeld drie maanden, zes maanden, negen maanden en twaalf maanden. De betaling leidt tot een factuur die voldoet aan de factuureisen van de Belastingdienst. Bovenstaande betekent dat er geen rekening wordt gehouden met het feit dat inkoop bij bedrijven centraal ingericht kan zijn en dat niet iedere medewerker namens een bedrijf kan betalen. Als hier gangbare oplossingen voor beschikbaar zijn die passen binnen het concept van volledige self-service door de gebruiker dan kan daar alsnog voor worden gekozen. Het is mogelijk om de voor een bepaalde periode kosteloos te gebruiken. Na het verstrijken van de periode dient betaald te worden om de voor het betreffende initiatief te blijven gebruiken. Er is voor gekozen om alleen gratis gebruik voor een bepaalde periode mogelijk te maken. Het is niet mogelijk om de voor een langere periode gratis te gebruiken voor een initiatief met een klein aantal deelnemers. De reden hiervoor is dat alle initiatiefnemers en coördinatoren van een initiatief nieuwe deelnemers kunnen toevoegen. Alle initiatiefnemers en coördinatoren zouden daardoor tegen de grens van het maximaal aantal deelnemers voor gratis gebruik kunnen aanlopen terwijl ze niet allemaal kunnen betalen. Om deze situatie te voorkomen is alleen gratis gebruik voor een bepaalde periode mogelijk, ongeacht het aantal deelnemers aan het initiatief. De deelnemers aan een gratis initiatief dienen een gebruikersaccount te hebben. De periode waarover gratis gebruik mogelijk is is door de beheerder te wijzigen. Bij wijziging van de periode geldt de nieuwe periode voor initiatieven die na de wijziging worden gestart. Voor een eenmaal gestart initiatief blijft de periode gelden die bij de start van kracht was. Pagina 22
Voor een initiatief dient, na een periode van gratis gebruik, betaald te worden. Zolang voor een initiatief niet betaald is hebben alle deelnemers wel toegang tot het initiatief maar kunnen geen wijziging aanbrengen. 6.2.2 Beveiliging De beveiliging van de -applicatie is opgezet conform NEN-ISO/IEC 27001:2005 nl en NEN-ISO/IEC 27002:2007 zoals opgenomen in de lijst van standaarden voor pas toe of leg uit van het Forum en College Standaardisatie, www.open-standaarden.nl. Daarnaast voldoet de -applicatie aan het Raamwerk Beveiliging Webapplicaties van GOVCERT: Raamwerk beveiliging webapplicaties, GOVCERT.NL, versie 1.3, 27 oktober 2006. De ontwikkeling van de voldoet aan de OWASP Guide to Building Secure Web Applications and Web Services: A Guide To Building Secure Web Applications and Web Services, july 27, 2005, owasp.org. De ontwikkeling moet in het bijzonder principes van defensief programmeren toepassen. Modularisatie, invoervalidatie, foutafhandeling en betekenisvolle logbestanden zijn als zodanig vereist. De applicatie voorziet in functiescheiding. In het algemeen geldt dat alleen een geautoriseerde gebruiker toegang heeft tot die gegevens en functies waar deze gebruiker vanuit zijn rol of initiatief bij mag. Een beheerder is in deze ook een gebruiker. Om de gebruiker zekerheid te geven over de identiteit van de applicatie en de communicatie met de applicatie te beveiligen moet de verbinding beveiligd zijn met eenzijdige TLS op basis van een EV servercertificaat. De applicatie geeft een gebruiker tijdens een sessie alleen toegang tot persoonlijke, initiatief en rolgebonden gegevens of functies nadat deze de gebruikersnaam met bijbehorend wachtwoord heeft ingevoerd om zich aan te melden. 6.3 Betrouwbaarheid De verwachte continuïteit van de is 7 x 24 uur. Zonder onderbreking moet deze beschikbaar kunnen zijn. De eis aan beschikbaarheid ligt op 98%, dit vertaalt zich naar een maximale uitval van 7,3 dagen op jaarbasis. De systeemomgeving dient te voorzien in een mechanisme voor backup en restore bij het onvoorzien uitvallen van de applicatie. De applicatie moet hier op zijn afgestemd. Pagina 23
Het uitvoeren van backup- en restore-operaties moet op ieder moment mogelijk zijn, onafhankelijk van de als applicatie. Het toegestane gegevensverlies bij het onvoorzien uitvallen van de applicatie of de systeemomgeving hangt af van de mutatiegraad van de gegevens op dagbasis. De grens hiervoor ligt bij 10%. De hersteltijd (de tijd voor het uitvoeren van een restore-actie) na uitval bedraagt maximaal één uur. Restore-procedures worden regelmatig getest door het terugzetten van backups van individuele componenten (maandelijks) en het terugzetten van het volledige systeem (halfjaarlijks). Er is een wekelijkse volledige backup en een historie van 8 weken van deze backups. Voor beheer (de bewaking van de betrouwbaarheid) is er voorzien in een periodieke rapportage ten aanzien van het middelenbeslag en gedrag van de applicatie, realtime monitoring van de applicatie en alarmering van ernstige anomaliteiten, storingen die de betrouwbaarheid kunnen schaden. De beheerder kan op basis van een monitor zien wat de status is van de applicatie. Bij het niet functioneren van een onderdeel wordt dit automatisch gemeld in de monitor. 6.4 Bruikbaarheid De context van een pagina is voor de gebruiker altijd duidelijk. Duidelijk zichtbaar is tot welk initiatief, fase en vraag de pagina behoort, indien relevant. Notificatie-emails zijn duidelijk afkomstig van de. Dit blijkt uit het email-adres van de afzender en uit het onderwerp. Notificatie-emails bevatten, indien relevant, een verwijzing (deep-link) naar het item waar de mail betrekking op heeft. De verwijzing leidt de gebruiker rechtstreeks naar het betreffende item in de. Indien nodig dient de gebruiker eerst in te loggen. Notificatie-emails bevatten voldoende informatie voor de gebruiker om te kunnen besluiten of vervolgacties nodig zijn en om eventuele vervolgacties uit te voeren. Het moet niet nodig zijn voor de gebruiker om naar aanleiding van een notificatie-email in te loggen op de om over voldoende informatie te beschikken. Pagina 24
Op iedere pagina van de is een link beschikbaar naar help over de betreffende pagina. Bij de help is het duidelijk waar de gebruiker aanvullende ondersteuning kan vinden en hoe de gebruiker in contact kan komen met de helpdesk van de. Bij een foutsituatie, om welke reden dan ook, dienen foutmeldingen getoond te worden. Deze foutmeldingen moeten informatie bevatten wat de gebruiker moet doen of welke actie de website gaat uitvoeren. Foutmeldingen mogen niet negatief/straffend geformuleerd zijn. 6.5 Efficiëntie Rekening dient te worden gehouden met de volgende aantallen initiatieven en gebruikers. Eerste jaar Tweede jaar Derde jaar en verder Aantal nieuwe 500 5000 20.000 initiatieven per jaar Aantal actieve 3000 30.000 150.000 gebruikers Gelijktijdige 30 300 1500 gebruikers Gemiddelde gegevensomvang per initiatief 500 MB 750 MB 1 GB Bewaartermijnen van inactieve gebruikersaccounts en inactieve initiatieven dienen instelbaar te zijn. In eerste instantie geldt: Initiatief: 12 maanden na verlopen betaalde periode initiatief. Gebruikersaccount: 12 maanden na laatste activiteit gebruiker. De volgende responsetijden dienen te worden gehaald: 3 seconden, maximaal 15 seconden toelaatbare wachttijd. Zie http://www.websiteoptimization.com/speed/tweak/web-page-performancethesis/. 6.6 Onderhoudbaarheid De voorbereidingsmodule moet goed onderhoudbaar zijn; van iedere versie, revisie voor productie is actuele broncode en actuele documentatie beschikbaar met een beschrijving van de wijzigingen ten opzichte van de voorgaande versie. Pagina 25
Er is gebruik gemaakt van gangbare methodieken voor software-ontwikkeling die de onderhoudbaarheid bevorderen zoals: codeerstandaards, automatische code analyse, unit testen en defensief programmeren. De eigenaar van de kan besluiten een analyse van de kwaliteit van de software uit te (laten) voeren. 6.7 Overdraagbaarheid De omgeving is dusdanig ingericht en gedocumenteerd dat aan het einde van het contract een leverancier de dienstverlening kan overdragen aan een willekeurige andere partij. De omgeving en in het bijzonder de applicaties zijn niet afhankelijk van licenties, patenten of andere bijzondere rechten waarvoor de eigenaar geen expliciete goedkeuring heeft gegeven. Dit heeft het doel ongewenste afhankelijkheden die de overdraagbaarheid belemmeren te voorkomen. Pagina 26
7 Domeinmodel Het domeinmodel benoemt de relevante onderwerpen van gesprek binnen de scope van de en de relaties en eigenschappen ervan. Het domeinmodel is vooral een model van de relevante werkelijkheid en van de belangrijkste gegevens van een initiatief. Het domeinmodel is geen model van de gegevensopslag in de ; het is geen relationeel gegevensmodel. Het domeinmodel laat het forumonderdeel en de algemene website van de buiten beschouwing. Het laat ook het aspect historie (wijziging van gegevens) buiten beschouwing. Eigenschappen als tijdstippen van registratie en wijziging zijn daarom niet in het domeinmodel opgenomen. De afbeelding hieronder toont het domeinmodel als UML class diagram. Dit hoofdstuk beschrijft de verschillende objecttypen in het domeinmodel, zoals Fase, Deelname en Bron, de relaties tussen deze objecttypen en de relevante eigenschappen ervan. Pagina 27
Afbeelding 2. Domeinmodel voor de. 7.1 Deelname Definitie: Deelname is de deelname van een persoon aan een initiatief in de rol van initiatiefnemer, coördinator of specialist. Relaties: Een deelname betreft de deelname van één persoon in één rol. Een persoon heeft bij ieder initiatief maximaal één deelname. Een persoon kan deelnemen aan verschillende initiatieven. Vanuit een deelname kan een persoon eigenaar zijn van nul of meer vragen. Vanuit een deelname kan een persoon verantwoordelijke zijn van nul of meer vragen. Vanuit een deelname kan een persoon beantwoorder zijn van nul of meer vragen. Vanuit een deelname kan een persoon nul of meer opmerkingen toevoegen. Vanuit een deelname kan een persoon nul of meer bronnen toevoegen. Pagina 28
Vanuit een deelname kan een persoon nul of meer bronnen bij vragen toevoegen. Eigenschappen: E-mailadres voor deelname: als een persoon in zijn gebruikersaccount verschillende e- mailadressen heeft vastgelegd, dan kan de persoon voor de specifieke deelname aangeven welk e-mailadres voor die deelname gebruikt dient te worden. Als de persoon geen specifiek e- mailadres opgeeft dan gebruikt het systeem het eerste e-mailadres van de persoon. Status: Een deelname heeft één van de volgende statussen: actief, beëindigd. Als een deelname is beëindigd dan heeft de betreffende persoon geen toegang meer tot het initiatief maar zijn bijdragen aan het initiatief blijven gehandhaafd. Toelichting: Als in het kader van het domeinmodel wordt gesproken over 'de persoon' wordt meestal bedoeld 'de deelname van de persoon aan een initiatief'. Zie de beschrijving bij het objecttype 'Rol' voor een uitleg van het onderscheid tussen Rol en Deelname. 7.2 Bron Definitie: Een bron bevat voor het initiatief relevante informatie en is ingebracht door een persoon die deelneemt aan het initiatief. Relaties: Een bron is ingebracht in één initiatief. Een bron is ingebracht via één deelname van een persoon aan hetzelfde initiatief. Een bron is (via Bron bij Vraag) toegevoegd aan nul of meer vragen in hetzelfde initiatief. Een bron die aan een vraag is toegevoegd is daarmee in feite aan het betreffende initiatief toegevoegd. Bij een bron zijn nul of meer opmerkingen toegevoegd. Eigenschappen: Naam: een bron heeft een naam. Toelichting: een bron heeft een omschrijving gegeven door de persoon die de bron heeft toegevoegd. Pagina 29
Toelichting: Er wordt bij bronnen onderscheid gemaakt tussen documenten en verwijzingen. Documenten worden aan het initiatief toegevoegd. Verwijzingen verwijzen naar informatie die elders beschikbaar is, veelal in de vorm van een website. Een bron hoeft niet noodzakelijk aan een vraag te zijn toegevoegd. De bron kan ook alleen aan het initiatief zijn toegevoegd. Iedere bron komt slechts één keer voor in het initiatief. Het toevoegen van een bron aan een vraag komt daarom neer op het toevoegen van de bron aan het initiatief en verwijzen vanuit de vraag naar de bron. 7.3 Bron bij Vraag Definitie: Een 'bron bij vraag' is de verwijzing vanuit een vraag naar een bron. Relaties: Een bron bij vraag betreft de toevoeging van één bron aan één vraag. Een bron bij vraag is toegevoegd aan de vraag via één deelname van een persoon. Op een bron bij vraag zijn nul of meer opmerkingen van toepassing. Eigenschappen: Toelichting: Een bron bij vraag heeft een toelichting gegeven door de persoon die de bron aan de vraag heeft toegevoegd. Toelichting: Een bron kan door dezelfde persoon aan het initiatief zijn toegevoegd en aan één of meer vragen. Dat is echter niet noodzakelijk. Het is ook mogelijk dat verschillende personen dezelfde bron aan verschillende vragen toevoegen. Om onderscheid te kunnen maken tussen de toelichting en opmerkingen bij een bron zelf en de toelichting en opmerkingen bij de toevoeging van een bron aan een vraag is het object 'bron bij vraag' onderkend. De toelichting en opmerkingen bij 'bron bij vraag' gaan over de bron in relatie tot de vraag en moeten zichtbaar te maken zijn bij de vraag. De toelichting en opmerkingen bij de bron betreffen de bron zelf en moeten zichtbaar te maken zijn in het dossier waarin alle documenten van het initiatief te vinden zijn. 7.4 Document Definitie: Een document is een bron van informatie die aan het initiatief is toegevoegd. Pagina 30
Relaties: Een document heeft één voorgaande versie, met uitzondering van de eerste versie. Een document heeft één volgende versie, met uitzondering van de laatst toegevoegde, actuele versie. Eigenschappen: Naam: Een document heeft als naam de naam van het bestand. Versienummer: Een documentversie heeft een versienummer toegekend door het systeem. Het versienummer start met 1 en wordt iedere versie met 1 opgehoogd. Toelichting bij versie: Een documentversie heeft een toelichting van de persoon die de versie heeft toegevoegd. Toelichting: Van een document kunnen verschillende versies aan het dossier zijn toegevoegd. Iedere versie heeft dezelfde bestandsnaam. Het systeem kent aan iedere versie een versienummer toe. Iedere versie kan een toelichting bij versie hebben. De laatst toegevoegde versie is de actuele versie. 7.5 Fase Definitie: Een fase is een stap in een initiatief waarbinnen een aantal vragen beantwoord dienen te worden. Relaties: Een fase behoort tot één initiatief. Een fase bevat nul of meer vragen. De vragen die rechtstreeks onder de fase vallen noemen we de hoofdvragen. Een fase heeft een voorgaande fase, met uitzondering van de eerste fase. Een fase heeft een volgende fase, met uitzondering van de laatste fase. Eigenschappen: Naam: Een fase heeft een naam zoals gegeven door een initiatiefnemer. Toelichting: Een fase heeft een toelichting zoals gegeven door een initiatiefnemer. Status: Een fase heeft een status. Mogelijke statussen zijn: inactief, actief en afgesloten. Een fase doorloopt de statussen in de genoemde volgorde. In een initiatief is maximaal één fase actief. De voorgaande fasen zijn afgesloten en de volgende fasen zijn inactief. Als een fase wordt afgesloten kan de volgende fase actief worden gemaakt. Alleen in een actieve fase kunnen deelnemers wijzigingen aanbrengen. Pagina 31
7.6 Initiatief Definitie: Een initiatief is de aanzet tot het aanpassen van de fysieke leefomgeving. Relaties: Aan een initiatief neemt minimaal één persoon deel in de rol van initiatiefnemer. Een initiatief kent minimaal één fase. Aan een initiatief zijn nul of meer bronnen toegevoegd. Een initiatief kent minimaal één thema. Eigenschappen: naam: een initiatief heeft een naam zoals gegeven door een initiatiefnemer. toelichting: een initiatief heeft een toelichting zoals gegeven door een initiatiefnemer. status: een initiatief heeft een status. Mogelijke statussen zijn: actief en beëindigd. In een beëindigd initiatief kunnen de deelnemers geen wijzigingen aanbrengen. locatie: een initiatief heeft een aanduiding van de locatie van het initiatief. De volgende soorten zijn minimaal mogelijk: een adres (straatnaam, huisnummer, postcode en plaatsnaam), coördinaten volgens een door de initiatiefnemer opgegeven stelsel, een kadastrale aanduiding en een verwijzing (bijvoorbeeld een URL van een locatie in Google Maps of vergelijkbare voorziening). Alle soorten locaties zijn optioneel en kunnen gecombineerd worden, bijvoorbeeld een adres in combinatie met een kadastrale aanduiding. aard van activiteiten: de aard van de activiteiten geeft aan wat voor soort initiatief het is: volledige nieuwbouw, gedeeltelijke verbouwing en dergelijke. De aard van activiteiten is een classificatie van het initiatief die onder andere helpt bij het bepalen van de te hanteren vragenlijsten. De mogelijke waarden van aard van activiteiten dienen nog te worden bepaald; risicoclassificatie: de risicoclassificatie is een beoordeling van het initiatief die helpt bij het inschatten van de risico s en het bepalen van de te hanteren vragenlijsten. De risicoclassificatie bestaat uit drie elementen: 1) ervaring met soortgelijke initiatieven, 2) uniekheid en 3) complexiteit. Ieder van deze drie elementen kan beoordeeld worden op een schaal van drie posities. Ervaring van veel tot geen, uniekheid van standaard tot uniek, complexiteit van eenvoudig tot complex. Een hogere waarde op de schaalverdeling betekent meer risico. overige eigenschappen: de initiatiefnemer kan andere relevante eigenschappen aan het initiatief toevoegen. Deze eigenschappen hebben een naam, een soort (tekst, getal, valuta) en een waarde. De overige eigenschappen maken het mogelijk om extra eigenschappen van het initiatief vast te leggen. Pagina 32