• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Requirements
Requirements
Functionele requirements vs. niet-functionele requirements
Gepubliceerd in Requirements
E-mail Afdrukken

cannegieter swart zandhuis

Binnen het vakgebied van requirements engineering wordt onderscheid gemaakt tussen functionele requirements en niet-functionele requirements:

  1. Functionele requirements: requirements die de vereiste werking beschrijven van een systeem; het door een systeemfunctie uit te voeren gedrag.

  2. Niet-functionele requirements: requirements die de manier beschrijven waarop het systeem deze werking moet aanbieden.

Volgens Cannegieter, De Swart en Zandhuis gaan functionele requirements gaan over het gewenste gedrag van het systeem. Ze definiëren functionaliteit als de mogelijkheden die het systeem moet bieden zoals gesteld in de functionele requirements. Een rammelende definitie omdat een systeem blijkbaar alleen functionaliteit kan bieden zodra er een functionele requirement aan ten grondslag ligt. Lijkt een kip-ei-discussie, maar functionaliteit is m.i. niets anders dan een de 'werkzaamheid' van een systeem: het systeem is, wat het systeem doet!

Cannegieter, De Swart en Zandhuis definiëren niet-functionele requirements als de kwaliteitseisen of beperkingen voor een systeem: hoe moet het beoogde systeem haar functionaliteit aanbieden. Een kwaliteitseis betreft een kwaliteitseigenschap die niet door de functionele requirements wordt afgedekt. Een beperking gaat over de oplossingsruimte in aanvulling op de functionele en kwaliteitsrequirements. Beperkingen kun je - in tegenstelling tot functionele requirements en kwaliteitseisen niet implementeren. Ze beperken alleen de oplossingsruimte (en daarmee het ontwikkelproces) en verkleinen daarmee de bewegingsvrijheid van de ontwikkelaars. Een voorbeeld van een beperking is bijvoorbeeld dat het systeem gebruik moet maken van een Oracle-database.

Volgens Agterbosch, Raemakers, Tijdink e.a. is het ontbreken van nadrukkelijke aandacht voor niet-functionele requirements een vaak voorkomend punt van zorg bij opdrachtgevers, "met name als ze de consequenties ervan ondervinden. Juist de niet-functionele requirements kunnen doorslaggevend zijn voor de keuze van de uiteindelijke oplossingsrichting.

De bekendste classificering van kwaliteitsrequirements is die van ISO/IEC 25010. De belangrijkste aandachtspunten bij het opstellen van de kwaliteitsrequirements zijn: beveiiligbaarheid, functionele correctheid, betrouwbaarheid (bedrijfszekerheid, fouttolerantie en herstelbaarheid), bruikbaarheid, efficiënte werking van het systeem (snelheid, middelenbeslag), de onderhoudbaarheid (analyseerbaarheid, aanpasbaarheid en testbaarheid van de software), en de overdraagbaarheid van het systeem (aanpasbaarheid, installeerbaarheid, vervangbaarheid.

Bron:

 

Laatst aangepast op zaterdag, 20 februari 2016 20:07  
Requirements volgens Borland
Gepubliceerd in Requirements
E-mail Afdrukken

elicitatie analyse specificatie validatie management development requirements

 

Laatst aangepast op zondag, 26 oktober 2014 18:05  
Requirements volgens Jill Dyche
Gepubliceerd in Requirements
E-mail Afdrukken

requirements development requirement

 

Laatst aangepast op vrijdag, 10 oktober 2014 20:04  
Requirements binnen RUP
Gepubliceerd in Requirements
E-mail Afdrukken

requirements workflow rup nicole swart

In het artikel Veel gebruikte requirementsprocessen geeft Nicole de Swart een overzicht van een aantal verschillende processen voor requirements. Bovenstaande schema is de workflow voor het opstellen van requirements binnen RUP (Rational Unified Process) wordt bovenstaan

Bron: Veel gebruikte requirementsprocessen, Nicole de Swart

Laatst aangepast op vrijdag, 10 oktober 2014 19:57  
Requirements volgens Nicole de Swart
Gepubliceerd in Requirements
E-mail Afdrukken

requirements development management nicole swart requirement

Bron: Veel gebruikte requirementsprocessen, Nicole de Swart

Laatst aangepast op vrijdag, 10 oktober 2014 20:01  
Requirements engineering volgens Van Veenendaal
Gepubliceerd in Requirements
E-mail Afdrukken

requirementsproces requirementsontwikkeling requirementsmanagement requirements

In de Checklist requirements engineering beschrijft - Tmap-goeroe - Erik Van Veenendaalde requirements engineering als combinatie van de processen requirementengineering en requirementsmanagement. Requirementsontwikkeling definieert hij als het proces dat gericht is op het afleiden en analyseren van de behoeften van de belanghebbenden en het vertalen van deze behoeften naar gespecificeerde producteisen. Dit proces bestaat - in hoofdlijnen - uit vier stappen:

  1. Requirementselicitatie: het communiceren met klanten en gebruikers om te bepalen wat hun behoeften en vereisten zijn, en dit vertalen in requirements.

  2. Requirementsanalyse: bepalen in welke mate de opgestelde requirements onduidelijk, incompleet, onbepaald of tegenstrijdig zijn, en deze onvolkomenheden corrigeren.

  3. Requirementsspecificatie: formeel documenteren van de requirements in ene requirementsspecificatie..

  4. Requirementsvalidatie: samen met de klanten en gebruikers evalueren of de set van requirements juist en volledig is in relatie tot hun behoeften en vereisten.

requirementsontwikkeling elicitatie specificatie validatie requirements

Requirementsmanagement gaat over het beheersen en beheren van de overeengekomen set requirements, het voorkomen van ongewenste scope-uitbreidingen en misverstanden over de inhoud van requirements gedurende het project.

Bron: Checklist requirements engineering, Erik van Veenendaal

Laatst aangepast op vrijdag, 24 oktober 2014 20:23  
Story mapping volgens Venneman, De Groot & Gerrits
Gepubliceerd in Requirements
E-mail Afdrukken

story map agile user stories story

"Een Story Map is een tweedimensionale weergave van een (deel van de) Product Backlog. Het is een visueel hulpmiddel om de requirements (User Stories) op de Product Backlog logisch op te knippen, te groeperen en te ordenen. Het is als het ware een kaart van de relaties tussen alle requirements.

Op de x-as staan diverse ketenonderdelen, dit kunnen processtappen, processen of functionele onderdelen zijn. Op de y-as worden de diverse Feature Sets geplaatst, ook wel slices genoemd. Dit zijn als het ware de lagen waaruit het totale product is opgebouwd. Elke laag is een verfraaiing van de daarboven gelegen lagen. De eerste laag wordt 'wandelend skelet' genoemd: het loopt wel, maar ziet er nog armzalig uit."

Bron: Agile - Pocketguide voor wendbare organisaties, Jeroen Venneman, Rik de Groot & Theo Gerrits

 

Laatst aangepast op maandag, 22 september 2014 20:05  
Requirements volgens Deltaisis
Gepubliceerd in Requirements
E-mail Afdrukken

requirements business case use case soorten

Bron: Deltaisis

Laatst aangepast op woensdag, 24 september 2014 07:10  
Requirements volgens IREB
Gepubliceerd in Requirements
E-mail Afdrukken

requirements ireb functioneel niet-functioneel beperkingen

In het boek Grip op requirements onderkennen Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis twee indelingen van requirements. De eerste onderverdeling die vaak wordt gebruikt voor requirements is de splitsing in functionele requirements en niet-functionele requirements. De tweede indeling van requirements is het onderkennen van business requirements, gebruikers requirements en systeem- of softwarerequirements.

Functionele requirements vs. niet-functionele requirements

  1. Functionele requirements: requirement die het door een systeemfunctie gewenste gedrag beschrijft.

  2. Niet-functionele requirements: requirement die niet het gedrag van het systeem beschrijft maar andere systeemeisen definieert (kwaliteitseisen en/of beperkingen waaraan het systeem moet voldoen)

Functionaliteit definiëren Cannegieter, De Swart en Zandhuis als de mogelijkheden die het systeem moet bieden zoals gesteld in functionele requirements.

Kwaliteitsrequirements geven aan hoe goed het beoogde systeem haar functionaliteit moet aanbieden; het gaat om een kwaliteitseigenschap die niet door een functioneel requirement wordt afgedekt. Een beperking is een requirement dat de oplossingsruimte beperkt in aanvulling op de functionele en kwaliteitsrequirements. In tegenstelling tot functionele en kwaliteitsrequirements kun je een beperking niet implementeren; het gaat om eisen die de oplossingsruimte of het ontwikkelproces limiteren. Bijvoorbeeld, 'het systeem moet gebruik maken van een Oracle-database' en 'het systeem moet voor het eind van het jaar operationeel zijn'.

Business requirements, gebruikersrequirements & systeem- of softwarerequirements

  1. Business requirements: requirements die beschrijven wat de met het systeem te realiseren doelen zijn (welke toegevoegde waarde heeft het systeem voor de organisatie?).

  2. Gebruikersrequirements: requirements die de activiteiten, processen of taken beschrijven die een gebruiker met het systeem wil uitvoeren (op welke manier ga je de business requirements halen?).

  3. Systeem- of softwarerequirements: requirements die het gewenste gedrag of de gewenste kwaliteit van het systeem beschrijven (aan welke eisen moet het systeem voldoen?).

Business requirements zijn geformuleerd vanuit het perspectief van bedrijfsdoelstellingen. Gebruikersrequirements vanuit het perspectief van de bedrijfsvoering en de gebruikers. Systeemrequirements worden beschreven vanuit het perspectief van het systeem.

Bron: Grip op requirements, Jan Jaap Cannegieter, Nicole de Swart & Johan Zandhuis

Laatst aangepast op dinsdag, 19 augustus 2014 17:16  
Grip op requirements (boekentip)
Gepubliceerd in Requirements
E-mail Afdrukken

grip op requirements jan jaap cannegieter nicole de swart zandhuis

Grip op requirements
IREB foundation examenstof uitgelegd en praktisch gemaakt
Jan Jaap Cannegieter, Nicole de Swart, Johan Zandhuis

Bij Bol.com

 

Laatst aangepast op zaterdag, 20 februari 2016 19:33  
Meer artikelen...


JPAGE_CURRENT_OF_TOTAL

You can elevate individual performances by elevating that of the entire system.

William Edwards Deming

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 213 gasten online
Artikelen

visie eind dag bill o'brien

remco claassen ik effectiviteit

IK
Gezond egocentrisme meer effectiviteit
Remco Claassen, Mayta Braun

Bij Managementboek

Banner

Lean boekentips

Banner