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.
Requirement: verschil tussen versies
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=40168008 19 jan 2014) |
||
| 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 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 | * 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 | 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 | ||
* [[ | * [[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 | 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]] | |||
* [[PDRE®]] | |||
== 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'. | ||
* [[Martin Arendsen]], [[Jan Jaap Cannegieter]], [[Arno Grund]], [[Petra Heck]], [[Serge de Klerk]], [[Johan Zandhuis]] (2008) ''Succes met de requirements! - Ontwikkeling, validatie en beheer van requirements voor informatiesystemen''. | |||
* [http://www.volere.co.uk Engelse website over requirement management] | |||
{{ | {{Appendix|2= | ||
{{References}} | |||
}} | |||
[[Categorie:Software engineering]] | [[Categorie:Software engineering]] | ||
[[Categorie:Techniek]] | [[Categorie:Techniek]] | ||
Versie van 7 nov 2017 10:43
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
- FURPS
- Methoden en technieken in de informatica
- Material Requirements Planning
- Softwareontwikkelmethode
- Use case
- V-model
- Ontwerpspecificatie
- PDRE®
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'.
- Martin Arendsen, Jan Jaap Cannegieter, Arno Grund, Petra Heck, Serge de Klerk, Johan Zandhuis (2008) Succes met de requirements! - Ontwikkeling, validatie en beheer van requirements voor informatiesystemen.
- Engelse website over requirement management
Bronnen, noten en/of referenties
|