In complex software environments, efective requirements management (RM) is essential for aligning stakeholder needs, managing uncertainty, and maintaining traceability across development stages. While platforms like Jira are widely used, they lack comprehensive native support for core RM functions, leading to reliance on third-party extensions. This paper presents a structured, lifecycle-oriented method for evaluating and selecting RM tools within the Jira ecosystem. Building on established RM functional dimensions, a decision support tool was developed to help users identify the tools best suited to their project-specific needs. The tool enables users to prioritize RM capabilities and compare them against actual tool performance across six lifecycle stages: elicitation, analysis, specification, validation, management, and traceability. Expert feedback validated the relevance and usability of the tool. The findings underscore the importance of structured tool selection in managing RM complexity, especially in environments where no single solution ofers full lifecycle support. The study contributes a replicable approach to RM tool evaluation and ofers practical guidance for improving decision-making in tool adoption and configuration.
Modern software development is defined by escalating complexity driven by globally distributed teams, rapidly evolving requirements, and increased regulatory and business demands. In this context, Requirements Management (RM) has emerged as a strategic function rather than a secondary support activity. RM plays a central role in reducing ambiguity, aligning stakeholder expectations, and ensuring traceability throughout the development lifecycle, thus minimizing costly rework and delivery risks [1, 2].
Although tools like Jira [3] are widely adopted for agile project coordination, their native functionality provides only partial support for formal RM processes. To address these limitations, the Atlassian Marketplace ofers a growing ecosystem of extensions aimed at enhancing RM capabilities within Jira. However, the overlapping, inconsistent, and sometimes opaque feature sets of these tools present a significant challenge to teams seeking solutions aligned with specific project contexts, particularly in high-stakes or compliance-driven environments.
This research addresses that gap by: 1. Evaluating Jira and four Jira-compatible RM tools (rmCloud [4], RMsis [5], EaseRequirements [6], TraceCloud [7]) against six RM lifecycle stages: elicitation, analysis, specification, validation, management, and traceability; lifecycle phases; functional priorities; future improvements. 2. Applying a structured evaluation framework to assess each tool’s functional coverage in these 3. Developing a decision-support tool that helps users select RM tools based on project-specific 4. Validating the selection tool through expert feedback and acknowledging recommendations for
CEUR
ceur-ws.org
By linking project-specific RM needs with actual tool capabilities, this work contributes a practical method for supporting structured, context-aware tool adoption. The outcome helps teams better navigate complexity and improve requirements practices in software projects of varying scale and criticality.
Research on requirements engineering (RE) tools has long emphasized the need for structured evaluation frameworks that account for functionality across the lifecycle. Hofmann et al. [ 8] outlined essential requirements for RM tools, highlighting the importance of features such as change management, traceability, and version control. More recent systematic reviews, such as Fontoura and Otávio [9], continue to document persistent challenges in RM practice and the fragmented tool support available. Several studies have investigated requirements management in agile and large-scale contexts, which are highly relevant to platforms like Jira. Fucci et al. [10] reported on the needs and challenges of platforms to support large-scale requirements engineering, emphasizing the lack of integrated solutions. Kamal et al. [11] examined success factors for agile requirements change management in distributed projects, while Käpyaho and Kauppinen [12] demonstrated how prototyping can enhance agile RE practices. Similarly, Lan and Balasubramaniam [13] conducted an empirical study of agile RE practices, underscoring the need for lightweight but structured tool support. These works establish that agile environments demand tools capable of balancing flexibility with rigorous requirements tracking and validation. Despite the widespread adoption of Jira for agile project management, research directly addressing its suitability for RM is limited. Filion et al. [14] presented an industrial case study on using Atlassian tools for requirements management, showing their potential but also exposing limitations in areas such as traceability and specification. More recently, Raatikainen et al. [ 15] highlighted the challenges of managing issue dependencies in large collaborative projects, a problem highly relevant to Jira’s issue-tracking foundation.
To validate this gap, a targeted literature search was conducted across Google Scholar, IEEE Xplore, ACM Digital Library, ScienceDirect, Cambridge Journals Online, Wiley Online Library, and O’Reilly. Search queries included “Jira requirements management”, “requirements engineering tools in Jira”, “Jira plugins for requirements management”, “requirements traceability in Jira”, and “Jira marketplace requirements”. The search did not return studies that systematically evaluate Jira-compatible RM extensions. This lack of research confirms that while generic RE tool assessments exist, there is no dedicated guidance on how Jira Marketplace tools address RM shortcomings.
This paper builds on lifecycle-oriented evaluation approaches [16] but extends them by applying a structured functional framework specifically to Jira-compatible tools. By combining lifecycle-based assessment with a decision-support tool that integrates project-specific priorities, it bridges the gap between generic RE tool surveys and the plugin-driven ecosystem of Jira, ofering actionable guidance for practitioners.
To efectively support RE in complex projects, it is essential to understand how each stage of the RM lifecycle maps to the actual capabilities of Jira. This chapter examines how Jira’s built-in components align with the six core RM phases elicitation, analysis, specification, validation, management, and traceability highlighting their functional roles across the project lifecycle.
The lifecycle-oriented method presented in this study is not bound to a specific software development methodology. While Jira is commonly used in agile contexts, the evaluation framework applies equally to other lifecycle models. The term “lifecycle-oriented” refers to the alignment of tool capabilities with the six established RM stages elicitation, analysis, specification, verification and validation, management and tracebility rather than to a particular development model. RM spans multiple interrelated activities throughout the project lifecycle, each aimed at ensuring that stakeholder needs are captured, understood, and fulfilled efectively [ with specific Jira features. 17]. As summarized in Table 1, each phase of the RM lifecycle is associated
The process begins with elicitation - gathering the foundational knowledge needed to define solution expectations. This includes identifying system goals, user concerns, and relevant constraints, forming the basis for further analysis [17]. In Jira, this is supported by components such as Forms, which collect structured input from stakeholders; the Backlog, which organizes early-stage requirements; and Goals, which define intended outcomes.
In analysis stage, requirements are clarified, organized into logical categories, and reviewed for conflicts [ 17]. Reaching consensus among stakeholders is essential, especially when priorities or expectations diverge. A clear, consistent requirements set is necessary to define a viable solution strategy. In Jira, this is supported by components such as the Backlog, where items are reviewed and prioritized; Kanban and Board, which help visualize task flow and identify bottlenecks; Forms, which ensure consistent input for updates; and Goals, which provide alignment with business objectives. Additionally, Estimation allows for evaluating efort, while Reports ofer insights into requirement trends and progress.
Specification involves formally documenting requirements in a way that aligns with their intended use and audience [17]. Specifications can vary in format and level of detail but serve as both a knowledge base and a reference for managing future changes or uncertainties in system development. In Jira, this is supported by components like Forms, which standardize input formats; All Work, which provides a comprehensive overview of all documented items; and the Backlog, where specified requirements are stored and structured for future development.
Validation ensures that requirements are accurate, feasible, and aligned with business goals [17]. Because most requirements originate from human input often informal or ambiguous validation is a critical filter, ensuring that decision-making rests on well-defined, traceable information. In Jira, this process is supported by Estimation, which helps evaluate implementation efort; the Backlog, where requirements can be reviewed before development; Forms, which support structured approval workflows; and Reports, which provide insights into progress, quality, and completion status.
Management stage includes structuring requirements in repositories, applying metadata (such as status or priority), and ensuring version control [17]. This supports both day-to-day coordination and long-term adaptability. In Jira, this is supported by multiple components: the Backlog enables tracking and reprioritization of ongoing work; Summary provides a high-level project snapshot; Board and Kanban views manage real-time task flow; Sprint organizes iterative work; All Work centralizes access to tasks; Calendar tracks timelines and deadlines; and Reports provide structured insights into team performance and project health.
Traceability connects requirements to related deliverables such as test cases, designs, and strategic objectives [17]. It plays a central role in impact analysis, especially when requirements change. Without a functioning traceability framework, it becomes dificult to maintain project coherence or ensure that the solution fulfills its intended purpose. In Jira, traceability is supported by the Board, which provides a clear visual representation of work status; the List, which enables structured tracking of individual items; Goals, which connect requirements to strategic outcomes; Kanban, which manages flow and dependencies; and All Work, which ofers visibility into related issues. Although traceability is often categorized in literature as a sub-activity of requirements management, in this study it is treated as a distinct stage. This separation is motivated by its cross-cutting role across lifecycle phases and its explicit implementation in many Jira plugins, making it more practical to evaluate as independent functionality.
While this section mapped the RM lifecycle stages to Jira’s built-in components, such alignment is not suficient for conducting a structured evaluation or comparison. To transition from descriptive mapping to functional assessment, it is necessary to establish a concrete set of evaluation criteria. These criteria must capture the essential activities and quality objectives associated with each phase of the RM lifecycle.
The study ”Requirements Engineering Tools: Capabilities, Survey and Assessment ” [16] proposed a classification framework for evaluating RM tools based on the functional aspects they support across diferent stages of the RM lifecycle. Building on this framework, this work adopts and refines these functional dimensions to establish a consistent set of evaluation criteria. An overview of these criteria, organized by lifecycle stage and accompanied by their abbreviated labels (shown in brackets), is presented in Table 2. These labels are used throughout the remainder of the analysis to ensure clarity and traceability across tool comparisons.
To assess Jira’s ability to support key RM functions, each stage of the RM lifecycle was evaluated using a structured scoring system. The evaluation focused on determining which functional aspects Jira provides fully, supports partially, or lacks entirely. This method enables a precise understanding of how Jira performs across each phase and where it may require additional configuration or third-party tools to meet project needs.
Each RM function was rated on a three-point ordinal scale: • 2 – Fully Supported: the function is available and usable without significant modification. • 1 – Partially Supported: the function is available but requires manual configuration, workarounds, or has limited scope.
• 0 – Not Supported: the function is unavailable or cannot be meaningfully implemented.
This structured approach allows for a clear comparison of Jira’s built-in and configurable components across six RM stages: elicitation, analysis, specification, verification & validation, management, and traceability. It highlights both Jira’s current strengths and functional limitations in supporting comprehensive RM practices, especially in complex project environments.
The scoring was conducted by the author based on hands-on testing of the tools, supported by vendor documentation and trial usage.
Elicitation involves identifying stakeholders and gathering preliminary requirements in various formats [16]. In Jira, stakeholder engagement begins with user and role assignments, enabling collaboration and access control. Tools such as Forms support structured input, while Backlog and Goals help organize early-stage needs. However, Jira lacks native mechanisms for capturing diferent requirement types (e.g., business vs. technical), requiring users to manually configure issue types and custom fields. Conclusion: Jira provides partial support for elicitation. While stakeholder identification and basic input collection are manageable, the system does not inherently support structured or diverse requirement capture. (See Supplementary Table A1 of [18] for scoring details.)
Analysis phase focuses on breaking down high-level requirements, evaluating feasibility, prioritizing tasks, and resolving conflicts [ 16]. In Jira, Kanban and Board components facilitate decomposition via linked issues and epics. Forms and Backlog support structured planning, while Estimation allows teams to assess efort. Priority can be assigned during issue creation, and conflicting or ambiguous items may be refined iteratively through Sprint planning. Conclusion: Jira ofers strong support for prioritization and feasibility evaluation. With customization, it also accommodates breakdown and conflict detection, although ambiguity resolution remains largely manual. (See Supplementary Table A2 of [18] for scoring details.)
Specification requires the formal documentation of requirements in structured and accessible formats [16]. In Jira, custom issue types and Forms allow users to define and organize requirements. The All Work and Backlog views provide overviews of documented items. However, Jira lacks modeling capabilities or formal specification frameworks out of the box, making it less suitable for projects that require visual or testable requirement structures. Conclusion: Jira partially supports specification. While it enables documentation and organization, it falls short in ofering modeling or formal verification features.(See Supplementary Table A3 of [18] for scoring details.)
Verification and Validation ensures that requirements are complete, and aligned with business goals [16]. In Jira, this is approximated through Estimation, Backlog review, and approval workflows via Forms. However, these features are designed more for task management than RM validation. Conclusion: Jira allows for basic verification and validation activities with component customization. It does not natively provide features for test coverage or requirement reviews beyond general issue tracking. (See Supplementary Table A4 of [18] for scoring details.)
Management involves tracking changes, versioning, and organizing requirements throughout the lifecycle [16]. Jira’s components including Backlog, Summary, Calendar, and Sprint enable dynamic task management and progress tracking. The Board and Kanban views support workflow transparency, while issue history and status fields provide basic traceability. Conclusion: Jira supports RM primarily through its task tracking features. However, dedicated requirement versioning or structured change control is not available by default. (See Supplementary Table A5 of [18] for scoring details.)
Traceability links requirements to related artifacts (e.g., tasks, tests, goals) and allows teams to monitor changes over time. Jira supports issue linking, hierarchical relationships, and change history. Strategic alignment can be visualized using Goals, while tools like Board and List facilitate navigation across dependencies. Still, traceability in Jira requires consistent user discipline or plugin support to maintain reliability over time. Conclusion: Jira provides partial support for traceability. While its linking mechanisms are flexible, they lack the structure required for formal RM processes. ( See Supplementary Table A6 of [18] for scoring details.)
This evaluation reveals that Jira’s native functionality ofers broad but uneven support for RM across the lifecycle. While components like Backlog, Forms, and Kanban enable task-driven requirement tracking, they fall short of meeting the needs of structured RM environments, particularly in specification, validation, and traceability.
These findings underline the importance of context-aware tool selection and motivate further analysis of Jira extensions, which is explored in the next chapter.
This section extends the evaluation logic introduced in Section 5 (Requirements Management Functionality Analysis in the Jira Environment) to selected Jira Marketplace extensions, hereafter referred to as “tools” for simplicity. Although these are technically Marketplace apps, they are assessed in the same way as Jira itself using the structured scoring framework (0–2 scale) that measures the extent to which specific RM functions are supported across the lifecycle.
To identify relevant Jira-compatible tools for RM, a targeted search was conducted in the Jira Marketplace using the keyword phrase “Requirement management.” From this search, four tools were selected for evaluation: • rmCloud [4] • RMsis [5] • EaseRequirements [6] • TraceCloud [7]
These tools were chosen because they are explicitly designed for requirements management, with feature sets clearly targeting RM activities. Selection was further guided by the clarity of their feature documentation and availability for user access (via free trial or demo versions). By applying the same structured comparison framework as in Section 5, the analysis highlights which RM capabilities are directly supported, which require workarounds, and where functional limitations may introduce complexity or risk. While the full evaluation dataset is embedded in the decision-support tool developed for this study, the subsections below summarize each tool’s performance across the six RM phases: elicitation, analysis, specification, verification & validation, management, and traceability. Functional limitations captured in stage-specific “Notes” were not incorporated into the tool’s scoring logic, but they are reported here to aid interpretation of tool suitability.
Elicitation phase for analyzed tools in Jira Marketplace: rmCloud excels in structured requirement entry with fields like title, priority, and type. It also supports traceability during early exploration, but its tendency to duplicate issues when re-linked introduces coordination challenges.
RMsis provides detailed filtering and attribute capture for requirements but lacks stakeholder-specific access or role management.
EaseRequirements uses Jira’s issue types and custom forms to support detailed requirement input. However, it lacks formal mechanisms for traceability during elicitation, relying on informal tags.
TraceCloud enables hierarchical structuring and progress tagging of early requirements, but like most other tools, it lacks stakeholder role visibility and mapping. (See Supplementary Table B1 of [19] for scoring details.)
Notes: • rmCloud creates duplicate Jira issues on re-linking.
• EaseRequirements needs predefined ”requirement” issue type in Jira.
rmCloud supports feasibility evaluation and manual prioritization through configurable fields but lacks mechanisms for identifying ambiguity or conflicts, which limits its efectiveness in high-stakes projects.
RMsis ofers strong support across all analysis functions, including structured sorting and explicit ifelds for conflict and ambiguity tracking though these must still be managed manually.
EaseRequirements enables hierarchical decomposition and uses Jira’s built-in prioritization, but ofers no direct support for feasibility or inconsistency checks, making it less suited for complex analysis tasks.
TraceCloud allows folder-based organization and progress tracking but lacks prioritization and conflict-handling capabilities, reducing its utility for navigating uncertainty. ( See Supplementary Table B2 of [19] for scoring details.)
Notes:
• TraceCloud lacks native prioritization support.
rmCloud provides structured documentation using customizable fields and folders. It enables sorting and categorization and supports basic exports, which help teams communicate and archive specifications. However, it lacks support for formal modeling or approval workflows.
RMsis delivers robust support for specification, ofering detailed data fields (e.g., criticality, dependencies) and baseline history for version control. Requirements can be linked logically or grouped hierarchically, aiding traceability and structured refinement.
EaseRequirements stands out for collaborative specification. It allows sub-requirements, team comments, and versioning directly within Jira. It also supports requirement modeling, making it better suited for distributed teams dealing with complex or evolving systems.
TraceCloud ofers flexible documentation through folders and metadata, with version history and export options. However, it lacks formal approval mechanisms, limiting control over the specification’s state transitions.
Jira itself can be adapted to support requirement specification via custom issue types and fields but does not support formal modeling or consistency checks without third-party extensions. (See Supplementary Table B3 of [19] for scoring details.)
Notes: • EaseRequirements requires Jira permission setup.
• TraceCloud lacks active status change visibility for approval.
rmCloud supports basic validation through change-tracking and status transitions (e.g., “under review”). Although it lacks formal approval workflows or reviewer roles, its visible edit history provides a transparent audit trail.
RMsis enables lightweight validation via a thumbs-up approval and commenting system, making it suitable for fast feedback loops. However, it lacks deeper integration with test cases or automated verification workflows.
EaseRequirements emphasizes traceability but does not provide native support for formal validation or verification steps. Approval processes and test linkage must be managed outside the tool.
TraceCloud allows users to assign validation states like “draft” or “approved” and supports collaborative input via comments. While mostly manual, it provides a basic structure for tracking requirement approval.
Jira, in its default form, ofers limited validation functionality. Requirements can be reviewed and assigned statuses, but structured validation processes require additional customization or plugins. (See Supplementary Table B4 of [19] for scoring details.)
Notes: • rmCloud shows changes but lacks version history. • RMsis only uses a single-icon validation with limited feedback.
• EaseRequirements lacks approval workflow.
rmCloud enables links between Jira issues and requirements, with status tracking and field-level change visibility. However, it lacks full versioning support, which can be limiting in high-complexity projects requiring historical traceability.
RMsis ofers strong change management capabilities, including full version history, dependency tracking, and an activity stream. This makes it well-suited for environments where requirement volatility and traceability are critical.
EaseRequirements supports collaborative editing and centralized visibility. While it doesn’t ofer native versioning, it leverages Jira’s built-in tracking (e.g., activity logs), making it efective in teams already embedded in the Jira ecosystem.
TraceCloud allows status updates and version comparisons but lacks detailed change tracking or rollback capabilities, reducing its efectiveness in projects with frequent requirement evolution.
Jira ofers basic support through issue status changes and activity logs, but dedicated requirement change management features must be configured or added via plugins. ( See Supplementary Table B5 of [19] for scoring details.)
Notes: • rmCloud change history limited.
• EaseRequirements relies on Jira for full audit trail.
rmCloud supports traceability via baselines and a traceability matrix that links requirements to Jira issues. While helpful for visibility, it lacks editable baselines and relies on manual updates for historical tracking.
RMsis provides strong end-to-end traceability. It includes a matrix for visualizing dependencies, supports both internal and external links, and maintains full version history making it well-suited for high-regulation or safety-critical environments.
EaseRequirements ofers comprehensive traceability, including link matrices, version history, and detailed logs of user actions. Each requirement can reference artifacts and change data, enabling transparent audit trails and impact assessments.
TraceCloud uses a hierarchical folder structure and status tracking to maintain full forward and reverse traceability between requirements and related Jira items. Version control is preserved, supporting in-depth change analysis.
Jira, without extensions, provides basic traceability through issue linking and activity history. It requires configuration or plugins for deeper lifecycle documentation and trace relationships. ( See Supplementary Table B6 of [19] for scoring details.)
As software projects grow in scope and complexity, selecting the right tools for managing requirements becomes increasingly critical. This paper, addresses this challenge by introducing a structured method for aligning tool selection with the functional priorities of a given project.
To support this aim, a decision-support tool was developed [20] (available in Latvian) to help users evaluate Jira Marketplace tools based on how well they fulfill core RM functions across the entire lifecycle. The tool builds on the RM functional dimensions proposed [16] and applies them specifically to Jira-compatible tools evaluated in this study.
The selection tool operates through a two-level evaluation repeated for each functionality within the RM lifecycle: 1. Importance rating. For every RM stage, the user rates its importance for the project on a scale from 1 (least important) to 5 (most important). This ensures that project-specific priorities are explicitly captured rather than assumed. 2. Tool performance rating. For the same functionality, the user then evaluates how well each of the analyzed Jira tool supports it by providing a description how the app provide this functionality. This is done on a scale from 1 (least efective) to 10 (most efective). The evaluation is repeated for all tools and all functionalities within the lifecycle stage.
This nested procedure is applied across all RM lifecycle stages. To ensure relevance, only RM functions that demonstrated at least minimal tool support (score ≥ 1) looked at in section Evaluation of Jira-Compatible Requirements Tools are included in the interface. This filtering reduces noise and allows the tool to focus only on features with real world application. Notably, partially supported functions (rated 1) are retained in the evaluation, as they still contribute significantly to user experience, configuration efort, and practical decision-making (see Figure 1).
The tool then aggregates results by multiplying the importance rating (
Result = ∑=1 × , , where denotes the importance assigned to functionality , , the rating of tool for functionality , and the total number of evaluated functionalities.
This design ensures that the ranking reflects not only objective tool capabilities but also the relative
importance of each functionality in a specific project context. To avoid bias, the tool is designed so that
users do not know which Jira app they are rating during the evaluation. For each functionality, the
interface presents descriptive text blocks in a fixed but anonymous order (internally corresponding
to rmCloud, RMsis, EaseRequirements and TraceCloud). The user only sees the description and then
provides a performance rating (
Finally, the system generates a ranking in which the tool with the highest total score is presented as the most suitable option for the given project context. In addition, partial scores are provided per lifecycle stage to highlight relative strengths and weaknesses of each tool.
To assess the usability and efectiveness of the developed tool, two domain experts a business analyst and a senior project manager were invited to test it and provide feedback. Both regularly work with Jira and are experienced in RM. Overall, the experts found the tool intuitive, easy to navigate, and potentially valuable for supporting tool selection decisions.
The business analyst raised concerns about lengthy descriptions, which could reduce usability. In contrast, the senior project manager found the structure logical and user-friendly. The senior project manager viewed the tool’s structure as logical, but suggested adding visual aids (e.g., screenshots or demo videos) to enhance clarity.
Both experts considered the tool useful in practice: the business analyst emphasized its suitability for smaller-scale projects, while the project manager highlighted its value for less experienced professionals in choosing appropriate RM tools. Suggestions for improvement included adding a comments section for qualitative feedback, providing more concise descriptions of tool functionality, and integrating visual examples.
The expert evaluations reflected difering preferences regarding the suitability of the tools assessed. One expert the business analyst indicated a preference for RMsis, while rmCloud was rated comparatively lower. The second expert the senior project manager favored EaseRequirements, with TraceCloud receiving the lowest overall score in their assessment. These contrasting results illustrate that tool efectiveness is not universally perceived and may depend on users’ roles, experience, and specific project contexts. Both experts, however, emphasized the importance of foundational RM functionalities particularly the ability to define business, user, functional, and non-functional requirements, as well as maintaining traceability and enabling validation.
This paper, Structuring Complexity: Functional Evaluation of Jira Tools for Requirements Management, introduced a structured, lifecycle-oriented method for evaluating and selecting Jira-compatible RM tools based on their functional coverage. Using a standardized scoring model, the study assessed how Jira and four selected Marketplace applications support key RM functions across six lifecycle stages: elicitation, analysis, specification, validation, management, and traceability.
The evaluation revealed that neither native Jira nor any of the assessed tools provide full support across all RM lifecycle phases. While some tools performed well in specific areas such as traceability or specification none ofered complete, out-of-the-box coverage for managing requirements in complex projects. This finding highlights the need for deliberate tool selection based on contextual priorities, supported by structured decision-making.
To address this, a decision-support tool was developed to help users align project-specific RM needs with available tool capabilities. Expert feedback confirmed the tool’s utility while pointing to potential improvements, particularly in the areas of clarity, visual guidance, and result interpretation.
Future work should focus on expanding the evaluation framework to include a broader range of Jira-compatible tools, especially those that ofer AI-assisted or automated RM functions.
Further development of the selection tool could include: • Automating app data retrieval from the Jira Marketplace • Incorporating dynamic warnings for functional limitations - in previous chapter ”Notes” • Improving interface usability through integrated visual examples and context-aware recommendations
Additionally, applying this framework outside the Jira ecosystem could test its generalizability across platforms, while also highlighting how platform constraints shape RM tool functionality. Another important direction is exploring how Jira could be extended with modeling tools that support enterpriselevel RE a functionality currently missing from all tools evaluated in this study, despite Jira’s widespread use in large-scale software projects.
During the preparation of this work, the author used GPT-4o and DeepL for grammar checking, translation, and rephrasing. All AI-assisted outputs were carefully reviewed and revised by the author, who take full responsibility for the final version of the manuscript. [12] M. Käpyaho, M. Kauppinen, Agile requirements engineering with prototyping: A case study, in: Proceedings of the 23rd IEEE International Requirements Engineering Conference (RE 2015), IEEE, Ottawa, Canada, 2015, pp. 334–343. doi:10.1109/RE.2015.7320450. [13] C. Lan, R. Balasubramaniam, Agile requirements engineering practices: An empirical study, IEEE
Software 25 (2008) 60–67. doi: 10.1109/MS.2008.1. [14] L. Filion, N. Daviot, J.-P. Le Bel, M. Gagnon, Using atlassian tools for eficient requirements management: An industrial case study, in: Proceedings of the Annual IEEE International Systems Conference (SysCon), IEEE, Montreal, Canada, 2017, pp. 1–6. doi:10.1109/SYSCON.2017.7934769. [15] M. Raatikainen, et al., Improved management of issue dependencies in issue trackers of large collaborative projects, IEEE Transactions on Software Engineering 49 (2023) 2128–2148. doi: 10. 1109/TSE.2022.3212166. [16] J. Carrillo de Gea, R. Nicolás, J. Fernández-Alemán, A. Toval, C. Ebert, Requirements engineering tools: Capabilities, survey and assessment, Information and Software Technology 54 (2012) 1142–1157. doi:10.1016/j.infsof.2012.04.005. [17] K. Zmitrowicz, Business analysis done right: Lessons learned and pitfalls avoided, 1 ed., Springer
Nature, Cham, 2024. doi:10.1007/978-3-031-62194-9. [18] A. Rozenberga, Table a – jira evaluation results, 2025. URL: https://ej.uz/AppendixA-ARozenberga, [Online; accessed 21-July-2025]. [19] A. Rozenberga, Table b – tool evaluation results, 2025. URL: https://ej.uz/AppendixB-ARozenberga, [Online; accessed 21-July-2025]. [20] A. Rozenberga, Jira rm tool selector (interactive web app), 2025. URL: https://script.google.com/ macros/s/AKfycbzD6VeuRejGDWbOAoBOEkoF8T85QuhdL0tsvHxz3sab/dev, [Online; accessed 21-July-2025].