• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Sturing en organisatie van ICT-voorzieningen volgens Thiadens
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

Thiadens

Volgens Theo Thiadens vormt de 'Sturing en Organisatie van ICT-voorzieningen' een vakgebied, dat bestaat uit drie deelgebieden: (a) Business/ICT-alignement: het afstemmen van de eisen van de organisatie op de ICT-mogelijkheden, (b) ICT-governance: de sturing van de organisatie van ICT, en (c) ICT-management: dagelijkse sturing van de functie, die zich met ICT in een organisatie bezighoudt, oftewel de ICT-organisatie.

(a) Business/ICT-alignement

Het doel van het sturen en de organisatie van ICT-voorzieningen is de realisatie van een zodanige ondersteuning van de processen in de organisatie door ICT, dat deze voldoet aan de functionele en prestatie-eisen, die door de betaler van de ICT-voorzieningen worden gesteld. Functionele eisen aan ICT-voorzieningen kunnen worden gesteld vanuit verschillende invalshoeken (bijv. gebruikers, keten, beheerders). Prestatie-eisen geven aan met welke kwaliteiten een dienst of product geleverd moet worden, bijv. de kwaliteitseisen vanuit de standaard ISO 9126.

De beoogde optimale ICT-ondersteuning is volgens Thiadens een bewegend doel, waarbij er altijd een kloof (gap) zal zijn tussen de wens van de organisatie en de ICT-ondersteuning. Het streven is moet dan ook zijn deze gap zo klein mogelijk te maken. Thiadens haalt in dit verband Luftman (2007) aan die stelt dat business/ict-aligment nooit optimaal is: er is nooit voor hander procent afstemming tussen de wensen van de organisatie en de ondersteuning door ICT. De afstemming is dynamisch en de aan deze afstemming gestelde eisen zijn voortdurend in ontwikkeling. Thiadens definieert Business/ICT-alignment dan ook als de mate waarin de inspanning van de vraag- en aanbodorganisatie van ICT zijn afgestemd op de doelen van de organisatie.

(b) ICT-governance

Thiadens definieert ICT-governance als het raamwerk van besluitvorming en verantwoordelijkheid in een organisatie of in een geheel van organisaties om het gewenste resultaat met ICT te realiseren. ICT-governance gaat over het sturen van ICT op het niveau van de organisatie. Sturing van ICT ontstaat als gevolg van beleid, processen en procedures. Deze zijn ontworpen om te verzekeren dat doelen bereikt worden en niet-gewenste gebeurtenissen worden voorkomen, ontdekt of gecorrigeerd. ICT-governance is volgens Thiadens onderdeel van Business/ICT-alignment.

Bij de inrichting van ICT-governance zijn er drie vragen cruciaal: Wie beslist? Waarover beslist men? Hoe vindt de besluitvorming plaats (structuren, afstemmingsprocesesn, communicatie)? Als het gaat om de onderwerpen waarover besluitvorming nodig is, onderscheidt Thiadens (zich baserend op Weil) vijf onderwerpen:

  • Principes achter ICT: beginselen bij de inzet van ICT
  • IV-/ICT-architectuur: logische organisatie van de informatievoorziening, haar ICT-infrastructuur en de nodige applicaties
  • ICT-infrastructuurbeleid: leveren van centraal afgestemde producten en diensten
  • Applicatiebehoeften: specificatie van de behoeften om toepassingen te ontwikkelen, beheren of aankopen
  • Prioriteitsstelling: omvang waarin en de plaats waarin in ICT wordt geïnvesteerd (incl. goedkeuring projecten)

(c) ICT-management

ICT-management betreft het managen van de ICT-organisatie. Deze ICT-organisatie kan een ICT-vraagorganisatie, een ICT-aanbodorganisatie of een combinatie van beide zijn. ICT-management stuurt taken aan op het gebied van exploitatie, ontwikkeling en onderhoud van ICT-voorzieningen. ICT-voorzieningen zijn te onderscheiden in voorzieningen op het terrein van infrastructuur en applicaties. ICT-management vindt plaats binnen het kader dat door ICT-governance is gezet, waarbij er ook andere kaders van toepassing zijn (bijv. hrm, financieel).

Instrumenten bij ICT-governance en ICT-management

Bij ICT-governance en ICT-managenent is overzicht nodig van de lopende en komende inzet van ICT. Een hulpmiddel hierbij is het werken met portfolio's. Door portfolio's te maken (en programma's van) projecten binnen portfolio's te rangschikken, ontstaat het gewenste overzicht.

Vraag-/aanbodorganisatie

Een ICT-organisatie heeft volgens Thiadens een vraag- en een aanbod-kant. De vraagkant wordt wel het functioneel beheer genoemd. Aan de aanbodkant treft men het applicatiebeheer en de exploitatie. Deze drie taken vormen tezamen het drievoudig model van beheer (Looijen).

Volgens Thiadens zijn er vier voorwaarden voor het effectief (kunnen) sturen van processen in een ICT-organisatie:

  1. Het doel van het proces moet duidelijk zijn

  2. Men moet een model hebben van het proces en haar omgeving

  3. Men moet de nodige informatie hebben om het proces te sturen

  4. Men moet over voldoende middelen beschikken om sturing te effectueren

Thiadens geeft aan dat er drie redenen zijn voor het inrichten van een vraagorganisatie:

  1. Helder communicatiekanaal met de aanbodorganisatie(s)

  2. Coördineren van afspraken met aanbodorganisatie over ICT

  3. Ondersteuning geven bij het gebruik van ICT

Het belang van het splitsen van vraag en aanbod zit volgens Thiadens vooral in het feit dat dit recht doet aan de klant/leverancier-relatie. Als de ICT-organisatie zowel gaat over de vraag als het aanbod ligt de rol van zowel klant als leverancier op één plaats. Hierdoor ontstaat een té grote rol bij prioriteitstelling voor ICT-producten en -diensten. Andere voordelen van de splitsing zijn dat een aparte vraagorganisatie voor een gebruiker van ICT vaak toegankelijker is dan een afdeling binnen een ICT-organisatie en dat de vraagorganisatie de focus kan leggen op functionaliteit, terwijl de aanbodorganisatie gefocused kan zijn op techniek.

De splitsing van vraag en aanbod leidt tot een regieorganisatie met drie kerntaken:

  1. Managen van het portfolio aan producten en diensten op strategisch niveau

  2. Planning & control van de processen aan de vraag- en aanbodzijde op tactisch niveau

  3. Functionaliteitenbeheer en de transitie van nieuwe of vernieuwde ICT-producten en diensten naar exploitatie op operationeel niveau

Thiadens gebruikt BiSL als methode voor het inrichten van de vraagorganisatie. BiSL kent op strategisch niveau taken voor het inrichten van de informatievoorziening en haar inhoud (toewijziging van taken op het terrein van informatiebeleid en de uitvoering ervan, bepalen van de inhoud van de informatievoorziening en haar ondersteuning door ICT, vernieuwing van het portfolio aan ICT-voorzieningen en het denken over de levenscyclus van afzonderlijke voorzieningen), op tactisch niveau zijn er taken voor planning, kosten, behoeftemanagement en contractmanagement. Op operationeel niveau zin er processen voor gebruiksbeheer (dag-in-dag-uit in productie houden van ICT-voorzieningen) en functionaliteitenbeheer (gepland veranderen van deze voorzieningen). Op tactisch niveau stuurt men de operationele processen aan.

Bron: Sturing en Organisatie van ICT-voorzieningen (2008), Theo Thiadens

Laatst aangepast op vrijdag, 17 november 2017 22:06  
Iteratief ontwikkelen met RUP (fasering, disciplines en iteraties)
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

Rup, fasering, iteraties en disciplines

Vier fasen

Een RUP-traject bestaat uit vier fasen:

  1. Inception: overeenstemming over scope, oplossing(srichting), eisen en wensen, belangrijkste risico's + tegenmaatregelen
  2. Elaboration: gedetailleerd beeld kritische requirements, stabiele architectuur in werkende code, kosten/planning + scope inzichtelijk

  3. Construction: functionaliteit gerealiseerd, product gereed voor Beta-testing, handleidingen/trainingsmateriaal gereed

  4. Transition: gerapporteerde bugs gefixed, gebruikers/beheerders getraind, voldaan aan acceptatiecriteria, evaluatie gehouden.

 

Negen disicipines

Er zijn negen disciplines die gedurende de duur van een project zullen voorkomen.

  1. Business modelling
  2. Requirement Engineering

  3. Analyse en ontwerp

  4. Implementatie

  5. Testen

  6. Deployment ('Put-into-Production')

  7. Project management

  8. Omgeving

  9. Configurate- en wijzigingenbeheer

De intensiteit waarmee een bepaalde discipline wordt uitgevoerd is vooral afhankelijk van de fase waarin het project zich bevindt. De 9 disciplines zijn verdeeld over twee hoofdgroepen: Ontwikkeling en Ondersteuning. De eerste zes discplines vallen onder Ontwikkeling. De laatste drie disciplines vallen onder Ondersteuning.

Iteraties

Een iteratie is een afgebakend, korte periode waarin een samenhangend hoeveelheid functionaliteit wordt ontworpen, gerealiseerd of geaccepteerd. Binnen RUP wordt in opeenvolgende iteraties van ontwerp (Use Case-ontwerp, Testontwerp en technisch ontwerp), realisatie (bouw en test), acceptatie (door de opdrachtgever) toegewerkt naar een steeds completer eindproduct. Een iteratie is een timebox, wat wil zeggen dat de tijdsduur vooraf vastligt. Het succes hangt volgens Dekker en Collaris af van de inrichting van het iteratieve proces.

Bron: RUP op Maat (2008), Eef Dekker en Remi-Armand Collaris

 

 

Laatst aangepast op maandag, 08 januari 2018 14:46  
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  
Prioriteringstechnieken
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

Prioritering

Binnen de context van requirements engineering onderscheidt De Swart vijf prioriteteringstechnieken:

(1) Hoog, middel, laag

Het maken van een onderverdeling in groepen: hoog, middel en laag is een van de eenvoudigste manieren van prioriteren. Zodra belanghebbenden aan bijna alles de hoogste prioriteit toekennen, is het nodig extra regels te introduceren, bijv. dat alledrie de prioriteiten evenveel keren moeten worden toegekend.

(2) MoSCoW-methode

Prioriteringstechniek die haar wortels heeft in de agile systeemontwikkelmethodiek DSDM, maar generiek toepasbaar is. MoSCoW is hierbij een acroniem voor vier categorieën: (a) Must have (onmisbaar), (b) Should have (niet onmisbaar, maar vaak wel 'workaround' nodig), (c) Could have (duidelijk toegevoegde waarde, maar ook bruikbaar zonder), (d) Won't have this time (niet in komende 'release').

(3) Relatieve prioritering

Bij het vaststellen van de relatieve prioriteit geven belanghebbenden paarsgewijs aan welk van de twee het belangrijkst is. Hierdoor ontstaat een rangorde van prioriteiten. Voor relatieve prioritering is één beslissingsbevoegde belanghebbende of een democratisch proces nodig. Met een groep belanghebbenden consensus bereiken over een geprioriteerde lijst (requirements) is vrijwel ondoenlijk en kost onevenredig veel tijd.

(4) Tevredenheid/ontevredenheid-ratio

De tevredenheid/ontevredenheid-ratio is een maat voor de meerwaarde die belanghebbenden ergens aan hechten. Nadruk ligt dus op toegevoegde waarde. De ontevredenheidsratio geeft aan hoe ontevreden de belanghebbende is als ergens niet aan voldaan wordt (bijv. als het systeem niet aan een requirement voldoet). De tevredenheidsratio geeft aan hoe tevreden een belanghebbende is als juist wél ergens aan wordt voldaan (systeem voldoet aan requirement).  De ratio's hebben een schaal van 1 tot 5. Een hoge score op beide ratio's wijst erop dat het gaat om iets dat veel waarde heeft. Grote verschillen tussen de ratio's zijn reden voor nader onderzoek.

(5) Urgentie vs. belangrijkheid

Een binnen time management veel toegepaste prioritering is door het uitzetten van urgentie (urgent, niet-urgent) tegen de mate van belangrijkheid (belangrijk, minder belangrijk). Hierdoor ontstaat een matrix met vier kwadranten.

Bron: Handboek Requirements (2010), Nicole de Swart

Laatst aangepast op dinsdag, 02 januari 2018 08:26  
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  


JPAGE_CURRENT_OF_TOTAL

Whoever is careless with the truth in small matters cannot be trusted with the important matters.  

Albert Einstein

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 103 gasten online
Artikelen

klantgericht volgens don peppers martha rogers lean klant

Banner
Banner

ontketen je brein theo compernolle

Ontketen je brein
Hoe hyperconnectiviteit en multitasking je hersenen gijzelen en hoe je eraan kunt ontsnappen
Theo Compernolle

Bij Bol.com | 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