Examples for Software Robustness Requirements
What means Robustness?
Robustness means in simple words: The system does not crash at the slightest disturbance.
In which Development Phase needs Robustness to be considered?
- You can't add Robustness by deploying a fragile application into a HA-Framwork; That would just quickly restart the failed module or the whole application but can't prevent the failures!
- Robustness needs to be a Design- and Development Requirement!
Five Example Requirements for Robust API's:
[ROB.1] The listener shall not terminate in case of invalid API-requests; the listener shall reject those.
Threat: The listener terminates in case of an invalid API-request.
Design Pattern: Strong input validation
Testing this requirement: Call API with wrong number of parameters, with wrong data types, with values exceeding the allowed range, with special characters e.g. white spaces, control-sequences, characters beyond standard ASCII-range, …
[ROB.2] The listener shall be resistant against unexpected flood of requests (which could be a real unexpected load-peak, the result of errors in the calling application resulting in infinite number of retries, or an intentional attack).
Threat: The listener terminates or stalls under an unexpected flood of requests.
Design Pattern: Ability to count and limit the number of requests or open sessions accepted per source (server, IP-number), username. Return a defined error message.
Testing: Submit more requests then the API can handle.
Comment:The calling application needs to treat this error message accordingly!
[ROB.3] The listener shall never spawn that many application processes such that the server hits a maximum process limit or runs out of memory, or the dedicated database sessions created by the application processes causes the database to exceed the maximum session limit.
Threat: The server crashes or stalls when reaching the process- or memory limit.
Design Pattern: Listener needs to be capable of keeping track of spawned and terminated application processes, and limiting those to a configurable limit.
Testing: Cause a load-situation that listener will spawn maximum number of application processes, and verify if after further increase listener rejects new requests.
Comment: The calling application needs to be also robust against termination in case that listener rejects API-requests!
[ROB.4] In case that the application process cannot connect to the database (e.g. database exceeded the session limit, or the account has been locked), the application process shall not mutate to a zombie process but terminate with an error message.
Threat: Server crashes due to too many zombie-processes
Design Pattern: Implement exception handling
Monitoring: Monitor for existence of zombie processes, create warn- and alarm notification on defined thresholds.
[ROB.5] The database shall be protected from reaching the session limit caused by unexpected number of database connections, e.g. from application processes or interfaces opening a new database connection per request without closing / log out previous database session.
Threat: The database reaches the session limit and rejects new sessions resulting in a partial unavailability of service.
Design Pattern: Use either “only one database session per application process instance” or use connection / session pooling.
Testing this requirement:Verify that the number of database sessions does not increase beyond the required and designed level.
Monitoring: monitor number of database sessions and warn / alert when reaching warning and alarm threshold.
Last line of defence: Locking database account of that interface, user or application module causing too many database sessions.
Pre-Requisite: using different user accounts for each interface and application module.
Non-Functional Requirements