Requirements Engineering Bronnen en Standaarden

Het onderwerp requirements is, zoals veel ICT onderwerpen, veelomvattend, divers en complex. Er worden termen gebruikt als requirements analyse, requirements management, requirements engineering. En er zijn de nodige bronnen en standaarden die elk zo hun visie op het onderwerp hebben en bijdrage aan het complex aan begrippen. Hieronder worden een aantal van deze bronnen en standaarden kort toegelicht.

CMMI: Raamwerk om volwassenheid van organisatie te bepalen, ook op requirements gebied. CMMI definieert het begrip “Requirements Engineering” als overkoepelend proces voor twee deelprocessen: “Requirements Development” en “Requirements Management”. Requirements Development richt zich op het opstellen van requirements en requirements specificaties. Requirements Management houdt zich bezig met het bewaken dat requirements up-to-date zijn. Dit is ondermeer te bereiken door het aanbrengen van traceerbaarheid in requirements die relaties met elkaar en met andere project / systeem informatie hebben. Verder moet change management op requirements aanwezig zijn en voortgang van het requirements engineering proces meetbaar zijn. Veel projecten/organisaties beginnen met het Requirements Engineering proces in het kader van een CMMI verbeteringstraject. Zo is CMMI-2 niveau vereiste dat het Requirements Management key process area geadresseerd wordt.

VOLERE: een visie en werkwijze oorspronkelijk uitgedragen door de auteurs James Robertson en Suzanne Robertson, in veel gelezen boeken en veel gevolgde seminars en trainingen. Maakt onderscheid in Business en Product Use Cases. Introduceert werkwijze met kaartjes (Snow Cards) waarop elke requirement wordt gespecificeerd met attributen zoals Id, type, versie, gerelateerde Use Cases, indiener, rationale (de justificatie), mate van klanttevredenheid, en fit criteria. Fit criteria vormen een belangrijk onderdeel waarbij voor elke requirement op meetbare wijze wordt geformuleerd hoe kan worden vastgesteld of aan een requirement wordt voldaan. Dit biedt een goed vertrekpunt voor acceptatiecriteria en testspecificaties.

RUP : een iteratieve ontwikkelmethode (ontwikkeld door Rational, nu IBM), met als één van de disciplines “requirements management”. Daarin is met name de requirements pyramide gepositioneerd met begrippen als “needs” en “features”. Er wordt onderscheid gemaakt tussen probleem- en oplossingsdomein. “Needs” maken deel uit van de probleemdefinitie en beschrijven de behoefte van de belanghebbenden. “Features” maken deel uit van het oplossingsdomein en beschrijven op hoog niveau de gewenste eigenschappen van de oplossing. Deze informatie maakt in RUP deel uit van het zgn. Vision Document, onderdeel van de Requirements Management discipline. Requirements worden ingedeeld in Functional en non Functional Requirements. De Non Functional requirements worden verder geclassificeerd in types zoals Usability, Reliability, Performance en Security. Deze functional en non functional categorieen worden ook wel aangeduid met de kreet FURPS.

Verdere uitwerking van requirements vindt plaats met Use Case specificatie.

UML en Use Cases: Een object georiënteerde modelleertaal, opgesteld door Grady Booch, James Rumbaugh en Ivar Jacobson , waarin met name het begrip “Use Cases” veelvuldig binnen requirements terugkomt als manier om requirements vast te leggen. Een Use Case beschrijft een functionaliteit als een dialoog tussen een gebruiker en het systeem. Deze beschrijving heeft de vorm van een reeks acties die door de gebruiker of systeem worden uitgevoerd. Een Use Case model is in essentie een eenvoudig model met Use Cases als ellips symbool en gebruikers of rollen als poppetjes. Use Cases kunnen ook onderlinge relaties hebben om bijv. hergebruik of afhankelijkheden weer te geven. Algemene wordt in de praktijk ervaren dat het snel te complex wordt. Use Cases mogen niet uitmonden in ontwerpmodellen.

De uitwerking van elke Use Case bestaat uit de beschrijving van de handelingen en acties die door gebruiker of systeem worden uitgevoerd. Dit wordt vaak aangevuld met de pre- en post-condities die de begin- en eindsituatie van een Use Case specificeren. Use Cases vormen een uitgangspunt voor het ontwerptraject. Daarbij worden Use Cases uitgewerkt in zogenaamde “Use Case Realizations” die de interne interactie laat zien tussen de verschillende UML classes om de gespecificeerde Use Case functionaliteit te implementeren.

IIBA en BABOK  : Een Amerikaanse, zeer uitgebreide business analyse standaard met de nodige certificatie trajecten. De standaard biedt een raamwerk met alle denkbare business analyse activiteiten en resultaten. Babok introduceert requirements niveau’s : Business-, Stakeholder- en Systeem requirements, aangevuld met Projectrequirements. Business Requirements worden beschouwd vanuit de belangen en bedrijfsdoelen van de organisatie als geheel. Stakeholder Requirements kijken vanuit de belangen van specifieke stakeholders (die niet altijd in lijn hoeven te zijn met de business doelen). De uiteindelijke systeemrequirements (of solution-, /product- requirements) vormen de uiteindelijke set eisen voor het te realiseren product, en worden afgeleid van de business- en stakeholder requirements. Daarbij wordt verantwoord welke business en stakeholder requirements al dan niet worden meegenomen, en worden eventuele conflicterende requirements opgelost. De project requirements zijn tijdelijk van aard en beschrijven de eisen die aan het project worden gesteld zoals bijv. tijdsduur, kosten, werkwijze, betrokkenen, conversie/migratie etc. Ook deze kunnen hun oorsprong hebben in de business en stakeholder requirements.

IREB : een Europese (Duitse) requirements engineering standaard met ook weer de nodige certificatie trajecten.

Agile / Scrum : Een werkwijze voor snelle ontwikkeling van software waarbij requirements globaal worden gespecificeerd in korte, puntsgewijze gebruikerstermen, “User Sories” genoemd. Niet te verwarren met Use Cases. Requirements uitwerking vindt vooral plaats in interactie met gebruikers waarbij gebruikersinbreng zo direct mogelijk naar werkende software wordt vertaald. De essentie van Agile op requirements is met name dat deze niet te gedetailleerd worden uitgewerkt, maar vooral in interactie met gebruikers tijdens het ontwikkeltraject duidelijk worden gemaakt. Agile Modelling pleit wat dat betreft voor de nodige terughoudendheid in het opzetten van requirements modellen.

TOGAF : Een Architectuur standaard waarin Requirements centraal worden gesteld als drijvende kracht achter de  “Architecture Development Method” cyclus. Als requirements worden verzameld in een omgeving waar op basis van een architectuurprincipes en kaders met een architectuurmethode zoals Togaf wordt gewerkt, dan is het gebruikelijk om de architectuurniveau requirements als vertrekpunt te gebruiken.

This entry was posted in Requirements and tagged . Bookmark the permalink.

4 Responses to Requirements Engineering Bronnen en Standaarden

  1. Pharmb292 says:

    Very nice site!

  2. Pharmd610 says:

    Hello! adgeggk interesting adgeggk site! I’m really like it! Very, very adgeggk good!

  3. Pharmf387 says:

    Very nice site!

  4. Pharme593 says:

    Hello! ekfgcgb interesting ekfgcgb site! I’m really like it! Very, very ekfgcgb good!

Geef een reactie

Je e-mailadres wordt niet gepubliceerd.

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>