Hubbry Logo
RequirementRequirementMain
Open search
Requirement
Community hub
Requirement
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Requirement
Requirement
Requirement
View on Wikipedia
from Wikipedia

In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.[1]

A specification or spec is a set of requirements that is typically used by developers in the design stage of product development and by testers in their verification process.

With iterative and incremental development such as agile software development, requirements are developed in parallel with design and implementation. With the waterfall model, requirements are completed before design or implementation start.

Requirements are used in many engineering fields including engineering design, system engineering, software engineering, enterprise engineering, product development, and process optimization.

Requirement is a relatively broad concept that can describe any necessary or desired function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, user, or other stakeholder.

Origins of term

[edit]

The term requirement has been in use in the software engineering community since at least the 1960s.[2]

According to the Guide to the Business Analysis Body of Knowledge® version 2 from IIBA (BABOK),[3] a requirement is:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

This definition is based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.[4]

Product versus process requirements

[edit]

Requirements can be said to relate to two fields:

  • Product requirements prescribe properties of a system or product.
  • Process requirements prescribe activities to be performed by the developing organization. For instance, process requirements could specify the methodologies that must be followed, and constraints that the organization must obey.

Product and process requirements are closely linked; a product requirement could be said to specify the automation required to support a process requirement while a process requirement could be said to specify the activities required to support a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., object-oriented programming), style-guides, or a review/inspection process (process requirements).

Types of requirements

[edit]

Requirements are typically classified into types produced at different stages in a development progression, with the taxonomy depending on the overall model being used. For example, the following scheme was devised by the International Institute of Business Analysis in their Business Analysis Body of Knowledge[5] (see also FURPS and Types of requirements).

Architectural requirements
Architectural requirements explain what has to be done by identifying the necessary integration of system structure and system behavior, i.e., system architecture of a system.
In software engineering, they are called architecturally significant requirements, which is defined as those requirements that have a measurable impact on a software system’s architecture.[6]
Business requirements
High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a business case.
User (stakeholder) requirements
Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.
Functional (solution) requirements
Usually detailed statements of the functions or capabilities, behavior, and information that the solution will perform. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as capabilities.
Quality-of-service (non-functional) requirements
Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate.[7] Examples include: reliability, testability, maintainability, availability. They are also known as characteristics, constraints or the ilities.
Implementation (transition) requirements
Usually, detailed statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.
Regulatory requirements
Requirements defined by laws (Federal, State, Municipal, or Regional), contracts (terms and conditions), or policies (company, departmental, or project-level).

Characteristics of good requirements

[edit]

The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.[8] [9]

Characteristic Explanation
Unitary (Cohesive) The requirement addresses one and only one thing.
Complete The requirement is fully stated in one place with no missing information.
Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
Non-Conjugated (Atomic) The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes".
Traceable The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
Current The requirement has not been made obsolete by the passage of time.
Unambiguous The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided.
Specify Importance Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance.
Verifiable The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling & simulation).

There are many more attributes to consider that contribute to the quality of requirements. If requirements are subject to rules of data integrity (for example) then accuracy/correctness and validity/authorization are also worthy attributes. Traceability confirms that the requirement set satisfies the need (no more - and no less than what is required).

To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present geocoded information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture.

Verification

[edit]

All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design).

Certain requirements, by their very structure, are not verifiable. These include requirements that say the system must never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.

Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent. However, they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level. Avionics software with its complicated safety requirements must follow the DO-178B development process.

Activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a feasibility study or a conceptual analysis phase of the project and requirements elicitation (gathering, understanding, reviewing, and articulating the needs of the stakeholders) and requirements analysis,[10] analysis (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).[11][12]

Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues.

There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they

  • take a long time to produce - sometimes to the point of being obsolete once completed
  • limit the implementation options available
  • are costly to produce

Agile approaches evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a just-in-time or last responsible moment basis.

Documenting requirements

[edit]

Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system must do. Example: 'The contractor must deliver the product no later than xyz date.' Other methods include use cases and user stories.

Changes in requirements

[edit]

Requirements generally change with time. Once defined and approved, requirements should fall under change control. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to requirements management studies and practices.

Issues

[edit]

Competing standards

[edit]

There are several competing views of what requirements are and how they should be managed and used. Two leading bodies in the industry are the IEEE and the IIBA. Both of these groups have different but similar definitions of what a requirement is.

Disputes regarding the necessity and effects of software requirements

[edit]

Many projects have succeeded with little or no agreement on requirements.[13] Some evidence furthermore indicates that specifying requirements can decrease creativity and design performance [14] Requirements hinder creativity and design because designers become overly preoccupied with provided information.[15][16][17] More generally, some research suggests that software requirements are an illusion created by misrepresenting design decisions as requirements in situations where no real requirements are evident.[18]

Meanwhile, most agile software development methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming for example describes requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated acceptance tests.

Requirements creep

[edit]

Scope creep may occur from requirements moving over time. In Requirements management the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen. It is easy for requirement changes to occur faster than developers are able to produce work, and the effort to go backwards as a result.

Multiple requirements taxonomies

[edit]

There are multiple taxonomies for requirements depending on which framework one is operating under. (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches). Differing language and processes in different venues or casual speech can cause confusion and deviation from desired process.

Process corruptions

[edit]

A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed. Examples include:

  • Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being ignored.
  • New players wanting a do-over - e.g., The natural tendency of new people to want to change their predecessor's work to demonstrate their power or claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution) already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project.
  • Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the highest possible priority.
  • Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development. This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the preference to be always right by waiting for post-work critique.

Within the U.S. Department of Defense process, some historical examples of requirements issues are

  • the M-2 Bradley issues of casual requirements movement portrayed in Pentagon Wars;
  • the F-16 growth from lightweight fighter concept of the Fighter mafia, attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost.
  • enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be appropriate or able to define what constituted 'Net-Ready'.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Requirement

View on Grokipedia
from Grokipedia
A requirement is a need or expectation that is stated, generally implied, or obligatory, serving as an essential criterion that must be fulfilled to achieve a specific objective, satisfy a standard, or meet contractual obligations. In fields such as systems engineering and quality management, requirements are formalized statements that define the capabilities, conditions, or constraints necessary for a system, product, or process to perform effectively and reliably. For instance, the IEEE Standard Glossary of Software Engineering Terminology describes a requirement as "a condition or capability needed by a user to solve a problem or achieve an objective," emphasizing its role in bridging user needs with technical solutions. Requirements can be categorized into types such as functional (specifying what a system must do), performance (detailing how well it must perform), and non-functional (addressing qualities like usability or security), each guiding development efforts to ensure compliance and stakeholder satisfaction. The process of eliciting, analyzing, and managing requirements is fundamental to disciplines like software engineering and project management, where incomplete or ambiguous requirements can lead to project failures, underscoring their critical importance in delivering successful outcomes.

Historical Development

Origins of the Term

The term "requirement" derives from the Latin verb requirere, composed of the prefix re- (meaning "again" or "repeatedly") and quaerere ("to seek" or "to ask"), thus signifying "to seek again" or "to ask for." It entered English via Old French requerre, with the verb "require" first attested in the late to denote "to ask" or "to inquire." The noun "requirement" emerged in the mid-15th century (around the 1520s) as "a request or requisition," evolving by the 1660s to mean "something necessary" or "a need," and later (by 1841) "a necessary condition." In technical contexts, the term first gained prominence in 19th-century , particularly with the expansion of railway infrastructure during the . Around the 1830s, as Britain and other nations built extensive rail networks, contracts and specifications employed "requirements" to outline mandatory conditions for construction, such as materials, load-bearing capacities, and safety standards, ensuring compliance amid large-scale projects that demanded precision and accountability. A key milestone in formalizing the concept occurred in the 1930s through U.S. manuals, which introduced structured lists of requirements to estimate and plan for munitions and supplies in anticipation of . The War Department's Industrial Plan, for instance, emphasized calculating detailed requirements to address production lead times and during periods of limited budgets and isolationist policies. By the , this approach marked a significant shift toward systematic in weapon system design, as exemplified by the U.S. 's Ordnance Department. During , requirements were explicitly defined for projects like and development, specifying performance criteria, reliability thresholds, and integration needs to streamline and innovation under wartime pressures.

Evolution in Engineering Disciplines

Following , the concept of expanded significantly within , driven by the demands of complex space programs. NASA's establishment in 1958 marked a pivotal moment, as it incorporated structured requirements planning into early mission architectures, laying the groundwork for large-scale projects like the . This approach emphasized defining technical specifications upfront to manage risks in , with formal systems evolving between 1960 and 1968 to include detailed requirements for and performance. The 1960s saw the emergence of software engineering as a distinct discipline, where requirements practices were formalized to address the growing "software crisis" in computing systems. The 1968 NATO Conference on Software Engineering in Garmisch, Germany, played a crucial role by highlighting the need for rigorous requirements definition to mitigate delays and cost overruns in large-scale software development, such as IBM's OS/360 and the SABRE airline reservation system. Conference proceedings advocated for systematic documentation of requirements as a foundational step, influencing subsequent standards in software lifecycle management. A key milestone in this evolution was the introduction of the Waterfall model in 1970 by Winston W. Royce, which structured software development into sequential phases with a strong emphasis on initial requirements analysis. Royce's framework, drawn from experiences in large systems development, positioned requirements elicitation and specification as the critical starting point, followed by design, implementation, verification, and maintenance, to ensure traceability and reduce iteration. This model became widely adopted in engineering disciplines for its linear predictability, particularly in regulated sectors like defense and aerospace. By the 1980s, further formalized requirements practices through international standards, notably IEEE Std 830-1984, which provided guidelines for developing comprehensive specifications (SRS). This standard outlined the content, qualities, and structure of an effective SRS, including sections for functional requirements, external interfaces, and performance criteria, to promote clarity and verifiability across engineering teams. It represented a shift toward standardized templates that facilitated collaboration in multidisciplinary projects. As of 2023, a recent advancement integrates with (MBSE) through updates to ISO/IEC/IEEE 15288, the international standard for system life cycle processes. The 2023 edition introduces a dedicated annex on MBSE, enabling formal modeling of requirements within digital environments to support simulation, analysis, and reuse across complex systems like autonomous vehicles and cybersecurity infrastructures. This evolution enhances traceability and adaptability, aligning requirements with digital twins and agile methodologies in modern engineering.

Fundamental Distinctions

Product Versus Process Requirements

Product requirements specify the characteristics, features, , and outputs of the end system or product, focusing on what it must achieve without prescribing how it is developed. For instance, a product requirement might state that "the application shall at least 1000 transactions per second under normal load" to ensure defined functionality and . These requirements guide the and verification of the deliverable, emphasizing operational, functional, and attributes such as , , and compliance with standards like ratings. In contrast, process requirements define the methods, procedures, and constraints for how the development, , or integration work is conducted, rather than the properties of the final product. Examples include mandates for compliance with systems like ISO 9001, which requires documented procedures for planning and control of product realization, or adherence to agile iteration cycles in software projects to ensure iterative reviews and adaptability. These requirements promote consistency, , and across the lifecycle, such as specifying verification protocols or during testing. The distinction between product and process requirements emerged prominently in the late through standards, with roots in 1970s advancements in planning like (MRP) systems, which emphasized process controls, contrasted against software 's focus on product specifications in early lifecycle models. Standards like (1994) formalized this by requiring detailed documentation of software products within structured development processes, bridging rigor with software flexibility. Product requirements benefit projects by directly aligning deliverables with stakeholder needs and enabling precise verification, while process requirements enhance and but can introduce trade-offs, such as added overhead that may constrain innovative approaches by enforcing rigid methodologies. A representative example appears in , where product requirements define crash performance, such as meeting Federal Motor Vehicle Safety Standard (FMVSS) 216 for roof crush resistance to protect occupants during rollovers, ensuring the vehicle's structural integrity under specified loads. Meanwhile, process requirements govern testing protocols, like those in , which mandate systematic , verification methods, and throughout the electrical/electronic system development to achieve functional integrity levels (ASIL). This separation allows engineers to focus product specs on end-user protection while using process mandates to standardize without altering the safety outcomes.

Functional Versus Non-Functional Requirements

Functional requirements define the specific behaviors, operations, inputs, outputs, and functions that a must perform to meet user needs. These requirements describe what the system does, focusing on the core capabilities and interactions, such as processing or executing transactions. For instance, a might specify that "the shall allow users to authenticate via and password, verifying credentials against a database and granting access upon success." This type of requirement is verifiable through testing that confirms the exact functionality, often expressed in terms of actions or services provided. In contrast, non-functional requirements specify the qualities, constraints, and attributes of the , detailing how it performs rather than what it does. These encompass aspects like reliability, , , , and , typically quantified with metrics to ensure measurable outcomes. Examples include "the shall maintain an uptime of greater than 99.9% during operational hours" for reliability or "the average response time for user queries shall not exceed 2 seconds under normal load." Non-functional requirements are crucial for overall effectiveness, as failure to meet them can render a functionally complete unusable or inefficient. The distinction between functional and non-functional requirements is outlined in established standards such as ISO/IEC/IEEE 29148:2018, which categorizes functional requirements as those describing system or element functions and behaviors, while non-functional requirements address quality attributes like and , often derived from implicit stakeholder needs. This framework aids in systematic by separating behavioral specifications from qualitative criteria, enabling targeted verification methods—such as demonstration for functionals and analysis or inspection for non-functionals. Challenges arise in distinguishing these categories due to overlaps and ambiguities, particularly in areas like where a requirement might blend specific operations (e.g., "the system shall encrypt data using AES-256") with broader qualities (e.g., "the system shall withstand penetration attempts with zero successful breaches in testing"). Such blending can lead to misclassification, complicating and validation, and requires careful elicitation to ensure clarity. A practical illustration is an platform: a might state "the user shall be able to add selected products to a and view the updated cart contents," defining the core shopping interaction. Conversely, a could specify "the platform shall support up to 10,000 concurrent users with no more than 1% error rate in ," ensuring during peak traffic. This separation highlights how functionals drive feature development while non-functionals guide architectural decisions for robustness.

Classification and Types

Stakeholder and User Requirements

Stakeholder requirements represent high-level needs and expectations articulated by individuals or groups with an interest in the , such as sponsors, regulators, or business owners, often focusing on overarching goals like constraints or . According to ISO/IEC/IEEE 29148:2018, these requirements emerge from the Stakeholder Needs and Requirements Definition , which translates stakeholder capabilities into verifiable statements to guide development. For instance, a project sponsor might specify that a new must operate within a of under $1 million to align with organizational financial objectives. User requirements, a of stakeholder requirements, capture the perspectives and operational needs of end-users who directly interact with the , emphasizing and task efficiency. In , these are defined as documented needs specifying how users intend to employ the to achieve specific objectives, often expressed in or through scenarios. They are typically elicited through direct engagement to ensure the supports daily workflows, such as a requirement for rapid in time-sensitive environments. Elicitation of stakeholder and user requirements involves structured techniques to gather and refine these needs, including surveys for broad input, collaborative workshops for consensus-building, and use cases to model user interactions. The BABOK Guide v3 outlines these methods as core practices in the Elicitation and knowledge area, recommending their selection based on stakeholder availability and to minimize misunderstandings. Personas and interviews further aid in representing diverse user viewpoints, ensuring comprehensive coverage. Poor alignment on stakeholder and user requirements contributes significantly to project outcomes, with the Standish Group's 2020 CHAOS Report estimating that around 66% of software projects fail or are challenged, frequently due to inadequate requirements gathering and . This underscores the need for iterative validation during elicitation to align expectations early. In healthcare , for example, stakeholders including regulators mandate HIPAA compliance for , while end-users such as nurses prioritize intuitive interfaces for swift access to patient records, balancing legal imperatives with practical . These high-level requirements are subsequently translated into detailed system and software specifications to enable implementation, maintaining to preserve original intents.

System and Software Requirements

represent holistic technical specifications for an integrated , encompassing functional, performance, interface, and quality attributes that ensure the system-of-interest meets derived stakeholder needs within its broader . These requirements address the system's role in the , including interactions with hardware, software, and external environments, such as specifying that a system shall integrate with a legacy database via defined protocols to maintain data compatibility. According to the Body of Knowledge (SEBoK), are generated through analysis processes that transform high-level stakeholder expectations into verifiable statements, forming the foundation for and activities. Software requirements, in contrast, provide detailed specifications tailored for code-level implementation, focusing on the behavioral and operational aspects of the software components within the system. These are typically documented in a (SRS) that outlines specific functions, data handling, user interfaces, and constraints, ensuring alignment with overall system objectives. The ISO/IEC/IEEE 29148:2018 standard guides the creation of such documents, emphasizing qualities like completeness, consistency, and verifiability to support development and testing of software intended for complex systems. Both and are derived through progressive refinement of initial stakeholder inputs, involving , interface analysis, and allocation to subsystems, with completeness often measured by coverage ratios in artifacts that indicate the proportion of higher-level needs addressed. A matrix (RTM) facilitates this linkage, presenting a tabular mapping from stakeholder requirements to and software specifications, as well as to design elements and tests, to ensure comprehensive coverage and change impact assessment. Tools like IBM Engineering Requirements Management DOORS enable automated creation and maintenance of such matrices, supporting multi-level in large-scale projects. For instance, in autonomous vehicle development, a system requirement might state that the vehicle shall detect obstacles at a minimum range of 100 meters under varying environmental conditions to ensure safe navigation, while a corresponding software requirement could specify that the achieves greater than 95% accuracy in object classification using data. These specifications derive from safety standards like and are traced back to user needs for reliable operation, highlighting the refinement process in safety-critical domains.

Quality Attributes

Characteristics of Effective Requirements

Effective requirements possess qualities that ensure they can be clearly understood, implemented, and verified, forming the foundation for successful projects. These characteristics have evolved from early templates like the Volere Requirements Specification Template, first published in 1995 and updated through recent editions as of 2022, such as edition 18, which emphasized clarity, completeness, and verifiability to address common pitfalls in requirement elicitation. According to the INCOSE Guide to Writing Requirements (2023), effective requirements align with SMART-like attributes: specific, meaning the statement has one clear interpretation without ; measurable, including quantifiable criteria for assessment; achievable, feasible within constraints like and resources; relevant, essential to the system's purpose and stakeholder needs; and traceable, linked to higher-level needs or sources for accountability. These align with characteristics defined in ISO/IEC/IEEE 29148:2018, such as complete, consistent, unambiguous, and verifiable. in a requirement is typically measured by whether it allows multiple interpretations among stakeholders, which can lead to implementation errors if not resolved through reviews. Beyond these, additional traits include unambiguous, ensuring precise language free of vague terms; complete, encompassing all necessary elements such as conditions, constraints, and performance measures without reliance on external assumptions; consistent, avoiding conflicts or varying terminology across the requirement set; feasible, realistic given available resources and risks; and verifiable, structured to be testable through methods like , demonstration, , or testing. For verifiability, a requirement must define success criteria that can be objectively confirmed, such as ranges for quantities rather than absolutes like "never fail," which are often impractical. For example, a poor requirement like "The system shall provide a fast response" is vague and unverifiable due to subjective interpretation of "fast," whereas an effective one states "The system shall respond to user queries in less than 500 milliseconds under a load of 1,000 concurrent users," which is specific, measurable, and testable. These characteristics not only facilitate robust but also support verification processes by enabling clear criteria for assessment.

Verification and Validation Techniques

Verification and validation are essential processes in to ensure that requirements are correctly specified and that the resulting fulfills stakeholder needs. Verification is the process of determining whether the products of a given development phase satisfy the requirements established during that phase, focusing on confirming that the requirements are internally consistent, complete, and feasible through static and dynamic checks against specifications. In contrast, validation is the process of evaluating the final products to determine whether they satisfy the specified user needs in the operational environment. These processes are often integrated into development lifecycles, such as in the IEEE Standard 1012 for , and Hardware (2024 revision), which outlines processes to detect errors early and improve quality. Common verification techniques include reviews, inspections, and walkthroughs, which are peer-based methods to scrutinize requirements documents for defects like ambiguities or inconsistencies. Inspections are formal and structured, involving checklists and roles like moderator and recorder to systematically examine requirements line-by-line for and logical errors. Walkthroughs, being more informal, facilitate knowledge sharing and early feedback without rigid preparation, often led by the author to simulate execution and identify issues. Expert reviews and analysis further support verification by having domain specialists assess feasibility, such as estimating resource needs or predicting performance based on requirements. In practice, these techniques help achieve low defect rates in requirements specifications, with defect density—measured as defects per unit size of the document—serving as a key metric; for instance, (CMMI) Level 3 processes emphasize monitoring this to target improvements in . Validation techniques emphasize dynamic evaluation to confirm alignment with user needs, including prototyping, simulations, and user . Prototyping involves creating executable models of requirements to gather stakeholder feedback on functionality and , allowing iterative refinement before full development. Simulations test requirements under various scenarios to validate non-functional aspects like or reliability, while user engages end-users in real-world-like exercises to ensure the meets operational expectations. In software contexts, beta testing validates overall through limited releases to representative users. These methods build on effective requirement characteristics, such as clarity and , to enable thorough assessment. Formal techniques enhance both by providing rigorous mathematical checks for logical consistency and completeness. , for example, uses tools like to verify requirements modeled in languages such as Promela against temporal properties, detecting deadlocks or inconsistencies in concurrent systems—particularly useful for mission-critical applications like . analysis links requirements to design, code, and tests, ensuring coverage and enabling of changes. Inconsistency analysis with tools based on , such as the Software Cost Reduction (SCR) approach, further validates requirements by identifying conflicts in tabular specifications derived from stakeholder inputs. These techniques, applied in high-stakes domains like projects, have demonstrated effectiveness in early error detection.

Documentation Practices

Requirement Specification Formats

Requirement specification formats provide standardized ways to document and communicate requirements, ensuring clarity, consistency, and verifiability in systems and software engineering. These formats range from informal natural language descriptions to highly structured templates and formal mathematical notations, each suited to different project needs and complexity levels. Natural language formats, such as user stories commonly used in Agile methodologies, express requirements in plain, conversational prose to facilitate stakeholder understanding and iteration. For instance, a user story might state: "As a registered user, I want to reset my password so that I can regain access to my account." Structured formats enhance this by organizing requirements into tables or predefined fields, including identifiers, descriptions, priorities, and rationale, to reduce ambiguity and support traceability. Formal formats, like the Z notation, employ mathematical constructs based on set theory and first-order predicate logic to precisely model system states and behaviors, enabling rigorous analysis and verification. Standards such as ISO/IEC/IEEE 29148:2018 guide the content and structure of requirement specifications by defining processes for eliciting, analyzing, and documenting requirements throughout the system life cycle. This standard outlines information items like requirement statements, attributes (e.g., priority, source), and relationships, emphasizing unambiguous, verifiable expressions without prescribing a single format. It promotes templates that include sections for functional and non-functional requirements, rationale, and verification methods to ensure completeness and consistency. The Volere Requirements Specification Template complements this by offering a comprehensive framework with over 80 fields across 11 main sections, covering project drivers, constraints, functional requirements, non-functional requirements (e.g., , ), and supporting elements like glossaries and matrices. Developed for and software systems, it uses checklists and examples to systematically capture atomic requirements while maintaining a knowledge model for interconnections. Best practices in requirement specification emphasize techniques that promote precision and behavioral clarity. Use cases serve as a key method for describing behavioral flows, encapsulating sequences of actions between actors and the system to achieve specific goals, often structured with elements like preconditions, main flow, alternatives, and postconditions. This approach aids in discovering requirements and deriving test cases by focusing on user interactions rather than implementation details. Additionally, modal verbs delineate obligation levels: "shall" indicates mandatory requirements, "should" denotes recommendations or desired outcomes, and "may" signifies optional permissions, aligning with IEEE guidelines to avoid ambiguity in specifications. These conventions, rooted in standards like the IEEE SA Style Manual, ensure requirements are testable and prioritized effectively. Tools facilitate the application of these formats in practice. Jira supports Agile by treating requirements as customizable issue types, enabling prioritization, tracking, and integration with for documentation, which streamlines collaboration in iterative environments. ReqView, a dedicated requirements tool, aids structured and traceable specifications by supporting templates compliant with ISO/IEC/IEEE 29148:2018, allowing formatted text, custom attributes, and bidirectional links for impact analysis, with via . A representative example is the (SRS) document, which typically follows an outline including an introduction (purpose, scope, definitions), overall description (product perspective, constraints), specific requirements (functional and non-functional, often in tables or use cases), supporting information (interfaces, appendices like glossaries), and verification criteria. This structure, as outlined in established guidelines, ensures comprehensive coverage while accommodating formats like or structured tables for functional requirements.

Tools and Standards for Documentation

Various software tools facilitate the creation, collaboration, and maintenance of requirements documentation by providing features for authoring, linking, and versioning requirements. Polarion, developed by , supports collaborative editing of requirements across distributed teams, enabling real-time co-authoring and workflow automation for approval processes in complex systems development. Engineering Requirements Management DOORS Next offers enterprise-level , allowing users to link requirements to design artifacts, tests, and code while supporting scalable management for large-scale projects. For open-source alternatives, ReqFlow provides analysis across documents, enabling efficient extraction and mapping of requirements without proprietary licensing costs. Regulatory standards guide the structure and processes for requirements documentation to ensure consistency and quality. The ISO/IEC/IEEE 29148:2018 standard outlines lifecycle processes for , including elicitation, analysis, specification, and validation, applicable to both systems and software products. In the automotive sector, Automotive SPICE (ASPICE) 4.0, released in 2023, incorporates REUSE processes to support the adaptation and integration of standard hardware, platforms, or product lines in requirements documentation, enhancing reusability and compliance in vehicle . Compliance in requirements documentation often involves features like audit trails and integration to meet regulatory demands for accountability and change tracking. Tools such as DOORS Next and Polarion include built-in audit trails that log all modifications to requirements, providing verifiable histories for audits, while integration with enables synchronization of requirements artifacts with code repositories for seamless development workflows. As of 2025, advancements in AI have introduced large language models (LLMs) into requirements tools for automated generation and analysis. IBM Engineering Requirements Management DOORS Next now integrates with the Engineering AI Hub v1.0, which deploys task-level AI agents powered by LLMs to assist in drafting requirements, identifying inconsistencies, and suggesting refinements based on inputs. In EU GDPR-compliant projects, standards require requirements to be documented in traceable formats, ensuring data protection measures are explicitly linked to system components for and purposes under Article 5 of the GDPR.

Management and Change Control

Processes for Requirement Changes

In , formal processes for handling changes to requirements are essential to maintain project stability and control scope during the development lifecycle. These procedures typically involve structured mechanisms to evaluate, approve, or reject modifications, ensuring that alterations align with project goals without introducing undue disruption. Key elements include dedicated bodies, standardized submission protocols, and reference points like baselines to gauge the necessity and timing of updates. A central component of these processes is the (CCB), a comprising subject matter experts, such as software engineers and project managers, tasked with reviewing change requests. The CCB evaluates proposed modifications to requirements, deciding whether to accept, reject, or defer them based on criteria like alignment with overall objectives and potential risks to the project timeline. To assess urgency, the CCB compares requests against established baselines, which represent approved snapshots of requirements at specific milestones; changes deemed non-urgent may be postponed until the next review cycle to preserve development momentum. The request process begins with the submission of a formal form by stakeholders, which must include detailed rationale for the proposed modification—such as evolving business needs or technical discoveries—and an assigned priority level. Priorities are often categorized numerically, with P0 denoting critical changes that require immediate action due to severe impacts on , compliance, or core functionality, followed by P1 for high urgency and lower levels for routine adjustments. This structured documentation ensures transparency and facilitates efficient by the CCB, minimizing ad-hoc alterations that could derail progress. Baselines serve as frozen sets of requirements established at key project milestones, such as the end of or design phases, providing a stable reference for all subsequent work. According to (CMMI) practices, baselining involves formal approval of requirement documents to track and control changes systematically, preventing unauthorized deviations while allowing controlled evolution. In CMMI's process area, baselines are integrated with to monitor variations, ensuring that any post-baseline changes undergo rigorous review to uphold integrity. In agile methodologies, processes for requirement changes adapt traditional controls to embrace and flexibility, often managing modifications through dynamic product backlogs rather than rigid boards. Changes are incorporated via prioritized backlog items, with sprint reviews at the end of each serving as checkpoints to validate adjustments based on stakeholder feedback and demonstrated progress. This approach, outlined in the Scrum framework, allows frequent refinements—typically every 1-4 weeks—while maintaining discipline through defined acceptance criteria and backlog grooming sessions. Research indicates that approximately 25% of requirements undergo changes during the development phase, highlighting the prevalence of volatility even with robust processes in place; exceeding this threshold often signals the need for process reevaluation to avoid escalating costs or delays. Such changes, if unmanaged, can contribute to issues like requirements creep, underscoring the importance of proactive controls.

Impact Analysis and Traceability

Impact analysis in involves systematically evaluating the effects of proposed changes to requirements, using techniques such as forward tracing to identify downstream impacts on , , and testing artifacts, and backward tracing to assess upstream dependencies from stakeholder needs. This process helps mitigate risks by revealing ripple effects, such as how a modification to a might necessitate updates to related test cases or validation procedures. According to , effective impact analysis reduces the uncertainty in change propagation, enabling teams to prioritize adjustments based on their scope and severity. Requirements traceability complements impact analysis by maintaining explicit links between requirements and associated lifecycle elements, ensuring that changes can be tracked bidirectionally—from high-level user needs to detailed code and tests. Traceability matrices, often implemented as tabular or graphical structures, map these relationships, allowing stakeholders to verify coverage and detect gaps during . For example, a matrix might link a requirement to specific modules and test scripts, facilitating quick identification of affected areas when alterations occur. Seminal work emphasizes that such matrices enhance by providing a clear throughout the project. Tools like Jira and support these practices through integrated workflows, where requirements are captured as Jira issues linked to Confluence documentation pages, enabling automated alerts for change notifications and dynamic views. This integration allows teams to generate reports on dependencies, streamlining without manual reconfiguration. Quantitative methods further refine this by employing dependency graphs, where nodes represent requirements or artifacts and weighted edges quantify relationship strength or risk, aiding in scoring potential change impacts for prioritization. In practice, altering a requirement, such as increasing response time thresholds, may propagate to invalidate related suites, requiring re-execution of coverage tools to confirm alignment with updated specifications; this underscores the value of in minimizing overlooked effects. Systematic reviews highlight that robust reduces project rework in complex systems, though adoption varies by .

Common Challenges

Requirements Creep and Scope Management

Requirements creep, also known as , refers to the uncontrolled and gradual expansion of a project's requirements or features beyond the originally defined scope, often without formal approval or evaluation of impacts on schedule, budget, or resources. This phenomenon typically arises from incremental additions that accumulate over time, leading to significant project disruptions; according to PMI's 2018 Pulse of the Profession report, 52% of projects experienced within the previous 12 months, contributing to average budget overruns of approximately 27% in IT projects affected by such expansions. Common causes of requirements creep include ambiguous or poorly defined initial scope, which allows for misinterpretations and unintended expansions; lack of formal processes for managing requirements, enabling unauthorized changes; inconsistent methods for gathering stakeholder input, resulting in fuzzy boundaries and extraneous demands; insufficient involvement from sponsors and stakeholders, leading to ad-hoc additions driven by external pressures; and extended durations, which increase exposure to evolving requests. Stakeholder pressure often exacerbates this by pushing for new features without assessing trade-offs, while poor fails to distinguish essential from desirable elements, allowing low-value additions to proliferate. Additionally, gold-plating by development teams—where extra functionalities are added unrequested in an effort to exceed expectations—contributes to creep by diverting resources from core objectives without client input. Effective management of requirements creep involves establishing clear scope baselines early in the lifecycle, which serve as a reference point for all changes and help maintain focus on approved deliverables. The prioritization method is a widely adopted technique for this purpose, categorizing requirements into Must-have (essential for success), Should-have (important but not vital), Could-have (desirable if time and resources permit), and Won't-have (excluded for the current scope), thereby aiding in controlled expansion and alignment with business priorities. This approach, originating from the (DSDM), ensures that only justified additions are considered, reducing the risk of uncontrolled growth. Mitigation strategies emphasize proactive controls, such as implementing regular review meetings to reassess scope against baselines and maintaining detailed change logs to track all proposed modifications, their rationale, and approvals. A formal process is critical, requiring impact analysis before approving any alterations to prevent haphazard inclusions. In agile environments, time-boxing—setting fixed durations for iterations like sprints—further contains creep by limiting the scope negotiable within each cycle, forcing prioritization and deferral of non-essential items to future iterations. These practices, when combined with ongoing stakeholder communication, help sustain viability amid evolving demands. A prominent illustrating the perils of requirements creep is the (DIA) automated baggage handling system project in the 1990s, where initial plans excluded automation but later incorporated it at the insistence of in 1991, leading to exponential scope growth as additional airlines and complexities were added without robust controls. Poor scope definition, communication gaps with stakeholders like , and inadequate resulted in requirements roughly doubling, causing a two-year delay from 1993 to 1995 and cost escalations from $2.08 billion to $4.8 billion—a 130% overrun—along with $35 million in rushed modifications and ongoing technical failures. The project's eventual partial abandonment for a conventional system underscored the need for early feasibility studies, stakeholder alignment, and structured change processes to avert such cascading failures.

Conflicting Standards and Taxonomies

In , various taxonomies exist to classify requirements, leading to inconsistencies that complicate specification and evaluation. One prominent taxonomy is FURPS+, introduced by Robert Grady at , which categorizes non-functional requirements into Functionality (features and capabilities), (ease of use), Reliability (dependability), (speed and efficiency), Supportability (, installability, and ), with the "+" denoting additional attributes like constraints or legal requirements. This model emphasizes practical grouping for but has been critiqued for its simplicity and overlap in categories. In contrast, the ISO/IEC 25010:2023 quality model provides a more structured, internationally standardized framework with eight product quality characteristics: functional suitability, efficiency, compatibility, , reliability, , , and portability, each broken down into sub-characteristics for precise measurement and evaluation. The divergence arises because FURPS+ focuses on high-level, project-oriented groupings often used in agile or proprietary contexts, while ISO 25010 prioritizes comprehensive, lifecycle-applicable metrics, resulting in mismatches when mapping, such as FURPS+'s broad "Supportability" encompassing aspects of ISO 25010's separate and portability. Standards from different bodies further exacerbate conflicts, particularly in defining non-functional requirements. The IEEE Std 29148-2018, which guides systems and requirements, defines as the ease of modification, correction, or improvement, encompassing modifiability, , and reusability within a broader systems context. Conversely, ISO/IEC 25010 delineates through sub-characteristics like , reusability, analyzability, modifiability, and , but integrates it more tightly with overall product quality evaluation, potentially narrowing its scope compared to IEEE's emphasis on operational and environmental factors in large-scale systems. These differences stem from IEEE's engineering-focused, U.S.-centric origins versus ISO's global consensus approach, leading to challenges where, for instance, a requirement compliant with one may require reinterpretation under the other. Overlapping frameworks from distinct domains add to the fragmentation. The BABOK Guide (version 3.0) from the International Institute of (IIBA) structures requirements classification around business needs, , and elicitation techniques, prioritizing to organizational goals in a context. In comparison, the INCOSE (version 5.0, 2023) adopts a systems-oriented , classifying requirements into stakeholder needs, , and derived technical specifications, with emphasis on verification across complex, interdisciplinary projects. While BABOK excels in bridging and IT, it often overlooks deep technical decomposition, whereas INCOSE's approach may undervalue metrics, creating confusion in hybrid projects where analysts and must align classifications. These conflicting standards and taxonomies pose significant challenges in multinational projects, where teams from diverse regulatory environments must reconcile varying interpretations, often resulting in increased specification errors, delays, and costs. Resolution is advancing through initiatives, such as the 2024 IEEE/ISO/IEC 24748-2 standard, which provides unified guidance on applying ISO/IEC/IEEE 15288 for life cycle processes, including , to bridge gaps between IEEE and ISO frameworks. A notable example is in security requirements, where NIST SP 800-53 classifies controls into families like and / for federal systems, focusing on technical safeguards, while GDPR (Article 32) emphasizes risk-based measures for personal data processing, prioritizing legal compliance and data subject rights, leading to overlapping yet distinct classifications that require dual mapping in transatlantic projects.

Contemporary Issues

Disputes on Requirement Necessity in Agile Contexts

The debate surrounding the necessity of detailed upfront requirements in software development has gained prominence within agile contexts, pitting traditional methodologies against iterative approaches. Proponents of traditional methods, such as the waterfall model, insist on comprehensive specifications to mitigate risks, ensure stakeholder alignment, and provide a clear roadmap for implementation, arguing that incomplete requirements lead to costly rework and project failure. Conversely, agile advocates, as articulated in the Agile Manifesto of 2001, emphasize responding to change over adherence to a plan, promoting emergent requirements that evolve through iterative development cycles, frequent feedback, and collaboration with stakeholders to better accommodate uncertainty and deliver value incrementally. Barry Boehm's 1988 spiral model offers a foundational bridge between these viewpoints, proposing a risk-driven process that integrates elements of traditional planning with iterative prototyping and evaluation, allowing requirements to be refined progressively across multiple cycles rather than fixed at the outset, thereby influencing the evolution of agile practices. illustrates the nuanced impacts of agile on requirement management: studies indicate that agile methodologies reduce requirements creep by fostering flexible and incremental delivery, with organizations achieving up to 28% higher rates compared to traditional approaches. However, this flexibility often heightens ambiguity, as lightweight artifacts like user stories may lack the precision of formal documents, resulting in varied interpretations and downstream defects, a challenge acknowledged in systematic reviews of agile . The 18th State of Agile Report (2025) highlights ongoing challenges in scaling agile practices effectively. In pipelines, which build on agile foundations, the principle of "just enough" requirements manifests through user stories and behavioral-driven development, enabling teams to focus on minimal viable increments that align with operational needs and facilitate . Disputes intensify in regulated sectors like pharmaceuticals, where agile's reduced documentation conflicts with mandatory requirements under FDA guidelines, prompting hybrid models that incorporate traceability matrices to ensure compliance without sacrificing iterative speed. By 2025, the emergence of AI-driven adaptive has intensified these debates, with tools automating elicitation, ambiguity detection, and real-time refinement of requirements, thereby challenging the imperative for static, comprehensive upfront specifications in favor of dynamic, context-aware that enhance agile adaptability.

Process Corruptions and Ethical Considerations

Process corruptions in often involve deliberate manipulation to benefit vendors or stakeholders, such as inflating requirements in contracts to secure higher payments or extend project scopes. A notable parallel is the bribery case, where institutionalized involved manipulating contracts to favor vendors through illicit payments exceeding €1.4 billion across global deals. Ethical dilemmas in requirements elicitation frequently arise from biases introduced by excluding diverse stakeholders, resulting in systems that perpetuate discrimination. When requirements gathering overlooks input from underrepresented groups, such as in AI-driven hiring tools, the resulting specifications can embed historical prejudices, leading to discriminatory outcomes like biased loan approvals or facial recognition failures for people of color. In surveillance technologies, privacy concerns are amplified during requirements definition, where inadequate specifications for data minimization can enable mass monitoring without consent, eroding civil liberties and enabling misuse by authorities. Professional frameworks address these issues by mandating fairness and accountability in requirements processes. The ACM Code of Ethics and Professional Conduct (2018) requires computing professionals to "be fair and take action not to discriminate," explicitly guiding requirements engineers to ensure inclusive elicitation and avoid biased specifications that could harm vulnerable populations. Complementing this, the EU AI Act (effective 2024) imposes ethical traceability requirements for high-risk AI systems, including detailed documentation of requirements evolution, risk assessments, and to prevent violations and biases from propagating into deployment. High-profile cases underscore the severe impacts of requirements failures on data ethics. The Cambridge Analytica scandal exemplified how lax requirements for data and in APIs allowed the unauthorized harvesting of 87 million users' profiles, enabling targeted political manipulation and eroding trust in digital systems. Such lapses not only triggered regulatory fines exceeding $5 billion but also highlighted how incomplete ethical requirements can facilitate societal harm, including election interference. To mitigate these corruptions and ethical risks, organizations employ regular audits of requirements documents and processes to detect manipulations or biases early. Forming diverse teams in elicitation phases ensures broader perspectives, reducing the likelihood of discriminatory specifications by incorporating varied stakeholder inputs. An emerging approach in involves leveraging for creating immutable logs of requirements changes, providing tamper-proof in collaborative environments to enhance and prevent retroactive alterations.

References

  1. https://www.iso.org/foreword-supplementary-information.html
  2. https://standards.ieee.org/ieee/29148/6937/
  3. https://blog.cauvin.org/2006/02/ieee-definition-of-requirement.html
  4. https://www.nasa.gov/reference/4-2-technical-requirements-definition/
  5. https://acqnotes.com/acqnote/tasks/requirement-types
  6. https://www.etymonline.com/word/requirement
  7. https://www.rchs.org.uk/wp-content/uploads/2016/08/Bailey.pdf
  8. https://history.army.mil/books/wwii/10-10/CMH_Pub_10-10.pdf
  9. https://appel.nasa.gov/2007/04/01/program-and-project-management-improvement-initiatives/
  10. https://www.researchgate.net/publication/221555451_Software_Engineering_As_it_was_in_1968
  11. https://www.praxisframework.org/files/royce1970.pdf
  12. https://standards.ieee.org/ieee/830/1220/
  13. https://standards.ieee.org/ieee/15288/10424/
  14. https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
  15. https://sebokwiki.org/wiki/System_Requirements_Definition
  16. https://www.dau.edu/acquipedia-article/systems-engineering-process
  17. https://www.netsuite.com/portal/resource/articles/erp/erp-history.shtml
  18. http://everyspec.com/MIL-STD/MIL-STD-0300-0499/MIL-STD-498_25500/
  19. https://www.sigmadzn.com/blog/product-requirements-a-systems-engineering-perspective
  20. https://www.parasoft.com/learning-center/iso-26262/what-is/
  21. https://chambers.com/articles/automotive-safety-standards-industry-insights-for-vehicle-rollover-cases
  22. https://www.nhtsa.gov/sites/nhtsa.gov/files/812285_electronicsreliabilityreport.pdf
  23. https://www.embitel.com/wp-content/uploads/ISO-26262-Standard-Handbook-1.pdf
  24. https://cs.ccsu.edu/~stan/classes/CS410/notes16/04-Requirements.html
  25. https://www.geeksforgeeks.org/software-engineering/functional-vs-non-functional-requirements/
  26. https://elogic.co/blog/functional-and-non-functional-requirements-for-ecommerce-websites/
  27. https://standards.ieee.org/standard/29148-2018.html
  28. https://www.iiba.org/contentassets/a566a72f87314878bbed046681829fb8/business-analysis-body-of-knowledge-babok-guide-v3.pdf
  29. https://www.3pillarglobal.com/insights/blog/why-software-development-projects-fail/
  30. https://www.hipaajournal.com/best-hipaa-compliance-software/
  31. https://www.reqview.com/blog/requirements-traceability-matrix/
  32. https://www.ibm.com/products/requirements-management
  33. https://www.appliedintuition.com/blog/requirements-management-and-traceability-in-autonomous-vehicle-development
  34. https://www.parasoft.com/blog/compliance-for-autonomous-driving-software/
  35. https://www.incose.org/docs/default-source/working-groups/requirements-wg/gtwr/incose_rwg_gtwr_v4_040423_final_drafts.pdf?sfvrsn=5c877fc7_2
  36. https://www.volere.org/templates/volere-requirements-specification-template/
  37. https://standards.ieee.org/ieee/1012/7324/
  38. https://www.diva-portal.org/smash/get/diva2:1533905/FULLTEXT01.pdf
  39. https://www.sei.cmu.edu/documents/3111/2004_017_001_23325.pdf
  40. https://ieeexplore.ieee.org/document/588521
  41. https://dl.acm.org/doi/10.1145/302405.302951
  42. https://www.altexsoft.com/blog/functional-vs-technical-requirements/
  43. https://www.geeksforgeeks.org/software-engineering/software-engineering-classification-of-software-requirements/
  44. https://www.ijert.org/research/z-formal-specification-language-an-overview-IJERTV1IS6492.pdf
  45. https://public.dhe.ibm.com/software/rational/web/whitepapers/2003/apprmuc.pdf
  46. https://development.standards.ieee.org/myproject/Public/mytools/draft/styleman.pdf
  47. https://support.atlassian.com/jira/kb/using-jira-for-requirements-management/
  48. https://www.reqview.com/
  49. https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document
  50. https://plm.sw.siemens.com/en-US/polarion/requirements/
  51. https://github.com/goeb/reqflow
  52. https://www.iso.org/standard/72089.html
  53. https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf
  54. https://www.ibm.com/new/announcements/introducing-ibm-engineering-ai-hub-v1-for-high-trust-engineering-domains
  55. https://www.sciencedirect.com/topics/computer-science/change-control-board
  56. https://www.projectmanager.com/blog/change-control-board-roles-responsibilities-processes
  57. https://www.jamasoftware.com/blog/the-change-control-board/
  58. https://monday.com/blog/project-management/change-request/
  59. https://www.projectmanager.com/blog/change-request-how-to-submit
  60. https://fibery.io/blog/product-management/p0-p1-p2-p3-p4/
  61. https://visuresolutions.com/alm-guide/requirements-baseline-and-versioning/
  62. https://www.wibas.com/cmmi/requirements-management-reqm-cmmi-dev
  63. https://scrumguides.org/scrum-guide.html
  64. https://www.atlassian.com/agile/scrum/sprint-reviews
  65. https://www.atlassian.com/agile/scrum/backlogs
  66. https://www.ifsq.org/finding-idd-5.html
  67. https://www.wohlin.eu/seke05.pdf
  68. http://sunnyday.mit.edu/16.355/watkins-tracing.pdf
  69. https://arxiv.org/pdf/1608.02757
  70. https://torkar.github.io/pdfs/00-SUBMITTED-PAPER.pdf
  71. https://www.pmi.org/learning/library/top-five-causes-scope-creep-6675
  72. https://www.trueprojectinsight.com/blog/project-office/estimate-at-completion
  73. https://www.pmi.org/learning/library/controlling-scope-creep-4614
  74. https://www.wrike.com/professional-services-guide/faq/scope-creep-vs-gold-plating/
  75. https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html
  76. https://www.simpliaxis.com/resources/time-boxing-in-agile-practices
  77. https://www.researchgate.net/publication/390746976_Scope_Creep_in_Large-Scale_Projects_Lessons_from_Denver_International_Airport
  78. https://www.iso.org/standard/78176.html
  79. https://www.perforce.com/blog/qac/what-is-iso-25010
  80. https://www.ptidej.net/courses/log3410/fall11/Lectures/Article_5.pdf
  81. https://www.researchgate.net/publication/270162966_An_Improved_Taxonomy_for_Major_Needs_and_Requirements_Artifacts
  82. https://www.wiley.com/en-us/INCOSE+Systems+Engineering+Handbook%2C+5th+Edition-p-9781119814290
  83. https://standards.ieee.org/ieee/24748-2/10895/
  84. https://securiti.ai/nist-privacy-framework-vs-eu-gdpr/
  85. https://quixy.com/blog/traditional-vs-agile-project-management/
  86. https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf
  87. https://fullscale.io/blog/agile-development-methodology-benefits/
  88. https://xbosoft.com/blog/agile-requirements-ambiguity/
  89. https://digital.ai/resource-center/analyst-reports/18th-state-of-agile-report/
  90. https://www.atlassian.com/agile/project-management/project-management-intro
  91. https://digitalcommons.lib.uconn.edu/cgi/viewcontent.cgi?article=1528&context=srhonors_theses
  92. https://www.arxiv.org/pdf/2510.25016
  93. https://pmc.ncbi.nlm.nih.gov/articles/PMC7415339/
  94. https://www.researchgate.net/publication/352093922_Bias_and_Discrimination_in_AI_A_Cross-Disciplinary_Perspective
  95. https://www.brookings.edu/articles/police-surveillance-and-facial-recognition-why-data-privacy-is-an-imperative-for-communities-of-color/
  96. https://www.ohchr.org/en/press-releases/2022/09/spyware-and-surveillance-threats-privacy-and-human-rights-growing-un-report
  97. https://www.acm.org/code-of-ethics
  98. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
  99. https://artificialintelligenceact.eu/high-level-summary/
  100. https://www.theguardian.com/news/2018/mar/17/cambridge-analytica-facebook-influence-us-election
  101. https://www.ftc.gov/news-events/news/press-releases/2019/12/ftc-issues-opinion-order-against-cambridge-analytica-deceiving-consumers-about-collection-facebook
  102. https://www.mdpi.com/2674-113X/1/1/3
  103. https://x-team.com/magazine/ethical-issues-in-software-development
  104. https://10fold.com/four-blockchain-trends-dominating-headlines-in-2025/
Add your contribution
Related Hubs
User Avatar
No comments yet.