Skip to main content

IT-Checklists.com - The eBook-Shop with Checklists and Templates for Professionals
logo
Our Guarantee
Immediate download
Money back if not fully satisfied
Skip main navigation
Template Systems Operations Manual Template Data Centre Operations Manual Data Migration Checklist Nonfunctional Requirements Interface (EAI) Checklist Server Upgrade / Migration Checklist Application Upgrade / Migration Checklist Application & Server Inventory Template Release Checklist Outage Planning Application Cloning Application Retirement Application Health check Archiving Requirements Disaster Recovery (DR) Technology Selection Backup OLA / SLA Database OLA / SLA DBA Job Description Database Health Check
Application SupportData MigrationOLA / SLA Operations Level AgreementSystem DocumentationProject ManagementDeploymentQuality AssuranceCompliance and StandardsDatabase Administration Non-FunctionalScalabilityRobustnessOperabilityDiagnosabiliyArchivingStart-up PhaseAchieving Operational ReadinessStabilized Operations

IT-Checklists > DevOps > Operability Requirements

Examples Software Operability Requirements


The "Template Operability Requirements" provides more than 100 detailed requirements covering following groups:
  1. Robustness
  2. Monitoring
  3. Performance and Scalability
  4. Manageability
  5. Troubleshooting
  6. Availability
  7. Recoverability
  8. Deployment

Robustness and Resilience Requirements

[ROB.001]External Disturbances don't result in a Crash or hang-up.
[ROB.002]In case of system starvation, e.g. because of overload the system will continue without requiring restart once load level is back within designed range.


Back to Top

Monitoring Requirements

Monitoring identifies anomalies before those become a problem. Addressing those anomalies and preventing problems which may lead to (short) interruptions due to failures, fail-overs or even requiring a restart is the optimal and desired approach to achieve high availability.
Buying a monitoring framework is just the very first step! - Standard modules of such monitoring frameworks support just monitoring of database, operating system and hardware [MON.001], but do not know anything about your specific application [MON.002], [MON.003], .....

[MON.001]Database, Operating System and Hardware are monitored using standard modules of monitoring framework.
[MON.002]All application batch jobs are monitored for terminations.
[MON.003]Monitoring needs to detect application batch jobs which did not start at scheduled time.

More monitoring requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top


Performance and Scalability Requirements

[SCAL.001]The application needs to be vertical scalable; the application's throughput needs to increase when adding CPU's and / or Memory.
[SCAL.002]The application needs to be horizontal scalable; the application throughput needs to increase when adding additional servers.
[SCAL.003]The application vendor needs to provide at least one reference where required scalability has been proven in production.
[PERF.001]The latency (response time) for activity ... must be below .. seconds in 98% of cases it ... load of .... requests/second.
[PERF.002]The latency (response time) for activity ... must be below .. seconds in 98% of cases it ... load of .... requests/second.

More Performance- and Scalability Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top

Manageability Requirements


[MANAG.001]All jobs and background processes must be start- and stoppable from command line.
[MANAG.002]The application needs to support the scheduling of batch jobs through our enterprise scheduling system <..product name..>.
[MANAG.003]All jobs should be runnable at any time without conflicting with other jobs or interactive users. In case that certain batch jobs can't run at same time, the later started job needs to detect that an incompatible job is running and it must terminate immediately with clear error message.
[MANAG.004]Change of processing parameters shall not require a restart; rolling restarts are accepted.

More Manageability Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top

Troubleshooting Requirements

In case that problems do happen, it's a matter of easy or complex troubleshooting and speed of repair / restart if SLA's will be violated or not.
[TROUB.001]Meaningful Warning- and Error-Messages including full error-stack need to be written to the application log file.
[TROUB.002]The application log files need to be switched e.g. daily, and the history needs to be kept ... days.
[TROUB.003]Debug-Mode (Trace-Mode) can be activated for selected processes (not just complete application) without restart.

More Troubleshooting Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top

Availability Requirements

Minimizing Scheduled Downtime
[AVAIL.001]Following parts of application shall support "Rolling Upgrade":....
[AVAIL.002]The required downtime for a major version upgrade shall be below ... hours including shutdown and restart.
[AVAIL.003]The required downtime for a patch upgrade shall be below ... minutes including shutdown and restart.

Minimizing Unplanned Downtime
[AVAIL.004]Low: The application needs to support a Failover-Cluster to mitigate hardware defects.
[AVAIL.005]The license key for the 2nd server is part of the delivery.
[AVAIL.006]Successful passed Failover-Testing is a mandatory pre-requisite before production deployment.
[AVAIL.007]High: The application needs to support an Active/Active (Hot/Hot), Active/Standby Cluster
[AVAIL.006]

More Availability Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top

Recoverability Requirements

[RECOV.001]The application needs to support Online-Backup.
[RECOV.002]The application needs to provide sufficient transaction logging such that in case of media failure requiring restore from last backup all transactions committed before failure can be recovered.
[RECOV.003]In case of crash in the middle of processing a data file, the application needs to provide a mechanism to either back out the transactions of the partial processed file, or allow to resume processing without causing missing or duplicate records.
[RECOV.004]The application needs to support a "Point-in-Time" recovery consistent across database and data outside of database.

More Recoverability Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top

Deployment Requirements

[DEPL.001]The deployment is fully automated; the deployment on production environment shall support manual confirmations in case of changes on data structures, e.g. "drop table", "alter table".
[DEPL.002]The deployment of a new release does NOT change back parameters to its default values.
[DEPL.003]In case that the deployment requires restart of processes, a rolling restart is desired to meet uptime requirements.

More Deployment Requirements are provided
in our "Template Operability Requirements": Arrow rightPurchase Information
Back to Top