Presentatie Klankbordgroep Studiedag 20 En 29 Mei 2008
RE patronen voor e-Procurement
1. RE patronen voor e-Procurement
Een onderzoek rond het opstellen van software-gerelateerde lastenboeken
Anja De Ridder
19 juni 2012
•Afstudeerbegeleider: Dr. Ella Roubtsova
•Examinator: Prof. Dr. Ir. Frans Mofers
2. Agenda
1. Persoonlijk introductie
2. Aanleiding en motivatie
3. Onderzoeksvragen en onderzoeksmodel
4. Proces e-Procurement
5. Requirements engineering en RE patronen
6. Ontwikkeling van prototypes
7. Validatie RE patronen via interviews
8. Aanbevelingen
9. Algemene conclusies
10. Persoonlijke lessons learned
11. Dankwoord
12. Vragen
4. Aanleiding en motivatie
Mogelijke eisen van Smartphone software
•Toegang tot de mailbox
•Browser
•Veiligheid
•Qwerty of Azerty toetsenbord
•Talen
5. Aanleiding en motivatie
Artikel “Aanbesteding elektronisch kinddossier onjuist“
“De rechter oordeelt dat de kwaliteitseisen in de
aanbestedingsprocedure niet helder geformuleerd zijn.”
7. Onderzoeksvragen en onderzoeksmodel
Onderzoeksvragen :
•Welke RE methoden worden gebruikt voor het opstellen van
het technisch gedeelte ?
•Hoe kunnen de gebruikte RE methoden ondersteund worden
met RE patronen ?
14. Proces e-Procurement
e-Notification
Search tender notice
Publish tender notice
e-Tendering e-Auction
Submit tender Configure auction
Open tenders Participate in auction
Public officer Supplier
15. Proces e-Procurement
e-Notification e-Awarding
Search tender notice Define evaluation
Publish tender notice Evaluate tenders
e-Tendering e-Auction
Submit tender Configure auction
Open tenders Participate in auction
Public officer Supplier
16. Proces e-Procurement
e-Notification e-Awarding
Search tender notice Define evaluation
Publish tender notice Evaluate tenders
e-Tendering e-Auction
Submit tender Configure auction
Open tenders Participate in auction
Public officer Supplier
17. Proces e-Procurement
e-Notification e-Awarding e-Catalogue
Search tender notice Define evaluation Prepare catalogue
Publish tender notice Evaluate tenders Approve catalogue
e-Tendering e-Auction
Submit tender Configure auction
Open tenders Participate in auction
Public officer Supplier
18. Proces e-Procurement
e-Notification e-Awarding e-Catalogue
Search tender notice Define evaluation Prepare catalogue
Publish tender notice Evaluate tenders Approve catalogue
e-Tendering e-Auction e-Ordering
Submit tender Configure auction Prepare order
Open tenders Participate in auction Deliver products
Public officer Supplier
19. Requirements engineering en RE patronen
Bron:Parallel model van het requirements proces (bron: Ann M. Hickey and Alan M. Davis, 2002)
20. Requirements engineering en RE patronen
Courante elicitatie-technieken
•Interview
•Enquête
•Workshop
•Informatiebronnen
21. Requirements engineering en RE patronen
Requirements Volere :
•Product drivers
•Project beperkingen
•Functionele eisen
•Niet-functionele eisen
•Project issues
22. Ontwikkeling van prototypes
Requirements voor de prototypes :
•RE patronen bevatten uitgebreide requirements
•Inhoud gemakkelijk aan te passen
•Gemakkelijk uit te breiden
•Output in XML-formaat
•Standaard terminologie
•Meertaligheid
•Webbased
28. Validatie RE patronen via interviews
Betrokken organisaties
FOD Personeel & Organisatie
•Ondersteuning en begeleiding van federale
overheidsdiensten in België
Fedict
•Uitwerking en opvolging van e-government
29. Validatie RE patronen via interviews
6 geïnterviewden met elk hun lastenboek (LB):
1.Adviseur van DG OPO
LB: Ondersteuning inzake enquêtes (Saas service)
2.Expert kennismanagement van de dienst KMCOMM
LB: Levering van updates voor een gemeenschappelijke
catalogus gehost op een publiek toegankelijke server
3.ICT verantwoordelijke van OFO
LB: Levering van diensten m.b.t. de ontwikkeling v/e correctie
en analyseplatform binnen een MS SharePoint-omgeving voor
rekening van het OFO
30. Validatie RE patronen via interviews
4. Aankoper van FOR
LB: Levering van licenties van Microsoft
5. Verantwoordelijke van e-Procurement
LB: Aankoop, customisatie en implementatie van e-
Awarding-software
6. Directeur-generaal systeem architectuur, standaarden en
support bij Fedict
LB: Nieuwe aanpak van de Fedict infrastructuurdiensten
(o.a. via Cloud-service providers)
31. Validatie RE patronen via interviews
De meest gebruikte elicitatie-technieken :
•(vak)literatuur
•workshop
•interview
•voorgaande lastenboek(en)
•(tevredenheids)enquête
•conferenties of forums
32. Validatie RE patronen via interviews
De resultaten van de validatie van de Requirements
•De meeste requirements zijn terug te vinden
•De andere requirements die niet terug te vinden zijn :
– de vereisten voor Cloud
– de vereisten i.v.m. ITIL
– de criteriums in SLA
– vereiste expertise en certificaten van de leveranciers
33. Validatie RE patronen via interviews
Conclusies van de RE patronen in de prototypes
•op structureel gebied: weinig aanpassing
•op inhoudelijk vlak: verdere aanvulling
•voordelen :
– gemakkelijk aan te passen
– gestandaardiseerde terminologie
– minimale vereisten vergeten
35. Algemene conclusie
1. Het RE patroon Volere is niet volledig voor e-Procurement
2. De patronen kunnen uitgekristalliseerd worden
3. Mijn bedrage aan dit onderzoek:
1. een eerste prototype met patronen
2. de plaatsbepaling van de patronen in de e-Procurement
architectuur
3. een eerste evaluatie van de ontwikkelde patronen bij specialisten
36. Algemene conclusie
Aanpak bij het opstellen van de requirements om het
probleem Kinddossier te voorkomen :
–topdown-analyse zodat de kans om belangrijke vereisten
te vergeten minimaal is
–eenduidige formulering via gestandaardiseerde
terminologie
37. Persoonlijke lessons learned
• Nieuwe inspirerende contacten met collega’s binnen en buiten mijn eigen organisatie.
• Aangenaam verrast over de spontane medewerking en aanmoediging van collega’s
tijdens het onderzoek.
• De nieuwe kennis betreffende requirements engineering, overheidsopdrachten en e-
Procurement .
• Het opzetten en uitvoeren van een wetenschappelijk verantwoord onderzoek.
• De verdere competentieontwikkeling rond literatuurstudie, interview- en
presentatietechnieken.
Kortom een verrijkende ervaring
38. Dankwoord
Mijn dank gaat naar:
• Dr. Ella Roubtsova (mijn afstudeerbegeleider)
• Dr. Frans Mofers (mijn tweede begeleider)
• Peter, Tom en Tim (mijn gezin)
• De vele collega’s van de FOD Personeel & Organisatie en Fedict die meewerkten aan dit
onderzoek
• Medestudent Jan Hummel en mijn neef Johny Geenens
Bijkomende vragen:
• Anja De Ridder
deridder.anja@gmail.com
Editor's Notes
Ik ben als onderzoeker een heel jaar bezig geweest met een onderzoek rond het thema requirements engineering. Mijn thesisonderzoek gaat over de requirements engineering patronen voor e-Procurement. Het praktisch onderzoek is vooral gericht op het opstellen van software-gerelateerde lastenboeken. De afbeelding hier heeft een symbolische waarde, het lastenboek wordt digitaal verwerkt in de digitale radar van e-Procurement. Een andere woord voor lastenboek is tender specificatie of bestek. Het RE patroon heeft hier de betekenis van een conceptueel kennismodel die voorgesteld is als een boomstructuur. e-Procurement betekent elektronische overheidsopdrachten voor overheid en ondernemingen.
Ik zal in kort over de volgende punten spreken van mijn thesisonderzoek : Aanleiding en motivatie Onderzoeksvragen en onderzoeksmodel e-Procurement en RE RE patronen en ontwerpen van prototypes Validatie RE patronen via de interviews Aanbevelingen Algemene conclusies Vragen
Ik zal me eerst voorstellen : Mijn naam is Anja De Ridder en woont in Gent dus in België. Ik ben moeder van twee kleuters Tom en Tim die jullie hier op de foto zien, opgenomen tijdens schoolfeest eind mei. Ik hoop na de presentatie dat ze meer aandacht krijgen van mij. Deze opleiding volg ik om meer inzicht te krijgen in procesbeschrijvingen die van de business afkomstig zijn om zo de kwalitatieve applicaties te leveren aan de business. En een andere reden is uiteraard ook om masterdiploma te halen. Ik werk als programmeur-analist, ongeveer 15 jaar bij de Belgische overheid. Mijn werk is vooral ontwikkeling van applicaties. . Dit was kort over mezelf.
De aanleiding van mijn onderzoek was dat ik werd gecontacteerd om samen met een collega om een lastenboek op te stellen voor aankoop van een applicatie documentbeheer. We hadden allebei nog nooit een lastenboek opgesteld. Hier door hebben we aan een andere collega een bestaande lastenboek opgevraagd. Daardoor was dit voor mij een aanleiding om lastenboeken voor overheidsopdrachten te bestuderen. Om kort toe te lichten wat lastenboek is, wil ik hier kort uitleggen wat eigenlijk de kern is van lastenboek. Iedereen wordt geconfronteerd met aankoop van een product, denken we aan de smartphone die de laatste jaren meer en meer wordt gekocht voor zowel privé als beroepsgebruik. We kunnen denken aan welke mogelijke eisen van smartphone software moet voldoen : Toegang tot de mailbox (m.a.w. tot de mailprovider) Webbrowser om het Internet te raadplegen Veiligheid denken we hoe men toegang kan krijgen tot de gegevens door inloggen via paswoord, biometrie (oogscan of vingerscan, …), enz. Wordt de gegevens gecrypteerd opgeslagen voorbeeld met Keepass Toetsenbord instelling: qwerty toetsenbord (typisch voor Nederland), of azerty toetsenbord (typisch voor België) Talen (welke talen moet de software bevatten) Het is belangrijk dat je alle behoeftes noteert zodat je achteraf bij de aankoop geen spijt hebt dat enkele functionaliteiten ontbreken.
Zo is het ook belangrijk voor de business dat je alle eisen goed formuleert dat je niets vergeet want het slecht opstellen van deze lastenboeken kunnen grote gevolgen hebben zoals vertraging van het project, financiële gevolgen, ontslag van de verantwoordelijke ambtenaar, enz. Ik heb enkele reële artikels gevonden over het slecht opstellen van lastenboeken. Eén ervan is over het artikel “ Aanbesteding elektronisch kinddossier onjuist” (09/2007) “ De rechter oordeelt dat de kwaliteitseisen in de aanbestedingsprocedure niet helder geformuleerd zijn.” M.a.w. de aanbestedingsdocumenten zijn niet transparant genoeg volgens de oordeel van de rechtbank in Utrecht. Met als gevolg dat de aanbesteding voor de ontwikkeling van het elektronische kinddossier opnieuw moest herschreven worden waardoor dreiging is om de planning nog te kunnen halen. Volgens de rechter stelt de stichting Elektronisch Kinddossier (EKD) tegenstrijdige eisen aan de prijs waaraan de inschrijvers moesten voldoen. (09/2007) Read more: http://www.computable.nl/artikel/nieuws/ecm/2142449/1277020/aanbesteding-elektronisch-kinddossier-onjuist.html#ixzz1w0XUR66Z De regio’s kopen daarom nu elk hun eigen systeem in, dat straks wordt aangesloten op het al bestaande Landelijk SchakelPunt. (22 juli 2008) http://www.binnenlandsbestuur.nl/sociaal/nieuws/nieuws/elektronisch-kinddossier-volgend-jaar-ingevoerd.93663.lynkx
Eén van de reden van slecht opgestelde lastenboeken is door hun complexiteit. Een lastenboek bestaat uit 3 gedeelten : Juridische gedeelte Technische gedeelte Administratieve gedeelte Gelukkig zijn er templates beschikbaar voor juridische en administratieve gedeelten. Voor technische gedeelte is geen template beschikbaar omdat dit gedeelte afhankelijk is van het product dat men wenst aan te kopen. Het is dit technische gedeelte waar verkeerd kan lopen omdat: Velen weten niet hoe ze de eisen moeten opstellen De verantwoordelijkheden worden vaag of niet vermeld De vereisten zijn niet gedetailleerd weergegeven waardoor de prijsoffertes niet correct zijn Sommige (belangrijke) eisen werden niet formeel vermeld De verschillende procedures zijn: De offerteaanvraag De offerteaanvraag is een procedure waarop de aanbestedende overheid altijd een beroep kan doen. De opdracht wordt gegund op basis van diverse gunningscriteria, zoals de prijs, de technische waarde, de nazorg, de geboden garanties, enz. De aanbesteding De openbare aanbesteding is een procedure waarop de aanbestedende overheid altijd een beroep kan doen. De opdracht wordt gegund op basis van één enkel gunningscriterium, nl. de prijs. Deze procedure wordt gebruikt wanneer de aanbestedende overheid de technische eisen van de geplande werken, leveringen of diensten nauwkeurig wil definiëren en weergeven in het bestek. De onderhandelingsprocedure Bij een onderhandelingsprocedure wordt de opdracht gegund ofwel op basis van één enkel criterium, nl. de prijs, ofwel op basis van diverse gunningscriteria. In het klassieke stelsel vormt de onderhandelingsprocedure een uitzonderingsprocedure.
Welke requirements engineering methoden worden voornamelijk gebruikt voor het opstellen van het technische gedeelte van de software-gerelateerde lastenboeken als input voor e-Procurement ? Hoe kunnen de gebruikte requirements engineering methoden ondersteund worden met RE patronen om het technische gedeelte van de software-gerelateerde lastenboeken geschikt te maken voor e-Procurement ?
Het onderzoeksmodel toont de werkzaamheden die tijdens het afstudeeronderzoek zijn uitgevoerd Het onderzoek bestaat uit 4 fasen : In de eerste fase (a) vindt de vak- en wetenschappelijke literatuur plaats: de vakliteratuur e-Procurement (1) levert inzicht op over de verschillende modules van e-Procurement, het mogelijke verloop van een proces en de mogelijkheden om gebruik te maken van e-Procurement; de vakliteratuur overheidsopdrachten (2) resulteert in de definities van de overheidsopdrachten met hun procedures en de definities rond lastenboeken en levert inzicht in de verschillende thema’s die in het lastenboek kunnen voorkomen; de Wetenschappelijke literatuurstudie van requirements engineering resulteert in de requirements engineering methoden (3) zoals de checklijst “Requirements”, het framework “elicitatie-technieken” en de beïnvloedingsfactoren van elicitatie-technieken. In de tweede fase (b) vindt het praktijkonderzoek plaats (d.w.z. het toepassen van de algemeen theoretische inzichten in de specifieke onderzoekscontext binnen de Belgische overheid), dat uit de volgende activiteiten bestaat: het ontwerpen van de prototypes op basis van RE patronen (4) dat het resultaat is van de drie delen van de literatuurstudies; het analyseren van de lastenboeken (5) met betrekking tot de toepasbaarheid van de ontworpen RE-patronen; het interviewen van de opstellers van het betreffende lastenboek (6) . In de derde fase (c) wordt de validatie van de RE patronen uitgevoerd (7) aan de hand van de interviewresultaten. Het onderzoek wordt in de vierde fase (d) afgesloten met de discussies (8) door de twee centrale onderzoeksvragen te beantwoorden. De verbeteringsvoorstellen (8) zijn vooral bedoeld voor het verder onderzoek.
Het onderzoeksmodel toont de werkzaamheden die tijdens het afstudeeronderzoek zijn uitgevoerd Het onderzoek bestaat uit 4 fasen : In de eerste fase (a) vindt de vak- en wetenschappelijke literatuur plaats: de vakliteratuur e-Procurement (1) levert inzicht op over de verschillende modules van e-Procurement, het mogelijke verloop van een proces en de mogelijkheden om gebruik te maken van e-Procurement; de vakliteratuur overheidsopdrachten (2) resulteert in de definities van de overheidsopdrachten met hun procedures en de definities rond lastenboeken en levert inzicht in de verschillende thema’s die in het lastenboek kunnen voorkomen; de Wetenschappelijke literatuurstudie van requirements engineering resulteert in de requirements engineering methoden (3) zoals de checklijst “Requirements”, het framework “elicitatie-technieken” en de beïnvloedingsfactoren van elicitatie-technieken. In de tweede fase (b) vindt het praktijkonderzoek plaats (d.w.z. het toepassen van de algemeen theoretische inzichten in de specifieke onderzoekscontext binnen de Belgische overheid), dat uit de volgende activiteiten bestaat: het ontwerpen van de prototypes op basis van RE patronen (4) dat het resultaat is van de drie delen van de literatuurstudies; het analyseren van de lastenboeken (5) met betrekking tot de toepasbaarheid van de ontworpen RE-patronen; het interviewen van de opstellers van het betreffende lastenboek (6) . In de derde fase (c) wordt de validatie van de RE patronen uitgevoerd (7) aan de hand van de interviewresultaten. Het onderzoek wordt in de vierde fase (d) afgesloten met de discussies (8) door de twee centrale onderzoeksvragen te beantwoorden. De verbeteringsvoorstellen (8) zijn vooral bedoeld voor het verder onderzoek.
Het onderzoeksmodel toont de werkzaamheden die tijdens het afstudeeronderzoek zijn uitgevoerd Het onderzoek bestaat uit 4 fasen : In de eerste fase (a) vindt de vak- en wetenschappelijke literatuur plaats: de vakliteratuur e-Procurement (1) levert inzicht op over de verschillende modules van e-Procurement, het mogelijke verloop van een proces en de mogelijkheden om gebruik te maken van e-Procurement; de vakliteratuur overheidsopdrachten (2) resulteert in de definities van de overheidsopdrachten met hun procedures en de definities rond lastenboeken en levert inzicht in de verschillende thema’s die in het lastenboek kunnen voorkomen; de Wetenschappelijke literatuurstudie van requirements engineering resulteert in de requirements engineering methoden (3) zoals de checklijst “Requirements”, het framework “elicitatie-technieken” en de beïnvloedingsfactoren van elicitatie-technieken. In de tweede fase (b) vindt het praktijkonderzoek plaats (d.w.z. het toepassen van de algemeen theoretische inzichten in de specifieke onderzoekscontext binnen de Belgische overheid), dat uit de volgende activiteiten bestaat: het ontwerpen van de prototypes op basis van RE patronen (4) dat het resultaat is van de drie delen van de literatuurstudies; het analyseren van de lastenboeken (5) met betrekking tot de toepasbaarheid van de ontworpen RE-patronen; het interviewen van de opstellers van het betreffende lastenboek (6) . In de derde fase (c) wordt de validatie van de RE patronen uitgevoerd (7) aan de hand van de interviewresultaten. Het onderzoek wordt in de vierde fase (d) afgesloten met de discussies (8) door de twee centrale onderzoeksvragen te beantwoorden. De verbeteringsvoorstellen (8) zijn vooral bedoeld voor het verder onderzoek.
Het onderzoeksmodel toont de werkzaamheden die tijdens het afstudeeronderzoek zijn uitgevoerd Het onderzoek bestaat uit 4 fasen : In de eerste fase (a) vindt de vak- en wetenschappelijke literatuur plaats: de vakliteratuur e-Procurement (1) levert inzicht op over de verschillende modules van e-Procurement, het mogelijke verloop van een proces en de mogelijkheden om gebruik te maken van e-Procurement; de vakliteratuur overheidsopdrachten (2) resulteert in de definities van de overheidsopdrachten met hun procedures en de definities rond lastenboeken en levert inzicht in de verschillende thema’s die in het lastenboek kunnen voorkomen; de Wetenschappelijke literatuurstudie van requirements engineering resulteert in de requirements engineering methoden (3) zoals de checklijst “Requirements”, het framework “elicitatie-technieken” en de beïnvloedingsfactoren van elicitatie-technieken. In de tweede fase (b) vindt het praktijkonderzoek plaats (d.w.z. het toepassen van de algemeen theoretische inzichten in de specifieke onderzoekscontext binnen de Belgische overheid), dat uit de volgende activiteiten bestaat: het ontwerpen van de prototypes op basis van RE patronen (4) dat het resultaat is van de drie delen van de literatuurstudies; het analyseren van de lastenboeken (5) met betrekking tot de toepasbaarheid van de ontworpen RE-patronen; het interviewen van de opstellers van het betreffende lastenboek (6) . In de derde fase (c) wordt de validatie van de RE patronen uitgevoerd (7) aan de hand van de interviewresultaten. Het onderzoek wordt in de vierde fase (d) afgesloten met de discussies (8) door de twee centrale onderzoeksvragen te beantwoorden. De verbeteringsvoorstellen (8) zijn vooral bedoeld voor het verder onderzoek.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
e-Procurement is elektronische overheidsopdrachten voor overheid en ondernemingen In deze afbeelding wordt het verloop van de koppeling van de verschillende modules in het proces e-Procurement weergegeven. Het proces begint bij het opstellen van een lastenboek voor opdracht(en) die via samenwerkingstool in e-Notification wordt beheerd om daarna in de finale versie van het lastenboek te publiceren in e-Notification . De leverancier kan de lastenboeken in e-Notification opzoeken die voor hem een interessante opdracht zijn of een mogelijke verkoop van het product inhouden. Nadat het lastenboek is gepubliceerd in e-Notification, kan de leverancier zijn/haar offerte plaatsen (dus aanbieden) in e-Tendering . Er kan eventueel een omgekeerde veiling van het betreffende lastenboek worden uitgevoerd door deze te configureren (of in te stellen) in e-Auctions . De kandidaat leveranciers die hun offerte in e-Tendering hebben aangeboden, kunnen deelnemen aan deze veiling. Na de afsluiting van het lastenboek in e-Tendering en/of na de afsluiting van de eventuele uitvoering van e-Auction, worden de offertes automatisch geëvalueerd in e-Awarding . De gegunde opdracht wordt gepubliceerd in e-Notification. Indien het lastenboek over het aanbieden van producten in een cataloog gaat, zal de gegunde leverancier zijn cataloog klaarzetten voor e-Catalogue . Na goedkeuring wordt de cataloog gepubliceerd. Vanaf dat ogenblik kunnen de verschillende overheidsdiensten hun producten uit de cataloog bestellen via e-Catalogue, waarbij automatisch een bestelbon wordt opgesteld in e-Ordening , en de leverancier de bestelde producten van de bestelbon kan leveren. De applicatie e-Procurement van FOD P&O is opgebouwd uit het basispakket e-PPS (Electronic Public Procurement System) (European Dynamics SA, 2012), die de softwareleverancier customiseert naar de behoeften van de klant.
De Requirements engineering (volgens M. Hickey et al (2002) heeft de volgende activiteiten te onderscheiden : Eliciteren: het identificeren van de informatiebronnen aangaande het systeem en het ontdekken van de behoeften van de klanten, gebruikers en andere potentiële belanghebbenden ; Modelleren: het creëren en analyseren van de modellen van de requirements met het doel te begrijpen en te zoeken naar onvolledigheden en inconsistentie ; Sorteren: het determineren van requirements die belangrijk zijn voor de aankoop van het softwarepakket ; Specificeren: het documenteren van de gewenste requirements ; Verifiëren: het determineren van de redelijkheid, consistentie, volledigheid, geschiktheid en het ontbreken van gebreken in een pakket van requirements. De vermeldde activiteiten vinden parallel plaats waarbij vooral de activiteiten “eliciteren” en “specificeren” het meeste werk en de meeste tijd in het requirements proces innemen. Het modelleren wordt in dit thesisrapport niet belicht, de redenen hiervoor zijn dat deze activiteit niet voor alle lastenboeken worden gebruikt omdat het niveau van lastenboeken niet altijd gedetailleerde beschrijvingen van concepten en gedragsmodellen vereist. Toch wil de onderzoeker vermelden dat één van de modelleringstechnieken de KAOS methode (Respect-IT sa, 10/2007) is die als nuttige requirements engineering methode voor het opstellen van lastenboeken voor overheidsopdrachten kan gebruikt worden.
Voor de activiteit “eliciteren”, heb ik de courante elicitatie-technieken bestudeert: De 3 elicitatie-technieken is in een framework opgenomen door de volgende vragen te beantwoorden Wat?, Wanneer toepassen?, Hoe verloopt het proces?, Complementaire elicitatie-technieken en de voor- en nadelen De andere courante elicitatie-techniek is informatiebronnen raadplegen waarvoor ik een checklijst opgesteld heb die in mijn thesisrapport opgenomen is (raadplegen van voorgaande lastenboeken, beschrijvingen van legacy systemen, gerelateerde processen, netwerken zoals conferencing, demo’s van nieuwe software, markanalisten zoals Gartner, …) Ik heb dit omgezet in het RE patroon van de elicitatie-technieken (die hier weergegeven is), dit heb ik uitgetekend a.d.h.v. de courante elicitatie-technieken. Ik heb dit ingedeeld in de courante elicitatie-technieken en de complementaire elicitatie-technieken die de courante elicitatie-technieken ondersteunen. Voorbeeld de courante elicitatie-techniek Workshop kan door de elicitatie-technieken Prototyping, scenarios en brainstorming ondersteund worden.
Voor de activiteiten “eliciteren” en “specificeren”, heb ik een uitgebreide checklist Requirements gevonden van de template van Volere, die onderverdeeld is in 5 thema’s: Product drivers Project beperkingen functionele eisen Niet-functionele eisen Project issues Ik heb dit omgezet in het RE patroon van Volere volgens de 3 niveaus: Thema’s van de Requirements Categorie Requirements Subcategorie Requirements Voorbeeld hier is thema “niet-functionele” die we kunnen onderverdelen in categorie requirements “Look and Feel” en “Veiligheid” waarbij categorie “Veiligheid” nog verder kunt onderverdelen in subcategorie requirements “Toegang” en “Privacy”.
De prototypes moeten aan de volgende eisen voldoen : de prototypes moeten de RE patronen hebben die uitgebreide requirementstypen bevatten ; de inhoud van de prototypes moet gemakkelijk aan te passen zijn ; de prototypes moeten gemakkelijk uit te breiden zijn ; de output van de checklijst “Requirements” moet in elk geval XML-formaat hebben zodat het gemakkelijk overdraagbaar is naar andere systemen (zoals bijvoorbeeld e-Procurement of Word) ; de checklijst requirements moet standaard terminologie en gestandaardiseerde formaten van data bevatten ; de prototypes moeten geschikt zijn voor meertaligheid ; de prototypes moeten webgebaseerd zijn, zodat het gemakkelijker toegankelijk kunnen gemaakt worden voor iedereen.
Mijn aanpak was om tot de requirements te komen, heb ik de RE patronen geïmplementeerd in de volgende prototypes: De portaalsite Specification : is een verzameling van verschillende diensten waarin de verschillende checklijsten bevinden van o.a. checklist requirements van Volere en het framework courante elicitatietechnieken. Het webformulier requirements is een eigen ontwikkelde webformulier volgens de template van Volere, dat dynamisch requirements selecteert en of tekst toevoegt. In deze afbeelding zie je een mogelijk infrastructuur van de prototypes en e-Procurement. Dit is wel één van de mogelijke oplossing want er kunnen nog andere oplossingen zijn afhankelijk van de business services. Deze beide prototypes kunnen toegankelijk gemaakt worden op het Internet en het webformulier is ook toegankelijk via de portaalsite “Specification” en mogelijk ook via de module e-Notification van e-Procurement.
De output van het webformulier requirements is XML- of pdf-bestand die je manueel kan plaatsen in de samenwerkingstool van e-Notification. Eventueel kan dit geautomatiseerd worden dat het xml of pdf-bestand geplaatst kan worden in e-Notification (dit is afhankelijk van de interface en security). Wel is zo dat het XML-bestand gemakkelijk overdraagbaar is naar andere systemen. De geselecteerde requirements die in xml-bestand zitten, kunnen ook hergebruikt worden Enerzijds voor e-Tendering waar de kandidaat leverancier kan aanduiden welke requirements men kan voldoen En anderzijds voor de gunningscriteria die men kan instellen in e-Awarding.
In de afbeelding wordt een overzicht gegeven van de verschillende actie stappen in het webformulier die men moet doorlopen om tot het resultaat te komen in het XML en/of pdf bestand. De resultaten in deze bestanden worden als wensen en eisen op basisniveau gedefinieerd om later uit te werken na een top-down analyse. De output van het webformulier “Requirements” is gemakkelijk overdraagbaar naar andere systemen (zoals bijvoorbeeld e-Procurement of Word).
De portaalsite is opgebouwd met een CMS-tool dat bestaat uit 2 delen: de frontoffice is dat deel van de site wat de bezoeker ziet en waar de content wordt geprojecteerd ; de backoffice is dat deel van de site waar de content wordt beheerd. In de afbeelding wordt een overzicht gegeven van de functionaliteiten (login, creëert en wijzigt de webpagina, kies template, settings properties, …) van de backoffice van een cms-tool. De checklijst “Requirements” en het framework “elicitatie-technieken” die de RE patronen bevatten worden geüpload in de backoffice van het CMS-tool om op de juiste webpagina geplaatst te worden.
In de afbeelding wordt de architectuur van de frontoffice van de portaalsite “Specification” weergegeven. De indeling zijn de “ Diensten”: helpdesk, e-Procurement en adviesbureau (diensten die je kan helpen om lastenboek op te stellen. “ Checklijsten”: de RE patronen van de checklijst “Requirements” en het framework “elicitatie-technieken” worden gecategoriseerd in de checklijsten. “ Forum” waar men gerichte vragen kan stellen en waar men geschikte antwoord kan ontvangen. Later kan de meest voorkomende vragen in een FAQ gegooid worden. “ Voorbeelden”: hier worden reële lastenboeken geplaatst die als goede referentie kan gebruikt worden. “ Contact”: personen aan wie men kan contacteren voor aanpassing van de site of inhoudelijke vragen kan stellen.
Om de RE patronen te valideren heb ik in minder of meerdere mate 6 specialisten geïnterviewd die uit de volgende organisaties komen : De Federale Overheidsdienst Personeel en Organisatie (P&O) Ondersteuning bieden en begeleiden van Belgische federale overheidsdiensten zodat ze doeltreffend en efficiënt kunnen bijdragen tot de welvaart en het welzijn van de burger. Fedict – de Federale Overheidsdienst Informatie- en Communicatietechnologie - is opgericht in mei 2001 en werd operationeel in 2002. Zorgen voor de uitwerking en opvolging van e-government en biedt hulp aan de federale overheidsdiensten om hun dienstverlening aan burgers, ondernemingen en ambtenaren te verbeteren met behulp van vernieuwende informatie- en communicatietechnologie (ICT).
Deze zijn de minder experten voor het opstellen van de lastenboeken waar de onderzoeker vooral hun ervaring (en problemen) opnam betreft het opstellen van het lastenboek. -> deze geïnterviewden hadden gemiddeld 5-tal lastenboeken opgesteld Adviseur van directie-generaal Organisatie- en personeelsontwikkeling (DG OPO) Procedure: Onderhandelingsprocedure met voorafgaande bekendmaking Fase van de overheidsopdracht: In de selectiefase van de aankoop Expert kennismanagement van de dienst kennismanagement & interne communicatie Procedure: Onderhandelingsprocedure zonder bekendmaking Fase van de overheidsopdracht: Software is in productie (er is nu een vervolgsessie voor een nieuw contract van 4 jaar) ICT verantwoordelijke van Opleidingsinstituut van de Federale Overheid (OFO) Procedure: Onderhandelingsprocedure zonder bekendmaking Fase van de overheidsopdracht: Software is in productie
Deze zijn de grote experten voor het opstellen van de lastenboeken waar de onderzoeker vooral nuttige tips kreeg betreft het opstellen van lastenboeken. -> deze geïnterviewden hadden elk gemiddeld 20 à 40-tal lastenboeken opgesteld Aankoper van Federale Overschrijdende Raamcontracten (FOR) Procedure: Openbare aanbesteding Fase van de overheidsopdracht: Contract is operationeel tot 15 juni 2013 Verantwoordelijke van E-procurement Procedure: Onderhandelingsprocedure met bekendmaking Fase van de overheidsopdracht: Software is in piloot Directeur-generaal systeem architectuur, standaarden en support bij Fedict Procedure: Onderhandelingsprocedure met bekendmaking Fase van de overheidsopdracht: Het lastenboek is in de laatste fase van de opstelling, normaal voorziene planning van publicatie is eind april 2012
Na analyse van de interviewresultaten kan men tot de conclusie komen dat de meest gebruikte elicitatie-technieken vooral : Het raadplegen van (vak)literatuur Het deelnemen aan of organiseren van workshops om te brainstormen Het afnemen van interview Het raadplegen van voorgaande lastenboek Het uitvoeren van enquêtes Netwerken van conferenties of forums Verklaring van de gebruikte elicitatie-technieken : Elicitatie-techniek “ het raadplegen van (vak)literatuur ” wordt veel gebruikt omdat het gemakkelijk toegankelijk is zonder veel inspanning of niet afhangt van anderen. Elicitatie-techniek “ het deelnemen aan of organiseren van workshops om te brainstormen ” wordt vooral toegepast wanneer de aankoop of het gebruik van het softwarepakket een grote impact heeft voor de dienst of organisatie. Hierdoor worden meer medewerkers betrokken binnen de dienst of organisatie. Elicitatie-techniek “ het afnemen van interview ” wordt vooral gebruikt als bepaalde informatie nodig is, waarbij de medewerker met ervaring of kennis ter zake de juiste informatie geeft voorbeeld juristen Elicitatie-techniek “ het raadplegen van voorgaande lastenboek ” wordt vooral gebruikt als dit lastenboek bestaat en een vervolglastenboek zal worden opgesteld a.d.h.v. het voorgaande lastenboek dat als basis dient met een aanpassing volgens de hedendaagse markt Elicitatie-techniek “ het uitvoeren van enquêtes ” wordt minder gebruikt ter voorbereiding voor het opstellen van het lastenboek omdat deze techniek meestal wordt gebruikt als tevredenheidsenquête over het gebruik of de levering van services van (soortgelijke) softwarepakket. Elicitatie-techniek “ netwerken van conferenties of forums ” wordt vooral toegepast als een grote impact heeft voor de dienst deze aankoop of gebruik van de services van het softwarepakket.
De requirements in de lastenboeken werden geanalyseerd en eventueel nog bijkomende vragen gesteld tijdens de interviews. Ik ben tot de volgende conclusie gekomen : De meeste requirements van de onderzochte lastenboeken zijn terug te vinden in de template van Volere. De andere requirements die niet in de template van Volere terug te vinden zijn : de vereisten voor Cloud (vb. overdracht van gegevens, waar de gegevens moeten opgeslagen zijn, …) de vereisten i.v.m. ITIL (vb. change management, incident management proces, …) de criteriums in SLA vereiste expertise en certificaten van de leveranciers Requirements van verschillende types zijn terug te vinden in het template van Volere, dit zijn o.a. : Product drivers Functionele eisen Niet functionele eisen Project issues De requirements van het type “project beperkingen” werd niet vermeld in de onderzochte lastenboeken. Begrippen : Cloud computing : Cloud computing is een model dat het mogelijk maakt om door middel van een computernetwerk gedeelde configureerbare computermiddelen (zoals netwerken, servers, opslag, applicaties en diensten) op aanvraag beschikbaar te stellen op een snelle, gemakkelijke en alomtegenwoordige manier met minimale beheer of interactie van een serviceprovider. ITIL : Information Technology Infrastructure Library is ontwikkeld als een referentiekader voor het inrichten van de beheerprocessen binnen een ICT-organisatie. ITIL is geen methode of model, maar eerder een reeks van best practices (de beste praktijkoplossingen) en concepten. SLA : Een Service level agreement (Serviceniveau-overeenkomst) - Dienstenniveau-overeenkomst (DNO) of Product level agreement (PLA), is een type overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product. De inhoud van een SLA bevat o.a. een beschrijving van de te leveren diensten (functionaliteit van de diensten, prestatie-eisen, restricties, max. aantal gebruikers, max. aantal transacties, …) Prince2 : PRINCE2 (PRojects IN Controlled Environments) is een gestructureerde methode voor projectmanagement. Deze methode is gericht op het management, de besturing en de organisatie van een project. PRINCE2 is ontwikkeld en wordt onderhouden door de Britse semi-overheidsorganisatie Office of Government Commerce (OGC)
Men kan de volgende conclusies trekken van de RE patronen in de prototypes: op structureel gebied zal weinig aanpassing vergen, buiten het uitbreiden van het aantal thema’s, categorieën en subcategorieën van de Requirements in het webformulier “Requirements”; op inhoudelijk vlak moeten nog verder worden aangevuld en verder onderzoek moet gebeuren over de integratie van de checklijst van Requirements in het webformulier “Requirements”. de voordelen van deze aangereikte RE patronen in de prototypes zijn door de requirementstypen in de databank te zetten, kunnen ze op een gemakkelijke manier worden aangevuld of aangepast aan de behoefte van de innovatieve markt; het gebruik van een gestandaardiseerde terminologie (zoals ITIL, Prince2, enz.), zodat er geen misverstanden ontstaan met de kandidaat leveranciers, waardoor de kans dat de betreffende overheidsinstelling een correcte prijsofferte ontvangt, toeneemt; door de topdown-analyse is de kans om belangrijke vereisten te missen minimaal.
Integratie van prototypes met andere e-Procurement tools De onderzochte applicatie-architectuur van e-Procurement is E-PPS, de andere e-Procurement tools zijn Tenderned en Coupa Software. Verbetering van de RE patronen voor e-Procurement Een inhoudelijke uitbreiding van het RE patroon van de checklijst “Requirements”: requirements in Cloud, criteria in SLA voor software in Cloud, andere domein zoals hardware, meubels, onderhoudsproducten, enz. Een gebruikersonderzoek van de RE patronen via de voorgestelde prototypes waarin de RE patronen geïmplementeerd zijn. Andere RE technieken voor e-Procurement In dit onderzoek is de requirements engineering methode “modelleren” tijdens het opstellen van het software-gerelateerde lastenboek niet onderzocht, wat echter wel interessant zou zijn te onderzoeken. Een onderzoektitel zou kunnen zijn “Modellering tijdens het opstellen van lastenboeken”. Een onderzoek naar een bestaande requirementstool die geschikt kan zijn als hulpmiddel voor het opstellen van lastenboeken voor overheidsopdrachten.
De algemene conclusie dat in deze onderzoek kan trekken, zijn : De meest uitgebreide RE patroon van checklijst Requirements is niet volledig voor e-Procurement. Er waren een aantal requirementstypen die niet aanwezig waren zoals ITIL, SLA, typische requirements van Cloud, enz. De patronen kunnen gekristalliseerd worden in de loop der tijd op de basis van de eerste prototype . Mijn bijdrage over dit onderzoek is implementatie van patronen als een eerste prototype bepalen van de plek van de patronen in de e-Procurement architectuur start van de eerste evaluatie van de ontworpen patronen
Om terug te keren naar het probleem van het Kinddossier waarbij de regels van transparantie en zorgvuldigheid met de voeten werden getreden, dit probleem kan worden voorkomen door mijn aanpak voor het opstellen van requirements toe te passen : volgens de topdown-analyse van de requirements is de kans om belangrijke vereisten te vergeten minimaal; door gebruik te maken van gestandaardiseerde terminologie wordt een eenduidige formulering gegeven die voor de kandidaat leveranciers begrijpelijk is, zodat er geen misverstanden kunnen ontstaan.
Mijn persoonlijke lessen die ik heb geleerd kan je hier lezen. Kortom voor mij was een verrijkende ervaring
