• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements
Requirements
Belanghebbenden (stakeholders) bij softwareontwikkeling
Gepubliceerd in Requirements
E-mail Afdrukken

Stakeholders bij softwareontwikkeling

Nicole de Swart definieert de belanghebbenden (stakeholders) bij een softwareontwikkeltraject als de personen of organisatie(onderdelen) die beïnvloed wordt door of zelf invloed kunnen uitoefenen op de uiteindelijke werking van het systeem en stelt dat belanghebbenden en requirements onlosmakelijk met elkaar verbonden zijn: belanghebbenden zijn de bron voor de requirements en bepalend voor de behoeften en eisen die vanuit de business aan het te ontwikkelen systeem worden gesteld.

De Swart maakt een onderverdeling in drie hoofdgroepen belanghebbenden (op basis van het verschil in belang dat men heeft):

  1. Belanghebbenden bij het businessdoel: belang bij het verbeteren van de interne bedrijfsvoering of bij het op de markt brengen van een nieuw softwareproduct. Bijv. opdrachtgever en/of sponsor.

  2. Belanghebbenden bij het systeem: belang bij, nadat het geautomatiseerde systeem is ingevoerd, de werking van het systeem, in de zin dat ze voordelen óf nadelen kunnen nadeel ondervinden van de invoering van het nieuwe systeem. Bijv. gebruikers, 'systeemondersteuners' (beheerders, helpdesk), 'autoriteiten' (juridische afdeling, IT-auditoren).

  3. Belanghebbenden bij het project: werken vaak mee aan de totstandkoming van het systeem en hebben tijdens het project en vaak ook daarna nog, als het systeem in beheer is genomen, invloed op de werking van het systeem. Bijv. projectteam, ICT-afdeling, gebruikersvoorbereiders (verandermanagers, opleiders, opstellers gebruikershandleiding)

Bron: Handboek Requirements (2010), Nicole de Swart en http://www.reaco.nl/handboekRequirements/praktischeHandvatten/ChecklistBelanghebbenden.pdf

Laatst aangepast op donderdag, 11 januari 2018 19:32  
Requirements volgens RUP
Gepubliceerd in Requirements
E-mail Afdrukken

Requirements binnen RUP

 

De systeemontwikkemethode Rational Unified Process (RUP) is onderverdeeld in negen disciplines onderscheiden. Requirements is één deze disciplines. Requirements als discipline maakt onderscheid tussen drie typen requirements en positioneert ze ten opzichte van elkaar in een piramide. Het volume van de piramide representeert het aantal requirements van een bepaald type.RUP plaatst requirements in het probleem- en oplossingsdomein. De needs vormen de zgn. businessrequirements. De features en de softwarerequirements gaan over de behoeften en eisen ten aanzien van het systeem. Ondanks het feit dat binnen de piramide geen gebruikersrequirements voorkomen, onderkent RUP wel use cases. Deze worden gepositioneerd bij de softwarerequirements. De reden hiervoor is dat de use cases de softwarerequirements in context plaatsen.

Binnen RUP worden zes activiteiten onderscheiden om requirements op te stellen:Binnen de discipline Requirements worden twee rollen onderkend die verantwoordelijk zijn voor het vastleggen van de functionele en niet-functionele eisen: (1) de informatie-analist, en (2) de Use Case ontwerper.

  1. Analyseer het probleem: welk probleem moet worden opgelost?

  2. Begrijp de behoeften (needs) van de belanghebbenden: wat wil men met het systeem bereiken?

  3. Defineer het systeem: onderkennen use cases + afbakenen van het systeem

  4. Manage de scope van het systeem: prioriteer features en use cases en bepaal de scope van de eerstvolgende iteratie

  5. Verfijn de systeemdefinitie: specificeer use cases + aanvullende requirements op het gewenste detailniveau

  6. Manage de veranderende requirements: analyseer impact van voorgestelde wijzigingen in de baseline + besluit

De rol van de informatieanalist (binnen RUP) is verantwoordelijk voor het helder krijgen van requirements en het modelleren van Use Cases, waardoor hij de functionaliteit en grenzen van het te bouwen systeem bepaalt en bewaakt. De Use Case ontwerper is verantwoordelijk voor het specficeren van Use Cases, inclusief schermontwerpen en schermverloop.

Bron: Handboek Requirements (2010), Nicole de Swart, en RUP op Maat (2008), Eef Dekker en Remi-Armand Collaris

 

Laatst aangepast op donderdag, 11 januari 2018 19:25  
Kwaliteitseisen (ISO 9126) en niet-functionele requirements
Gepubliceerd in Requirements
E-mail Afdrukken

Iso 9126

De niet-functionele (software)requirements zijn de kwaliteitseisen waaraan een systeem moet voldoen. De ISO 9126 standaard (ISO, 2001) bevat een checklist met kwaliteitseigenschappen voor het opstellen van de niet-functionele requirements. De checklist omvat zes hoofdeigenschappen met daarbinnen subeigenschappen.

(1) Functionaliteit: hoe goed moet het systeem de gewenste ondersteuning leveren?

  • Juistheid
  • Geschiktheid
  • Naleving voorschriften
  • Beveiligbaarheid
  • Koppelbaarheid

(2) Betrouwbaarheid: in welke mate moet het systeem zonder verstoringen functioneren?

  • Bedrijfszekerheid
  • Foutbestendigheid
  • Herstelbaarheid

(3) Bruikbaarheid (usability): hoe eenvoudig moet het systeem te gebruiken zijn?

  • Begrijpelijkheid
  • Leerbaarheid
  • Gebruiksgemak
  • Aantrekkelijkheid

(4) Efficiency: hoe snel moet het systeem haar taken uitvoeren en hoeveel middelen mogen hierbij gebruikt worden?

  • Snelheid
  • Middelenbeslag

(5) Onderhoudbaarheid: hoe eenvoudig moet het zijn om het systeem aan te passen?

  • Wijzigbaarheid
  • Analyseerbaarheid
  • Stabiliteit
  • Testbaarheid

(6) Overdraagbaarheid (portabiliteit): in welke mate moet het systeem naar een andere omgeving overgezet kunnen worden?

  • Aanpasbaarheid
  • Installeerbaarheid
  • Gezamenlijkheid
  • Inpasbaarheid

Nicole de Swart geeft in onderstaande documenten (PDF formaat) voor alle kwaliteitseigenschappen een definitie (incl. voorbeelden en 'elicitatievragen' waarmee business analisten niet-functionele requirements concreet en tastbaar kunnen maken vor belanghebbenden):

Bij het opstellen van niet-functionele requirements is het van belang dat de business analist zoekt naar de belangrijkste kwaliteitseigenschappen. Volgens De Swart zijn in de praktijk vaak niet meer dan vijf tot acht kwaliteitseigenschappen echt belangrijk zijn voor een ICT-systeem en is het (dus) overbodig om voor alle kwaliteitseigenschappen niet-functionele requirements op te stellen: "Dat zou veel tijd kosten, weinig toegevoegde waarde opleveren en een saaie exercitie worden". De Swart stelt van elk systeem een bepaalde basiskwaliteit verwacht mag worden (bijv. het feit dat op schermen de responsetijd enkele seconden en niet enkele minuten mag zijn) en is het alleen nodig de 'bovengemiddeld zware en belangrijkste' niet-functionele requirements te specificeren.

Bron: Handboek Requirements (2010), Nicole de Swart en http://www.handboekrequirements.nl/non-functional-requirements/

Zie ook het artikel Softwareproductkwaliteit van Danny Greefhorst en Gert Florijn in Informatie.

 

Laatst aangepast op vrijdag, 29 december 2017 22:15  
Requirements binnen softwareontwikkeling
Gepubliceerd in Requirements
E-mail Afdrukken

What customer really needed

Bij het opstellen van requirements gaat het erom overeenstemming te bereiken over een set requirements, de zgn. baseline. De wijze waarop deze baseline tot stand komt, is afhankelijk van het gekozen ontwikkelproces.

(1) Ontwikkelen volgens waterval-methode

Bij toepassing van de waterval-methode worden alle requirements in één keer aan het begin van het traject opgesteld, goedgekeurd en opgenomen in de baseline. Voor de start van het systeemontwerp en de realisatie zijn alle requirements bekend.

(2) Iteratief ontwikkelen

Bij een iteratief ontwikkelproces worden aan het begin van het traject aleen globale requirements opgesteld, goedgekeurd en opgenomen in de baseline. Het detailleren van de requirements gebeurt (net) voorafgaand aan de iteratie. Deze requirements worden tijdens de iteratie geïmplementeerd.

(3) Agile

In een agile-ontwikkeltraject worden voorafgaande aan de iteratie alleen globale requirements goedgekeurd en opgenomen in de baseline (product backlog genoemd). Detaillering en implementatie van de requirements vindt plaats tijdens de iteraties.

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op zondag, 28 januari 2018 09:05  
Een requirement als use case
Gepubliceerd in Requirements
E-mail Afdrukken

Use case

Volgens De Swart kan een use case worden beschouwd als een requirements aangezien een use case aangeeft welke geautomatiseerde ondersteuning gewenst is. Een use case representeert namelijk de geautomatiseerde ondersteuning aan een gebruiker bij de uitvoering van een procestaak.

Een use case levert een resultaat dat zelfstandig waarde heeft voor de gebruiker en geeft aan hoe de gebruiker en het systeem samenwerken om dat resultaat te behalen. Elke use cases bestaat uit een verzameling requirements die gezamelijk nodig zijn om het gewenste resultaat te realiseren.

De use case techniek is een techniek om requirements te specificeren vanuit het businessperspectief. Een use case geeft aan hoe het systeem en de gebruiker samenwerken om een eindresultaat te halen dat waarde heeft voor de gebruiker. Alle acties van het systeem en de gebruiker die nodig zijn om het doel van de gebruiker te halen, zijn gegroepeerd tot een use case.

De Swart definieert use cases als een verzameling gedetailleerde requirements die samen een logisch geheel vormen van opeenvolgende acties die leiden tot een resultaat dat waarde heeft voor de gebruiker.

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op zondag, 28 januari 2018 09:06  
Requirementsmodel De Swart
Gepubliceerd in Requirements
E-mail Afdrukken

Requirementsmodel Nicole de Swart

De term requirements is een volgens De Swart een verzamelnaam voor allerlei typen systeemeisen en voor de behoeften aan geautomatiseerde ondersteuning van belanghebbenden uit de business. In haar 'Handboek requirements' beschrijft zij een requirementsmodel waarbij zij zich baseert op een analyse van de bonte verzamelingen aan typeringen die binnen het vakgebied Requirements engineering van requirements worden gegeven.

In het requirementsmodel onderscheidt De Swart twee perspectieven: het systeemperspectief, met daarin de softwarerequirements, en het business perspectief, met daarin de business requirements en de gebruikersrequirements.

Het systeemperspectief: functionele en niet-functionele software requirements

Het systeemperspectief gaat over de eisen die vanuit de business aan het systeem worden gesteld, waarbij het gaat om requirements van het type softwarerequirements. De Swart definieert softwarerequirements als het gedrag (functionaliteit) of kwaliteit die het systeem moet bezitten om in een behoefte te voorzien van een belanghebbende uit de business. Het gaat dus om systeemeisen die voortkomen uit behoeften van de business (bijvoorbeeld: het systeem moet maximaal twee seconden nadat de klant een zoekopdracht heeft gegeven de lijst met gevraagde hotelkamers tonen).

Softwarerequirements kunnen worden onderverdeeld in functionele requirements en niet-functionele requirements. Bij functionele requirements gaat het om het gewenste gedrag (functionaliteit) van het systeem. Het gaat hierbij om van buitenaf waarneembaar gedrag en niet om de interne werking van het systeem. Functionele requirements beschrijven de input die het systeem nodig heeft, de output die het systeem levert en dategene wat ervoor nodig is om de input om te zetten in output, oftewel de systeemfuncties.

De Swart definieert functionele softwarerequirements als het gedrag (functionaliteit) dat een systeem moet vertonen om in een behoefte te voorzien van een belanghebbende uit de business. Functionele requirements komen op verschillende detailniveaus voor. Globale functione requirements geven op hoofdlijnen het gedrag van het systeem weer (bijv. het systeem moet continu actuele statusinformatie geven). Om de software te kunnen ontwikkelen die voldoet aan de behoeften van de business zijn gedetailleerde(re) requirements nodig. Dit kunnen acties zijn die het systeem moet uitvoeren in specifieke situaties en de wijze waarop het systeem bij bepaalde fouten moet reageren.

Niet-functionele requirements zijn de aan het systeem gestelde kwaliteitseisen. Deze eisen hebben betrekking op het systeem als geheel of op een specifieke functie van het systeem; ze geven aan hoe goed het systeem moet werken. De Swart definieert niet-functionele requirements als kwaliteitseisen waaraan het systeem moet voldoen om in een behoefte te voorzien van een belanghebbende uit de business.

Het businessperspectief: business- en gebruikersrequirements

Binnen het businessperspectief gaat het om de behoeften van de business om processen te ondersteunen met geautomatiseerde systemen. Het businessperspectief omvat twee typen requirements: business requirements en gebruikersrequirements. Het businessperspectief voegt aan het systeemperspectief toe 'waarom' het systeem gewenst (business requirements) is en 'wat' voor proces of activiteit het systeem moet ondersteunen (gebruikersrequirements).

Business requirements geven aan welke toegevoegde waarde het systeem moet leveren aan de business. Het systeem is voor de business immers geen doel op zich. De opdrachtgever wil met het systeem een businessdoel realiseren. Heldere business requirements zijn nodig om de kans te vergroten dat een te ontwikkelen systeem daadwerkelijk bijdraagt aan de beoogde doelen. Doelen zijn altijd op te splitsen in subdoelen en ieder doel is ook onderdeel van een hoger liggend doel. Het hoger liggende doel is te achterhalen door te vragen waarom iemand een bepaald doel wil bereiken. Subdoelen zijn te achterhalen door te vragen hoe iemand een bepaald doel wil realiseren. De business requirements bepalen welke gebruikers- en welke softwarerequirements relevant zijn. Requirements die niet bijdragen aan de realisatie van business requirements vallen buiten de scope.

De Swart definieert business requirements als een verbetering in een bestaand proces of een nieuw proces die een belanghebbende uit de business met het systeem wil realiseren (bijvoorbeeld een opdrachtgever die producten via het internetkanaal wil aanbieden). De meeste procesverbeteringen zijn slechts gedeeltelijk met een geautomatiseerd systeem te realiseren. Vaak gaat het om een combinatie van handmatige en geautomatiseerde acties om een proces uit te voeren.

Gebruikersrequirements geven aan op welke manier de business requirements gerealiseerd worden. Ze geven aan welke werkzaamheden door het systeem uitgevoerd of ondersteund moeten worden (bijv. hotelgast wil kamer laten zoeken op basis van ingevoerde selectiecriteria). De Swart definieer gebruikersrequirements als een proces (of subproces of taak of activiteit) die de gebruiker met behulp van het systeem wil uitvoeren. Gebruikersrequirements komen op meerdere detailniveaus voor: ondersteuning van een bedrijfsproces, subproces, procestaak of activiteit. Volgens De Swart hebben gebruikersrequirements de voorkeur bij systemen met veel gebruikersinteractie. Functionele softwarerequirements liggen meer voor de hand bij systemen waarbij zich het belangrijkste deel van de functionaliteit buiten het gezichtsveld van de gebruikers afspeelt (bijv. bij batchprocessen)

typen requirements requirementsmodel Nicole de Swart

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op donderdag, 11 januari 2018 19:25  
Functionele vs. niet-functionele requirements
Gepubliceerd in Requirements
E-mail Afdrukken

Requirementsspecificatie vs. functioneel ontwerp

Een veelgebruikte onderverdeling van requirements is het onderscheid in functionele en niet-functionele requirements. Een functionele requirement geeft gewenst gedrag van het systeem weer, terwijl niet-functionele requirements een kwaliteitseis is waaraan het systeem moet voldoen.

Volgens De Swart moet onderscheid gemaakt worden tussen een functionele requirement en een gewenste systeemfunctie. Een functioneel requirement stelt een eis aan het gedrag van een systeem, terwijl een systeemfunctie dat gedrag zélf representeert.

"Een systeemfunctie zet invoer van het systeem om in uitvoer. De actie die het systeem hiervoor uitvoert is de systeemfunctie ofwel het gedrag van het systeem. Een traditioneel functioneel ontwerp is een ontwerp van de gewenste (niet-technische) systeemfuncties en de benodigde systeeminvoer en -uitvoer."

Volgens De Swart impliceert het verschil tussen systeemfuncties en functionele requirements dat een functioneel ontwerp vervangen wordt door een requirementsspecificatie: eisen kun je namelijk niet ontwerpen. De business stelt eisen aan het systeem en een requirements moet deze eisen expliciet maken door ze te specificeren in de zgn. requirementsspecificatie.

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op vrijdag, 29 december 2017 22:14  
Veranderende requirements
Gepubliceerd in Requirements
E-mail Afdrukken

Veranderende requirements

De Swart stelt dat het logisch en onvermijdelijk is dat requirements tussentijds wijzigen. Volgens haar is het idee achter de waterval-aanpak dat eenmaal opgestelde requirements voor de rest van het traject bevroren kunnen worden achterhaald.

In de woorden van De Swart:

"De business en de gewenste ondersteuning daarvan door het systeem staan niet stil tijdens de looptijd van het softwareontwikkelingstraject. Daarnaast is het optreden van voortschrijdend inzicht bij de betrokken gebruikers een normaal verschijnsel. Het managen van de wijzigende requirements voorkomt het zo gevreesde verschijnsel scope creept waarbij de omvang van de te ontwikkelen software ongemerkt of ongecontroleerd blijft toenemen. Hiervoor moet het ontwikkelteam inzicht hebben in de wijzingen, de actuele versie en de status van de requirements."

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op zondag, 28 januari 2018 09:07  
Nut en noodzaak van requirements
Gepubliceerd in Requirements
E-mail Afdrukken

nut en noodzaak van requirements

Volgens De Swart zijn requirements buitengewoon belangrijk voor succesvolle softwareontwikkeling. Zij citeert in dit verband Karl Wiegers: "Als het niet lukt om de requirements te achterhalen, maakt het ook niet uit meer hoe goed je de overige activiteiten uitvoert" en stelt dat inconsistente, ontbrekende en foutieve requirements doorwerken in vrijwel alle softwareontwikkelactiviteiten.

Fouten die tijdens het opstellen van requirements worden ontdekt en hersteld kosten volgens De Swart vijf tot tien keer minder dan dezelfde fout die tijdens realisatie wordt ontdekt en hersteld. Als die fout pas na ingebruikname zou zijn ontdekt, zouden de herstelkosten 200 keer zoveel zijn dan tijdens het opstellen van de requirements (zie ook Wet van Boehm).

De Swart is van mening dat problemen binnen softwareontwikkeling vaak te maken hebben met requirements, waarbij de oorzaak vaak ligt bij: (a) gebrekkige kwaliteit van de specificatie van requirements, (b) wijzigingen in de requirements, en (c) gebrek aan gebruikersinbreng. Deze problemen zijn te vertalen naar drie kritieke succesfactoren voor softwareontwikkeling:

  1. Kwalitatief goede requirementsspecificaties: volledigheid, consistentie, eenduidigheid, bijdragend aan bedrijfsdoel ('validiteit')

  2. Managen van wijzigingen in de requirements

  3. Voldoende gebruikersinbreng

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op donderdag, 11 januari 2018 19:31  
Requirements engineering
Gepubliceerd in Requirements
E-mail Afdrukken

Requirements engineering

Requirements engineering gaat over het definiëren, documenteren en onderhouden van requirements gedurende de levenscyclus van de ontwikkeling van een informatiesysteem. Requirements engineering is een iteratief proces. Eerst moeten de business requirements worden ontwikkeld en vastgesteld ('gebaselined'), vervoglens vormen de business requirements input voor het ontwikkelen van requirements op gebruikersniveau. Hierbij kan het nodig zijn de business requirements aan te vullen en/of verder te verfijnen.

Requirements engineering wordt onderverdeeld in: (1) requirements development, en (2) requirements management.

Requirements development omvat alle activiteiten voor het identificeren en vastleggen van requirement en het vervolgens bereiken van overeenstemming over de requirements.

Volgens De Swart is het doel van requirements engineering het tot stand brengen en in stand houden van overeenstemming tussen de opdrachtgever, medewerkers en de softwareontwikkelaars over de requirements. Requirements development richt zich op het tot stand brengen van de overeenstemming.

Requirements development omvat alle activiteiten die problemen, kansen en behoeften omzetten naar een overeengekomen set aan requirements, de zgn. baseline. Anders gezegd gaat het om de activiteiten die nodig zijn om nieuwe requirements aan de baseline toe te voegen. Het begint bij het in kaart brengen van globale requirements, waarna de requirements tot op het gewenst detailniveau worden gespecificeerd. De gedetailleerde requirements in de baseline dienen bij een waterval- of iteratief ontwikkeltraject als basis voor de realisatie van het systeem.

Bij het specificeren van requirements dreigt volgens De Swart altijd verlammingsgevaar (analysis paralysis): de specificaties van requirements zijn nooit perfect, het kan altijd beter, completer en duidelijker. Het risico is dus dat je té lang doorgaat met het perfectioneren van beschreven requirements. Requirements development streeft naar requirementsspecificaties die 'goed genoeg' zijn om met een aanvaardbaar risico te starten met het realiseren van het systeem. Het risico bestaat in dit verband uit de kosten voor en het uitvoeren van herstelwerkzaamheden bij fouten in reeds goedgekeurde specificaties. De kwaliteit van de requirementsspecificaties is hoog genoeg, zodra de kosten voor het nog verder verhogen van de kwaliteit van de requirementsspecificaties niet meer opwegen tegen de verwachte herstelkosten later in het traject.

Volgens De Swart zijn 'de requirements in de baseline namelijk niet in beton gegotenen geldt: "Hoewel de requirements in de baseline zijn goedgekeurd en misschien zelfs al zijn geïmplementeerd, zijn wijzigingen daarin onvermiijdelijk. Dit komt omdat de wereld niet stil staat tijdens de ontwikkeling van het systeem." Als gevolg van wijzigingen in de omgeving en voortschrijdend inzicht, zullen namelijk gedurende de gehele cyclus van softwareontwikkeling wijzigingen plaats (moeten) vinden. Requirements management omvat alle activiteiten die nodig zijn om wijzigingen in de specificaties van de requirements in de baseline door te voeren. Doel hiervan is het gecontroleerd laten plaatsvinden van wijzigingen. De activiteiten met betrekking tot het omgaan met wijzigingen op requirements die 'gebaselined' zijn: het doen van wijzigingsverzoeken, het uitvoeren van impactanalyses en de besluitvorming over en invoering van goedgekeurde wijzigingen.

De Swart onderscheid vier processtappen, met daarbinnen specifieke activiteiten

Requirements development

(1) Positioneren van het systeem binnen het businessdomein

  • Analyseren van de business
  • Zoeken van belanghebbenden en gesprekspartners

(2) Definiëren van de gewenste oplossing

  • Vaststellen behoeften en eisen aan geautomatiseerde ondersteuning
  • Selecteren belangrijkste kwaliteitseigenschappen
  • Identificeren technische beperkingen
  • Afbakenen systeem

(3) Detailleren van de requirements

  • Vaststellen van door het systeem uit te voeren activiteiten
  • Vaststellen van benodigde kwaliteitsniveau van het systeem

Volgens De Swart zijn bij elk van de drie processtappen binnen requirements development vier subgebieden nodig:

[i] Elicitatie (expliciet maken van requirements)
[ii] Analyse (onderzoeken requirements op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid)
[iii] Specificatie (vastleggen van requirements, incl. meta-informatie)
[iv] Validatie (zekerstellen dat gespecificeerde requirements overeenkomen met behoeften van de business)

Requirements managmeent

(4) Beheren van de requirements

Volgens De Swart rust requirements management op vijf pijlers:

[a] Wijzigingsbeheer
[b] Versiebeheer
[c] Traceerbaarheid
[d] Metagegevens
[e] Managementoverzichten (inzicht in stand van de requirements in de baseline)

 

Bron:  Software Requirements Engineering: What, Why, Who, When and How (Linda Westfall), Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op donderdag, 11 januari 2018 19:32  


JPAGE_CURRENT_OF_TOTAL

What we call the beginning is often the end. And to make an end is to make a beginning. The end is where we start from.

T.S. Eliot

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 232 gasten online
Artikelen

measuring process performance management improvement roger tregear

Banner

effectief tijdbeheer ineke kievit

Effectief Tijdbeheer
Handleiding Voor Praktische Time- En Self-Management
Ineke E Kievit-Broeze

Bij Bol.com of Managementboek

Lean boekentips

Dagstarts en Hoshin Kanri
Continu Leren en Verbeteren in de juiste richting met Dagstarts en Hoshin Kanri
Bert Teeuwen

Bij Bol.com | Managementboek

Banner