[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-240206-105":53,"doc-detail-240206-en":126},{"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":119,"head_meta":121,"extra_data":123,"updated_unix":125},105,"en","a-quality-framework-for-agile-requirements-a-practitioners-perspective","A Quality Framework for Agile Requirements - A Practitioner's Perspective","","Verification activities ensure that requirements are specified correctly, yet much existing research addresses only traditional up-front requirements. Agile and just-in-time requirements are inherently incomplete, not fully specific, and can be ambiguous at first, which changes the meaning of correctness. The paper analyzes how agile requirements quality should be verified using both traditional and agile requirements literature, then instantiates an agile quality framework for feature requests and user stories. Qualitative validation with eight Dutch practitioners shows overall positive feedback.",{"@graph":63,"@context":118},[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":51,"@type":70,"position":76},"https://docshare.wps.com/template/general/",3,{"item":78,"name":59,"@type":70,"position":79},"https://docshare.wps.com/template/a-quality-framework-for-agile-requirements-a-practitioners-perspective/240206/",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-quality-framework-for-agile-requirements-a-practitioners-perspective/240206.png","ImageObject",442,249,{"name":88,"@type":89},"Violet","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-09-25","2026-09-11",true,{"@type":98,"interactionType":99,"userInteractionCount":79},"InteractionCounter",{"@type":100},"ViewAction",{"@type":102,"mainEntity":103},"FAQPage",[104,110,114],{"name":105,"@type":106,"acceptedAnswer":107},"Why does agile requirements verification need a different notion of correctness?","Question",{"text":108,"@type":109},"Agile or just-in-time requirements are initially sketches that are incomplete, not fully specific, and may be ambiguous. This makes “correctness” different from the standard used for fully specified up-front requirements.","Answer",{"name":111,"@type":106,"acceptedAnswer":112},"What drives the paper’s main research question?",{"text":113,"@type":109},"The authors did not find a practical implementation of verification for agile requirements quality. This motivates asking how to verify the quality of agile or just-in-time requirements.",{"name":115,"@type":106,"acceptedAnswer":116},"How is the quality framework validated?",{"text":117,"@type":109},"The framework is instantiated for feature requests in open source projects and user stories in agile projects, and then qualitatively validated with eight practitioners from the Dutch agile community, yielding overall positive feedback.","https://schema.org",{"og:url":78,"og:type":120,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":122,"canonical":78},"index,follow",{"doc_id":124,"site_id":56},240206,1789158376,{"code":4,"msg":5,"data":127},{"doc_id":124,"user_id":128,"nickname":88,"user_avatar":129,"doc_module":9,"category_id":50,"category_name":51,"doc_title":59,"doc_description":61,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":79,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":8,"language":135,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":136,"faqs":137,"seo_title":138,"seo_description":61,"update_tm":125,"read_time":79},4398048950312,"https://ap-avatar.wpscdn.com/avatar/400002538284de19e3c?_k=1778320343897328908","A Quality Framework for Agile Requirements: A Practitioner's Perspective  \nPetra Heck  \nFontys Applied University Eindhoven, The Netherlands Email: [p.heck@fontys.nl](p.heck@fontys.nl)  \nAndy Zaidman  \nDelft University of Technology Delft, The Netherlands Email: [a.e.zaidman@tudelft.nl](a.e.zaidman@tudelft.nl)  \narXiv : 1406 .4692v1 [ cs . SE] 18 Jun 2014  \nAbstract—Veriﬁcation activities are necessary to ensure that the requirements are speciﬁed in a correct way. However, until now requirements veriﬁcation research has focused on traditional up-front requirements. Agile or just-in-time requirements are by deﬁnition incomplete, not speciﬁc and might be ambiguous when initially speciﬁed, indicating a different notion of `correctness'. We analyze how veriﬁcation of agile requirements quality should be performed, based on literature of traditional and agile requirements. This leads to an agile quality framework, instantiated for the speciﬁc requirement types of feature requests in open source projects and user stories in agile projects. We have performed an initial qualitative validation of our framework for feature requests with eight practitioners from the Dutch agile community, receiving overall positive feedback.  \nIndex Terms—Just-in-time requirements, SMART, agile, quality framework, veriﬁcation, INVEST, feature requests, user stories  \nI. INTRODUCTION  \nIt is increasingly uncommon for software systems to be fully speciﬁed before implementation begins [1] . As stated by Ernst et al. [2], “The `big design up front' approach is no longer defensible, particularly in a business environment that emphasizes speed and resilience to change”. They observe that increasingly more industry projects treat requirements as tasks, managed with task management tools like Jira or Bugzilla. A similar task-based approach is seen in the agile movement (with e.g. user stories) and in open source projects [3], [4] . In an earlier paper Ernst and Murphy [5] use the term `just-in-time requirements' for this type of requirements. They observed that requirements are “initially sketched outwith simple natural language statements”, only to be fully elaborated (not necessarily speciﬁed in written form) when being developed. In their analysis on requirements engineering for agile development Paetsch et al. [6] conclude that “agile methods tend to err on the side of producing not enough documentation while traditional approaches tend to overdocument. . . . As all agile approaches include at least a minimum of documentation, it is the responsibility of the development team to ensure enough documentation is available for future maintenance.”. By documentation they mean requirements documentation. According to a recent publication by IREB (International Requirements Engineering Board) [7] the documentation formats used in waterfall and agile environments do not differ that much and there is a continuous evolution in  \nthe deﬁnition of quality attributes for requirements. However, they do not explicitly deﬁne the current quality attributes for agile environments. This leads us to investigating the quality attributes for just-in-time requirements documentation in this paper.  \nBoth the Business Analysis Body of Knowledge (BABOK) guide [8] and it's agile extension [9] state that requirements should be veriﬁed before they are validated with stakeholders. In our paper we describe a veriﬁcation framework for agile requirements, thereby following the deﬁnitions of BABOK:“Requirements veriﬁcation ensures that requirements speciﬁcations and models meet the necessary standard of quality to allow them to be used effectively to guide further work. Requirements validation ensures that all requirements support the delivery of value to the business, fulﬁll its goals and objectives, and meet a stakeholder need.”  \nVeriﬁcation activities ensure that the requirements are speciﬁed in a correct way. Standards such as IEEE-830 [10] deﬁne what `correct' means: requirements should","cbCaibo2Y8N66nq8","https://ap.wps.com/l/cbCaibo2Y8N66nq8","pdf",517877,"English","# Introduction\n## Research Motivation and Problem Statement\n## Related Work and Foundations\n## Goal and Research Question","[{\"question\":\"Why does agile requirements verification need a different notion of correctness?\",\"answer\":\"Agile or just-in-time requirements are initially sketches that are incomplete, not fully specific, and may be ambiguous. This makes “correctness” different from the standard used for fully specified up-front requirements.\"},{\"question\":\"What drives the paper’s main research question?\",\"answer\":\"The authors did not find a practical implementation of verification for agile requirements quality. This motivates asking how to verify the quality of agile or just-in-time requirements.\"},{\"question\":\"How is the quality framework validated?\",\"answer\":\"The framework is instantiated for feature requests in open source projects and user stories in agile projects, and then qualitatively validated with eight practitioners from the Dutch agile community, yielding overall positive feedback.\"}]","A Quality Framework for Agile Requirements - A Practitioner's Perspective | PDF"]