Skip to main content - The eBook-Shop with Checklists and Templates for Professionals
logo ITCL
Skip main navigation
Template Systems Operations ManualTemplate Data Centre Operations ManualData Migration ChecklistNonfunctional RequirementsApplication Interface (EAI) Checklist Server Upgrade / Migration ChecklistApplication Upgrade / Migration ChecklistApplication & Server Inventory TemplateRelease ChecklistOutage PlanningApplication RetirementApplication Health checkArchiving RequirementsDisaster Recovery (DR) Technology SelectionBackup OLA / SLADatabase OLA / SLADBA Job DescriptionDatabase Health CheckStandby Database
The author of this template bears following credentials:
OCP 9i Logo
OCP 10g Logo
Logo ITIL green
Application SupportData MigrationOLA / SLA Operations Level AgreementSystem DocumentationProject ManagementDeploymentQuality AssuranceCompliance and StandardsDatabase AdministrationStart-up PhaseAchieving Operational ReadinessStabilized Operations

Examples for 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:

Figure showing 5 Requirements for Robustness of an API

[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.

More Robustness Requirements

Robustness is one important group of Non-Functional Requirements. More you find in our template dedicated to this important topic:

Other Non-Functional Requirements

Other Non-Functional Requirements find in our template dedicated to this important topic: