Fact-checked by Grok 2 weeks ago

Requirements engineering

Requirements engineering is the branch of systems and software engineering concerned with the real-world goals for, functions of, and constraints on systems, as well as the relationships of these factors to precise specifications of system behavior and to their evolution over time and across system families.^[1] Requirements engineering emerged in the late 1970s and 1980s as part of structured systems analysis and has since evolved with advancements in software and systems practices.^[1] It involves a systematic process of discovering, documenting, and maintaining requirements to ensure that developed systems meet stakeholder needs effectively.^[2] As a foundational discipline in systems and software development, requirements engineering applies iteratively and recursively across the entire lifecycle, from acquisition and development to operation, maintenance, and disposal.^[2] The core activities of requirements engineering include elicitation, where stakeholders' needs are identified through techniques such as interviews, workshops, and observation; analysis, which involves modeling requirements to detect inconsistencies, incompleteness, and conflicts; specification, the precise documentation of requirements in forms like natural language or formal notations; validation, ensuring requirements accurately reflect stakeholder intentions; and management, handling changes and traceability throughout the project.^[1] These activities draw from multiple fields, including computer science, cognitive and social sciences, and systems theory, making requirements engineering a multidisciplinary, human-centered endeavor.^[1] The IEEE/ISO/IEC 29148 standard emphasizes attributes of good requirements, such as being unambiguous, verifiable, and feasible, to support high-quality outcomes.^[2] Challenges in requirements engineering often stem from dealing with evolving, incomplete, or conflicting stakeholder inputs, particularly for non-functional requirements like performance and security, as well as integrating with system architecture and reuse practices.^[1] Recent advancements incorporate formal methods, using mathematical techniques like temporal logics for analysis, and emerging tools leveraging natural language processing for elicitation in complex domains such as safety-critical systems.^[3] Effective requirements engineering is crucial for project success, as deficiencies here contribute significantly to system failures, underscoring its role in bridging real-world objectives with technical implementation.^[1]

Introduction

Definition and Scope

Requirements engineering is the disciplined application of tools, methods, and practices to discover, elicit, develop, analyze, verify, validate, document, and manage requirements for systems and software throughout their lifecycle.^[2] This process ensures that stakeholder needs are systematically translated into a clear, verifiable set of requirements that guide development without prescribing solutions.^[4] The scope of requirements engineering encompasses both functional requirements, which specify what the system must do—such as processing inputs or performing specific operations—and non-functional requirements, which define how the system performs, including attributes like performance, security, usability, reliability, and maintainability. It focuses on establishing these requirements early to avoid downstream issues, distinctly separating this phase from subsequent design and implementation activities, where solutions are architected and coded based on the agreed requirements.^[5] Within broader systems engineering, requirements engineering serves as a core subset dedicated to capturing and refining stakeholder needs into verifiable system requirements, ensuring alignment across the entire engineering lifecycle from concept to verification.^[4] Key concepts include stakeholder identification, which involves recognizing all parties affected by or influencing the system to gather diverse perspectives; traceability, which maintains links between requirements, their sources, and downstream artifacts to support change management and verification; and requirement attributes such as completeness (covering all necessary aspects without omissions), consistency (free of conflicts), and unambiguity (open to only one interpretation).^[2]^[5]

Historical Development

The origins of requirements engineering as a formal discipline trace back to the 1960s and 1970s, amid the emerging "software crisis" characterized by project overruns, failures, and difficulties in managing complexity for large-scale systems. This period saw increasing recognition of inadequate requirements handling as a core contributor to these issues, exemplified by challenges in projects like IBM's OS/360 operating system and the SABRE airline reservation system. The crisis prompted the first NATO Software Engineering Conference in Garmisch, Germany, in 1968, where participants, including prominent figures like Edsger Dijkstra and Friedrich L. Bauer, highlighted the need for systematic approaches to software development, including better requirements definition to address reliability and maintainability problems.^[6]^[7] By the 1980s, requirements engineering began to formalize with the establishment of standards and guidelines to structure the process. A pivotal milestone was the publication of IEEE Std 830-1984, "IEEE Guide for Software Requirements Specifications," which provided a recommended practice for developing software requirements specifications (SRS), emphasizing qualities like completeness, consistency, and verifiability while offering sample outlines for SRS documents. This standard aimed to assist in both new developments and evaluations of existing software, marking a shift toward documented, traceable requirements practices that could mitigate the ambiguities identified in earlier decades.^[8] The 1990s saw requirements engineering integrate with emerging paradigms, particularly object-oriented methods, which extended modeling techniques from design into requirements analysis to better capture system behaviors and structures. Approaches like those in the Object Management Group’s Unified Modeling Language (UML), introduced in the mid-1990s, facilitated object-oriented requirements specification by incorporating use cases and class diagrams, enabling more modular and reusable representations of stakeholder needs. Influential works further advanced the field: Michael Jackson's Problem Frames (2001) introduced a frame-based approach to analyze and structure software problems by identifying common patterns in requirements contexts, such as required behavior or information display frames, to bridge domain issues with software solutions. Similarly, Axel van Lamsweerde's goal-oriented requirements engineering, detailed in his 2001 IEEE paper "Goal-Oriented Requirements Engineering: A Guided Tour," emphasized modeling requirements as hierarchical goals with operationalization and refinement, supporting elicitation, analysis, and conflict resolution through formal reasoning techniques.^[9]^[10] The early 2000s brought challenges to traditional requirements engineering through the Agile Manifesto (2001), which prioritized "working software over comprehensive documentation" and welcomed changing requirements to harness customer advantage, influencing iterative practices that de-emphasized upfront specification in favor of continuous refinement. Standish Group CHAOS reports from this era and beyond underscored the ongoing impact, attributing a significant portion of project failures—such as the 31.1% cancellation rate in their 1994 analysis—to poor requirements management, reinforcing the need for adaptive yet rigorous approaches.^[11] From the 2010s to 2025, requirements engineering evolved toward collaborative and AI-assisted paradigms, moving away from purely document-centric models to integrated, tool-supported processes that leverage automation for elicitation and validation. The rise of agile and DevOps methodologies fostered collaborative environments with techniques like user story mapping and behavior-driven development, while AI integration—such as machine learning for requirements classification and natural language processing for ambiguity detection—gained traction, with studies showing productivity gains in handling large-scale requirements sets as of 2024-2025.^[12]^[13]

Core Processes

Requirements Elicitation

Requirements elicitation is the foundational process in requirements engineering where analysts systematically gather and discover the needs, expectations, and constraints of stakeholders to form a comprehensive understanding of the system to be developed. This phase emphasizes uncovering both explicit requirements stated directly by stakeholders and implicit ones that may not be immediately apparent. Effective elicitation ensures that the subsequent development aligns with real-world needs, reducing the risk of costly rework later in the project lifecycle.^[14] A variety of techniques are employed in requirements elicitation, each suited to different project contexts and stakeholder dynamics. Interviews involve one-on-one or group discussions to probe deeply into individual perspectives, providing rich qualitative data but requiring skilled facilitators and consuming significant time. Surveys and questionnaires enable efficient collection of responses from large groups, offering broad coverage at low cost, though they often lack depth and may lead to misinterpretations due to fixed response formats. Workshops, such as Joint Application Design (JAD) sessions, foster collaborative discussions among multiple stakeholders to build consensus on high-level features, promoting idea generation and conflict resolution, but they demand high coordination and participant availability. Observation allows analysts to witness users in their natural environment, revealing tacit behaviors and unarticulated needs, particularly useful for novice teams; however, it is time-intensive and raises privacy concerns. Prototyping creates tangible mockups to elicit feedback and validate assumptions, engaging even non-technical stakeholders visually, yet it can be resource-heavy and prematurely shift focus toward design details. Use cases describe system interactions through narrative scenarios, clarifying processes and including diverse inputs, but they may overlook non-functional requirements and require effort to develop comprehensively. Brainstorming sessions encourage free-flowing idea generation from diverse experts to uncover innovative requirements, though they need strong facilitation to avoid dominance by vocal participants and maintain structure. These techniques are selected based on factors like project scale and stakeholder expertise, with interviews being the most frequently documented in literature.^[15]^[16] Stakeholder involvement is central to successful elicitation, beginning with identification of key roles such as end-users who articulate daily needs, clients or sponsors who define business objectives and scope, and domain experts who provide specialized knowledge on technical or regulatory constraints. Methods for identification include stakeholder analysis frameworks that map influence and interest levels, ensuring representation from all affected parties to avoid biases. Conflicts among stakeholders, often arising from differing priorities or perspectives, are handled through inclusive techniques like workshops that facilitate negotiation and prioritization in a group setting, promoting mutual understanding and compromise. Proper engagement requires clear communication of the process, setting expectations for participation, and iterative feedback to build trust and elicit accurate information.^[17] Despite these approaches, requirements elicitation faces significant challenges, including incomplete or ambiguous information due to stakeholders' limited articulation of needs, the difficulty in surfacing tacit knowledge embedded in routines, and scope creep from evolving expectations. Communication barriers, such as jargon mismatches between technical and non-technical parties, hinder effective exchange, while problems in mutual understanding can lead to misaligned interpretations of requirements. Volatility in requirements, driven by changing business environments, further complicates the process, often resulting in overlooked needs if not managed proactively. These issues underscore the need for experienced analysts to adapt techniques dynamically.^[18] The primary outputs of requirements elicitation are raw lists of gathered requirements, often in unstructured or semi-structured formats like notes or initial diagrams, which serve as input for refinement in subsequent analysis phases. These artifacts capture the breadth of stakeholder input, forming the basis for modeling and validation without yet resolving inconsistencies or ambiguities.^[14]

Requirements Analysis

Requirements analysis is the phase in requirements engineering where elicited requirements are systematically examined, refined, and structured to eliminate ambiguities, resolve inconsistencies, and confirm their practicality for implementation. This process transforms raw stakeholder inputs into a coherent set that supports subsequent specification and design activities. According to ISO/IEC/IEEE 29148:2018, requirements analysis encompasses organizing requirements for traceability, identifying conflicts, and evaluating feasibility to ensure the resulting set is complete, consistent, and unambiguous.^[2]

Activities in Requirements Analysis

Key activities include prioritization, conflict resolution, feasibility assessment, and modeling. Prioritization ranks requirements based on business value, risk, and dependencies to guide resource allocation; a widely adopted technique is the MoSCoW method, which categorizes requirements as Must-have (essential for delivery), Should-have (important but not vital), Could-have (desirable if time permits), or Won't-have (out of scope for the current iteration).^[19] This method, originating from dynamic systems development, facilitates decision-making in resource-constrained environments by focusing efforts on high-impact items first.^[20] Conflict resolution addresses discrepancies among requirements, often arising from differing stakeholder perspectives, through negotiation and trade-off analysis. Techniques involve stakeholder workshops to identify inconsistencies, such as overlapping functional needs, and reconciling them via voting, pairwise comparison, or expert mediation to achieve consensus without compromising core objectives.^[21] Feasibility assessment evaluates whether requirements can be realized within technical, economic, and operational constraints, including cost-benefit analysis and risk evaluation to discard or modify unviable items early.^[2] Modeling supports analysis by representing requirements visually; data flow diagrams (DFDs) illustrate how data moves through processes, highlighting interactions and potential bottlenecks, as pioneered by DeMarco and Yourdon for structured analysis.^[22] Entity-relationship (ER) models, introduced by Chen, depict data entities, attributes, and associations to clarify structural requirements and ensure data integrity.

Key Concepts

Requirements must exhibit specific attributes for quality: atomicity ensures each requirement expresses a single, indivisible need; traceability links requirements to their origins and downstream artifacts; and verifiability allows objective testing against criteria.^[2] These attributes, emphasized in ISO/IEC/IEEE 29148, prevent scope creep and enable validation. Non-functional requirements, such as scalability—the system's ability to handle increased load without performance degradation—are analyzed separately to define measurable thresholds, like supporting 10,000 concurrent users with <2-second response time.^[23]

Techniques

Root cause analysis uncovers underlying issues in ambiguous or conflicting requirements using methods like the "5 Whys" to trace symptoms back to sources, improving refinement accuracy.^[24] Prototyping builds executable models to validate assumptions, allowing stakeholders to interact with partial implementations and refine requirements iteratively.^[25] Goal-oriented modeling, exemplified by the KAOS framework, decomposes high-level objectives into sub-goals, agents, and operations to detect obstacles and ensure alignment with system intent.^[9]

Outputs

The primary outputs are analyzed and categorized requirements—functional and non-functional—organized by priority, type, and traceability, ready for formal specification; this refined set minimizes downstream rework and supports verifiable development.^[2]

Requirements Specification

Requirements specification involves documenting the outcomes of requirements analysis in precise, unambiguous formats that facilitate communication among stakeholders and guide system implementation. This process transforms refined requirements into structured artifacts, such as software requirements specifications (SRS), ensuring they are verifiable and traceable. Common formats for requirements specification include natural language templates, structured English, and formal notations. In natural language, requirements are often expressed using imperative statements like "The system shall [perform action]," which promote clarity while remaining accessible to non-technical stakeholders.^[26] Structured English builds on this by employing standardized templates, forms, and restricted syntax to specify logic and constraints, reducing vagueness in describing processes or decisions.^[27] Formal notations, such as the Z schema, use mathematical constructs like set theory and predicate logic to define system states and operations rigorously; however, Z's limitations include a lack of native support for time, concurrency, and complex dynamic behaviors, making it less suitable for certain real-time systems.^[28] The ISO/IEC/IEEE 29148:2018 provides a widely adopted standard for SRS documents, outlining a recommended structure to ensure completeness and usability. Key elements include an introduction covering purpose, scope, definitions, references, and overview; an overall description detailing product perspective, major functions, user classes, constraints, assumptions (e.g., environmental factors like hardware availability), and apportioning of requirements; and specific requirements sections addressing external interfaces, functional behaviors (e.g., input validation and error handling), performance criteria (e.g., response times under load), logical database requirements, design constraints, and software system attributes like reliability and security. The standard emphasizes qualities of a good SRS, such as correctness, unambiguity, completeness, consistency, verifiability, modifiability, and traceability, with annexes offering templates like those organized by user class, feature, or mode.^[2] Best practices in requirements specification incorporate visual aids and traceability mechanisms to enhance understanding and maintenance. UML use case diagrams are particularly effective for illustrating interactions between actors and system functionalities, providing a graphical complement to textual descriptions and aiding in the identification of functional requirements. Traceability matrices, often presented as tables mapping requirements to design elements, test cases, and sources, support impact analysis and verification by linking high-level needs to implementation artifacts.^[29] A prevalent pitfall in requirements specification is linguistic ambiguity, where terms like "all," "any," or "or" allow multiple interpretations, leading to implementation errors and downstream conflicts.^[30] Such ambiguities often stem from overly flexible natural language usage and can be mitigated by adhering to standard templates and formal reviews, though they remain a primary cause of project rework.^[31]

Requirements Validation

Requirements validation is the process of confirming that the documented requirements accurately capture stakeholder needs, ensuring they are complete, consistent, unambiguous, feasible, and testable. This step occurs after requirements specification and focuses on evaluating the requirements artifact to prevent costly rework in later development phases. By involving stakeholders early, validation helps align the requirements with intended system behavior and business objectives.^[32] A key distinction exists between requirements validation and verification: verification assesses whether the requirements document is constructed correctly—checking for adherence to standards, internal consistency, and proper formatting—while validation determines if the requirements describe the correct system that fulfills user expectations and solves the right problem. This separation ensures both procedural correctness (verification) and substantive relevance (validation). In the broader verification and validation (V&V) framework, requirements validation serves as the foundational activity, establishing a reliable requirements baseline that informs subsequent design, implementation, and testing phases, thereby minimizing defect propagation and enhancing overall software quality. According to IEEE Std 1012-2024, V&V processes, including requirements validation, systematically demonstrate that development products conform to activity requirements and intended use.^[33]^[32] Several established techniques support requirements validation, each tailored to detect different types of issues. Reviews, including informal peer reviews and structured walkthroughs, enable stakeholders to collaboratively examine the requirements for clarity, completeness, and alignment with needs; these methods promote discussion and early error identification without requiring additional artifacts. Formal inspections, such as the Fagan inspection process, involve a disciplined team-based review with predefined roles (moderator, author, reader, inspector) to systematically uncover defects like ambiguities or inconsistencies, often limiting sessions to 2 hours with 3-5 participants for optimal effectiveness. Prototyping, either throwaway or evolutionary, allows stakeholders to interact with a tangible representation of the system—such as executable models or simulations—to verify feasibility and elicit feedback on whether the requirements reflect real-world usage scenarios. Additionally, defining acceptance criteria establishes measurable, observable conditions for each requirement, facilitating later traceability and confirmation of fulfillment. Empirical evidence from industry surveys indicates that prototyping and reviews are widely adopted, with usage rates of 54.5% and 51.5% respectively among practitioners, due to their ability to incorporate stakeholder input effectively.^[32]^[32]^[34]^[34] To evaluate the effectiveness of these techniques, metrics such as coverage analysis and defect detection rates are employed. Coverage analysis quantifies the proportion of requirements reviewed, prototyped, or linked to acceptance criteria, ensuring no gaps in validation; for instance, full coverage requires every requirement to be addressed across techniques. Defect detection rates measure the number of issues identified per review or prototype iteration relative to the total defects present, with studies showing that group-based inspections achieve higher detection rates—up to 20-30% improvement over individual reviews—due to diverse perspectives. In Fagan inspections, a rework threshold of more than 5% document changes triggers re-inspection to maintain quality. These metrics provide quantitative insights into validation thoroughness, guiding process improvements and resource allocation.^[32]^[32]

Requirements Management

Requirements management encompasses the systematic activities involved in tracking, controlling, and maintaining requirements throughout the software or systems development lifecycle, ensuring that they remain consistent with project objectives and stakeholder needs.^[2] This process builds on initial requirements validation by establishing baselines of approved requirements, which serve as stable references for subsequent development phases.^[35] Key activities in requirements management include version control, which involves maintaining historical records of requirement changes to allow reversion to previous states if needed, and baselining, the process of approving and freezing a set of requirements at a specific project milestone to control further modifications.^[36] Traceability establishes bidirectional links between requirements, design elements, and test cases, enabling verification that all requirements are addressed and facilitating the identification of dependencies.^[37] Change impact analysis evaluates the effects of proposed modifications on existing requirements, designs, and tests, often incorporating cost-benefit assessments to weigh the value of changes against potential disruptions. Processes for managing changes typically involve a change control board (CCB), a formal group responsible for reviewing and approving modification requests to ensure only justified alterations proceed. This board conducts impact assessments, considering factors such as resource implications and alignment with evolving stakeholder needs, to maintain project integrity. Requirement management systems integrate these activities by providing centralized platforms for versioning, traceability matrices, and automated impact analysis, allowing teams to collaborate on updates while preserving audit trails.^[38] Effective requirements management is crucial for preventing scope creep—the uncontrolled expansion of project scope through unmanaged changes—and ensuring ongoing alignment with business goals, thereby reducing risks of delays and cost overruns.^[39]

Methodologies and Approaches

Traditional Methods

Traditional methods in requirements engineering emphasize structured, plan-driven approaches that prioritize comprehensive upfront planning and detailed documentation to ensure clarity and completeness before proceeding to design and implementation. These methodologies emerged as a response to the complexities of large-scale software development in the mid-20th century, drawing roots from structured programming paradigms of the 1970s and 1980s.^[40] The Waterfall model integrates requirements engineering as a foundational, sequential phase conducted early in the development lifecycle, where all requirements are elicited, analyzed, and specified before any coding begins. Introduced by Winston Royce in 1970, this model structures the process into distinct phases—requirements definition, analysis, design, implementation, verification, and maintenance—with requirements engineering occupying the initial stages to establish a stable baseline that minimizes changes later.^[41] This upfront focus allows for thorough validation of requirements against stakeholder needs, reducing risks associated with incomplete specifications in complex projects.^[41] Structured analysis, a cornerstone of traditional methods, employs graphical notations to model functional and data aspects of the system, facilitating precise decomposition of requirements. Key techniques include data flow diagrams (DFDs) to illustrate how data moves through processes, external entities, and data stores, and entity-relationship diagrams (ERDs) to define data structures and relationships.^[42] The Yourdon/DeMarco notation, popularized in the late 1970s, standardizes DFDs with symbols for processes (circles), data flows (arrows), external entities (rectangles), and data stores (open rectangles), enabling analysts to create hierarchical models from context-level overviews to detailed primitives.^[42] This approach, as detailed by Tom DeMarco in his 1978 work, promotes modular decomposition to ensure requirements are traceable and verifiable.^[42] Complementing DFDs, ERDs—formalized by Peter Chen in 1976 but integrated into structured analysis—model entities, attributes, and relationships to specify data requirements accurately.^[43] Edward Yourdon's extensions in the 1980s further refined these tools for real-time and structured systems design.^[40] The Volere framework provides a comprehensive template-based approach to requirements specification, organizing knowledge into a structured model that categorizes requirements by type, such as functional, non-functional, and constraints. Developed by Suzanne and James Robertson in the 1990s, it includes detailed checklists and forms for capturing project drivers, client requirements, and solution constraints, ensuring all aspects are systematically documented.^[44] The framework's knowledge model uses a wheel diagram to represent interconnected elements like business events and atomic requirements, promoting consistency and completeness in specifications.^[44] These traditional methods are particularly suited to stable, well-understood domains where requirements are unlikely to change significantly, such as safety-critical systems in avionics or medical devices, as they enable rigorous verification and compliance with standards like DO-178C.^[45] In such contexts, the emphasis on exhaustive documentation supports certification processes and risk mitigation.^[45]

Agile and Iterative Approaches

Agile and iterative approaches in requirements engineering represent a shift from rigid, document-heavy processes to adaptive, collaborative practices that integrate requirements activities directly into development cycles, allowing for rapid response to changing needs. These methods, formalized in the 2001 Agile Manifesto, prioritize individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.^[46] In requirements engineering, this translates to ongoing elicitation and refinement rather than exhaustive upfront gathering, enabling teams to deliver value incrementally while minimizing risks associated with incomplete or outdated specifications. A core artifact in these approaches is the user story, a concise, informal description of a feature from the end-user's perspective, serving as a placeholder for discussion rather than a detailed requirement. Coined in the context of Extreme Programming, user stories follow the "3 C's" model—Card (a written summary), Conversation (team dialogue to clarify details), and Confirmation (acceptance criteria for validation)—to foster shared understanding without premature commitment to implementation. The standard template, originating from practices at Connextra, structures stories as: "As a [type of user], I want [some goal] so that [some reason/benefit]."^[47] For larger initiatives, epics are employed as high-level user stories that capture broad functionality too extensive for a single iteration, which are then decomposed into smaller, actionable stories to maintain manageability.^[48] To ensure quality, user stories adhere to the INVEST criteria: Independent (standalone from other stories), Negotiable (open to discussion), Valuable (delivers user or business benefit), Estimable (can be sized by the team), Small (fits within an iteration), and Testable (verifiable through acceptance criteria).^[49] Iterative elicitation occurs continuously through practices like product backlog refinement and sprint planning in Scrum frameworks, where the product owner and development team collaboratively prioritize and detail items from the backlog to align with emerging priorities. Backlog refinement involves breaking down epics and stories, estimating effort, and adding acceptance criteria, typically consuming 5-10% of team capacity per sprint to keep the backlog "ready" without over-specifying.^[50] During sprint planning, the team selects high-priority stories for the upcoming iteration, eliciting further details through discussion to define a sprint goal and forecast deliverables, ensuring requirements evolve based on current context rather than fixed plans.^[50] Lean principles further enhance these approaches by promoting just-in-time requirements elicitation, where details are gathered only as needed to avoid waste from overproduction of specifications or unnecessary features. Adapted from manufacturing to software in Lean Software Development, key tenets include eliminating waste (such as excess documentation or handoffs), amplifying learning through frequent feedback, and deferring commitment until requirements are well-understood, thereby reducing rework and aligning output with actual value.^[51] Post-2001 adaptations emphasize continuous validation via sprint reviews, where teams demonstrate working increments to stakeholders for immediate feedback, allowing requirements to adapt iteratively and incorporate changes without derailing progress.^[50] In iterative contexts, requirements management focuses on backlog evolution, with ongoing refinement ensuring traceability and prioritization amid flux.^[50]

Model-Driven and AI-Enhanced Methods

Model-driven engineering (MDE) approaches in requirements engineering leverage abstract models to systematically capture, analyze, and transform requirements into executable specifications, particularly beneficial for managing complexity in large-scale, interdisciplinary systems. These methods emphasize the creation of models at higher abstraction levels, using standardized languages to represent requirements independently of implementation details. Seminal work in MDE highlights the use of development models—including requirements models—to address the gap between problem domains and concrete artifacts, enabling automated transformations that enhance consistency and reusability.^[52] Key modeling languages include the Systems Modeling Language (SysML) and the Unified Modeling Language (UML), which support the integration of requirements with architectural elements. SysML, an extension of UML tailored for systems engineering, facilitates requirements capture through use case diagrams that group stakeholder needs into functional and non-functional categories, while ensuring traceability via explicit links to model elements. In practice, SysML models requirements as input/output transformations using sequence diagrams for logical behaviors and internal block diagrams for physical interfaces, thereby eliminating the traditional distinction between functional and non-functional requirements and modeling modes via state machines. This approach constructs "true model-based requirements" by applying construction rules derived from mathematical frameworks like Wymore's transformation theory, promoting precise boundary definitions and decomposition.^[53]^[54] Domain-specific languages (DSLs) complement general-purpose modeling by providing tailored syntax and semantics for particular application domains, such as safety-critical systems in aerospace. DSLs enable domain experts to express requirements in a concise, verifiable manner, often integrated into MDE toolchains for automated validation and generation of downstream artifacts like code or tests. For instance, textual DSLs treat requirements as structured source code within version control systems, supporting formal verification and evolution tracking akin to software development practices.^[52]^[55] Goal-oriented requirements engineering (GORE) represents a specialized model-driven paradigm that focuses on modeling stakeholder intentions to drive the RE process from elicitation through specification. The i* framework, a foundational GORE approach, uses actor-oriented diagrams to depict strategic dependencies (e.g., goals, tasks, resources) among agents in socio-technical systems, facilitating the analysis of alternatives, conflict resolution, and refinement of high-level goals into operational requirements. By modeling intentional elements—such as softgoals for non-functional attributes—i* supports early detection of trade-offs and provides a rationale for decisions, unifying fragmented RE practices under a goal-centric perspective.^[56] As of 2025, AI-enhanced methods integrate artificial intelligence techniques to automate and augment traditional RE activities, particularly in handling unstructured data and decision-making under uncertainty. Natural language processing (NLP) is prominently used for automated requirement extraction from textual sources like stakeholder dialogues, emails, or legacy documents, employing techniques such as tokenization, BERT embeddings, and semantic role labeling to identify entities (e.g., actors, use cases) with precisions up to 81%. For example, tools like SyAcUcNER combine NLP with support vector machines to extract system components, achieving 76% recall in classifying requirements from natural language inputs.^[57] Machine learning (ML) further enhances prioritization by applying supervised algorithms, including random forests and gradient boosting, to rank requirements based on multifaceted criteria like cost, value, and dependencies, often outperforming manual methods in accuracy (e.g., up to 100% in release planning scenarios). In anomaly detection, ML models such as convolutional neural networks (CNNs) and BERT classify requirements for inconsistencies or ambiguities, processing large datasets to flag issues like vague phrasing with high precision in industrial contexts. Systematic reviews indicate that these AI applications are increasingly adopted in RE stages like elicitation and management, bridging academia's advanced models with practitioner tools.^[57]^[13] The primary benefits of model-driven and AI-enhanced methods lie in automation and improved quality assurance. Model transformations in MDE automatically generate traceability links—such as 1,178 traces from 390 requirements in healthcare projects—reducing manual effort and maintenance costs while ensuring bidirectional consistency across artifacts. This automation minimizes human-induced errors, such as overlooked dependencies, by detecting conflicts during evolution and supporting impact analysis. AI integration amplifies these gains by accelerating extraction and prioritization, leading to fewer ambiguities and faster validation in complex systems. Overall, these methods have evolved from the manual processes dominant in the 2010s, offering scalable solutions for modern, data-intensive RE challenges.^[58]

Challenges and Criticisms

Common Problems

One of the most prevalent issues in requirements engineering (RE) is the presence of defects in requirements specifications, including volatility, incompleteness, and inconsistencies. Requirements volatility refers to frequent changes in requirements after initial elicitation, often driven by evolving user needs or external factors, and affects more than 70% of large software development programs, leading to increased rework and project risks.^[59] Incompleteness occurs when requirements omit critical details, such as unspecified system behaviors under certain conditions, while inconsistencies arise from conflicting statements within the specification, such as ambiguous natural language descriptions that allow multiple interpretations. These defects are common in natural language-based requirements and can propagate to later development phases, amplifying costs; poor requirements quality can lead to a significant portion of software defects discovered during testing and maintenance.^[60]^[61] Stakeholder-related problems further exacerbate RE challenges, primarily through miscommunication and hidden assumptions. Miscommunication often stems from differing stakeholder perspectives, where technical teams and end-users fail to align on needs, resulting in requirements that do not fully capture domain-specific expectations or lead to overlooked edge cases. Hidden assumptions, such as unstated preconceptions about system performance or integration, can introduce subtle errors that surface later. Additionally, gold-plating— the unauthorized addition of unnecessary features by developers or analysts to enhance perceived value—introduces extraneous elements, bloating the scope without stakeholder approval and diverting resources from core functionalities.^[62]^[63] These RE issues often manifest as broader project impacts, notably scope creep, which involves uncontrolled expansion of project boundaries due to unresolved requirements ambiguities or late changes. Scope creep frequently causes delays, budget overruns, and reduced quality, with unclear requirements and scope creep frequently cited as leading causes of project failures or challenges in Standish Group CHAOS reports. In domain-specific contexts, such as healthcare and finance, evolving regulations compound these problems; for instance, frequent updates to standards like HIPAA in healthcare or SOX in finance require ongoing requirements adjustments, introducing volatility and compliance risks that demand specialized elicitation to track regulatory shifts.^[64]^[65]

Criticisms and Limitations

Traditional requirements engineering practices have faced significant criticism for placing excessive emphasis on comprehensive documentation, often resulting in "analysis paralysis," where teams become mired in exhaustive upfront analysis at the expense of progress. This approach, characterized as "big design up front" by agile proponents, assumes requirements are stable and fully knowable early on, leading to rigid specifications that hinder adaptability in volatile project environments.^[66] Further critiques highlight the challenges in handling uncertainty within complex socio-technical systems, where formal methods in requirements engineering exhibit rigidity that fails to accommodate evolving stakeholder needs or unforeseen risks. Barry Boehm has notably argued that such sequential, documentation-heavy processes overlook the inherent uncertainties in software development, potentially amplifying errors in dynamic contexts rather than mitigating them through iterative risk assessment. In the realm of AI-enhanced requirements engineering, ethical concerns have intensified since the early 2020s, particularly around bias in automated elicitation tools that may embed fairness issues from training data into requirement specifications, perpetuating discriminatory outcomes in system design. Recent analyses underscore how these biases can undermine equitable software development, calling for greater transparency and accountability in AI-driven processes to address potential societal harms. Empirical evidence further underscores these limitations, with studies from NASA revealing that requirements engineering shortcomings contribute substantially to software rework costs; for instance, approximately 40% of unexpected software behaviors in aerospace systems arise from absent or inadequately specified requirements, escalating overall project expenses.^[67]

Tools, Standards, and Best Practices

Supporting Tools

Requirements engineering (RE) relies on a variety of software tools to capture, analyze, trace, and manage requirements throughout the development lifecycle. These tools are categorized primarily into requirement management systems and modeling platforms, each designed to streamline specific RE activities while supporting integration with broader software development environments. As of 2025, the market for RE tools has evolved to emphasize scalability, interoperability, and automation, driven by the need for efficient handling of complex, large-scale projects in industries like aerospace, automotive, and finance. Requirement management tools form the core of RE support, enabling teams to document, prioritize, and track requirements from elicitation to verification. For instance, Atlassian's Jira, widely adopted for agile environments, facilitates RE through customizable workflows, issue tracking, and traceability matrices that link requirements to user stories and defects. Similarly, IBM Engineering Requirements Management DOORS Next provides advanced traceability features, allowing bidirectional linking between requirements, design elements, and test cases to ensure compliance and impact analysis in regulated sectors. These tools often include version control capabilities, which aid in managing requirement changes over time. Modeling tools complement requirement management by visualizing and specifying requirements through diagrams and formal notations. Sparx Systems' Enterprise Architect is a prominent example, supporting Unified Modeling Language (UML) for creating use case, activity, and sequence diagrams that clarify stakeholder needs and system behaviors. It integrates with requirement repositories to generate models directly from textual specifications, reducing ambiguity in RE processes. Other tools like Cameo Systems Modeler extend this to SysML for systems engineering, but Enterprise Architect remains a staple for its extensibility and support for collaborative modeling sessions. Key features in modern RE tools enhance usability and efficiency, particularly in team-based settings. Collaboration functionalities, such as real-time editing and commenting, are standard in tools like Jira and DOORS Next, enabling distributed teams to co-author requirements without version conflicts. AI integrations are increasingly prevalent; for example, IBM Watson's natural language processing (NLP) capabilities within DOORS Next analyze requirement documents to detect inconsistencies, ambiguities, or duplicates automatically, improving quality. These features are particularly valuable in handling unstructured data from stakeholder interviews or legacy specifications. The RE tool landscape includes both commercial and open-source options, influencing selection based on organizational needs. Commercial solutions like Siemens' Polarion offer end-to-end RE with robust reporting, audit trails, and integrations to tools like Git for DevOps pipelines, making it suitable for enterprise-scale deployments in compliance-heavy domains. In contrast, open-source alternatives such as ReqView provide lightweight, customizable requirement tracking with export capabilities to CSV or XML, appealing to smaller teams or those prioritizing cost and flexibility; however, they may require more setup for advanced traceability. Selection criteria often prioritize seamless integration with DevOps pipelines (e.g., CI/CD tools like Jenkins), scalability for large datasets, and support for industry-specific templates to minimize adoption barriers. Post-2020 trends reflect the shift toward cloud-based RE tools to accommodate remote and distributed teams, accelerated by global work changes. Platforms like Jira Cloud and Azure DevOps enable access from any location with features like shared dashboards and API-driven automations, reducing latency in requirement reviews compared to on-premises setups. This evolution supports agile practices without compromising traceability, though it raises considerations for data sovereignty in multinational projects.

Standards and Frameworks

Requirements engineering relies on established standards to ensure consistency, quality, and interoperability in defining and managing system and software requirements. The ISO/IEC/IEEE 29148:2018 standard provides a comprehensive framework for the processes and products involved in requirements engineering throughout the life cycle of systems and software, emphasizing elicitation, analysis, specification, validation, and management activities.^[68] This standard unifies previous ISO and IEEE efforts, offering guidelines for creating verifiable, traceable, and unambiguous requirements specifications suitable for complex engineering projects.^[69] The International Council on Systems Engineering (INCOSE) complements these with practical guidelines tailored to systems engineering contexts. INCOSE's Guide to Writing Requirements outlines rules for crafting clear, necessary, and feasible requirements, aligning with broader systems engineering processes to mitigate common pitfalls like ambiguity and incompleteness.^[70] Through its Requirements Working Group, INCOSE promotes education and best practices that integrate requirements engineering into interdisciplinary system development.^[71] Frameworks such as the Business Analysis Body of Knowledge (BABOK) Guide from the International Institute of Business Analysis (IIBA) extend requirements engineering into business analysis domains. BABOK integrates requirements elicitation, analysis, and management with organizational strategy, providing techniques for stakeholder collaboration and solution evaluation to bridge business needs with technical specifications.^[72] The International Requirements Engineering Conference (RE), including its 29th edition (RE'21), serves as a key forum for advancing standards through research outcomes on emerging practices. Proceedings from RE'21 highlight evolving approaches to requirements engineering, such as sustainability integration and traceability enhancements, influencing updates to global standards.^[73] Certification programs like the International Requirements Engineering Board (IREB) Certified Professional for Requirements Engineering (CPRE) syllabus formalize these standards into structured curricula. The CPRE Foundation Level syllabus covers core competencies in requirements elicitation, documentation, and validation, ensuring practitioners apply standards effectively across projects.^[74] Advanced levels build on this with specialized topics like requirements modeling and management.^[75] By 2025, standards have increasingly incorporated domain-specific concerns. For cybersecurity, NIST Special Publication 800-53 Revision 5.2 introduces controls for secure software development and deployment, embedding requirements for risk assessment and resiliency in engineering processes.^[76] On sustainability, updates like the ASCE/COS 73-23 Standard Practice for Sustainable Infrastructure define requirements for environmental impact assessment in engineering projects, promoting lifecycle considerations for resource efficiency and emissions reduction.^[77]

Emerging Best Practices

In recent years, requirements engineering (RE) has increasingly integrated with DevOps practices to support continuous delivery, embedding RE activities directly into CI/CD pipelines for real-time requirement validation and refinement. This continuous RE approach enables teams to iteratively elicit, analyze, and trace requirements alongside code changes, reducing downstream defects by incorporating feedback loops from automated testing and deployment stages.^[78] Shift-left principles in this context advocate moving RE upstream in the development lifecycle, allowing early detection of requirement ambiguities through automated tools integrated into pipelines, thereby enhancing overall software reliability in dynamic environments.^[78] Post-2020 diversity, equity, and inclusion (DEI) initiatives have prompted RE practices to prioritize diverse stakeholder engagement, ensuring requirements reflect varied perspectives to mitigate exclusionary outcomes in software systems. Techniques such as inclusive elicitation workshops and stakeholder mapping now emphasize representation from underrepresented groups, fostering equitable requirement prioritization.^[79] For ethics, emerging methods include ontology-based approaches to detect and address biases in requirements, such as algorithmic discrimination risks, by systematically analyzing ethicality during elicitation and specification phases.^[80] AI enhancements serve as enablers here, automating bias audits in requirement artifacts to support these ethical practices. Sustainability considerations are gaining prominence in RE, with practices focused on incorporating green requirements that specify energy efficiency metrics, such as power consumption thresholds for software features, to align with environmental goals. A systematic mapping of 55 publications identifies 29 approaches since 2000 for embedding sustainability into RE, including non-functional requirements for carbon footprint reduction and resource optimization.^[81] Influenced by the EU Green Deal's 2050 climate-neutrality targets, these practices extend to software systems by mandating requirements for renewable energy integration and lifecycle emissions tracking, promoting greener IT infrastructure.^[82] Hybrid approaches blending agile and formal methods address RE needs in regulated industries, such as aerospace and healthcare, by combining agile's iterative elicitation with formal verification to ensure compliance while maintaining flexibility. In medical device software, for instance, hybrid models integrate agile prioritization with regulatory traceability matrices to balance speed and safety standards.^[83] Metrics like the requirement stability index, calculated as RSI = CP / (Cumulative ΔCP_CHANGE + CP) where CP is the initial complexity points and Cumulative ΔCP_CHANGE is the sum of complexity point changes (add, update, delete) across the SDLC, quantify RE success by measuring change volatility based on complexity, with values closer to 1 indicating stable processes.^[84]

References

[1]
[PDF] Requirements Engineering: A Roadmap
“Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It.
[2]
IEEE/ISO/IEC 29148-2018 - IEEE SA
Nov 30, 2018 · It defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses the iterative and ...
[3]
[PDF] Formal Methods in Requirements Engineering: Survey and Future ...
Apr 15, 2024 · ABSTRACT. Requirements engineering plays a pivotal role in the development of safety-critical systems. However, the process is usually a ...
[4]
Requirements Engineering - SEBoK
May 24, 2025 · Requirements Engineering: From System Goals to UML Models to Software Specifications. ... Part 5: Enabling Systems Engineering · Part 6: Related ...Missing: subset | Show results with:subset
[5]
[PDF] IEEE Recommended Practice For Software Requirements Speci ...
Abstract: The content and qualities of a good software requirements specification (SRS) are de- scribed and several sample SRS outlines are presented.
[6]
(PDF) Software Engineering: As it was in 1968. - ResearchGate
The 1968 NATO Conference on Software Engineering identified a software crisis affecting large systems such as IBM's OS/360 and the SABRE airline reservation ...
[7]
[PDF] NATO Software Engineering Conference. Garmisch, Germany, 7th to ...
NATO SOFTWARE ENGINEERING CONFERENCE 1968. 2. The present ... The program manager must determine for each design process what requirements for interfac-.
[8]
IEEE 830-1984 - IEEE SA
This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and ...
[9]
The use of object-oriented models in requirements engineering
Object-oriented methodologies can generally be thought of as having evolved from programming languages and design modeling (Graham 1994).
[10]
Goal-oriented requirements engineering: a guided tour - IEEE Xplore
Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, ...
[11]
Problem frames | Guide books - ACM Digital Library
Problem frames: analyzing and structuring software development problems. November 2000. Author: Michael Jackson ... Copyright © 2001. Publisher. Addison ...
[12]
[PDF] THE CHAOS REPORT
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects ...
[13]
https://www.sciencedirect.com/science/article/pii/S095058492400082X
[14]
Machine learning for requirements engineering (ML4RE)
This paper reviews machine learning for requirements engineering (ML4RE), using academic papers and Stack Overflow to understand research progress and the gap ...
[15]
Requirements Elicitation: A Survey of Techniques, Approaches, and ...
The objectives of this chapter are to present a comprehensive survey of important aspects of the techniques, approaches, and tools for requirements elicitation ...Missing: seminal | Show results with:seminal
[16]
Requirements elicitation techniques: a systematic literature review ...
Aug 1, 2018 · This study presents a systematic review of relevant literature on requirements elicitation techniques, from 1993 to 2015, by addressing two research questions.Introduction · Related work · Research method · ResultsMissing: seminal | Show results with:seminal
[17]
[PDF] Requirements Elicitation Techniques: Comparative Study - IJRDET
Studies have exposed that problems associated with requirements engineering could cost 10-200 times more to rectify the program after its implementation, than ...<|separator|>
[18]
A systematic literature review of stakeholder identification methods ...
This review examines stakeholder identification methods in requirements elicitation, including current status, best practices, consequences of incorrect ...
[19]
IISIT - Requirements Elicitation Problems: A Literature Analysis
This paper proposes a classification of problem types that occur in requirements elicitation. The classification has been derived from a literature analysis.
[20]
Moscow Rules: A Quantitative Exposé - SpringerLink
Jun 9, 2022 · This article analyzes the performance of the MoSCoW method to deliver all features in each of its categories: Must Have, Should Have and Could Have using Monte ...
[21]
MoSCoW Prioritisation - DSDM Project Framework Handbook
MoSCoW (Must Have, Should Have, Could Have and Won't Have this time) is a prioritisation technique for helping to understand and manage priorities.
[22]
(PDF) Conflict in the Requirements Engineering Process
Feb 14, 2021 · Requirements engineering is a human centric process and is as such prone to the occurrence of conflict between the various stakeholders.
[23]
Yourdon dataflow diagrams: A tool for disciplined requirements ...
Yourdon dataflow diagrams: A tool for disciplined requirements analysis ... T DeMarco. Structured Analysis and System Specifcation. (1978). V Weinberg ...
[24]
10.30 Non-Functional Requirements Analysis | IIBA®
Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform.10.30 Non-Functional... · 10.30. 3 Elements · . 1 Categories Of...
[25]
https://ieeexplore.ieee.org/document/5989723/
[26]
Prototyping - IEEE Xplore
The prototyping process validates the requirements for a system. This includes finding those requirements that are so obvious the customer did not even ...Missing: analysis | Show results with:analysis
[27]
[PDF] Lecture 1 - UTC
Each sentence should express one requirement. Structured natural language. The requirements are written in natural language on a standard form or template.
[28]
https://dl.acm.org/doi/abs/10.1109/32.345826
[29]
Specifying a Safety-Critical Control System in Z - ACM Digital Library
The limitations of the Z notation in this context—the lack of built-in facilities for expressing time and concurrency—are also outlined.
[30]
Automated Requirements Traceability: The Study of Human Analysts
The requirements traceability matrix (RTM) supports many software engineering and software verification and validation (V&V) activities such as change ...
[31]
[PDF] Avoiding Ambiguity in Requirements Specifications
May 5, 2012 · Ambiguity in an RS is a contributor to system difficulties because the RS fails to specify unique requirements for the system.
[32]
Ambiguity in Requirements Specification - SpringerLink
This chapter identifies the problem of ambiguity in natural language requirements specifications. After observing that ambiguity in natural language ...Missing: pitfalls | Show results with:pitfalls
[33]
None
### Summary of Requirements Verification and Validation
[34]
IEEE 1012-2024 - IEEE SA
Aug 22, 2025 · The Verification and Validation (V&V) processes are used to determine whether the development products of a given activity conform to the ...
[35]
[PDF] Requirements Validation Techniques and Factors Influencing them
This paper is about the factors that influence the selection of requirements validation technique and analyz- ing the most critical factors. Objectives:Our ...Missing: seminal | Show results with:seminal
[36]
[PDF] Managing Requirements for Design - incose
Starting at the Top. Client and stakeholder requirements are the starting point for development efforts. These upper-level requirements.
[37]
[PDF] Guide to Needs and Requirements Overview - incose
Change control - ability to baseline requirements, track changes after a baseline, or revert requirements set back to a baseline. Visual Modeling - ability ...
[38]
[PDF] Requirements Management Tool - Evaluation Report - incose
• Robust traceability suite with visualizations and impact analysis to ensure changes are managed appropriately and no requirements are missed. • Central ...
[39]
[PDF] Developing and Modeling an Approach for Requirements ... - incose
Apr 15, 2021 · Usage of the collaborative requirements management tool enables all users to see the source of requirement data and trace, enabling the change ...
[40]
[PDF] Needs and Requirements Manual Section 15 Needs ... - incose
All change requests must be captured and placed under configuration control. – In addition to the change requests, the impact analysis and any other documents.
[41]
[PDF] Structured Design ISBN 0-917072-11 - vtda.org
... Design. Page 3. Page 4. STRUCTURED DESIGN. Fundamentals of a Discipline of Computer Program and Systems Design. Second Edition. Edward Y ourdon and. Larry L ...
[42]
[PDF] Managing The Development of Large Software Systems
Implementation steps to deliver a small computer program for internal operations. A more grandiose approach to software development is illustrated in Figure 2.
[43]
Structured analysis and system specification : DeMarco, Tom
Jun 8, 2019 · Structured analysis and system specification. by: DeMarco, Tom. Publication date: 1979. Topics: Flow charts, System analysis. Publisher ...
[44]
[PDF] Managing the Development of Large Software Systems - CS - Huji
Reading Course on Software. Development. Managing the Development of. Large Software Systems. Winston W. Royce, Proc. IEEE WESCON, Aug 1970. Page 2. Who is ...
[45]
Volere Requirements Specification Template
The complete Volere Requirements Template contains 80 pages of checklists, examples and guidance.
[46]
[PDF] Requirements engineering for safety-critical systems
The report provides an overview of the state in the following areas of software engineering for safety: hazard anal- ysis; safety requirements specification and ...
[47]
Manifesto for Agile Software Development
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. Twelve Principles of Agile Software
[48]
How the industry broke the Connextra Template | antonymarcano.com
Aug 31, 2016 · The Connextra template (As a / I want to / So that) helps us start valuable conversations about: who the user is, what they want to do and why;
[49]
What is an Epic User Story? - Agile Alliance
Epics allow you a way to establish a hierarchy for your backlog items where the Epic represents the original idea often closely related to a particular outcome.
[50]
What does INVEST Stand For? - Agile Alliance
INVEST stands for a set of criteria used to assess the quality of a user story. If the story fails to meet one of these criteria, the team may reword it.
[51]
The 2020 Scrum Guide TM
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint ...Missing: elicitation | Show results with:elicitation
[52]
[PDF] Lean Software Development: An Agile Toolkit - Pearsoncmg.com
ware Development. But in Lean Software Development, Mary and Tom Poppendieck take lean in- dustrial practices to a new level—they tell us how to apply them ...
[53]
[PDF] Model-driven Development of Complex Software - arXiv
The term Model-Driven Engineering (MDE) is typically used to describe software development approaches in which abstract models of software systems are created ...
[54]
[PDF] SysML-based systems engineering using a model-driven ...
This paper describes a SysML-based process that systems engineers can use to capture require- ments and specify architecture. The process uses SysML exclusively ...Missing: DSL | Show results with:DSL
[55]
Constructing True Model-Based Requirements in SysML - MDPI
Mar 28, 2019 · This paper presents an approach to construct true model-based requirements in SysML. The presented approach leverages some of SysML's behavioral and structural ...
[56]
[PDF] A Domain-Specific Language for Requirements Engineering in ...
The approach treats requirements like source code, using a domain-specific language to represent them in the source repository, called 'Treat Requirements Like ...
[57]
Goal-Oriented Requirements Engineering: A Unifying Framework
The study of contemporary requirements engineering (RE) methodologies indicates that modelling of organisational goals constitutes a central activity of the ...
[58]
Machine Learning Techniques for Requirements Engineering - MDPI
In this article we conduct a systematic review on how AI, ML and NLP are being used in the various stages of requirements engineering.
[59]
Lean requirements traceability automation enabled by model-driven ...
Jan 25, 2022 · The benefits of requirements traceability, such as improvements in software product and process quality, early testing, and software maintenance ...
[60]
[PDF] Assessing Requirements Volatility and Risk using Bayesian Networks
Jones (Jones, 1994) noted that more than 70% of large software application development programs experience volatility; and this volatility, combined with poor.
[61]
[PDF] Pinpointing Ambiguity and Incompleteness in Requirements ...
The existence of viewpoints inevitably leads to inconsistencies and conflicts in stakeholders' requirements. Recognizing and reconciling these issues are key.Missing: pitfalls | Show results with:pitfalls<|control11|><|separator|>
[62]
Common Requirements Problems, Their Negative Consequences ...
Requirements defects that are not identified during the requirements engineering process will negatively impact all subsequent activities. When eventually ...
[63]
[PDF] Challenges in Requirements Engineering and Its Solutions
Among the challenges identified, the ones that had the highest occurrence were: lack of communication between stakehold- ers, ambiguous, incomplete, and ...Missing: incompleteness | Show results with:incompleteness
[64]
[PDF] Stakeholders in Requirements Engineering - IFI UZH
Yes, satisfying stakeholders' desires is crucial for product success. No, this leads to gold-plating and lets developers run away from their responsibility ...Missing: miscommunication | Show results with:miscommunication
[65]
Top Five Causes of Scope Creep - PMI
Oct 12, 2009 · Summary: Scope creep occurs when scope or requirements management doesn't occur. Changes to scope need to follow a clear process to prevent ...
[66]
[PDF] Standish Group Chaos Report 2024
The Chaos Report identifies several recurring reasons behind project challenges and failures: Unclear Requirements or Scope Creep: Changes in project scope ...
[67]
Towards semantic methodologies for automatic regulatory ...
However, these systems are experiencing challenges in coping with the frequent changes and updates in the regulations. ... Requirements Engineering and Law, 2008.
[68]
Is Design Dead? - Martin Fowler
Not just is much design activity ridiculed as “Big Up Front Design”, but ... So a lot of people focus on requirements engineering processes to get better ...Is Design Dead? · Patterns And Xp · Uml And Xp<|separator|>
[69]
Historical Aerospace Software Errors Categorized to Influence Fault ...
A substantial forty percent (40%) of unexpected software behavior was indicated by the absence of code, arising from unanticipated situations and missing ...
[70]
ISO/IEC/IEEE 29148:2018 - Systems and software engineering
In stock 2–5 day deliveryThis document specifies the required processes implemented in the engineering activities that result in requirements for systems and software products.
[71]
IEEE Standards Association
### Summary of IEEE/ISO/IEC 29148-2018: Requirements Engineering
[72]
[PDF] Guide to Writing Requirements - incose
Jul 1, 2023 · change control, completeness, correctness ... of SE, traceability, organizing needs and requirements, and managing needs and requirements.
[73]
Requirements - incose
The purpose of the Requirements Working Group (RWG) is to advance the practices, education and theory of systems engineering.
[74]
A Guide to the Business Analysis Body of Knowledge (BABOK Guide)
IIBA's KnowledgeHub is a brand-new online destination with actionable business analysis content. The KnowledgeHub provides instant online access to the BABOK® ...IIBA Bookstore · IIBA Membership · BABOK® Guide v3 Errata · Standard
[75]
Requirements Engineering 2021 - conf.researchr.org
The IEEE International Requirements Engineering Conference is the premier requirements engineering conference, where researchers, practitioners, students and ...Missing: outcomes standards
[76]
Foundation level – start working effectively in RE - IREB® CPRE
With this certificate, you will learn the basic principles, methods, and techniques for professionally eliciting, documenting, and managing requirements. Clear ...
[77]
[PDF] IREB Certified Professional for Requirements Engineering - GASQ
Oct 7, 2020 · This syllabus defines the Foundation Level of the certification Certified Professional for. Requirements Engineering established by the ...
[78]
SP 800-53 Rev. 5, Security and Privacy Controls for Information ...
On August 27, 2025, NIST issued a minor release of SP 800-53 (Release 5.2.0) that includes: New Control/Control Enhancements: SA-15(13), SA-24, SI-02(07) ...SP 800-53B · SP 800-53A Rev. 5 · CPRT Catalog · CSRC MENU
[79]
Setting the standard for infrastructure sustainability - ASCE
Jul 1, 2025 · ASCE/COS 73-23 Standard Practice for Sustainable Infrastructure defines sustainability in infrastructure programs and projects.
[80]
Requirements management in DevOps environments: a multivocal ...
Jan 13, 2023 · DevSecOps advocates shifting security to the left (by applying security measures throughout the development process), security by design and ...
[81]
Responsible Software Engineering: Requirements and Goals
Dec 21, 2023 · Values are subjective and depend on the diverse viewpoints of stakeholders because different stakeholders describe value requirements ...Missing: DEI | Show results with:DEI
[82]
An ontology-based approach to engineering ethicality requirements
Jul 22, 2023 · In this paper, we rely on Ontology-based Requirements Engineering (ObRE) as a method to elicit and analyze ethicality requirements.Eliciting Ethicality... · 2 Research Baseline · 4 Domain Ontology...Missing: diverse | Show results with:diverse
[83]
Requirements engineering for sustainable software systems
Jun 7, 2023 · We conducted a systematic mapping study, analyzed 55 publications, and identified 29 approaches that have been published since the year 2000.
[84]
What Is Green Software and Why Do We Need It? - IEEE Spectrum
Mar 23, 2024 · Green software engineering is an emerging discipline consisting of best practices to build applications that reduce carbon emissions.Hello There! · Ai The Green Way · Tips For Greener Ai
[85]
A hybrid assessment approach for medical device software ...
The hybrid approach integrates agile methods into the medical device software development process while adhering to the requirements of the regulatory standards ...
[86]
[PDF] PREDICTION OF SOFTWARE REQUIREMENTS STABILITY BASED ...
Software Requirements Stability Index Metric (RSI) helps to evaluate the overall stability of requirements and also keep track of the project status. Higher ...