1. Motivation: The need for a new requirements authoring tool
Requirements engineering is a cornerstone of the design process, transforming stakeholder needs into actionable, well-defined specifications (Reference Lellan, Morkos, Mocko and SummersMcLellan et al., 2011; Reference Shankar, Morkos and SummersShankar et al., 2012). Effective requirements authoring ensures alignment between project goals and outcomes, while incomplete requirements often result in project delays and cost overruns (Reference Shankar, Morkos and SummersShankar et al., 2012). Despite advancements in computational tools for requirements engineering, significant gaps remain in supporting requirement prioritization, lifecycle management, and authoring using controlled vocabularies (Reference Bao, Yang, Yang and YinBao et al., 2022; Reference Dai, Aurisicchio and ArmstrongDai et al., 2013; Reference Jain, Verma, Kass and VasquezJain et al., 2009; Reference StollerStoller, 1988; Reference Wali and NordinWali & Nordin, 2024). This paper outlines the need for a comprehensive Requirements Authoring Design Enabler (RADE) to address these gaps by integrating features like real-time feedback, controlled vocabularies, and robust change tracking. Design enablers such as the Requirements Boilerplate Sanity Checker (RUBRIC) and the Tracing and Control of Engineering Requirements (TRACER), offer functions like boilerplate conformance and traceability (Reference Arora, Sabetzadeh, Briand, Zimmer and GnagaArora et al., 2013; Reference StollerStoller, 1988). However, these tools lack features for iterative refinement or educational support to improve authoring practices. As engineering projects grow increasingly complex, there is a need for a unified tool that bridges these gaps, ensuring high-quality requirements authoring and lifecycle management. For this design enabler, the initial stakeholder set includes capstone design students with limited formal instruction in requirements authoring. The specific requirements on the design enabler are extracted from the following literature review.
2. Elicited requirements for RADE
Engineering requirements serve as a bridge between stakeholder needs and project execution, guiding teams through the design and development process (Reference Mattson and SorensenMattson & Sorensen, 2020; Reference Ullman, Summers and FieldingUllman et al., 2024). These requirements must be clear, complete, and actionable to ensure project success. Incomplete or poorly written requirements often result in misaligned goals, increased costs, and delays (Reference Mullis, Chen, Morkos and FergusonMullis et al., 2024). A well written requirement, at a minimum, includes a subject, verb, and modality (Reference Joshi and SummersJoshi & Summers, 2015a). Additional elements, such as an object and adjuncts, enhance clarity and specificity (Reference Joshi and SummersJoshi & Summers, 2015a). Consider the requirement: “The tool must have a controlled vocabulary with no synonyms”. “The tool” is the subject; “must” is the modality; “[to] have” is the verb; “a controlled vocabulary” is the object; and “with no synonyms” is the adjunct describing the object. Without the object, the requirement lacks meaning while the adjunct adds details. Requirements can also be reformulated in multiple ways to convey the same information such as:
1. The tool must have a controlled vocabulary.
2. The controlled vocabulary must not include synonyms.
Requirements evolve throughout the project lifecycle, with changes such as splitting, refining, adding, or deleting requirements impacting project outcomes (Reference Morkos, Shankar and SummersMorkos et al., 2012). Capturing these changes is critical for understanding the relationship between requirement evolution and project health (Reference Asgher-Nadeem, Hasnain, Saleemi, Awais-Mohsin, Adeel-Ansari and EssalahAsgher-Nadeem et al., 2024). For instance, tracking changes helps identify the propagation of requirement modifications and their influence on cost and timelines.
To address these challenges, 28 specific requirements justified with relevant literature were elicited for the development of RADE (Table 1). These requirements ensure that users write complete requirements while also supporting future project management and reasoning.
Table 1. Elicited requirements for RADE
3. Comparative analysis of existing tools
Table 2 presents a comparative analysis of 15 existing tools alongside RADE to illustrate identified gaps and feature support. Requirements engineering involves critical activities such as elicitation, modelling, analysis, validation, verification, and management, all of which shape the success of a design project (Reference Barcelos, Antonino and NakagawaBarcelos et al., 2024; Reference Umar and LanoUmar & Lano, 2024). Requirements play a significant role in the design process by establishing a clear understanding between stakeholders and project teams (Reference Ullman, Summers and FieldingUllman et al., 2024).
Table 2. Comparative analysis of requirements modelling tools
A robust requirements management tool must facilitate these activities throughout the project lifecycle, enabling users to track changes, prioritize requirements, and ensure clarity and consistency. Despite the availability of various requirements modelling tools, significant gaps persist. Many existing tools excel in specific areas, such as documentation or tracking changes, but fail to integrate all essential features (Reference Bao, Yang, Yang and YinBao et al., 2022; Reference Dai, Aurisicchio and ArmstrongDai et al., 2013; Reference Jain, Verma, Kass and VasquezJain et al., 2009; Mich & Garigliano, 2000; Reference StollerStoller, 1988; Sud, 2003; Reference Wali and NordinWali & Nordin, 2024). RADE was developed to fill this void, providing comprehensive support for feedback, boilerplate guidance, change tracking, prioritization, lifecycle management, and controlled vocabulary.
Existing requirements modelling tools provide valuable but fragmented support for requirements engineering. RADE integrates critical functionalities; real-time feedback, boilerplate guidance, change tracking, prioritization, lifecycle management, and controlled vocabularies—into a single, user-friendly platform. By doing so, RADE positions itself as a holistic solution to modern requirements engineering challenges.
3.1. Feedback
Providing real-time feedback helps users refine their requirements while writing (Reference Wang, Mitchell and PiechWang et al., 2024). Tools like LOLITA and QuARS provide limited feedback, primarily focused on detecting ambiguities (Reference Fabbrini, Fusani, Gnesi and LamiFabbrini et al., 2001; Mich & Garigliano, 2000). For instance, LOLITA identifies lexical and sentence ambiguities, offering guidance to improve clarity (Mich & Garigliano, 2000). Similarly, QuARS detects defects such as vagueness and under specification (Reference Fabbrini, Fusani, Gnesi and LamiFabbrini et al., 2001). However, these tools lack the ability to ensure compliance with boilerplate structures or provide actionable error messages. RADE enhances this capability by offering immediate feedback for incomplete requirements.
3.2. Boilerplates guidance
Boilerplates provide standardized templates for writing requirements, which ensures consistency across requirement documents (Reference Ibrahim, Kadir and DerisIbrahim et al., 2014). By guiding authors through predefined structures, boilerplates simplify the process of creating requirements that are clear, actionable, and aligned with industry standards (Reference Antoniou, Kravari and BassiliadesAntoniou et al., 2024; Reference Lim, Chiew, Su, Ong, Subramaniam, Mustafa and ChiamLim et al., 2024). Tools like RCT and RUBRIC adopt established templates, such as those from the International Requirements Engineering Board (IREB), to support this standardization (Reference Arora, Sabetzadeh, Briand, Zimmer and GnagaArora et al., 2013; Reference Wang, Mitchell and PiechWang et al., 2024). However, these tools often rely on static templates that may not be easily customizable or user-friendly. RADE advances this functionality by incorporating dynamic boilerplates directly into its interface, using structured columns that guide users through the requirement-writing process. This approach ensures that every requirement includes critical components—such as subject, verb, and modality—while allowing flexibility for user-specific needs, such as custom object or adjunct fields.
3.3. Change tracking
Requirements often evolve during a project due to shifting stakeholder needs, unforeseen constraints, or technological advancements (Reference Morkos, Joshi and SummersMorkos et al., 2019). Effective change tracking allows teams to document these modifications and analyse their impact on project goals (Reference StollerStoller, 1988). Tools like TRACER and Telelogic DOORS provide hierarchical tracing of requirements, enabling users to follow the propagation of changes from parent to child requirements (Reference Lellan, Morkos, Mocko and SummersMcLellan et al., 2011; Reference StollerStoller, 1988; Sud, 2003). This feature is particularly useful for impact assessments, as it highlights dependencies and potential conflicts (Sud, 2003). These tools can be complex to set up and require significant manual effort to maintain traceability. RADE simplifies change tracking by integrating dedicated columns for adding, modifying, or deleting requirements. Each change is date-stamped, ensuring a complete history of requirement evolution. This functionality not only supports traceability but also enables teams to monitor trends in requirement modifications, such as frequent additions or deletions.
3.4. Prioritization
Prioritization is a critical feature for managing competing requirements, particularly in resource-constrained projects (Reference Berntsson Svensson and TorkarBerntsson Svensson & Torkar, 2024). Existing tools like Starbase Caliber-RM and Rational Suite AnalystStudio use attributes such as cost, value, or risk to rank requirements (Sud, 2003). These rankings help teams focus on high-impact requirements that deliver the greatest value to stakeholders. However, prioritization in these tools is often subjective, relying heavily on user inputs without standardized criteria. RADE addresses this challenge by introducing a criticality scale, where requirements are classified into three levels of importance: low, medium, and high. This scale is intuitive and aligns with common project management frameworks, allowing teams to quickly identify critical requirements and allocate resources accordingly (Reference Ullman, Summers and FieldingUllman et al., 2024).
3.5. Project lifecycle management
The lifecycle of a requirement extends from its initial elicitation to its validation, implementation, and eventual retirement (Sud, 2003). Effective lifecycle management ensures that requirements remain relevant, aligned with project goals, and adequately documented at each stage (Reference HalbleibHalbleib, 2003; Reference Hoffmann, Weber and BittnerHoffmann et al., 2004). Tools like Telelogic DOORS offer multi-level traceability, assigning states (e.g., “new,” “in review,” or “approved”) to requirements, while Starbase Caliber-RM maintains version histories for easy comparison of changes over time (Sud, 2003). While these features are valuable, they often operate in silos, requiring manual effort to integrate with other project management tools. RADE enhances lifecycle management by combining tracking with date-stamped documentation, ensuring that every change is logged and visible. RADE’s integration with prioritization and controlled vocabulary features allows users to manage requirements holistically, ensuring consistency and relevance throughout the design process.
3.6. Documentation
Documentation is essential for managing requirements across diverse stakeholders and project phases (Reference Behutiye, Rodríguez, Oivo, Aaramaa, Partanen and AbhervéBehutiye et al., 2022). Tools such as RDT 3.0 and Starbase Caliber-RM, provide basic documentation features like traceable links and version control (Sud, 2003). However, these tools often lack flexibility in organizing and presenting requirements, which can hinder accessibility and usability. RADE addresses this limitation by offering multiple views: a database view for granular analysis and a document view for higher-level summaries. Requirements in RADE are organized using serialized numbering and structured fields, making it easy to track relationships and dependencies. Additionally, RADE’s integration of documentation with change tracking and lifecycle management ensures that every requirement is not only well-documented but also kept up-to-date as projects evolve.
3.7. Controlled vocabulary
Controlled vocabularies standardize the language used in requirement statements, reducing ambiguity and ensuring consistency across documents. Tools like Starbase Caliber-RM and RAT employ predefined glossaries to define acceptable terms for specific industries or projects (Reference Jain, Verma, Kass and VasquezJain et al., 2009; Sud, 2003). Starbase Caliber-RM includes glossaries for industry-specific terms, while RAT offers entity and action glossaries for system components and functionalities. However, these vocabularies are often static and may not accommodate project-specific terminology. RADE improves on these features by incorporating two controlled vocabularies. The verb vocabulary classifies requirements as functional or non-functional, while the modality vocabulary captures criticality (e.g., “must,” “should”). Users can also update these vocabularies to reflect unique project needs, providing both standardization and flexibility.
4. RADE: development approach and system architecture
RADE was developed with a robust system architecture (Figure 1) to address the complexities of requirement authoring, management, and lifecycle tracking. Its design prioritizes user accessibility, real-time feedback, and structured documentation, leveraging a macro-enabled Excel workbook as its graphical user interface (GUI). The architecture integrates multiple column types, controlled vocabularies, and feedback mechanisms to ensure high-quality requirements and seamless user interaction.
Figure 1. RADE system architecture
4.1. System architecture
The RADE system architecture consists of automated, hybrid, controlled, and free-text columns, each playing a distinct role in requirement authoring and management. These components are integrated into a boilerplate structure, ensuring consistency and adaptability across projects.
4.1.1. Automated colums
Automated columns perform predefined functions without requiring user input, simplifying the requirement authoring process. The Complete % column calculates the percentage completeness of a requirement by assessing the presence of its components, ensuring users are aware of missing elements. The Functional vs. Non-Functional (F vs NF) column categorizes requirements automatically as either functional, such as actions the system must perform, or non-functional, such as performance criteria. Additionally, the Integrated Requirement column combines key components, including the subject, modality, verb, and predicate phrase into a single, comprehensive requirement statement.
4.1.2. Hybrid columns
Hybrid columns allow for limited user input while maintaining structured options for consistency. For instance, the Subject, Test, Stakeholder, and Owner Lists can be customized by users to reflect project-specific contexts, ensuring adaptability. Change tracking is facilitated by the Add, Modify, Delete, and Restore columns, which capture updates to requirements throughout their lifecycle. These are complemented by the Date column, which tracks changes to aid traceability and historical analysis.
4.1.3. Controlled columns
Controlled columns enforce uniformity by restricting inputs to predefined options derived from controlled vocabularies or standard conventions. The Modality and Verb columns, as core elements of RADE’s controlled vocabulary, ensure consistent phrasing across requirements. The Modality column defines criticality levels, distinguishing between constraints such as “must” and criteria such as “should,” while the Verb column classifies actions as either functional or non-functional. Other controlled columns include the Serial Number, which assigns unique identifiers to each requirement, and the Target Value and Criticality columns, which capture prioritization details, allowing requirements to be ranked based on their importance.
4.1.4. Free-text columns
Free-Text columns provide users with the flexibility to elaborate on requirement details. The Predicate Phrase column allows users to add essential context to a requirement statement, ensuring precision and completeness. Similarly, the Justification column provides space to explain the rationale behind each requirement, fostering transparency and aiding stakeholder understanding.
4.2. Controlled vocabulary
Controlled vocabularies are a fundamental element of RADE’s architecture, ensuring consistency, clarity, and precision in requirement authoring. RADE incorporates two controlled vocabularies: verbs and modalities, both developed through a systematic and rigorous process.
The Verb Vocabulary was created by analysing multiple sources, including a wind turbine requirements repository, NASA’s NPR 7120, and academic studies on design vocabularies (Reference Hirtz, Stone, McAdams, Szykman and WoodHirtz et al., 2002). Overlapping terms from these sources were identified, redundancies removed, and synonyms consolidated, resulting in a refined list of 64 standardized verbs. This vocabulary categorizes requirements as functional or non-functional, aiding classification and analysis.
The Modality Vocabulary focuses on criticality, distinguishing between constraints and criteria. This classification allows users to prioritize requirements based on their necessity and importance within the project scope. By guiding users in selecting appropriate terms, the modality vocabulary ensures uniformity and facilitates decision-making in requirement prioritization. Together, these controlled vocabularies serve as essential tools for minimizing ambiguity, ensuring consistency, and maintaining high standards in requirement documentation.
4.3. Real-time feedback mechanism
Real-time feedback is a critical feature of RADE, designed to enhance the accuracy and completeness of requirement authoring. The system dynamically generates feedback based on the completeness and correctness of user entries, helping to identify and rectify errors during the writing process. For example, if key fields such as Subject, Verb, or Predicate Phrase are left blank, RADE triggers context-specific prompts such as “The Requirement Needs a Subject” or “Please Complete the Requirement.” Additionally, incomplete requirements are flagged in the Complete % column, providing users with a visual cue to address gaps promptly. This feedback loop improves the quality of requirements and functions as an educational tool. By exposing users to best practices in real-time, RADE helps users develop a deeper understanding of structured requirement writing, making it especially valuable for novice authors.
4.4. Change tracking and lifecycle management
RADE integrates change tracking and project lifecycle management features to support iterative and dynamic design processes. These features ensure that requirement documents remain aligned with project goals while adapting to changes over time. The Add, Modify, Delete, and Restore columns, combined with date-stamped Date entries, create a detailed record of requirement evolution. This structured tracking allows users to monitor the history of modifications, facilitating traceability and ensuring accountability throughout the project lifecycle. Requirements are kept relevant and actionable from their initial elicitation to their final documentation.
4.5. Dual-mode interface
RADE enhances usability through its dual-mode interface, catering to technical and non-technical users. The Database View provides a comprehensive display of all requirement fields in a structured format, ideal for detailed analysis, tracking, and technical review. The Document View summarizes requirements, focusing on key elements and justifications, making it well-suited for stakeholder communication. This dual-mode interface ensures accessibility for diverse audiences, allowing teams to seamlessly switch between detailed technical insights and high-level summaries.
5. Implementation of the design enabler
RADE underwent extensive testing across diverse user groups, including pre-service engineers (undergraduate students), the UTDesign-R lab, and the NASA Micro-g NExT team. These testing environments offered valuable insights into the tool’s usability, effectiveness, and areas for improvement. The iterative feedback gathered from these groups informed RADE’s development, driving refinements that enhanced its functionality and overall user experience.
The feedback process was integral to RADE’s iterative development. Undergraduate students using version 1.2 of RADE identified several issues that were addressed in subsequent updates. For instance, inconsistencies in drop-down columns and malfunctions in the real-time feedback mechanism were observed in some workbooks. Users also found certain column definitions unclear and deemed some fields unnecessary. Additionally, the Integrated Requirement column, which concatenated key components such as subject, modality, and predicate phrase, did not display correctly in all cases.
Another area of concern was the data validation setup required in version 1.2, which made updating stakeholder, owner, and test columns time-consuming. To resolve this, version 1.3.1 automated data validation on the back end, allowing users to directly update their options in the vocabulary sheet. These adjustments, along with fixes to other inconsistencies, significantly improved RADE’s usability and functionality. Feedback from the NASA team highlighted the tool’s practical utility but also underscored the need for further enhancements to support large-scale, iterative projects.
6. Conclusions and future work
Requirement modelling tools play a critical role in optimizing the engineering design process, yet many existing tools fail to address key needs such as prioritization, comprehensive lifecycle management, and real-time feedback for requirement authors. RADE was developed to fill these gaps, incorporating features like controlled vocabularies, automated feedback mechanisms, and robust tracking capabilities. Its development involved creating a controlled vocabulary, implementing the authoring design enabler in Excel, writing a user manual, and conducting usability studies.
While RADE has demonstrated significant promise, limitations remain. One challenge is the need to unblock macros when accessing the tool on certain devices, such as tablets. Future work will involve analysing the evolution of requirements authored with RADE in capstone industry sponsored projects. The design enabler will be used to capture historical data, focusing on typology and the balance between constraints and criteria based on (Reference Joshi and SummersJoshi & Summers, 2014; Reference Summers, Joshi and MorkosSummers et al., 2014).
Open access
