The success of a software system is fundamentally measured by how well it fulfills its intended purpose. To ensure this alignment, a structured approach known as Requirements Engineering (RE) is employed.
Definition
RE is a comprehensive process aimed at uncovering the specific needs and expectations of various stakeholders involved in a project.
This process encompasses several critical steps:
- Identifying Stakeholders: Stakeholders are individuals or entities with a vested interest in the software system. They can range from end-users and clients to non-human systems that will interact with the software. It is essential to:
- Identify Who They Are: Understand the different types of stakeholders, such as users, managers, technical teams, and external systems.
- Define Their Roles: Determine the responsibilities of each stakeholder and how they will interact with the system.
- Clarify Their Expectations: Gather insights into what each stakeholder expects from the system, which will guide the requirements gathering process.
- Eliciting Needs: Once stakeholders are identified, the next step is to elicit their needs, which involves:
- Understanding Their Goals: What do stakeholders aim to achieve with the system? This could include functionality, performance, and usability objectives.
- Recognizing Constraints: Identify any limitations or constraints that must be adhered to during development, such as budget, technology, regulatory standards, and timelines.
- Documenting Requirements: Effective documentation of the identified requirements is crucial for clear communication among stakeholders and for guiding development. This documentation should:
- Be Clear and Comprehensive: Use unambiguous language and standard formats to ensure that all parties have a common understanding of the requirements.
- Facilitate Analysis: The documentation must be structured in a way that allows for analysis to identify potential issues, conflicts, or gaps in requirements.
- Support Implementation: Ensure that the documented requirements are feasible and can be translated into actual software functionalities.
- Analyzing and Communicating Requirements: Once documented, requirements must be analyzed to ensure they meet stakeholder needs. This includes:
- Reviewing and Validating Requirements: Engage stakeholders in reviewing requirements to confirm their accuracy and completeness.
- Communicating Findings: Share insights and potential concerns with stakeholders, fostering collaboration and alignment.
- Implementing Requirements: The final stage involves turning documented requirements into a working software system. This requires:
- Technical Specifications: Translate requirements into technical specifications that developers can follow.
- Iteration and Feedback: During implementation, seek continuous feedback from stakeholders to ensure the system remains aligned with their needs.
Definition
Requirement: A specific statement detailing what must be fulfilled by the software system to satisfy stakeholder needs.
Types of Requirements in Software Development
In software development, requirements are categorized into three primary types: functional requirements, non-functional requirements (NFRs), and constraints. Each type plays a crucial role in defining the expectations for the software system and guiding its design and implementation.
- Functional Requirements: Functional requirements specify the interactions between the software system and its environment. They outline what the system must do and describe the main functionalities that must be implemented, independent of how these functionalities are realized.
Example
- “The word processor shall allow users to search for strings in the text.” This requirement specifies a core functionality of the application, enabling users to locate specific text within documents.
- “The system shall allow users to reserve taxis.” This describes a fundamental feature of a transportation application, illustrating how users can interact with the service.
- Non-Functional Requirements (NFRs): Non-functional requirements characterize the qualities and constraints of the system that are not directly tied to specific functionalities. They provide additional context regarding how the system should perform, ensuring a positive user experience and operational efficiency.
Example
- “The response time must be less than 1 second.” This requirement emphasizes the performance expectation of the system, indicating that user interactions should be processed swiftly.
- “The server must be available 24 hours a day.” This defines the reliability expectation, indicating that the system should have high availability and uptime.
- Constraints (Technical Requirements): Constraints are limitations imposed by external factors, such as customer specifications or environmental conditions. These requirements define the boundaries within which the system must operate and guide design decisions.
Example
- “The implementation language must be Java.” This constraint specifies the programming language that developers must use, influencing design and development approaches.
- “The credit card payment system must be able to be dynamically invoked by other systems relying on it.” This requirement illustrates an integration constraint, emphasizing the need for interoperability with other software systems.
Non-Functional Requirements (NFRs) and Product Qualities
Non-functional requirements (NFRs) are critical to defining the overall quality and effectiveness of a software system. Unlike functional requirements, which detail what a system should do, NFRs focus on how the system performs its functions and the external qualities that must be achieved.
Characteristics of NFRs
- Measurable Metrics: NFRs are predicated upon external qualities that can be quantified through specific metrics. This allows for objective assessment and verification during testing and evaluation.
- Constraints on Functionality: NFRs impose constraints on how functionalities should be delivered to the end user, influencing the user experience and satisfaction.
- Domain-Specific Relevance: The importance and prioritization of NFRs are determined by the application domain. Different systems will have varying NFRs based on their context and purpose.
Examples
- For Streaming Services like Netflix:
- Availability: The system must ensure high uptime to provide uninterrupted service to users.
- Performance: Fast response times and minimal buffering are essential for a smooth streaming experience.
- Scalability: The system should handle a growing number of users without degradation in performance.
- For Aerospace Systems like Ariane 5:
- Safety: The system must ensure user and operational safety, as failure can have catastrophic consequences.
- Reliability: The system should consistently perform as expected under various conditions, with minimal risk of failure.
- Compliance: Adherence to regulatory standards is crucial in ensuring safety and reliability.
NFRs significantly influence the architecture and design choices made during the software development process:
- Architectural Decisions: NFRs guide how a system is structured. For example, a requirement for 24/7 availability may necessitate a replicated system architecture with redundant components to ensure continuous operation.
- Design Choices: Choices related to technology stacks, data storage solutions, and deployment strategies are often driven by the need to meet NFRs.
- Cost Considerations: Implementing and testing NFRs can be expensive. As such, they must be carefully analyzed and managed throughout the development lifecycle to avoid unforeseen challenges.
Examples of bad requirements
- “The system shall validate and accept credit cards and cashier’s check with high priority”
Issue(s)? Description Multiple concerns two requirements instead of one Ambiguous if the credit card processing works, but the cashier’s check validation does not, is this requirement satisfied? Ambiguous does “high priority” refer to cashier’s checks only, so are credit cards low priority? Other way around? Are they both high priority?
- “The system shall process all mouse clicks very fast to ensure users do not have to wait”
Issue(s)? Description Cannot be verified (tested) what does “fast” mean? Do we have a metric? Can you quantify it?
- “The user must have Adobe Acrobat installed”
Issue(s)? Description Cannot be achieved by the software system itself it is not something the system must do It could be expressed as a constraint or assumption, but it is not a functional requirement
Issues Concerning Requirements Engineering
Requirements Engineering is a critical phase in the software development lifecycle, yet it faces several challenges that can undermine the success of a project.
Quality of requirements is a critical aspect of software development, yet poorly defined or ambiguous requirements are ubiquitous in many projects. Such requirements can lead to misunderstandings, scope creep, and ultimately project failure. For instance, a requirement stating, “The system should guarantee that the reserved taxi picks the user up,” may sound reasonable at first glance, but it raises questions about feasibility, accountability, and the conditions under which this guarantee can be made. Additionally, not all requirements are implementable due to various constraints such as technological limitations, budgetary issues, or unrealistic expectations. Therefore, requirements must be scrutinized for practicality to avoid complications during implementation. According to Bell and Thayer’s empirical study (1976), requirements need to be continuously reviewed and revised. As projects evolve, stakeholder needs and environmental conditions may change, necessitating ongoing adjustments to the requirements.
The complexity of RE is another significant challenge. F. Brooks (1987) emphasized that one of the most challenging yet vital functions of software engineering is the iterative extraction and refinement of requirements. This process involves engaging stakeholders to gather insights about their needs, which can be complex as different stakeholders may have conflicting requirements or varying levels of understanding. The iterative nature of RE adds complexity, requiring careful management of time and resources to revisit and refine requirements multiple times. Effective RE is critical to the success of a software project. Poorly defined requirements can lead to costly rework, project delays, and the delivery of systems that do not meet user needs or expectations.
Cost of Late Correction in Software Development
In software development, the timing of error detection greatly influences correction costs. According to Boehm, the cost of correcting an error increases as development progresses, particularly for errors originating in the requirements phase.
- Cost Dependency: The cost to correct an error escalates with the number of decisions influenced by that error. Late identification means more decisions are affected, leading to higher correction costs.
- Impact of Requirement Errors: Errors in requirements are particularly costly because they underpin subsequent design and implementation decisions. A flawed requirement can cascade through the development process, compounding costs.
The chart below illustrates the relative cost of error correction across different stages of the development lifecycle:
xychart-beta x-axis [Requirements, Design, Code, Unit Test, Acceptance Test, Maintenance] y-axis "Relative Cost of Error Correction" 0 --> 200 title "Cost of Error Correction" bar [1,5,10,20,50,200]
- Requirements Phase: The cost of correcting errors is minimal during the requirements phase, as changes can be made relatively easily and without significant implications for subsequent stages.
- Design Phase: Costs begin to rise as design decisions are based on requirements, making any necessary corrections more complicated and costly.
- Code Phase: By the time coding begins, the cost escalates further, as developers may have implemented features based on flawed requirements.
- Unit Test Phase: Correction costs continue to rise during unit testing when errors must be identified and fixed in the code.
- Acceptance Test Phase: By acceptance testing, the costs increase dramatically as the system is evaluated against user expectations and requirements.
- Maintenance Phase: In the maintenance phase, the cost of correcting errors reaches its peak. Changes may require substantial rework, including updates to documentation, retraining users, and more.
Complexity of Requirements Engineering
Requirements Engineering is inherently complex due to several interconnected factors. Firstly, the broad scope of RE involves understanding a combination of human organizations, physical devices, and software components, making the system’s context multifaceted. Often, there are various proposals for the desired system, including system evolutions and product families, which complicate decision-making. Additionally, RE must address different levels of abstraction, from high-level goals to operational details, requiring a comprehensive understanding of both strategic and tactical aspects.
Secondly, RE encompasses various concerns, including functional requirements, which define what the system should do, and quality attributes, which describe how well the system performs its functions, such as performance and reliability. Development considerations, including resources, timelines, and technologies needed for implementation, must also be taken into account. Both hard concerns, which are measurable aspects like performance, and soft concerns, which are subjective aspects like user satisfaction, must be balanced.
Lastly, RE involves multiple stakeholders with varying backgrounds and perspectives, such as customers who fund and define needs, users who interact with the system and provide insights on usability, domain experts who offer specialized knowledge relevant to the system, and developers who implement the system and understand technical constraints. Conflicts may arise between stakeholders due to differing priorities and perspectives. Effective RE requires managing these conflicts and finding trade-offs that satisfy the needs of all parties involved.
This RE workflow emphasizes the iterative nature of the process, where feedback loops exist between elicitation, modeling, analysis, and validation. By engaging stakeholders throughout and leveraging existing systems and documentation, RE aims to create well-defined requirements that guide the successful development of software systems.
- Stakeholders: Various individuals or groups (e.g., customers, users, domain experts) who have an interest in the system. Their input is essential for understanding needs and expectations.
- Existing Systems and Documents: These provide context and background information that inform the requirements gathering process. They help identify what has been done previously and what can be improved or integrated.
- Elicitation and Modeling: This step involves gathering requirements through discussions, interviews, and workshops with stakeholders. It also includes modeling those requirements using diagrams and frameworks to visualize relationships and functionalities.
- Requirements Models: The output of the elicitation and modeling process, these models represent the gathered requirements in a structured way, making it easier to analyze and validate them.
- Analysis and Validation: This phase ensures that the requirements are clear, complete, and aligned with stakeholder needs. It involves reviewing the models with stakeholders to confirm their accuracy and relevance.
- Generation of RE Deliverables: From the validated requirements models, formal documentation is produced, including a requirements document. This document serves as a comprehensive reference for the development team and other stakeholders
The World and the Machine
Definition
- Machine: the portion of the system to be developed (typically, software-to-be + hardware)
- World (or environment): the portion of the real-world affected by the machine
The purpose of the machine is always in the world.
Ambulance Dispatching System
- For every urgent call reporting an incident, an ambulance should arrive at the incident location within 14 mins
- For every urgent call, details about the incident are correctly encoded
- When an ambulance is dispatched, it will reach the incident location in the shortest possible time
- Accurate ambulance locations are known by GPS
- Ambulance crews correctly notify ambulance availability through a mobile data terminal
Requirements Engineering focuses on understanding phenomena occurring in the real world and translating these into actionable requirements for software systems. Using an ambulance dispatching system as an example, we can differentiate between real-world occurrences and machine-level phenomena.
Real-World Phenomena are occurrences that take place in the environment and are critical for understanding the system’s context:
- Occurrences of Incidents: Events that require emergency response.
- Reporting of Incidents: Public calls to report emergencies, which initiate the dispatching process.
- Encoding of Call Details: The process of inputting the details from the calls into the dispatching software.
- Allocation of an Ambulance: The decision-making process involved in assigning the nearest ambulance to the incident.
- Arrival at Incident Location: The actual arrival of the ambulance at the site of the emergency.
Machine-Level Phenomena are actions occurring within the software or system, focusing on internal processes:
- Creation of a New Object of Class Incident: A programming action that represents the creation of an incident record in the system.
- Update of a Database Entry: An operation that modifies existing data related to incidents or resources in the database.
Categories of Assertions
- Goals: Goals represent desired outcomes formulated in terms of world phenomena. These goals may not necessarily be shared among all stakeholders. For example, a goal might be to reduce the average response time for ambulance dispatches.
- Domain Properties/Assumptions: These assertions describe properties that are assumed to hold in the real world. They provide a foundation for understanding the environment in which the system operates, such as the average time it takes for an ambulance to arrive at different locations.
- Requirements: Requirements are formulated in terms of shared phenomena that stakeholders agree upon. These represent the functionalities and constraints of the system, such as the requirement that an ambulance must be allocated within a specific time frame after an incident is reported.
Example
Example Goal ”For every urgent call reporting an incident, an ambulance should arrive at the incident scene within 14 minutes” Domain assumptions ”For every urgent call, details about the incident are correctly encoded" "When an ambulance is dispatched, it will reach the incident location in the shortest possible time" "Accurate ambulance locations are known by GPS" "Ambulance crews correctly notify ambulance availability through through an existing mobile data terminal” Requirement ”When a call reporting a new incident is encoded, the Automated Dispatching Software should send the nearest available ambulance according to information available from location updates and availability notifications”
Given the set of requirements
where
Examples of Goals, Assumptions and Requirements
The Turnstile Control System (TCS) is designed to manage and control access, allowing entry only to individuals who have made a payment (in this case, using a coin). Below are the key goals associated with the system:
Goal
: Entry Limitation
At any given time, the total number of entries must not exceed the total number of payments received. For simplicity, we assume that one coin corresponds to one entrance. This goal ensures that the system does not allow more entries than the payments made.
: Access for Paying Individuals
Individuals who have paid should be allowed to enter without any restrictions imposed by the turnstile. This goal guarantees that the payment mechanism functions correctly, enabling access for those who fulfill the entry requirement.
The stated goals (
Steps
- Carry out domain analysis, identifying phenomena, in particular the shared ones, and relationships among phenomena
- Define requirements, with an eye towards the goals to be achieved, and make sure that requirements are expressed using only shared phenomena
- Prove that
(i.e., requirements + domain assumptions guarantee goal satisfaction)
When designing the Turnstile Control System, it’s important to identify phenomena that are relevant to its purpose—specifically, controlling entrance to a building. We can categorize these phenomena into four distinct types: Environment, World, Shared, and Machine. Each category describes how these phenomena interact with the TCS and the environment.
| Type of Phenomena | Phenomena | Description |
|---|---|---|
| Environment/Shared | Coin | A coin is inserted into the machine. |
| World | Push | A person pushes the turnstile. |
| Environment/Shared | Turn | The turnstile turns after being pushed. |
| World | Enter | A person enters the room through the turnstile. |
| Machine/Shared | Lock | The machine locks the turnstile after entry. |
| Machine/Shared | Unlock | The machine unlocks the turnstile for entry. |
The events Push, Turn, and Enter are interconnected and exist outside the control of the TCS. These relationships are encapsulated in domain assumptions, which help in understanding how these phenomena interact within the system:
: A Turn occurs only after a Push. This assumption states that for the turnstile to turn, it must first be pushed by a person. : A Turn leads to an Enter. Once the turnstile turns, it allows entry into the room. : An Enter occurs only after a Turn. Entry into the building is contingent on the successful turning of the turnstile.
While the Push and Turn events are distinct, they are often closely linked in practice. To simplify the study of the TCS, we can conflate these two events into a single event termed Push&Turn, which can be considered a shared, world-controlled event. This leads to the introduction of a new assumption:
: A Push leads to a Turn. This assumption simplifies the analysis by stating that pushing the turnstile results in it turning.
The following domain assumptions outline the operational constraints and relationships inherent in the Turnstile Control System (TCS). These assumptions ensure that the system functions smoothly while adhering to the specified goals.
-
Alternation of Events:
: An Enter cannot occur without a preceding Push&Turn. : A new Push&Turn cannot occur until the previous visitor has entered. - Combined Assumption
: Push&Turn and Enter alternate, starting with Push&Turn. This encapsulates the idea that each action must follow a specific order to maintain system integrity.
-
Effectiveness of Push&Turn:
: A Push&Turn always leads to an Enter. This assumption is supported by the mechanics of the turnstile, which ensures that once it turns, entry is granted.
-
Lock Mechanism:
: A Push&Turn cannot occur if the turnstile is Locked. This establishes a control mechanism where the state of the turnstile directly affects the ability to initiate a new entry.
-
Minimum Delay Requirement:
: After a Push&Turn, there is a minimum delay before the next Push&Turn can occur. This delay prevents rapid successive entries, ensuring orderly access and managing crowd control.
The goal
- Controlling Entries: The system can manage the number of Enter events to ensure they do not surpass the number of coins inserted.
- Controlling Coins: While the machine cannot directly enforce Coin events (since it relies on user action to insert coins), it can prevent Enter events through the Lock mechanism.
Requirements Analysis
The goals of the Turnstile Control System are defined as follows:
Goal
: The number of entries must never exceed the number of accumulated payments (i.e., ). : Individuals who pay should not be prevented from entering (by the machine).
To ensure that these goals are met, we outline specific requirements and demonstrate how they collectively guarantee the goals.
Requirements for Goal
: TCS must issue the unlock command only if the number of Push&Turn events is less than the number of accumulated payments (i.e., only if holds). : If a Push&Turn occurs and holds, TCS must issue a Lock command within time (i.e., before the next Push&Turn can occur). : TCS must lock the turnstile at startup time.
The combination of
- From
: holds. - Thus, if
is maintained, it ensures .
graph LR start -.-> A((e=p)) -- Push&Turn --> B((e=p-1)) -- Enter --> A
- Initially, when
, the turnstile is locked (as per ), so no Push&Turn can occur (due to ). - The turnstile can only be unlocked if
(according to ). Hence, the first coin must be inserted before the first Push&Turn can take place. - When
, if a Push&Turn occurs (let’s denote the updated count as ): - If
, necessitates a time before another Push&Turn can occur, and ensures a Lock command is issued within that time frame. - Thus, a new Push&Turn cannot happen unless a new coin is inserted (i.e., until
again).
- If
Requirements for Goal
: TCS must lock the turnstile only if holds. : If holds and the turnstile is locked, TCS must unlock the turnstile.
The combination of
- From
and , Enter occurs if and only if Push&Turn occurs. - From
, Enter can only occur if the turnstile is unlocked. - To demonstrate
: - If
, we consider two scenarios: - If the turnstile is already unlocked,
states the machine does not lock it, so it remains unlocked. - If the turnstile is locked,
mandates that the machine unlocks it.
- If the turnstile is already unlocked,
- If
What can go wrong when defining
In September 1993, a Lufthansa Airbus A320 crashed while landing in poor weather conditions, resulting in fatalities and injuries. A critical factor in this incident was a software-controlled braking system that deployed with a significant delay. This delay led to insufficient runway length for the aircraft to stop safely. The analysis identified multiple causes, including human errors and software errors in the braking control system.
The primary goal of the aircraft’s system was to ensure that reverse thrust was enabled when the aircraft was moving on the runway, represented logically as
However, the intended correctness argument suggested that the requirements
The consequences of these flawed assumptions were significant, highlighting the critical dependence of system performance on valid domain assumptions. The crash illustrated that assumptions are often based on ideal conditions that may not always be present in real-world scenarios. When these assumptions are incorrect, they can lead to catastrophic failures. Additionally, the incident underscored the importance of considering edge cases, such as adverse weather conditions or mechanical failures, in the design of safety-critical systems.