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

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

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

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):

• Functionaliteit
• Betrouwbaarheid
• Bruikbaarheid
• Efficiëncy
• Onderhoudbaarheid
• Overdraagbaarheid

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.

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

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

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)

Bron: Handboek Requirements (2010), Nicole de Swart

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

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

Barry Boehm ontdekte al in 1979 dat de herstelkosten exponentieel toenemen naarmate een fout later in het ontwikkelproces wordt gevonden en hersteld. Het is dan ook zinvol zo vroeg mogelijk in het ontwikkelproces fouten te voorkomen of corrigeren: de kwaliteits- en preventiekosten verdien je dus al snel terug omdat door deze maatregelen de faal- en herstelkosten lager zijn.