Wikisage, de vrije encyclopedie van de tweede generatie, is digitaal erfgoed

Wikisage is op 1 na de grootste internet-encyclopedie in het Nederlands. Iedereen kan de hier verzamelde kennis gratis gebruiken, zonder storende advertenties. De Koninklijke Bibliotheek van Nederland heeft Wikisage in 2018 aangemerkt als digitaal erfgoed.

  • Wilt u meehelpen om Wikisage te laten groeien? Maak dan een account aan. U bent van harte welkom. Zie: Portaal:Gebruikers.
  • Bent u blij met Wikisage, of wilt u juist meer? Dan stellen we een bescheiden donatie om de kosten te bestrijden zeer op prijs. Zie: Portaal:Donaties.
rel=nofollow

Requirement: verschil tussen versies

Uit Wikisage
Naar navigatie springen Naar zoeken springen
(https://nl.wikipedia.org/w/index.php?title=Requirement&oldid=16273894 -1b - Mdd 2 apr 2009)
 
(https://nl.wikipedia.org/w/index.php?title=Requirement&oldid=46561077 21 apr 2016)
 
(Een tussenliggende versie door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
Een '''requirement''' in de [[techniek]] is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen. Het wordt in formele zin veel gebruikt in de [[systems engineering]] en [[software engineering]]. In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van een systeem geïdentificeerd, die bruikbaar zijn en meerwaarde bieden voor een gebruiker.<ref>Ralph R. Young (2001). ''Effective Requirements Practices''. Boston: Addison-Wesley, 2001. Zie ook [http://www.ralphyoung.net RalphYoung.net], een website over requirements-gerelateerde onderwerpen.</ref>      
Een '''requirement''' in de [[techniek]] is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen. Het wordt in formele zin veel gebruikt in de [[systems engineering]] en [[software engineering]]. In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of [[Kwaliteit (eigenschap)|kwaliteiten]] van een systeem geïdentificeerd, die bruikbaar zijn en meerwaarde bieden voor een gebruiker.<ref>Ralph R. Young (2001). ''Effective Requirements Practices''. Boston: Addison-Wesley, 2001. Zie ook [http://www.ralphyoung.net RalphYoung.net], een website over requirements-gerelateerde onderwerpen.</ref>


== Overzicht ==
== Overzicht ==
Het begrip requirements is een van oorsprong Engels begrip. In het Nederlands betekent dit iets als behoeften, eisen, specificatie, specificatie van eisen, vereisten of wensen, maar geen van deze begrippen dekt de lading. Het begrip kan duiden op:
Het begrip requirements is een van oorsprong Engels begrip. In het Nederlands betekent dit iets als behoeften, eisen, specificatie, specificatie van eisen, vereisten of wensen, maar geen van deze begrippen dekt de lading. Het begrip kan duiden op:
* een bepaalde vereiste van een systeem  
* een bepaalde vereiste van een systeem
* de activiteit van het opstellen van vereisten, de requirement analyse
* de activiteit van het opstellen van vereisten, de [[requirementsanalyse]]
* de documentatie van de vereisten in een formeel document  
* de documentatie van de vereisten in een formeel document


In de klassieke technische benadering wordt een set van requirements gebruikt als input in het ontwerpstadium van een productontwikkeling. De requirements beschrijven welke elementen en functies benodigd zijn voor een specifiek project.
In de klassieke technische benadering wordt een set van requirements gebruikt als input in het ontwerpstadium van een productontwikkeling. De requirements beschrijven welke elementen en functies benodigd zijn voor een specifiek project.


Een requirement analyse traject kan vooraf zijn gegaan door een haalbaarheidsstudie, of een fase van conceptuele analyse. De requirements analyse fase kan worden opgedeeld in:<ref>Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003</ref>
Een requirementsanalyse traject kan vooraf zijn gegaan door een haalbaarheidsstudie, of een fase van conceptuele analyse. De requirementsanalysefase kan worden opgedeeld in:<ref>Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003</ref>
* requirement ontlokken : verzamelen van vereisten van [[stakeholder]]s
* requirement ontlokken (elicitatie, van het engels: elicitation) : verzamelen van vereisten van [[stakeholder]]s
* [[requirements analyse]] : controleren op consistentie en volledigheid
* [[requirementsanalyse]] : controleren op consistentie en volledigheid
* specificatie : gedetailleerde documentatie, en
* specificatie : gedetailleerde documentatie, en
* verificatie : controleren of de verkregen requirements correct zijn.
* verificatie : controleren of de verkregen requirements correct zijn.
Regel 17: Regel 17:
== Indeling van requirements ==
== Indeling van requirements ==
=== Functionele requirements ===
=== Functionele requirements ===
Functionele requirements beschrijven een specifiek gedrag of functies, die het systeem dient te vervullen. Bijvoorbeeld het opmaken van een tekst of de moduleren van een signaal. Deze worden ook wel capaciteiten genoemd.  
Functionele requirements beschrijven specifiek gedrag of functies, die het systeem dient te vervullen. Bijvoorbeeld het opmaken van een tekst of het moduleren van een signaal. Deze worden ook wel capaciteiten genoemd.


=== Niet functionele requirements ===
=== Niet-functionele requirements ===
Niet functionele requirements specificeren criteria om het functioneren van het systeem te beoordelen, maar beschrijven niet het specifieke gedrag zelf.  
Niet-functionele requirements specificeren criteria om het functioneren van het systeem te beoordelen, maar beschrijven niet het specifieke gedrag zelf.


Deze niet functionele requirements kunnen verder onderverdeeld worden in requirements betreffende performance, onderhoud, veiligheid, betrouwbaarheid, of menig ander aspect.  
Deze niet-functionele requirements kunnen verder onderverdeeld worden in requirements betreffende performance, onderhoud, veiligheid, betrouwbaarheid, of menig ander aspect.
 
Modellen als [[ISO 9126|ISO/IEC 9126]] of [[ISO 25010]] kunnen helpen om de niet-functionele requirements te structureren, inventariseren en prioriteren.


== Zie ook ==
== Zie ook ==
Regel 31: Regel 33:
* [[Use case]]
* [[Use case]]
* [[V-model]]
* [[V-model]]
* [[Ontwerpspecificatie]]


== Literatuur ==
== Literatuur ==
* [[Wim Hartman]] (1968) ''Information systems handbook : analysis, requirements determinaton, design and development, implementation and evaluation (ARDI)'' met H. Matthes, en A. Proeme. Apeldoorn: Philips'.
* [[Wim Hartman]] (1968) ''Information systems handbook : analysis, requirements determinaton, design and development, implementation and evaluation (ARDI)'' met H. Matthes, en A. Proeme. Apeldoorn: Philips'.


{{bron|bronvermelding={{reflist}}}}  
<!-- Marrakech: Door het ontbreken van Nederlandstalige bronnen is het onduidelijk of deze term gebruikelijk is in het Nederlands. Los daarvan is de tekst slecht geschreven en hier en daar zelfs onbegrijpelijk. Zo luidt de definitie: 'Een requirement in de techniek is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen'. Een '''enkelvoudig gedocumenteerde'' bepaling'? En 'een bepaling wat een dienst zou moeten doen'? 'In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van een systeem geïdentificeerd'? 'Het begrip [requirement] kan duiden op de activiteit van het opstellen van vereisten'?  -->
 
{{Appendix|2=
{{References}}
}}
{{authority control|TYPE=|Wikidata=q774228}}
[[Categorie:Software engineering]]
[[Categorie:Software engineering]]
[[Categorie:Techniek]]
[[Categorie:Techniek]]

Huidige versie van 7 nov 2017 om 10:47

Een requirement in de techniek is een enkelvoudig gedocumenteerde bepaling, wat een bepaald product of dienst zou moeten doen. Het wordt in formele zin veel gebruikt in de systems engineering en software engineering. In een requirement worden de benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van een systeem geïdentificeerd, die bruikbaar zijn en meerwaarde bieden voor een gebruiker.[1]

Overzicht

Het begrip requirements is een van oorsprong Engels begrip. In het Nederlands betekent dit iets als behoeften, eisen, specificatie, specificatie van eisen, vereisten of wensen, maar geen van deze begrippen dekt de lading. Het begrip kan duiden op:

  • een bepaalde vereiste van een systeem
  • de activiteit van het opstellen van vereisten, de requirementsanalyse
  • de documentatie van de vereisten in een formeel document

In de klassieke technische benadering wordt een set van requirements gebruikt als input in het ontwerpstadium van een productontwikkeling. De requirements beschrijven welke elementen en functies benodigd zijn voor een specifiek project.

Een requirementsanalyse traject kan vooraf zijn gegaan door een haalbaarheidsstudie, of een fase van conceptuele analyse. De requirementsanalysefase kan worden opgedeeld in:[2]

  • requirement ontlokken (elicitatie, van het engels: elicitation) : verzamelen van vereisten van stakeholders
  • requirementsanalyse : controleren op consistentie en volledigheid
  • specificatie : gedetailleerde documentatie, en
  • verificatie : controleren of de verkregen requirements correct zijn.

Indeling van requirements

Functionele requirements

Functionele requirements beschrijven specifiek gedrag of functies, die het systeem dient te vervullen. Bijvoorbeeld het opmaken van een tekst of het moduleren van een signaal. Deze worden ook wel capaciteiten genoemd.

Niet-functionele requirements

Niet-functionele requirements specificeren criteria om het functioneren van het systeem te beoordelen, maar beschrijven niet het specifieke gedrag zelf.

Deze niet-functionele requirements kunnen verder onderverdeeld worden in requirements betreffende performance, onderhoud, veiligheid, betrouwbaarheid, of menig ander aspect.

Modellen als ISO/IEC 9126 of ISO 25010 kunnen helpen om de niet-functionele requirements te structureren, inventariseren en prioriteren.

Zie ook

Literatuur

  • Wim Hartman (1968) Information systems handbook : analysis, requirements determinaton, design and development, implementation and evaluation (ARDI) met H. Matthes, en A. Proeme. Apeldoorn: Philips'.

Bronnen, noten en/of referenties

Bronnen, noten en/of referenties
  1. º Ralph R. Young (2001). Effective Requirements Practices. Boston: Addison-Wesley, 2001. Zie ook RalphYoung.net, een website over requirements-gerelateerde onderwerpen.
  2. º Karl E. Wiegers, Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle, Second Edition, Microsoft Press 2003
rel=nofollow
rel=nofollow
rel=nofollow