Assessing program risk for hidden reliability obstacles
Before a single defect is counted, IEEE 1633 has the program look at itself: process maturity, staffing experience, requirements volatility, tooling, and schedule pressure are all obstacles that quietly determine how reliable the software will be, regardless of how skilled the engineers are.
This early risk assessment surfaces the obstacles that a later defect count or test report would never reveal on its own — the things that go wrong before the code does.
Requs AI Risk ID has the complete assessment built from the world's biggest defect density benchmarking study.
Software failure modes analysis
IEEE 1633 prescribes a software-specific FMEA: failure modes are identified from how software actually breaks — logic, requirements, interfaces, timing, and state — rather than adapted from a hardware parts-and-mechanisms model. It's the same discipline SAE1025's Section 7 draws on for its own SwFMEA treatment.
Requs AI Software FMEA has the structured list of root causes (common defect enumerations) tailored to your software system. Our machine learning model automatically computes the occurrence in compliance with SAE 1025. Requs AI Blueprint takes Requs AI Software FMEA a step further with pre-populated edge cases based on your design models.
Predicting software reliability before the code is written
Using factors known at the planning stage — application domain, development process maturity, team experience, and estimated size — the practice produces an initial failure-rate prediction before development starts. That early number is what lets a program set realistic test budgets and release criteria instead of discovering them too late.
Forecasting reliability growth in testing
Once testing is underway, software reliability growth models fit the shape of the failure-discovery curve to forecast how reliability will keep improving as defects are found and fixed — turning a raw defect log into a projection of when the software will actually be ready.
Requs Trend does common sense forecasting as per the IEEE 1633 2026 edition. The goal isn't to pick "one" model. The goal is to apply a variety of models, ignore the models with assumptions that don't fit the data and ensemble average the others based on their accuracy.
Measuring reliability in operation — and calibrating the model
After release, field failure data closes the loop: it's used to measure actual operational reliability and, just as importantly, to recalibrate the characterizations used at prediction and growth-forecasting time — so the next program's early estimates get sharper, not just the current one's after-the-fact report card.
Common Defect Enumerations
Failure modes analysis in IEEE 1633 draws on Common Defect Enumerations (CDE) — structured, pre-populated lists of defect types that have historically and repeatedly led to software failures — so analysts start from an evidence-backed inventory instead of a blank page.
Illustrative examples of the kind of defect classes a CDE-style taxonomy indexes — shown here to convey the approach, not reproduced from the standard's own list.
Requs AI Edge Case and Requs AI Software FMEA have the latest common defect enumeratins built in. The software determines which do and do not apply and then it expands the CDEs into the software FMEA and assesses the immediate effect
AI/ML functional and process failures
The practice extends beyond conventionally-coded software to systems built on machine learning, covering two distinct failure layers:
Failures in what the model actually does — degraded accuracy on data unlike its training set, drift as the operating environment changes, and behavior that's hard to specify precisely because it was learned rather than coded.
Failures in how the model is built and kept current — data governance gaps, training-data bias, missing validation before deployment, and ungoverned retraining that silently changes behavior over time.
End-to-end: a smart traffic light system
IEEE 1633 is illustrated with a worked example — a smart traffic light controller — carried through every practice above, so the methods are shown working together rather than in isolation.
Producing assessments that add value to the program
A reliability assessment that only produces a score is shelfware. IEEE 1633 frames the goal as decision-useful output — findings tied to real program choices like release readiness, test-effort allocation, and staffing — so the analysis changes what the program does, not just what it files.
Chaired by the person who wrote much of this discipline
Ann Marie Neufelder, founder of Mission Ready Software, chairs the IEEE 1633 working group — the same practitioner behind the occurrence-rating model referenced elsewhere in this framework, and behind much of the practical, evidence-based approach to software reliability that IEEE 1633 codifies.