Eisen die beschrijven wat het systeem moet doen; worden
ook wel gedrags of operationele eisen genoemd (Young,
2004). Functionele eisen leggen de interactie tussen de
componenten en de omgeving vast (Kotonya & Sommerville,
1996) Functionele eisen omvatten: (1) specificaties van de
functionaliteit van het product, (2) acties die door het
product moeten worden uitgevoerd en (3) afgeleide eisen van
het fundamentele doel. De functionele eisen worden voor de
communicatie gedocumenteerd middels een functioneel
document of specificatie (Robertson & Robertson, 1999).
Niet-functionele eisen
(Robertson & Robertson, 1999; Young, 2004; Kotonya & Sommerville, 1996):
Eisen die een systeem moet hebben om de reden van bestaan
mogelijk te maken (Robertson & Robertson, 1999). Doordat
deze de eigenschappen van het systeem specificeert, worden
deze ook wel kwaliteitseisen genoemd (Young, 2004).
Kenmerkend van de eisen is de beperking van de
oplossingsruimte (Kotonya & Sommerville, 1996).
Ontwerparchitectuur :
Geeft de structuur van het ontwerpproces weer in de vorm
van processtappen die moeten worden genomen om tot een
(expliciet) ontwerp te komen.
Randvoorwaarden
(V&W, 2005)
:
Eisen die een beperkende werking hebben op de
ontwikkeling en oplossingen van het systeem. Deze zijn van
toepassing op het gehele systeem en worden extern opgelegd.
Specificatie :
De verzameling van formele eisen wordt vastgelegd in een
document (eisenspecificatie) dat de afsluiting van de
specificatiefase vormt. Formele vastlegging van het
definitieve ontwerp is de ontwerpspecificatie (ook wel
product- of technische specificatie genoemd) en vormt de
afsluiting van de ontwerpfase. De processpecificatie legt alle
(ontwerp)keuzes en attentiepunten gedurende het gehele
proces vast. Deze moet zowel als afsluiting van de
specificatie- alsmede voor de ontwerpfase worden gemaakt.
Specificatieproces
(Suh, 1990; Hull et al.,2005; Nuseibeh, 2001)
:
Continue interactie (Suh, 1990) tussen het probleem- en
oplossingsdomein (Hull et al., 2005), waarbij echter strikte
scheiding moet blijven tussen de (oplossingsvrije) eisen en
het ontwerp (Nuseibeh, 2001).
Stakeholders (Freeman
in Mitchell et al., 1997;Bryson, 2004)
:
Elke groep of individu die het behalen van de doelen van de
organisatie kan beïnvloeden of hierdoor wordt beïnvloed.
9
Referenties
9.1 L
ITERATUURBaarda, D., Goede, M. de (1997), ‘Basisboek methoden en technieken – praktische handleiding
voor het opzetten en uitvoeren van onderzoek’, 2
eherziene druk, Stenfert Kroese, Houten
Boes, J., Dorée, A., Suurenbroek, Y. (2004), ‘Bouwprocessen’, Universiteit Twente, dictaat
Blanchard, B. (1998), ‘Systems engineering and analysis’, Prentice-Hall, third edition
Brinkman, J. (1992), ‘Cijfers spreken – Statistiek en methodologie voor het hoger onderwijs’,
Wolters-Noordhof, Groningen
Browning, T. (2001), ‘Applying the Design Structure Matrix to system decomposition and
integration problems: A review and new directions’, IEEE Transactions on engineering
management, vol. 48, no. 3
Browning, T. (2002), ‘Process integration using the Design Structure Matrix’, Wiley, Systems
Engineering, vol. 5, no. 3
Browning, T., Fricke, E., Negele, H. (2006), ‘Key Concepts in modelling product development
processes’, Systems Engineering, vol. 9, no. 2
Brunton, J., Tarling, K. (2003), ‘Dynamically complex rail projects – A systems engineering
view’, Proceedings of the 2003 IEEE/ASME Joint Rail Conference
Bryson, J. (2004), ‘What to do when stakeholders matter – Stakeholder identification and
analysis techniques’, Public Management Review, vol. 6, Issue 1, 21-53
Conklin, J. (2003), ‘Wicked problems and social complexity’, Cognexus Institute
Davies, A., Brady, T. (2000), ‘Organisational capabilities and learning in complex product
systems: towards repeatable solutions’, Elsevier, Research Policy 29,.931–953
DoD (2001), ‘Systems engineering fundamentals’, Universiteit Twente, dictaat
Easterbrook, S., Nuseibeh, B. (2004), ‘Fundamentals of requirements engineering’
Eijbersen, M., Eelants, J., Amstel, N., Heide, J. van der, Keldermans, F., Korteweg, A., Lamers,
M., Mulder, R., Oehler, J. (2004), ‘Van functie tot bouwstof – Leidraad specificeren’, CROW,
publicatie 211
Eppinger, S., Whitney, D., Smith, R., Gebala, D. (1994), ‘A model-based method for organizing
tasks in product development’, Research in Engineering Design
Fricke, E., Schulz, P. (2005), ‘Design for changeability (DfC): Principles to enable changes in
systems throughout their entire lifecycle’, Systems engineering, vol. 8, no. 4
Gann, D., Salter, A. (2000), ‘Innovation in project-based, service-enhanced firms: the
construction of complex products and systems’, Elsevier, Research policy 29, 955-972
Gause, D., Weinberg, G. (1989), ‘Exploring requirements: quality before design’, Published by
Dorset House Publishing Co. Inc., New York
Hobday, M., Rush, H. (1999), ‘Technology management in complex product systems (CoPS) –
Ten questions answered, Int. J. Technology Management, vol. 17, no. 6
Hull, E., Jackson, K., Dick, J. (2005), ‘Requirements Engineering’, Springer, second edition
Hutjes, J., Buuren, J. van (1992), ‘De gevalstudie – Strategie van kwalitatief onderzoek’, Boom,
Meppel
Katasonov, A., Sakkinen, M. (2006), ‘Requirements quality control: a unifying framework’,
Requirements Eng (2006) 11: 42–57
Kotonya, G., Sommerville, I. (1996), ‘Requirements engineering with viewpoints’, software
engineering journal
Kotonya, G., Sommerville, I. (1998), ‘Requirements Engineering – processes and techniques’,
Wiley
Kramer, N., Smit, J. de (1997), ‘Systeemdenken’, Stenfert Kroese, vijfde herziene druk, dictaat
Universiteit Twente
Leinonen, J. (2001), ‘Requirements management tool as a catalyst for communication’
Lindstedt, P., Burenius, J. (2003), ‘The Value Model – How to master product development and
create unrivalled customer value’, Nimba, Sweden
Nuseibeh, B., Easterbrook, S. (2000), ‘Requirements Engineering: A Roadmap’, Future of
software engineering limerick Ireland, ACM
Nuseibeh, B. (2001), ‘Weaving together requirements and architectures’, Software
management, march
Mar, B. (1997), ‘Back to basics again – A scientific definition of systems engineering’,
presented at INCOSE
Martin, J. (2000), ‘Systems engineering Guidebook – A process for developing systems and
products’, CRS Press, Boca Raton, Florida
Mitchell, R., Agle, B., Wood, D. (1997), ‘Toward a theory of stakeholder identification and
salience: defining the principle of who and what really counts’, Academy of management
review, vol. 22, no. 4, 853-896
Pimmler, U., Eppinger, S. (1994), ‘Integration analysis of product decompositions’, MIT, ASME
Design Theory and Methodology Conference
Pohl, K. (1994), ‘The three dimensions of requirements engineering: A framework and its
applications’, Information Systems, vol. 19 no. 3, pp. 243 – 258, Elsevier Science
Pohl, K. (1997), ‘Requirements engineering: An overview’, Encyclopedia of Computer Science
and Technology, 36
Ratchev, S, Urwin, E., Muller, D., Pawar, K., Moulek, I. (2003), ‘Knowledge based requirement
engineering for one-of-a-kind complex systems’, Elsevier, Knowledge-Based systems 16, 1-5
Robertson, S., Robertson, J. (1999), ‘Mastering the requirements process’, Pearson Education
Limited, ACM Press
Sheard, S. (1995), ‘Twelve systems engineering roles’, software productivity consortium
Suh, N. (1990), ‘The principles of design’, Massachusetts Institute of Technology, Oxford
University Press, New York - Oxford
Swanborn, P. (1994), ‘Methoden van sociaal-wetenschappelijk onderzoek’, Boom, Meppel
Verschuren, P., Doorewaard, H. (2005), ‘Het ontwerpen van een onderzoek’, Uitgeverij
Lemma, Utrecht, derde druk
9.2 P
UBLICATIES/
RAPPORTEN/
PRESENTATIESBoersma, P., Engelmoer, H. (2006), ‘Systems Engineering cursus HZL-aansluitingen’, Movares,
23 maart
Klarenbeek, J. (2004), ‘Richtlijnen voor het railverkeerstechnisch ontwerp’ (RVTO), ProRail
Nieuwbouw Projectencentrum Railverkeerstechniek, versie 4.0
In document
Systems engineering : expliciet functioneel specificeren en ontwerpen: een haalbare wens?
(pagina 92-95)