This content will become publicly available on October 6, 2025
- PAR ID:
- 10538216
- Publisher / Repository:
- IEEE
- Date Published:
- Subject(s) / Keyword(s):
- Requirements Management Documentation Software Engineering
- Format(s):
- Medium: X
- Location:
- Flagstaff, Arizona
- Sponsoring Org:
- National Science Foundation
More Like this
-
Software engineering practices such as constructing requirements and establishing traceability help ensure systems are safe, reliable, and maintainable. However, they can be resource-intensive and are frequently underutilized. To alleviate the burden of these essential processes, we developed the Requirements Organization and Optimization Tool (ROOT). ROOT centralizes project information and offers project visualizations and AI-based tools designed to streamline engineering processes. With ROOT's assistance, engineers benefit from improved oversight and early error detection, leading to the successful development of software systems.more » « less
-
Modeling from the perspectives of software engineering and systems engineering have co-evolved over the last two decades as orthogonal approaches. Given the central role of software in modern cyber-physical systems and the increasing adoption of digital engineering practices in complex systems design, there is now significant opportunity for collaborative design among system users, software developers, and systems engineers. Model-based systems engineering (MBSE) and systems modeling languages can support seamless cross-domain connectivity for design, simulation, and analysis of emerging technologies such as Augmented Reality (AR). This paper presents a co-design process for extending the capability of an existing AR application referred to as a No-Code AR Systems (NCARS) framework. NCARS enables content developed by multi-domain authors to be deployed on AR devices through a software layer that bridges the content to the game engine that drives the AR system. Utilizing a software dependency diagram of the AR Annotation function, an existing MBSE model of the AR system is extended to include the structure and behavior of relevant software components. This allows a modular design of the system to address needs in integrating new requirements into the existing application. New user requirements for tracking items in motion in the user’s physical environment with virtual annotations in the augmented space are collaboratively designed and visualized through use case, block definition, internal block, and sequence diagrams. They capture the required structure and behavior of the proposed to-be system.more » « less
-
Abstract—Many organizations use internal phishing campaigns to gauge awareness and coordinate training efforts based on those findings. Ongoing content design is important for phishing training tools due to the influence recency has on phishing susceptibility. Traditional approaches for content development require significant investment and can be prohibitively costly, especially during the requirements engineering phase of software development and for applications that are constantly evolving. While prior research primarily depends upon already known phishing cues curated by experts, our project, Phish Finders, uses crowdsourcing to explore phishing cues through the unique perspectives and thought processes of everyday users in a realistic yet safe online environment, Zooniverse. This paper contributes qualitative analysis of crowdsourced comments that identifies novel cues, such as formatting and typography, which were identified by the crowd as potential phishing indicators. The paper also shows that crowdsourcing may have the potential to scale as a requirements engineering approach to meet the needs of content labeling for improved training tool development.more » « less
-
Implicit Requirements (IMR) identification is part of the Requirements Engineering (RE) phase in Software Engineering during which data is gathered to create SRS (Software Requirements Specifications) documents. As opposed to explicit requirements clearly stated, IMRs constitute subtle data and need to be inferred. Research has shown that IMRs are crucial to the success of software development. Many software systems can encounter failures due to lack of IMR data management. SRS documents are large, often hundreds of pages, due to which manually identifying IMRs by human software engineers is not feasible. Moreover, such data is evergrowing due to the expansion of software systems. It is thus important to address the crucial issue of IMR data management. This article presents a survey on IMRs in SRS documents with the definition and overview of IMR data, detailed taxonomy of IMRs with explanation and examples, practices in managing IMR data, and tools for IMR identification. In addition to reviewing classical and state-of-the-art approaches, we highlight trends and challenges and point out open issues for future research. This survey article is interesting based on data quality, hidden information retrieval, veracity and salience, and knowledge discovery from large textual documents with complex heterogeneous data.more » « less
-
Abstract Developing sustainable software for the scientific community requires expertise in software engineering and domain science. This can be challenging due to the unique needs of scientific software, the insufficient resources for software engineering practices in the scientific community, and the complexity of developing for evolving scientific contexts. While open‐source software can partially address these concerns, it can introduce complicating dependencies and delay development. These issues can be reduced if scientists and software developers collaborate. We present a case study wherein scientists from the SuperNova Early Warning System collaborated with software developers from the Scalable Cyberinfrastructure for Multi‐Messenger Astrophysics project. The collaboration addressed the difficulties of open‐source software development, but presented additional risks to each team. For the scientists, there was a concern of relying on external systems and lacking control in the development process. For the developers, there was a risk in supporting a user‐group while maintaining core development. These issues were mitigated by creating a second Agile Scrum framework in parallel with the developers' ongoing Agile Scrum process. This Agile collaboration promoted communication, ensured that the scientists had an active role in development, and allowed the developers to evaluate and implement the scientists' software requirements. The collaboration provided benefits for each group: the scientists actuated their development by using an existing platform, and the developers utilized the scientists' use‐case to improve their systems. This case study suggests that scientists and software developers can avoid scientific computing issues by collaborating and that Agile Scrum methods can address emergent concerns.