Skip to main content - The eBook-Shop with Checklists and Templates for Professionals
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

Template Software Operability Requirements - Overview

Operability Requirements are the major group within the group of Non-Functional Requirements, often referred as “Quality Attributes”.
The purpose of operability requirements is to ensure that an application / an IT system is
  • easy to maintain (serviceability)
  • easy and efficient to operate
  • with high availability and reliability.
Operability Features are best explained by a list of negative examples when those are missing:
  • In case of certain errors the the application hangs up and needs complete restart.
  • To change a simple parameter you need to restart the application. That takes time, and reduces the uptime.
  • During backup the application needs to be shut down (cold backup).
  • To activate debug mode (when searching for errors) the application needs to be restarted.
  • Debug mode works only system-wide, and not for a single process. Not usable during production load – performance will break down, and disks will run full within short time.
  • Adding CPU's does not increase processing capacity because main functionality is served by only one single-threaded process.
Purpose of Operability Requirements is to facilitate reliable operations with sufficient performance. The more requirements are addressed by software, the less repeating work for staff members, who then can pay more attention to improving automated operation and optimizing the system.
Layer Purpose Software Staff
Prevention Avoid interruptions and downtime
  • Recording of operational statistics
  • Monitoring for anomalies e.g. unexpected deviations from operational statistics
  • Daily / weekly activities are fully automated (including archiving and purging of old data and log files)
  • Monthly / Quarterly / Yearly manual review and analysis of operational statistics + activities addressing the findings
  • Manual activities which are not automated yet
  • Adjusting operational parameters
Protection / Defence Avoid interruptions and downtime Limiting workload (e.g. Number of requests/second) to design limit to prevent overload
Self-Repair Minimize duration of interruptions and avoid global downtime "Build Resilience into the Code" e.g.
  • Automated (but limited) restart of a terminated process (e.g. after loosing database connection).
  • Software supports transparent fail-over to other server.
Troubleshooting / Manual Repair Minimize duration of interruptions and avoid global downtime
  • Log files contain meaning full information which is relevant and easy to find.
  • Application software supports activation of debug mode on process level without restart.
  • Other debugging tools are installed.
  • Application supports restarts on process level, without requiring total restart
  • Understanding the internals of application required for troubleshooting.
  • Experience in use of tools used during troubleshooting – in critical situations time to study documentation would result in breaking SLA's.