Requirements Engineering in Software Engineering

Original

Within software engineering, requirements engineering serves as the critical bridge connecting user needs with technical implementation. By employing scientific methods, standardized processes, and professional tools, it transforms ambiguous user requests into clear, actionable development specifications, thereby establishing the fundamental standard that distinguishes professional development from amateur efforts. Requirements engineering extends far beyond the simple "collection of requirements"; it constitutes a comprehensive, systematic endeavor spanning the entire development lifecycle, whose quality directly determines a software product's success or failure. This article provides a thorough analysis of the core principles of requirements engineering, examining its definition, essential processes, key methodologies, and practical significance.

1. The Essential Definition of Requirements Engineering

The fundamental objective of requirements engineering is to "clearly describe the functions, behavioral characteristics, and associated constraints of the system under development." Professionally defined, it is the disciplined process of creating an organized, standardized description of a software system through proven, effective methods and suitable modeling tools. The term "effective methods" encompasses established techniques such as questionnaires and user interviews. "Appropriate tools" include modeling notations like UML diagrams, data flow diagrams, and use case diagrams. Crucially, the resulting "system description" must explicitly address two dimensions: first, the functionalities the system must provide (its behavioral characteristics); and second, the mandatory conditions governing its development and design (including constraints such as security standards, performance benchmarks, compliance mandates, and related requirements).

In contrast to the imprecise transmission of requirements based on experience and intuition alone, requirements engineering establishes a standardized operational framework. It ensures consensus among all stakeholders—including the development team, end-users, and business experts—regarding "what must be built." This alignment prevents project rework, delays, or outright failure stemming from misunderstandings, omissions, or conflicts in the requirements. In essence, requirements engineering renders the question of "what to do" quantifiable, verifiable, and executable.

2. The Five Core Stages of Requirements Engineering

The lifecycle of requirements engineering permeates the complete software development process and is structured into five interconnected stages, each with distinct objectives and key deliverables:

2.1 Requirements Elicitation: Comprehensive Collection of Stakeholder Needs

Requirements elicitation initiates the requirements engineering process. Its primary goal is to gather requirements comprehensively and accurately through effective engagement with stakeholders (e.g., clients, end-users, business experts), thereby preventing omissions and misinterpretations. The core process typically involves six key activities:

• Develop a high-level business model to outline core business processes, such as depicting the complete "user login to payment" journey in an e-commerce system.
• Define the project scope and high-level requirements to establish clear system boundaries and prevent uncontrolled scope expansion.
• Identify user roles and their representatives to ensure the needs of all relevant user groups (e.g., consumers, merchants, marketing staff in an e-commerce context) are captured.
• Conduct detailed requirement gathering for each identified role, extracting specific needs such as a consumer's requirement for "price filtering" or a merchant's need for "bulk product import."
• Elucidate business workflows and rules, defining precise operational steps and constraints, like the business rule "orders are automatically canceled after 30 minutes of non-payment."
• Consolidate and summarize the elicited requirements into preliminary documentation, categorizing them into functional, performance, security, and other relevant types.

Common elicitation techniques include: user interviews for direct, firsthand feedback; requirements workshops to facilitate real-time, multi-stakeholder discussion and conflict resolution; questionnaires for large-scale, structured data gathering (often used in conjunction with other methods); field observation to identify latent pain points by studying user operations; prototyping to use demonstrative models for clarifying and refining needs; and brainstorming sessions to foster creative exploration of innovative requirements.

2.2 Requirements Analysis: Transformation into Formal Specifications

The central task of the requirements analysis phase is to convert the gathered raw requirements into a set of clear, complete, consistent, and verifiable software specifications through systematic analysis. Widely adopted analytical approaches include Structured Analysis (SA), which focuses on data flows, and Object-Oriented Analysis (OOA). This phase involves filtering out unreasonable or infeasible demands, resolving conflicts between competing requirements, establishing priorities, and providing a unambiguous foundation for subsequent design and development activities. For example, a vague user need for "fast response" must be analyzed and translated into a concrete, measurable performance requirement, such as "page response time shall not exceed 2 seconds under specified high-concurrency conditions."

2.3 Requirements Documentation: Formalizing the Specifications

Requirements documentation entails recording the analyzed and agreed-upon requirements in a standardized format to produce a formal document, the Software Requirements Specification (SRS). This document frequently serves as a contractual appendix in software development agreements. A well-structured SRS typically includes sections such as Introduction, Overall Description, Functional Requirements, Non-Functional Requirements, Interface Requirements, Data Requirements, System Attributes, and appendices.

Using an online e-commerce system as an example, the SRS would need to specify: the operational environment (supported browsers, operating systems, databases); user roles and their associated requirements (e.g., shopping functions for buyers, product management functions for administrators); detailed functional descriptions (login/registration, product search, order processing); non-functional criteria (e.g., capacity to handle 1,000 queries per second, 99.9% system availability, use of BCrypt encryption for password storage); and any legal or regulatory compliance obligations. The SRS is generally authored under the leadership of product managers, with collaborative input from users and the development team to ensure its accuracy and practical feasibility.

2.4 Requirements Validation: Ensuring Specification Quality

Requirements validation is the process of comprehensively reviewing the SRS to verify its quality and correctness. This primarily involves five key verification activities:

• Correctness Check: Confirms that each requirement accurately reflects the genuine needs of users and stakeholders.
• Consistency Check: Ensures that no logical contradictions exist between different requirements within the specification.
• Feasibility Check: Assesses whether the requirements can be realistically implemented within the given technological, budgetary, and schedule constraints.
• Completeness Check: Verifies that no necessary requirements have been omitted, paying particular attention to the handling of exception conditions and edge cases.
• Verifiability Check: Guarantees that each requirement is stated in terms that allow for objective testing and measurement, avoiding subjective or ambiguous phrasing like "provides a good user experience."

2.5 Requirements Management: Governing Evolution Across the Lifecycle

Requirements management is an ongoing activity that spans the entire software development process. Its central purpose is to effectively track and control the evolution of requirements, encompassing practices such as change control, version control, and requirements traceability. When a change is requested, a formal procedure is typically followed, involving stages like "problem analysis and change request specification," "change impact analysis and cost evaluation," and "change implementation approval," often overseen by a Change Control Board (CCB). Version control mechanisms maintain a complete history of all modifications to requirement documents, ensuring full traceability. Requirements traceability establishes and maintains links between requirements and other artifacts through both forward tracing (from requirements to design elements, code components, and test cases) and backward tracing (from tests back to code, design, and originating requirements). This ensures that all specified requirements are implemented and that no unauthorized functionality is introduced.

3. The Practical Value and Significance of Requirements Engineering

While sometimes perceived as mundane, requirements engineering provides indispensable foundational governance for software development. First, its standardized processes significantly reduce misunderstandings and omissions, thereby lowering the risk of costly project rework and conserving development resources. Industry studies suggest that over 70% of defects in software projects can be traced back to shortcomings in the requirements phase; robust requirements engineering practices are crucial for mitigating these issues. Second, it creates a unified frame of reference for communication among diverse stakeholders, enabling users, product managers, developers, and testers to collaborate effectively based on a shared understanding documented in the SRS, thus minimizing cognitive gaps. Furthermore, requirements engineering instills a professional, disciplined mindset, steering the development process away from an ad-hoc, intuition-based mode toward a standardized, systematic methodology. This disciplined approach represents a core differentiator between professional software engineering and amateur development.

In today's dynamic market landscape, changes to requirements are inevitable. A mature requirements engineering framework enables more disciplined and orderly management of these changes, ensuring that the project remains aligned with its core business objectives. Whether for a simple utility application or a complex enterprise platform, requirements engineering stands as the decisive cornerstone for product success. Only by giving requirements engineering the priority it warrants can software products genuinely fulfill user needs and achieve a harmonious synthesis of commercial value and technical excellence.