| ... |
... |
@@ -29,9 +29,10 @@ |
| 29 |
29 |
* **Non-Functional Requirements** |
| 30 |
30 |
** **Lower-level technical use cases** derived from high-level business use cases that are not directly visible to end users, but form the backbone of software functionality. This includes the expected behavior of the underlying components, modules and units. |
| 31 |
31 |
** **Border cases** that could theoretically occur, such as maximum/minimum values, nulls, invalid input outside the permissible value range, zeroes, negative numbers, empty lists, values with special meaning, exceptions, etc. |
| 32 |
|
-** **Performance requirements** |
| 33 |
|
-** **Security requirements** |
| 34 |
|
-** **Load requirements**, when software is expected to handle a certain number of requests per second. |
|
32 |
+** If existent: |
|
33 |
+*** **Performance requirements** |
|
34 |
+*** **Security requirements** |
|
35 |
+*** **Load requirements**, when software is expected to handle a certain number of requests per second. |
| 35 |
35 |
* At any level of abstraction, you should always test **happy path** requirements, where everything works as expected, and **unhappy path** requirements, where something goes wrong or an unusual input is provided. Writing tests for the latter makes the software robust against misuse. |
| 36 |
36 |
|
| 37 |
37 |
=== Related Topics === |
