[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-240943-105":53,"doc-detail-240943-en":127},{"code":4,"msg":5,"data":6},0,"success",[7,14,19,24,29,34,39,44,49],{"id":8,"doc_module":9,"doc_module_name":10,"category_name":11,"show_sort_weight":12,"slug":13},11,1,"Template","Presentations",90,"presentations",{"id":15,"doc_module":9,"doc_module_name":10,"category_name":16,"show_sort_weight":17,"slug":18},12,"Resumes",80,"resumes",{"id":20,"doc_module":9,"doc_module_name":10,"category_name":21,"show_sort_weight":22,"slug":23},14,"Invoices",70,"invoices",{"id":25,"doc_module":9,"doc_module_name":10,"category_name":26,"show_sort_weight":27,"slug":28},15,"Posters",60,"posters",{"id":30,"doc_module":9,"doc_module_name":10,"category_name":31,"show_sort_weight":32,"slug":33},16,"Social Media",50,"social-media",{"id":35,"doc_module":9,"doc_module_name":10,"category_name":36,"show_sort_weight":37,"slug":38},17,"Forms",40,"forms",{"id":40,"doc_module":9,"doc_module_name":10,"category_name":41,"show_sort_weight":42,"slug":43},18,"Letters",30,"letters",{"id":45,"doc_module":9,"doc_module_name":10,"category_name":46,"show_sort_weight":47,"slug":48},21,"Paper Templates",5,"papers-templates",{"id":50,"doc_module":9,"doc_module_name":10,"category_name":51,"show_sort_weight":4,"slug":52},158,"General","general-158",{"code":4,"msg":54,"data":55},"ok",{"site_id":56,"language":57,"slug":58,"title":59,"keywords":60,"description":61,"schema_data":62,"social_meta":120,"head_meta":122,"extra_data":124,"updated_unix":126},105,"en","international-design-conference-design-2010-from-requirements-to-design","INTERNATIONAL DESIGN CONFERENCE - DESIGN 2010 - FROM REQUIREMENTS TO DESIGN","","The paper addresses limitations of traditional development processes for mechatronic systems characterized by complexity, dynamics, and uncertainty, where software increasingly drives functionality and competitive advantages. It argues for a formal, model-centric requirements engineering perspective and clarifies the distinction between solution-space and problem-space design specifications. The proposed approach refines narrative requirements into well-formed, complete, unambiguous, traceable, and verifiable specifications using a logical reasoning and incidence-matrix framework within an integrated SysML-aligned extension.",{"@graph":63,"@context":119},[64,80,102],{"@type":65,"itemListElement":66},"BreadcrumbList",[67,71,74,77],{"item":68,"name":69,"@type":70,"position":9},"https://docshare.wps.com","Home","ListItem",{"item":72,"name":10,"@type":70,"position":73},"https://docshare.wps.com/template/",2,{"item":75,"name":11,"@type":70,"position":76},"https://docshare.wps.com/template/presentations/",3,{"item":78,"name":59,"@type":70,"position":79},"https://docshare.wps.com/template/international-design-conference-design-2010-from-requirements-to-design/240943/",4,{"url":78,"name":59,"@type":81,"image":82,"author":87,"headline":59,"publisher":90,"fileFormat":93,"inLanguage":57,"description":61,"dateModified":94,"datePublished":95,"encodingFormat":93,"isAccessibleForFree":96,"interactionStatistic":97},"DigitalDocument",{"url":83,"@type":84,"width":85,"height":86},"https://docshare.wps.com/thumbnails/international-design-conference-design-2010-from-requirements-to-design/240943.png","ImageObject",442,249,{"name":88,"@type":89},"Chumphorn","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-10-20","2026-09-11",true,{"@type":98,"interactionType":99,"userInteractionCount":101},"InteractionCounter",{"@type":100},"ViewAction",7,{"@type":103,"mainEntity":104},"FAQPage",[105,111,115],{"name":106,"@type":107,"acceptedAnswer":108},"Why does the paper criticize the traditional development process for mechatronic systems?","Question",{"text":109,"@type":110},"It is viewed as inappropriate for products with complexity, dynamics, and uncertainty, especially as software plays an ever-increasing, driving role in innovation and competitive advantages.","Answer",{"name":112,"@type":107,"acceptedAnswer":113},"What is the difference between design specifications and analysis specifications in this context?",{"text":114,"@type":110},"Design specifications describe the solution space, while analysis specifications describe the problem space, including requirements specifications and problem-space structuring via analysis models.",{"name":116,"@type":107,"acceptedAnswer":117},"How does the proposed approach handle narrative requirements?",{"text":118,"@type":110},"It formalizes narrative system requirements by refining and extending them through a model-centric, integrated logical reasoning and incidence matrix framework, producing requirements that are complete, unambiguous, traceable, and verifiable.","https://schema.org",{"og:url":78,"og:type":121,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":123,"canonical":78},"index,follow",{"doc_id":125,"site_id":56},240943,1791737067,{"code":4,"msg":5,"data":128},{"doc_id":125,"user_id":129,"nickname":88,"user_avatar":130,"doc_module":9,"category_id":8,"category_name":11,"doc_title":59,"doc_description":61,"doc_content":131,"file_id":132,"file_url":133,"file_type":134,"file_size":135,"view_count":101,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":15,"language":136,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":137,"faqs":138,"seo_title":139,"seo_description":61,"update_tm":140,"read_time":79},2336475401981,"https://ap-avatar.wpscdn.com/avatar/22000c94efd8d5204d?x-image-process=image/resize,m_fixed,w_180,h_180&k=1786935347598174694","INTERNATIONAL DESIGN CONFERENCE-DESIGN 2010 Dubrovnik-Croatia, May 17-20, 2010.  \nFROM REQUIREMENTS TO DESIGN  \nSPECIFICATIONS-A FORMAL APPROACH  \nW. Brace and K. Thramboulidis  \nKeywords: requirements, requirements checklist, design specification, requirements formalization, model-centric requirements engineering  \n1. Introduction  \nThe traditional development process for mechatronic systems is criticized as inappropriate for the development of systems characterized by complexity, dynamics and uncertainty as is the case with today’s products. Software is playing an always increasing role in the development of these systems and it has become the evolving driver for innovations. It does not only implement a significant part of the functionality of today’s mechatronic systems, but it is also used to realize many of their competitive advantages [Thramboulidis 2009] . However, the current process is traditionally divided into software, electronics and mechanics, with every discipline to emphasize on its own approaches, methodologies and tools. Moreover, vocabularies used in processes and methodologies are different making the collaboration between the disciplines a great challenge.  \nSystem development activities such as requirements and design specification, implementation and verification are well defined in software engineering. In terms of software engineering the term“design specification” is used to refer to the various models that are produced during the design process and describe the various models of the proposed solutions. Therefore,“design specifications”are descriptions of solution space while “analysis specifications” are descriptions of problem space. Analysis specifications include both requirements specifications but also the problem space structuring that is represented by analysis models such as class diagrams that capture the key concepts of the problem domain and in this sense they provide a specific structuring of the problem space. Dorst and Cross (2001) emphasize on the co-evolution of problem and solution spaces up to the point of time that a match will be found, and consider artefacts of both spaces very important. However, it is clear that the most important are the ones of the problem space since it is not possible to have an acceptable system even with the best solution space if this is based on an incorrect problem space formulation. On the other hand it is possible to have an acceptable system, even without a very good solution space formulation assuming that this is based on a correct problem space model. It is clear that both activities i.e. those involved in problem space formulation (problem space structuring) as well as those involved in solution space formulation include design decisions. Requirements engineering along with domain analysis improve the knowledge on the problem space and make the reasoning steps during the subsequent design process more effective. A well defined model-driven process in software engineering might result at the end to the automatic synthesis of the executable code [Douglas 2006] . Such type of formal processes has not been obtained in engineering design. This is due to the fact that knowledge in engineering design is still more empirical and concepts are not defined with the precision and uniformity as in the software engineering domain. In addition, the role of knowledge management in the early development phases has to be intensified due to increased systems complexity, and more demanding productivity requirements and competitiveness.  \nDESIGN METHODS 639  \nRaw requirements, i.e. requirements that have not been analyzed and formulated, are usually expressed in narrative format. These narrative requirements (NR) provide the foundation for the design efforts but do not necessarily provide the complete knowledge required for the subsequent design process. Therefore it is important to analyze and formulate them to become abstract, unambiguous, traceable, and validata","cbCaihF3yqyIleo9","https://ap.wps.com/l/cbCaihF3yqyIleo9","pdf",1088131,"English","# 1. Introduction\n## From requirements to design specifications - a formal approach","[{\"question\":\"Why does the paper criticize the traditional development process for mechatronic systems?\",\"answer\":\"It is viewed as inappropriate for products with complexity, dynamics, and uncertainty, especially as software plays an ever-increasing, driving role in innovation and competitive advantages.\"},{\"question\":\"What is the difference between design specifications and analysis specifications in this context?\",\"answer\":\"Design specifications describe the solution space, while analysis specifications describe the problem space, including requirements specifications and problem-space structuring via analysis models.\"},{\"question\":\"How does the proposed approach handle narrative requirements?\",\"answer\":\"It formalizes narrative system requirements by refining and extending them through a model-centric, integrated logical reasoning and incidence matrix framework, producing requirements that are complete, unambiguous, traceable, and verifiable.\"}]","INTERNATIONAL DESIGN CONFERENCE - DESIGN 2010 - FROM REQUIREMENTS TO DESIGN | PDF",1789167831]