System availability objectives, error budgets, and integration with hardware
Turn a system-level availability objective into an achievable software error budget, and combine software and hardware predictions into one system reliability picture.
A system objective is only useful once it's been split into a software budget
A system-level availability requirement doesn't mean anything to a software team until it's been translated into a specific error budget — the portion of allowable failure that software is actually responsible for. This class covers how to apportion that budget, combine it with hardware predictions into one system reliability number, and allocate it back down using either a top-down or bottom-up approach.
This class pairs naturally with Requs AI Predict — but doesn't require owning it. It's built to be useful on its own.
What the class covers
Five modules, covered in a single self-guided half day.
Identify the portion of failures that will originate in the software
Methods for apportioning the software's share of system failures — by work effort, by past history, and by achievable failure rates — instead of an arbitrary split.
Every downstream calculation in this class depends on getting this apportionment right. Guess here, and the error budget that follows is meaningless.
Identify a system-level RAM objective that is feasible for this error budget
How to check whether a proposed system-level RAM objective is actually achievable given the software's apportioned error budget — before the objective gets locked in.
An infeasible objective doesn't become feasible by being written into a requirements document. Catching it here is far cheaper than catching it in test.
Combine software and hardware reliability predictions to predict system reliability
How to combine software and hardware reliability predictions into a single system-level number, using models including reliability block diagrams, mission models, operational profile models, use case models, fault tree models, and Markov models.
A system doesn't care whether a failure came from hardware or software. Reporting them separately hides the number that actually matters.
Establish reliable software allocations using top-down or bottom-up approaches
How to allocate the system reliability budget down to individual software components, using either a top-down approach (starting from the system objective) or a bottom-up approach (starting from component-level estimates).
An allocation is what turns a system-level number into something an individual software team can actually design and test against.
Identify system-level alternatives and trade-offs
How to identify system-level alternatives when the numbers don't add up — where scope, schedule, hardware redundancy, or the objective itself might need to give.
An infeasible budget isn't the end of the conversation. This module is how you find what's actually negotiable.
Format, duration, and prerequisites
Half Day
Delivered as a single, condensed half day of self-guided instruction.
Virtual, Self-Guided
Work through the material on your own schedule, at your own pace.
None Required
No prior class or Requs AI product is required — this class can be taken entirely on its own.
This class supports two Reliable Software SOW tasks
The topics in this class map directly to two tasks in the DoW Reliable Software Statement of Work.
Include Software in the System Reliability Model
Combining software and hardware predictions into one system reliability model, as covered in §3.
Reliable Software Allocation
Establishing top-down or bottom-up reliable software allocations, as covered in §4.
Turn a system objective into a software budget your team can actually hit.
Register for the class, or schedule a demonstration of Requs AI Predict.