[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-246879-105":53,"doc-detail-246879-en":118},{"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":111,"head_meta":113,"extra_data":115,"updated_unix":117},105,"en","a-requirements-elicitation-approach-based-in-templates-and-patterns","A Requirements Elicitation Approach Based in Templates and Patterns","","Requirements elicitation struggles with how to express customer requirements so they are understandable to both requirements engineers and non-computer professional customers and users. Natural language is commonly used but is often unclear due to writing quality and the structure of sentences, while adopting formal notations too early can block comprehension. The paper introduces requirements templates to improve elicitation and expression, plus linguistic patterns and reusable requirements patterns for frequent needs across the process.",{"@graph":63,"@context":110},[64,80,101],{"@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/a-requirements-elicitation-approach-based-in-templates-and-patterns/246879/",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/a-requirements-elicitation-approach-based-in-templates-and-patterns/246879.png","ImageObject",442,249,{"name":88,"@type":89},"Levi","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-10-19","2026-09-12",true,{"@type":98,"interactionType":99,"userInteractionCount":25},"InteractionCounter",{"@type":100},"ViewAction",{"@type":102,"mainEntity":103},"FAQPage",[104],{"name":105,"@type":106,"acceptedAnswer":107},"What do the paper’s templates and patterns contribute to the process?","Question",{"text":108,"@type":109},"The paper presents requirements templates and two reusable pattern types: linguistic patterns that can be parameterized and integrated, and requirements patterns that are generic templates found frequently and adapted to new situations.","Answer","https://schema.org",{"og:url":78,"og:type":112,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":114,"canonical":78},"index,follow",{"doc_id":116,"site_id":56},246879,1791743796,{"code":4,"msg":5,"data":119},{"doc_id":116,"user_id":120,"nickname":88,"user_avatar":121,"doc_module":9,"category_id":8,"category_name":11,"doc_title":59,"doc_description":61,"doc_content":122,"file_id":123,"file_url":124,"file_type":125,"file_size":126,"view_count":25,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":127,"language":128,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":129,"faqs":130,"seo_title":131,"seo_description":61,"update_tm":132,"read_time":47},7971461740909,"https://ap-avatar.wpscdn.com/davatar_155a257f0dc6eb9ab79c44ca47cae57d","A Requirements Elicitation Approach Based in  \nTemplates and Patterns 􀀁  \nA. Durán Toro, B. Bernárdez Jiménez, A. Ruiz Cortés, and M. Toro Bonilla  \nDepartamento de Lenguajes y Sistemas Informáticos, Facultad de Informática y Estadística, Universidad de Sevilla, Avda. Reina Mercedes s/n, 41012 Sevilla, España {amador,beat,aruiz,[mtoro}@lsi.us.es](mtoro}@lsi.us.es)  \nAbstract One of the main problems of requirements elicitation is expressing customer requirements in a form that can be understood not only by requirements engineers but also by noncomputer professional customers and users. The usual choice for expressing elicited requirements is natural language, since it is frequently the only common language to all participants. Problems of natural language are well–known, but using more formal notations too early is a risky choice that can make requirements impossible to understand for customers and users. Moreover, requirements engineers do not usually have good writing skills, and sometimes semantically correct requirements, expressed in natural language, are not understood because of the way they are written. In this paper, we present requirements templates that can improve requirements elicitation and expression, and two kinds of patterns: linguistic patterns, which are very used sentences in natural language requirements descriptions that can be parameterized and integrated into templates, and requirements patterns, which are generic requirements templates that are found very often during the requirements elicitation process and that can be reused with some adaptation.  \nKeywords: requirements engineering, requirements elicitation  \n1 Introduction  \nFollowing [15], requirements elicitation can be defined as the process through which customers and users of a software system discover, reveal, articulate, and understand their requirements. According to [3], problems of requirements elicitation can be classified into three main groups: problems of scope, i.e. deciding the boundary of the system and avoiding unnecessary information, problems of understanding between the communities involved in the process, and problems of volatility since requirements evolve overtime.  \nOne of the main problems of understanding is expressing and recording the requirements in a form that can be understood not only by requirements engineers but also by noncomputer professional customers and users [5, Principle 56] . Current elicitation techniques such as Joint Application Development (JAD), brainstorming or interviews  \n􀀁 This work is funded by the CICYT project \"MENHIR\". TIC 97-0593-C05-01, Ministry of Education and Science (Spain)  \n[15] do not address requirements expression. For example, in JAD and brainstorming sessions, elicited requirements are supposed to remain visible to the participants, but the way those requirements are expressed is not described by these elicitation techniques.  \nThe usual choice for expressing elicited requirements is natural language, since it is frequently the only common language to customers, users and requirements engineers. Problems of natural language are well–known, but using more formal notations too early is a risky choice that can make requirements impossible to understand for customers and users [5, Principles 54, 55 and 56] . Since requirements engineers do not usually have good writing skills, sometimes requirements expressed in natural language are not understood because of the way they are written [5, Principle 51] .  \nIn this paper, we present requirements templates and patterns that can help requirements engineers and users to elicit, express and record information systems requirements using natural language. We have developed requirements templates and identified two kinds of patterns: linguistic patterns (L–patterns), which are very used sentences in natural language requirements descriptions that can be parameterized and integrated into templates, and requirements patterns (R–patterns), which are ","cbCaiaW2rpubIc12","https://ap.wps.com/l/cbCaiaW2rpubIc12","pdf",94170,13,"English","# 1 Introduction\n# 2 Requirements Engineering Model\n## Requirements Elicitation\n## Requirements Analysis","[{\"question\":\"What do the paper’s templates and patterns contribute to the process?\",\"answer\":\"The paper presents requirements templates and two reusable pattern types: linguistic patterns that can be parameterized and integrated, and requirements patterns that are generic templates found frequently and adapted to new situations.\"}]","A Requirements Elicitation Approach Based in Templates and Patterns | PDF",1789238787]