System requirements describe what a system should do, the services it provides, and its operational constraints, based on customer needs.
The process of discovering, analyzing, documenting, and validating these requirements is called requirements engineering (RE). In practice, the term "requirement" can range from broad, high-level statements to detailed, formal system definitions.
User Requirements
Hover to see definition!
natural language statements with diagrams that describe the services the system should provide and its constraints
System Requirements
Hover to see definition!
detailed specifications for a system's functions, services, and constraints
Objectives
The objective of this chapter is to introduce software requirements and to discuss the processes involved in discovering and documenting these requirements. When you have read the chapter you will:
understand the concepts of user and system requirements and why these requirements should be written in different ways;
understand the differences between functional and nonfunctional software requirements;
understand how requirements may be organized in a software requirements document;
understand the principal requirements engineering activities of elicitation, analysis and validation, and the relationships between these activities;
understand why requirements management is necessary and how it supports other requirements engineering activities.
Software system requirements are often classified as functional requirements or non-functional requirements:
Functional Requirements
Non-functional Requirements
These are statements of services the system should provide, how the system should react to particular inputs, and how the system
These are constraints on the services or functions offered by the system.
They include timing constraints, constraints on the development process, and constraints imposed by standards.
Figure 4.1: Readers of different types of requirements specification
4.1.1 Functional requirements
Functional requirements describe what a system should do, depending on the type of software, its users, and the organization’s approach to requirements. At the user requirement level, they are written in abstract, easy-to-understand terms, while at the system requirement level, they provide detailed descriptions of functions, inputs, outputs, and exceptions.
These requirements can range from general expectations about the system’s behavior to very specific needs tied to local practices or existing systems. Ideally, functional requirements should be complete (covering all needed services) and consistent (free from contradictions).
In practice, achieving completeness and consistency in large systems is very difficult. Mistakes and omissions often occur due to system complexity, and multiple stakeholders bring differing or even conflicting needs. These inconsistencies may remain hidden during specification and only surface after deeper analysis or once the system is delivered.
4.1.2 Non-functional requirements
Non-functional requirements define system properties and constraints that are not directly tied to specific services. They cover aspects like performance, reliability, security, and availability, or constraints such as hardware capabilities and data formats. These requirements usually apply to the system as a whole rather than individual functions.
They are often more critical than functional requirements because failure to meet them can render the entire system unusable, as seen with safety, reliability, or performance issues in mission-critical systems. Unlike functional requirements, non-functional requirements are harder to trace to specific components since their implementation is often spread across the system.
Figure 4.2: Types of non-functional requirement
Non-functional requirements can originate from three sources:
Product requirements – Define or constrain software behavior, such as performance (speed, memory use), reliability, security, and usability.
Organizational requirements – Stem from policies and practices of the customer or developer, including operational processes, development standards (languages, tools), and environmental constraints.
External requirements – Come from outside factors like regulatory rules, legal obligations, and ethical considerations that ensure compliance and public acceptability.
Exercise
Which of the following is a non-functional requirement?
The software requirements document (SRS) is an official statement of what developers must implement, containing both user requirements and detailed system requirements. These may be integrated into one document or split into separate sections depending on the number and complexity of requirements.
Requirements documents are especially important when software is developed by external contractors. However, agile methods argue against them, claiming requirements change too quickly and make documents obsolete. Instead, agile approaches like Extreme Programming use incremental user stories prioritized for each system release. Still, a short supporting document covering business and dependability requirements is recommended to avoid overlooking system-wide needs.
The requirements document serves a wide range of users—from senior management funding the project to engineers building the software—each relying on it for different purposes.
Figure 4.3: Users of a requirements document
The requirements document must balance different needs: clearly communicating requirements to customers, providing precise detail for developers and testers, and including information on potential system evolution to guide designers and maintenance engineers. The level of detail varies with context—critical systems require highly detailed specifications for safety and security, outsourced projects need precise definitions for clarity, while in-house iterative development can rely on less detailed documents since ambiguities can be addressed during development.
Figure 4.4: The structure of a requirements document
The content of a requirements document depends on the software type and development approach. In evolutionary development, the document emphasizes user requirements and high-level non-functional requirements, leaving out detailed specifications. Designers and programmers then use their judgment to address the outlined needs.
Exercise
Which statement best describes the main purpose of a Software Requirements Document (SRS)?
Requirements specification is the process of documenting both user and system requirements. While they should ideally be clear, complete, consistent, and easy to understand, this is difficult to achieve in practice because stakeholders often interpret requirements differently and conflicts or inconsistencies frequently arise.
User requirements should describe both functional and non-functional needs in a way that is understandable to non-technical users. They should focus on the system’s external behavior, avoiding technical jargon, software notations, or design details. Instead, they are best expressed in natural language, supported by tables, forms, or simple diagrams.
System requirements build on user requirements by adding detail for engineers to use in system design. They define exactly how user needs will be implemented and may serve as part of the contract for development. As such, they must provide a complete and precise specification of the system.
4.3.1 Natural language specification
Natural language has long been the main way of writing software requirements because it is expressive, intuitive, and widely understood. However, it can also be vague and ambiguous, leading to misunderstandings. Despite proposals for alternatives, natural language remains the most common approach.
To reduce ambiguity, several guidelines are recommended:
Use a standard format for all requirements, ideally as single sentences with a rationale and source for clarity.
Distinguish mandatory from desirable requirements by using consistent terms like shall (mandatory) and should (desirable).
Highlight key parts of the text with bold, italics, or color.
Avoid technical jargon, acronyms, and abbreviations since not all readers understand software engineering terms.
Include rationales for each requirement to explain why it exists, which is helpful when changes are needed.
4.3.2 Structured specifications
Structured natural language is a method of writing system requirements that limits writer freedom by enforcing a standard format. It keeps the clarity of natural language while adding uniformity through templates, sometimes using programming-like constructs and visual cues for emphasis.
When specifying functional requirements in this form, the document should include:
Function or entity description.
Inputs and their sources.
Outputs and their destinations.
Required data or system entities.
Actions to be taken.
Preconditions and postconditions (if applicable).
Any side effects of the operation.
Exercise
Which of the following best describes the goal of requirements specification?
Requirements engineering involves four main activities: feasibility study (assessing business usefulness), elicitation and analysis (discovering requirements), specification (documenting them in standard form), and validation (ensuring they match customer needs). These activities are carried out iteratively in a spiral process, with each cycle producing a requirements document. The time and effort spent on each activity varies depending on the system type and the development stage.
Exercise
Which of the following best describes the goal of requirements specification?
After the feasibility study, the requirements elicitation and analysis stage begins, where software engineers collaborate with customers and end-users to understand the application domain, required services, performance expectations, and system constraints. This process involves multiple stakeholders—anyone directly or indirectly influencing requirements, such as end-users, managers, domain experts, engineers of related systems, and even trade union representatives.
Figure 4.6: The requirements elicitation and analysis process
The process generally includes four key activities:
Requirements discovery – Engaging stakeholders and reviewing documentation to identify both system and domain requirements using various techniques.
Requirements classification and organization – Structuring and grouping related requirements, often based on system architecture, to link them with subsystems.
Requirements prioritization and negotiation – Addressing conflicts between stakeholders by prioritizing needs and negotiating compromises to resolve differences.
Requirements specification – Documenting the agreed requirements formally or informally for the next iteration of the process.
This iterative cycle ensures stakeholder needs are uncovered, refined, and clearly documented for system development.
Requirements elicitation and analysis is an iterative process, starting with discovery and ending with documentation, with feedback improving the analyst’s understanding in each cycle. The process concludes when the requirements document is complete.
4.5.1 Requirements discovery
Requirements discovery (or elicitation) is the process of gathering information about the required system and existing systems, then extracting user and system requirements. Information sources include documentation, stakeholders, and similar system specifications. Interaction with stakeholders may involve interviews, observation, scenarios, or prototypes to clarify needs.
Stakeholders range from end-users to managers and external regulators. For example, in a healthcare system, stakeholders include patients, doctors, nurses, receptionists, IT staff, ethics managers, healthcare managers, and records staff. Beyond stakeholders, requirements can also arise from the application domain and interacting systems.
These sources can be organized into system viewpoints, each showing a subset of requirements. Viewpoints highlight different perspectives on the problem, often overlapping with shared requirements, and help structure both discovery and documentation.
4.5.2 Interviewing
Interviews with stakeholders are a common requirements elicitation technique, where engineers ask questions about current systems and the new system to be developed. These can be closed interviews (structured, pre-defined questions) or open interviews (flexible, exploratory), though in practice most are a mix of both. Interviews help gain insight into stakeholder tasks, interactions with the system, and existing difficulties, but are less effective for uncovering domain or organizational knowledge.
Challenges include stakeholders’ use of domain-specific jargon, which can be misunderstood, and implicit knowledge that experts assume is obvious and therefore fail to mention. Interviews are also limited for organizational requirements, since power dynamics and political issues are often hidden or left unspoken.
Effective interviewers are open-minded and willing to adjust their views based on stakeholder input. They also use springboard questions, proposals, or prototypes to guide discussion, since vague prompts like “tell me what you want” rarely work.
Information from interviews should supplement other sources such as documentation, observations, and prototypes. Used alone, interviews risk missing essential details, so they are best combined with other elicitation methods.
4.5.3 Scenarios
Scenarios help stakeholders better understand system requirements by presenting real-life examples of interactions rather than abstract descriptions. They are especially useful for expanding outline requirements into detailed ones, as each scenario illustrates one or a few possible interactions.
Scenarios evolve from an initial outline to a detailed description during elicitation and can take different forms depending on the level of detail needed. At its most general, a scenario may include:
A description of what the system and users expects when the scenario starts.
A description of the normal flow of events in the scenario.
A description of what can go wrong and how this is handled.
Information about other activities that might be going on at the same time.
A description of the system state when the scenario finishes.
4.5.4 Use cases
Use cases are a key requirements discovery technique introduced in the Objectory method and now central to UML. At their core, they identify the actors (users or systems) involved and the type of interaction with the system. Beyond this, use cases are expanded with textual descriptions or graphical models (e.g., UML sequence or state charts) to illustrate the details of how the interaction unfolds. This helps clarify system behavior and ensures stakeholders understand how the system will be used.
Figure 4.7: Use cases for the MHC-PMS
4.5.5 Ethnography
Software systems do not operate in isolation; they are embedded within social and organizational contexts that strongly influence their success. If these contexts are ignored, a system may technically function but remain unused because it fails to align with real-world practices and constraints. Therefore, understanding and addressing social and organizational requirements is essential in requirements engineering.
One effective technique for uncovering such requirements is ethnography, where an analyst directly observes and immerses themselves in the working environment. By studying day-to-day tasks and interactions, ethnography reveals implicit requirements that may not surface in interviews or formal documentation. This helps capture how people actually work, rather than how organizations say they work.
Figure 4.8: Ethnography and prototyping for requirements analysis
Ethnography becomes even more powerful when combined with prototyping. The prototype provides a tangible system model that can guide the ethnographer’s focus, highlighting problems and raising questions for deeper investigation. At the same time, insights from ethnographic observation can refine the prototype, reducing the number of iterations needed. This integration ensures that requirements are grounded in both real user practices and practical system feedback.
Exercise
What is the main goal of the requirements elicitation and analysis process?
Requirements validation is the process of ensuring that the documented requirements truly reflect what the customer wants from the system. It overlaps with requirements analysis, as both focus on identifying problems or inconsistencies in the requirements. This step is crucial because undetected errors at this stage can lead to significant rework later in development or even after the system is deployed.
Fixing requirement-related issues is far more expensive than correcting design or coding errors. This is because changes in requirements often require revisiting system design, updating implementation, and conducting thorough re-testing. Therefore, validating requirements early helps reduce risks, saves costs, and ensures that the system aligns with customer expectations.
During requirements validation, several checks are performed to ensure the quality and accuracy of the requirements document. These checks include:
Validity checks confirm that the documented requirements truly reflect the needs of stakeholders, while also recognizing that diverse stakeholders may require compromises.
Consistency checks ensure that no requirements conflict or contradict each other, especially when describing the same system function.
Completeness checks verify that all required functions and constraints have been captured, avoiding gaps that could cause issues later.
Realism checks assess whether the requirements are technically feasible and achievable within the given budget and schedule.
Verifiability checks ensure that requirements are expressed in a way that allows testing, making it possible to confirm whether the delivered system meets the specified needs.
Figure 4.9: Requirements evolution
There are a number of requirements validation techniques that can be used individually or in conjunction with one another:
Requirements reviews - The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies.
Prototyping - In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers. They can experiment with this model to see if it meets their real needs.
Test-case generation - Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems.
Requirements for large software systems are always changing because they are developed to solve “wicked” problems, which cannot be completely defined. Since the problem itself is unclear or evolving, the software requirements will inevitably be incomplete and subject to change.
After a system is installed and used, new requirements naturally emerge because users and customers cannot fully anticipate its impact on business processes. With real experience, new needs and priorities are discovered, making change inevitable.
There are several reasons why change is inevitable:
Business and technical environments evolve — new hardware, system integrations, shifting business priorities, or new laws and regulations require updates.
Different stakeholders have conflicting needs — customers who fund the system set requirements based on constraints, which may clash with user needs, leading to additional features after delivery.
Diverse user communities — large systems serve many users with varying, sometimes conflicting priorities, so compromises made initially often need rebalancing as real use reveals gaps.
Requirements management is the process of tracking and controlling changes to system requirements. It involves maintaining links between requirements to assess impacts, establishing a formal change process, and starting management as soon as a draft document exists, while planning for changes should begin during requirements elicitation.
4.7.1 Requirements management planning
Planning is an essential first stage in the requirements management process. The planning stage establishes the level of requirements management detail that is required.
During the requirements management stage, you have to decide on:
Figure 4.10: Requirements change management
Requirements identification - Each requirement must be uniquely identified so that it can be cross-referenced with other requirements and used in traceability assessments.
A change management process - This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.
Traceability policies - These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.
Tool support - Requirements management involves the processing of large amounts of information about the requirements.
4.7.2 Requirements change management
Requirements change management is applied after the requirements document is approved to evaluate proposed changes. It ensures that the benefits outweigh the costs and provides a formal, consistent process so all changes are controlled and documented properly.
There are three principal stages to a change management process:
Problem analysis and change specification - The change management process begins with a requirements problem or change proposal, which is then analyzed for validity. The results are shared with the requester, who may either revise the proposal or withdraw the request.
Change analysis and costing - The proposed change is evaluated by assessing its impact on requirements using traceability data and system knowledge. The cost of implementation is estimated, covering updates to the requirements document and possible design or implementation changes. Based on this analysis, a decision is made on whether to approve or reject the change.
Change implementation - When a change is approved, the requirements document, and if needed, the system design and implementation, are updated. To make this process efficient, the document should be organized for easy modification, with minimal external references and modular sections. This way, individual parts can be updated or replaced without disrupting the rest of the document.
There is often a temptation to implement urgent requirements directly and update the requirements document afterward, but this should be avoided as it risks creating inconsistencies between the specification and the system. Agile methods, like extreme programming, address this by handling changes without formal change management. Instead, users prioritize the new requirement, and if it is high priority, they decide which planned features should be dropped in the next iteration.
Exercise
Why is requirements management important in large software projects?
