Reference: Sommerville, Software Engineering, 10 ed., Chapter 4

Requirements engineering (RE) is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. As much as possible, requirements should describe what the system should do, but not how it should do it.

Two kinds of requirements based on the intended purpose and target audience:

User requirements

High-level abstract requirements written as statements, in a natural language plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

System requirements

Detailed description of what the system should do including the software system's functions, services, and operational constraints. The system requirements document (sometimes called a functional specification) should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

Three classes of requirements:

Functional requirements

Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.

Non-functional requirements

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services.

Domain requirements

Constraints on the system derived from the domain of operation.

Functional requirements describe functionality or system services. They depend on the type of software, expected users and the type of system where the software is used.

• Functional user requirements may be high-level statements of what the system should do.
• Functional system requirements should describe the system services in detail.

Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. In principle, requirements should be both

• Complete: they should include descriptions of all facilities required, and
• Consistent: there should be no conflicts or contradictions in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and consistent requirements document.

Non-functional requirements define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

Non-functional requirements may affect the overall architecture of a system rather than the individual components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements.

Three classes of non-functional requirements:

Product requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organizational requirements

Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.

External requirements

Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. If they are stated as a goal (a general intention of the user such as ease of use), they should be rewritten as a verifiable non-functional requirement (a statement using some quantifiable metric that can be objectively tested). Goals are helpful to developers as they convey the intentions of the system users.

The system's operational domain imposes requirements on the system. Domain requirements may be new functional or non-functional requirements, constraints on existing requirements, or define specific computations. If domain requirements are not satisfied, the system may be unworkable. Two main problems with domain requirements:

Understandability

Requirements are expressed in the language of the application domain, which is not always understood by software engineers developing the system.

Implicitness

Domain specialists understand the area so well that they do not think of making the domain requirements explicit.

Processes vary widely depending on the application domain, the people involved and the organization developing the requirements. In practice, requirements engineering is an iterative process, in which the following generic activities are interleaved:

• Requirements elicitation;
• Requirements analysis;
• Requirements validation;
• Requirements management.

Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include:

Requirements discovery

Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.

Requirements classification and organization

Groups related requirements and organizes them into coherent clusters.

Prioritization and negotiation

Prioritizing requirements and resolving requirements conflicts.

Requirements specification

Requirements are documented and input into the next round of the spiral.

Closed (based on pre-determined list of questions) and open interviews with stakeholders are a part of the RE process. User stories and scenarios are real-life examples of how a system can be used, which are usually easy for stakeholders to understand. Scenarios should include descriptions of the starting situation, normal flow of events, what can go wrong, other concurrent activities, the state of the system when the scenario finishes.

Use-cases are a scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system.

Problems to look for during requirements elicitation and analysis:

• Stakeholders don't know what they really want.
• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system requirements.
• The requirements change during the analysis process.
• New stakeholders may emerge and the business environment may change.

Requirements specification is the process of writing down the user and system requirements in a requirements document. User requirements have to be understandable by end-users and customers who do not have a technical background. System requirements are more detailed requirements and may include more technical information. The requirements may be part of a contract for the system development and it is important that these are as complete as possible.

In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable.

User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document. System requirements may also be written in natural language but other notations based on forms, graphical system models, or mathematical system models can also be used. Natural language is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.

Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. This approach maintains most of the expressiveness and understand-ability of natural language but ensures that some uniformity is imposed on the specification.

Requirements validation is concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important.

What problems to look for:

• Validity: does the system provide the functions which best support the customer's needs?
• Consistency: are there any requirements conflicts?
• Completeness: are all functions required by the customer included?
• Realism: can the requirements be implemented given available budget and technology?
• Verifiability: can the requirements be checked?

Requirements validation techniques:

Requirements reviews

Systematic manual analysis of the requirements. Regular reviews should be held while the requirements definition is being formulated. What to look for:

• Verifiability: is the requirement realistically testable?
• Comprehensibility: is the requirement properly understood?
• Traceability: is the origin of the requirement clearly stated?
• Adaptability: can the requirement be changed without a large impact on other requirements?

Prototyping

Using an executable model of the system to check requirements.

Test-case generation

Developing tests for requirements to check testability.

Requirements management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use. Reasons why requirements change after the system's deployment:

• The business and technical environment of the system always changes after installation.
• The people who pay for a system and the users of that system are rarely the same people.
• Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.

Requirements engineering is about discovering, analyzing, documenting, validating, and managing what a system should do and the constraints under which it must operate. Large Language Models (LLMs) are especially tempting here because requirements work is heavily language-based: interviews, notes, documents, user stories, and specifications. LLMs can speed up drafting and synthesis, but they also introduce a serious risk: requirements that are plausible and well-written yet incorrect, unvalidated, or inconsistent with stakeholder intent.

Where LLMs help in requirements engineering? Below are common uses, along with the main risks in each area:

Elicitation support (turning messy input into candidate requirements)

LLMs can help transform informal descriptions, meeting notes, and emails into candidate requirements, user stories, or questions to ask next. This can reduce effort and help teams notice missing information. The risk is that the model fills gaps by inventing details. In requirements work, invented details are not harmless: they can become "sticky" and later get treated as truth.

Clarifying and rewriting requirements

LLMs can rewrite vague statements into clearer, testable language and propose consistent terminology. This is useful for improving readability. The risk is that rewriting changes meaning. The model may make an ambiguous requirement sound precise without actually resolving the ambiguity with stakeholders.

Finding ambiguity, inconsistency, and incompleteness

LLMs can flag vague words ("fast," "user-friendly," "as needed"), identify possible conflicts (two requirements that cannot both be true), and suggest missing scenarios. This is valuable as a checklist and as a prompt for discussion. The risk is false alarms and false reassurance: the model may miss real conflicts, or confidently report that a requirement set is consistent when it is not.

Generating acceptance criteria and test ideas

From a story or requirement, LLMs can propose acceptance criteria, edge cases, and negative scenarios that support validation. The risk is shallow coverage: models often emphasize "happy paths," underemphasize abuse cases and operational constraints, and may generate criteria that are not measurable or not aligned with stakeholder priorities.

Requirements traceability and change summaries

LLMs can draft traceability mappings ("this requirement connects to these stories/tests/modules") and summarize what changed across versions of a requirements document. This can reduce overhead. The risk is quiet mismatches: traceability is only as good as the underlying understanding of the system, and models can create convincing-but-wrong links.

Nonfunctional requirements (NFRs) and constraints

LLMs can suggest typical NFR categories (security, privacy, performance, reliability, usability) and propose candidate constraints to consider. This is useful for reminding teams what they might be missing. The risk is generic requirements that don't match the domain and that create unrealistic expectations ("must be secure") without measurable targets or feasibility analysis.

Bottom line: LLMs can be useful assistants for requirements work because they operate on language, but requirements engineering is fundamentally about validated intent. Anything produced by an LLM is a draft hypothesis until a human confirms it with stakeholders and checks it against constraints and project reality.

A simple guided example

Scenario:

You are given a short, messy stakeholder statement and want to turn it into candidate requirements and questions.

Messy input:

"We need the system to handle lots of users. People keep getting locked out. Also, managers want reports, but we don't want anyone seeing data they shouldn't."

Prompt to an LLM:

"Extract candidate functional and nonfunctional requirements from this statement. For each requirement, list clarifying questions we must ask before we consider it 'done'."

Typical Output (Excerpt):

"NFR: system supports 10,000 concurrent users. FR: users can unlock accounts via email verification. FR: managers can generate usage reports. NFR: role-based access control..."

Why this helps:

It produces a structured starting point and forces the team to identify what must be clarified (scale definition, lockout policy, reporting scope, authorization rules).

Why this can mislead:

The model is likely to invent numbers ("10,000 users"), mechanisms ("email verification"), and policies ("RBAC") that were never stated. It can also turn a stakeholder concern into a specific solution, which is a common requirements mistake.

Discussion point:

Which parts of the AI output are requirements, which parts are design decisions, and which parts are unsupported assumptions? How would you rewrite the requirements to stay solution-neutral?

Key Takeaways

• LLMs are powerful for drafting and reorganizing requirement text, but they can also invent details and turn ambiguity into false precision.
• Requirements engineering depends on validation with stakeholders and constraints; AI output is never a substitute for that validation.
• The most productive use of LLMs in requirements work is to generate candidate requirements, questions, and checks, then have humans decide what is true and what matters.