Your company produces electric windows and corresponding control units. The newest control unit for electric windows has repeatedly been problematic…

Requirement 142 is not verifiable at the system test level. System testing typically validates a system from a black-box perspective, focusing on external inputs and observable outputs. The requirement to "send the message M-85" describes an internal design detail—an internal communication—rather than an externally observable system behavior. Verifying this would necessitate tools to monitor internal bus traffic, which is characteristic of integration or component testing, not system testing. The ISO/IEC/IEEE 29148 standard mandates that requirements must be verifiable. Since this requirement cannot be validated through typical system test approaches, it violates this quality criterion.

A. The requirement 85 is not atomic

Requirement 85 is atomic as it describes a single, indivisible function (the motor stops when resistance is met).

B. The requirement 37 is Inconsistent on system level.

Inconsistency for requirement 37 cannot be determined because no conflicting requirements are provided in the scenario.

C. The requirement 12 is ambiguous.

Requirement 12 is not ambiguous; the terms "central lock is activated" and "windows are automatically closed" are clear and well-understood in the automotive domain.

---

1. ISO/IEC/IEEE 29148:2011, Systems and software engineering — Life cycle processes — Requirements engineering.

Section 5.2.7.8 (Verifiable): This section states, "A requirement is verifiable if its satisfaction can be checked... Non-verifiable requirements include those that are subjective... or specify internal operations of the system that cannot be observed." Requirement 142 specifies an internal operation (sending message M-85) that is not observable from a system-level, black-box perspective, thus violating this characteristic.

2. Wiegers, K., & Beatty, J. (2013). Software Requirements (3rd ed.). Microsoft Press.

Chapter 11, "Specifying Requirements": This chapter distinguishes between functional requirements and design constraints. The requirement to "send the message M-85" is a design or implementation detail, not a true system requirement. A proper system requirement would state the externally observable behavior, such as "The window shall not move when a door is open."

3. Pohl, K. (2010). Requirements Engineering: Fundamentals, Principles, and Techniques. Springer Publishing.

Section 4.3.2 (Quality Criterion: Verifiability/Testability): Pohl explains that a requirement is verifiable if a finite, cost-effective process exists to check its satisfaction. Specifying internal messages makes verification at the system level difficult and costly, as it requires moving beyond black-box testing into more intrusive grey-box or white-box methods, which are typically not the focus of a system test. This aligns with the problem in requirement 142.