Software Requirements Engineering (Requirement Engineering)
1. Overview
A. Definition
A software engineering activity that, through a systematic process of elicitation, analysis, specification, validation, and management of stakeholder needs, defines the requirements a target system must meet accurately, completely, and consistently, and controls them through to change.
Requirements engineering is the activity of clarifying "what to build (What)," and is distinguished from design and implementation, which deal with "how to build it (How)." In other words, defining the problem space is the essence of requirements engineering; it is the stage of agreeing precisely on the problem itself before moving into the solution space. If this boundary collapses and design details are fixed prematurely at the requirements stage, the room to examine better alternatives disappears and the requirements become tied to a specific implementation, losing flexibility.
Requirements engineering is not merely a document-writing activity but the engineering of communication and agreement. Because each stakeholder has different background knowledge, terminology, and interests, a semantic gap in which the same word is interpreted differently is ever-present. Requirements engineering narrows this gap through the engineering means of models, specifications, and validation, so that the development team and the client picture the "same system" in their minds.
In particular, because software is an intangible artifact that cannot be seen, agreeing on requirements is even harder. In architecture, the finished appearance can be shared in advance through drawings and renderings, but software is hard to see in concrete form until it is complete, so stakeholders cannot express their requirements concretely. This is precisely why requirements engineering emphasizes visualization means such as models and prototypes.
B. Background and Necessity
The biggest cause of software project failure is not coding mistakes but "building the wrong thing well"—that is, errors in requirements. In many industry surveys, including the Standish Group's CHAOS report, incomplete requirements, frequent requirement changes, and lack of stakeholder involvement repeatedly top the list of causes of project failure and delay. This shows that requirement quality, more than code quality, first determines a project's fate.
The later a requirement defect is found, the more exponentially the cost of fixing it grows. The 1:10:100 rule—a defect that costs 1 to fix at the requirements stage costs 10 at design and 100 in operation—expresses this. The reason is that while a defect flows downstream, design, code, tests, and documents pile up layer upon layer on top of it. If a requirement error surfaces during operation, the entire set of artifacts already built must be traced back and corrected, so the scope of rework explodes.
Also, if requirements are ambiguous, the scope keeps changing during development (scope creep), and rework surges. When un-agreed requirements such as "we'll need an admin screen too" keep being added during development, the workload grows while schedule and budget stay the same, and quality collapses. To prevent such losses, requirements engineering treats requirements not as impromptu conversation but as an engineering process, securing agreement and traceability among stakeholders. In particular, by fixing requirements as a baseline and controlling changes, it clarifies "what is the contracted scope" and reduces disputes and rework.
2. The Requirements Engineering Process
Requirements engineering is an iterative activity in which the five stages are sequential yet return to analysis whenever a change occurs. The concept diagram below shows the flow of the entire process and the change feedback loop.
flowchart LR
E["Elicitation"] --> A["Analysis"]
A --> S["Specification"]
S --> V["Validation"]
V --> M["Management"]
M -.change occurs.-> A
Each stage refines the output of the previous stage, ultimately converging on a trustworthy requirements specification. The detailed diagram below shows the inputs each stage consumes, the outputs it produces, and its interactions with stakeholders and configuration management tools.
flowchart TB
ST["Stakeholders"] -->|needs/expectations| E2["Elicitation"]
E2 -->|raw requirement list| A2["Analysis/Modeling"]
A2 -->|refined & prioritized requirements| S2["Specification(SRS)"]
S2 -->|SRS draft| V2["Validation(review/prototype)"]
V2 -->|approved requirements| BL["Requirements Baseline"]
BL --> M2["Change Management(CCB/RTM)"]
M2 -.re-analyze after impact analysis.-> A2
M2 -->|traceability links| RTM["Requirements Traceability Matrix"]
A. Elicitation — the stage of identifying stakeholders and drawing out their needs and expectations. The core challenge here is that users themselves are often unclear about what they want. This is called the tacit knowledge problem: business rules so obvious to practitioners that they go unspoken often fail to be reflected in the system and later become defects.
Therefore elicitation must uncover latent requirements by combining not only direct questioning techniques such as interviews and workshops, but also observation of actual work from the side, prototyping that draws out reactions with a working model, and analysis of existing documents and logs. For example, when building a warehouse logistics system, interviews alone will not reveal the exceptional flow "when busy, people write by hand instead of scanning barcodes," but on-site observation captures it immediately.
Also, in the elicitation stage, conflicts of requirements among stakeholders first surface. Because the sales department prioritizes feature variety, operations prioritizes stability, and finance prioritizes cost reduction, elicitation must be a process of securing different perspectives in balance, not mere collection. Since bias toward a particular loud stakeholder distorts the requirements, identifying all relevant parties through a stakeholder map must come first.
B. Analysis — the stage of resolving conflicts, redundancy, and ambiguity in the collected requirements and weighing feasibility and priority. Raw requirements exist in mutually contradictory ("fast yet cheap"), redundant (the same requirement in different wording), or unverifiable forms (such as "it must be easy to use"). Analysis refines these into a developable form.
Here, modeling with use cases, DFDs, and UML is the core means. Natural language is ambiguous, but a model structures requirements and visually reveals omissions and contradictions. For example, while drawing a use-case diagram, an undefined flow such as "what if an unauthenticated user attempts payment?" is naturally discovered. A model is also a communication tool with stakeholders: discussing over a picture reduces misunderstanding compared with text.
For prioritization, MoSCoW (Must/Should/Could/Won't) or the Kano model is used. If all requirements are treated equally, resources fall short for the ones that truly matter, so one must distinguish what is essential (Must) from what is nice to have (Could). The Kano model divides requirements into must-be, one-dimensional, and attractive quality, distinguishing "must-be requirements" that cause dissatisfaction when absent but no delight when present from "attractive requirements" whose presence sharply raises satisfaction. For example, in a banking app "transfers are processed accurately" is a must-be requirement that earns no praise even when done well, but "biometric login in 3 seconds" is an attractive requirement that becomes a competitive advantage. On a limited budget, it is reasonable to first complete the must-be requirements and then invest in attractive ones.
Feasibility review is also central to analysis. One must weed out infeasible requirements early by checking whether they are technically implementable, achievable within schedule and budget, and not in conflict with legal and organizational constraints. If this review is poor, the fact that "this requirement was impossible from the start" surfaces late in development, causing large-scale rework.
C. Specification — the stage of documenting agreed requirements as an SRS (Software Requirements Specification). Because the SRS is a contractual document that becomes the common basis for development, testing, and acceptance, the room for interpretation must be minimized. To reduce the ambiguity of natural language, use-case specifications, user stories, and, if needed, formal specifications (Z, state machines, etc.) are combined. For example, in safety-critical domains such as finance and aviation, requirements are sometimes described mathematically with formal specifications to eliminate ambiguity at the source.
Consistency of expression is also important when writing a specification. Calling the same concept by different terms throughout the document (e.g., "member," "user," "subscriber") causes misunderstanding, so a glossary is kept to unify domain terms. Also, each requirement must be given a unique identifier (REQ-001, etc.) so that traceability links can later be attached and, when a change occurs, exactly which requirement changed can be pinpointed. A descriptive requirement without an identifier is untraceable at the management stage and effectively falls outside control.
D. Validation and Management — Validation is the stage of confirming, through reviews, inspections, and prototypes, whether the specification captures stakeholders' actual needs accurately, completely, and consistently. Here the distinction between validation (are we building the right thing) and verification (are we building it per the specification) is important. Because a requirement defect missed in validation flows straight downstream, validation is the last line of defense in requirements engineering. A prototype is an especially powerful validation means: when a stakeholder who sees a working screen points out early that "this isn't what I had in mind," misunderstandings that documents cannot catch can be filtered out at low cost.
Management is the activity of fixing confirmed requirements as a baseline and then controlling changes through configuration management, RTM, and a Change Control Board (CCB). Its purpose is not to block change itself, but to analyze the impact of change and reflect it only through an agreed procedure, preventing disorderly change. When a change request comes in, the CCB analyzes the ripple effects on schedule, cost, quality, and other requirements and decides to approve, hold, or reject; only with this procedure can scope creep—"the scope quietly grows on someone's single request"—be institutionally blocked.
| Stage | Activity | Representative Techniques | Key Outputs |
|---|---|---|---|
| Elicitation | Stakeholder identification, requirement collection | Interviews, workshops, observation, prototyping | Raw requirement list |
| Analysis | Conflict/redundancy resolution, prioritization | Use cases, DFD/UML, MoSCoW, Kano | Requirement models, priorities |
| Specification | SRS documentation | Natural-language/formal spec, use-case spec | SRS |
| Validation | Accuracy/completeness/consistency check | Reviews/inspections, prototypes | Approved requirements |
| Management | Change/history/traceability management | Configuration management, RTM, CCB | Baseline, RTM |
3. Types of Requirements
The reason requirements are divided by type is that validation methods and design impact differ by type. Functional requirements define the system's behavior, so they are relatively easy to express and verify; non-functional requirements, however, influence the system subtly throughout, are easy to miss, yet fundamentally govern the architecture.
In particular, non-functional requirements (NFRs) are a core driver of architectural decisions. For example, a performance requirement of "10,000 concurrent users, response within 2 seconds" is unachievable on a single server and forces load balancing, caching, and distributed architecture from the outset. Conversely, if this requirement is left unspecified and development proceeds, when a performance problem later erupts, the worst kind of rework—overhauling the entire architecture—occurs. That is why NFRs are not "something to tune later" but something that must be fixed before design.
To elicit NFRs systematically, it is effective to reference a standard classification of quality characteristics. The ISO/IEC 25010 product quality model presents eight characteristics—functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability—and using this list like a checklist can prevent omissions such as "availability was set, but the maintainability target was left out." In other words, NFRs should be elicited exhaustively against a standard classification rather than listed by intuition.
Constraints are external conditions the system must follow, limiting the development team's options. Laws and regulations such as the Personal Information Protection Act and electronic financial supervision rules, specific platforms and languages, and budget and deadlines belong here. Constraints must be stated distinctly from requirements so that, when examining design alternatives, options that violate them can be screened out from the start. Since discovering a constraint late means discarding an already-fixed design, identifying constraints should, as a principle, be completed early in analysis.
| Category | Content | Example |
|---|---|---|
| Functional requirement | Functions/services the system performs | Login, order processing |
| Non-functional requirement | Quality attributes such as performance/security/availability | 2-second response, 99.9% availability |
| Constraint | Legal/standard/platform/budget constraints | Compliance with the Personal Information Protection Act |
4. The SRS and Quality Characteristics
An SRS consists of purpose and scope, functional/non-functional requirements, interfaces, and constraints, and it must satisfy the quality characteristics of "what is a good requirement." The international standard ISO/IEC/IEEE 29148 presents necessity, clarity, completeness, consistency, verifiability, and traceability as characteristics a good requirement should have (a standard that replaced and integrated the once widely used IEEE 830-1998).
The reason these characteristics matter is that violating even one leads to interpretation differences and rework at the development stage. For example, the requirement "the screen must be fast" is unverifiable, so it must be written verifiably with conditions and quantitative criteria, such as "the main screen loads within 2 seconds on a 3G environment." Without verifiability, the client and the developer end up arguing over "fast/slow" at acceptance time.
Completeness and consistency are especially easy to miss. Completeness means whether exceptional and boundary conditions—not just the normal flow—are covered exhaustively. If exceptions such as "what happens when payment fails" or "what if inventory goes negative?" are missing from the specification, developers handle them arbitrarily and sow the seeds of bugs. Consistency means there must be no contradiction among requirements; as scale grows, the risk of different requirements colliding rises, so traceability management is also needed.
| Characteristic | Meaning |
|---|---|
| Completeness | Includes all necessary requirements (including exceptions/boundaries) |
| Consistency | No conflict among requirements |
| Clarity | Unambiguous, single interpretation possible |
| Verifiability | Confirmable by testing (quantitative criteria) |
| Traceability | Links upper requirement–design–test |
5. Comparison and Application Cases
The actual shape of requirements engineering diverges greatly by project character. The table below compares requirements management under a plan-driven approach and an agile approach. The difference between the two is not merely a matter of document volume, but stems from a fundamental philosophical difference of "when to fix requirements."
| Aspect | Plan-driven (waterfall) | Agile |
|---|---|---|
| Requirement fixing time | Fixed all at once early | Progressively fixed each sprint |
| Form of expression | SRS document | User Story·Backlog |
| Attitude to change | Control·minimize | Accept·welcome |
| Suitable domain | Regulation/safety-critical (finance/aviation/medical) | Services with high market uncertainty |
| Validation | Review/inspection/acceptance test | DoD/acceptance criteria/demo |
The fundamental reason this difference arises is that the cost curve of change differs by domain. For a system like air traffic control, where once deployed a fix is extremely hard and directly linked to safety accidents, the cost of perfectly fixing requirements early and even going through formal validation is justified. Conversely, a startup's commerce service is better off continually changing requirements while watching market response, so complete early fixing is instead a waste. Therefore the requirements engineer's judgment point is not "which approach is right" but "which approach fits this project."
As a concrete case, in a large-scale public informatization project, a Request for Proposal (RFP) and a detailed requirements definition are fixed at the ordering stage and taken as the contract scope. If requirements are poor here, disputes over the task scope are frequent during execution, so detailing requirements and securing traceability determine the project's success or failure. In contrast, in in-house mobile service development, user feedback is reflected in the backlog every 2-week sprint, and over 6 months it is considered normal for much of the requirements to differ from the initial definition. It is the same "requirements engineering," yet the operating manner is the exact opposite.
6. In Depth: Requirements Engineering in the Agile Era and Recent Trends
Traditional requirements engineering presumed a Big Design Up Front that fixes requirements all at once early in development, but as market and technology changes accelerated, this premise wavered. Requirements inevitably change over time, yet the attempt to fix everything early instead treated change like a defect and caused friction. In response, agile shifted the paradigm toward accepting requirement change as natural.
In agile, the SRS is not fixed all at once but expressed as User Story·Product Backlog and refined progressively each iteration sprint. Each story is written in the "role-function-value (As a … I want … so that …)" form, and verifiability is secured through the Definition of Done (DoD) and Acceptance Criteria. However, agile does not abolish requirements engineering. Elicitation, analysis, and validation are still needed; only their timing—once concentrated early in the project—is now distributed across all sprints. Backlog prioritization and story refinement meetings are precisely ongoing requirements engineering.
Recently, the IREB CPRE (Certified Professional for Requirements Engineering) system that certifies requirements-engineering expertise is spreading internationally, and tools supporting requirements management (Jira, DOORS, Polarion, etc.) are automating traceability and impact analysis. Furthermore, attempts to use generative AI to extract candidate requirements as drafts from stakeholder interview records, or to automatically check the ambiguity and redundancy of a specification, are increasing. However, because an AI-produced requirement draft must ultimately be validated and agreed on by people, AI is trending toward settling in as an auxiliary tool that helps generate drafts and check quality rather than replacing the requirements engineer.
Another trend worth noting is model-based requirements engineering. If requirements, structure, and behavior are connected and managed with a model such as SysML instead of a text SRS, the impact of a requirement change on design and test models can be tracked automatically. In particular, the model-based approach is spreading in fields such as automotive and aviation, where systems are complex and safety certification is required. This shows a shift in perspective in which requirements are no longer a static document sitting only at the front of development, but are treated as a living asset across the entire development life cycle.
7. Considerations and Implications
- Securing traceability: By bidirectionally linking requirement–design–code–test through an RTM (Requirements Traceability Matrix), impact analysis is instant when a requirement changes and testing without omission is guaranteed. This is the core tool of quality assurance, and in regulated industries (medical devices, aviation) traceability evidence is mandatory for certification.
- Change management and baseline: The key is controlled change that, rather than blocking change unconditionally, analyzes impact (schedule/cost/quality) through the CCB and reflects only what is agreed. Without a baseline, "what is the contract scope" becomes ambiguous, and disputes and scope creep arise.
- Choosing a requirements-management strategy that fits the methodology: For domains where requirements are stable and regulation is strict, document-based SRS and formal validation are advantageous; for domains with high market uncertainty, backlog-based progressive refinement is. Not uniform application but trade-off judgment tailored to project characteristics is the requirements engineer's competency.
- Stakeholder involvement and agreement (sign-off): Ultimately, the foundation of requirements-engineering success is people, not tools. Without stakeholders' active involvement and explicit agreement (sign-off), even a well-written SRS is nullified by acceptance rejection of "this isn't what we wanted."
- Early fixing of non-functional requirements: Because NFRs such as performance, security, and availability govern the architecture, they must be fixed with quantitative criteria before design. An NFR that surfaces late invites the worst cost of a full architectural overhaul.
- Introducing AI/automation and validation responsibility: While generative AI accelerates requirement drafts and ambiguity checks, it must be made clear that responsibility for the final requirements' accuracy and agreement rests with people. Uncritically accepting auto-generated requirements can let plausible-but-wrong requirements seep into the specification, so AI should be used as a productivity tool while the validation gate is maintained.
References
- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering: https://www.iso.org/standard/72089.html
- IREB (International Requirements Engineering Board): https://www.ireb.org/en/
- SWEBOK Guide V3.0, Software Requirements (Chapter 1), IEEE Computer Society: https://www.computer.org/education/bodies-of-knowledge/software-engineering
In one line: Requirements engineering systematizes stakeholder needs engineering-wise through the process of elicitation→analysis→specification→validation→management, and prevents requirement defects and project failure (1:10:100) with a complete, consistent, clear, verifiable, and traceable SRS plus baseline, RTM, and CCB; in agile it is evolving into backlog-based progressive requirement refinement.