Analyse-it is commercial off-the-shelf (OTS) statistical analysis software, developed following a documented software development lifecycle with extensive internal and benchmark testing before every release. We are responsible for producing numerically accurate, reliable software and for maintaining evidence of how we build and test it. You, the user, are responsible for validating Analyse-it for your specific intended use within your quality system — the shared-responsibility model that applies to all off-the-shelf software in regulated environments.
This page describes our development and testing process, summarises your validation responsibilities, and answers common questions from quality managers, regulatory affairs professionals, and auditors. It is written to support validation activities under the FDA Quality Management System Regulation (QMSR), 21 CFR Part 11, ISO 15189, ISO/IEC 17025, ISO 13485, EU IVDR, and CLIA ’88.
The principle that the end user is responsible for validating off-the-shelf software for its intended use is consistent across every major regulatory framework our customers work under. Analyse-it is used by IVD manufacturers, clinical laboratories, quality and process teams, and regulated research groups working under:
In every one of these frameworks, the validation scope is defined by your intended use, not by the software vendor. The evidence we provide on this page — our development process, numerical accuracy testing, change control, and release history — supplies the vendor-side inputs to your validation file.
On 3 February 2026 the FDA issued its current Computer Software Assurance (CSA) guidance for production and quality management system software. It supersedes the version issued on 24 September 2025 and Section 6 of the 2002 General Principles of Software Validation, and is the current FDA-recommended approach for assuring software used in medical device production and quality management systems.
CSA is a risk-based, least-burdensome framework. Rather than applying uniform scripted testing to every feature of every piece of software, it directs validation effort toward the features whose failure could affect product quality, patient safety, or record integrity, and explicitly encourages manufacturers to leverage vendor documentation in place of recreating evidence from scratch.
This page, our development process documentation, the NIST StRD numerical accuracy benchmarks, and our release history are exactly the vendor evidence CSA expects you to leverage. For a GAMP Category 3 product such as Analyse-it, a typical CSA approach is:
The same risk-based principle is reflected in EU GMP Annex 11, ISPE GAMP 5 (2nd Edition), and the separate February 2026 FDA guidance covering pharmaceutical quality systems.
Under the ISPE GAMP 5 framework, Analyse-it is Category 3 — Non-configured Product. Category 3 software is used as supplied, without user-defined configuration that affects computational behaviour. This is the lowest-risk software category and carries the lightest validation burden.
In practice, Analyse-it:
Analyse-it Software, Ltd is responsible for developing, testing, and releasing software that produces numerically accurate and reliable results. We maintain:
As the end user in a regulated environment, you are responsible for validating Analyse-it for your specific intended use within your quality management system. Your activities typically include:
This split of responsibilities is standard across the industry. No commercial statistical software — Minitab, JMP, SAS, SPSS, or others — comes pre-validated for your intended use. The software vendor provides the evidence of development rigour and testing; the regulated user validates it for their application.
Analyse-it is developed by a small, experienced team working to a structured release cycle. Major releases are planned on a nine- to twelve-month cadence, with maintenance releases in between as needed.
| Languages | C#, with numerical libraries in C++ and FORTRAN |
|---|---|
| Development environment | Microsoft Visual Studio |
| Source control and code review | Git |
| Requirements, issue, and defect tracking | Azure DevOps |
| Unit and regression testing | NUnit, JetBrains dotCover, JetBrains dotTrace |
| Exception reporting | In-house exception handling and reporting, with automated diagnostic capture from the installed software |
| Documentation | DITA Open Toolkit |
| Installer | MSI-based installer with code signing |
Requirements come from customer feedback, support enquiries, partner requests, regulatory and standards updates (notably new or revised CLSI protocols), and internal development priorities. Every requirement is captured as a user story in the issue tracking system and prioritised against the development backlog.
When planning a release, the highest-priority backlog items are selected into a release backlog. A specification outlines the features to be implemented, and work is broken into short sprints with milestones that are reviewed regularly to keep code quality and test coverage high.
All code changes are recorded in source control with commit notes, providing a complete audit trail. Automated and manual testing begins as features are implemented, with test cases recorded in the test management system. Bugs are tracked and, where possible, fixed immediately to keep the codebase stable. Developers review each other’s changes to identify edge cases and confirm that design and implementation choices are sound, and performance and memory profiling tools are used to confirm the implementation is efficient.
Once the planned features for a release are implemented, the requirements are frozen. Further sprints concentrate on testing and defect resolution, with every additional change reviewed to confirm it addresses the intended issue only.
Unit, integration, and system tests are developed throughout the release. Wherever practical, tests are automated so they can be re-run to regression-test subsequent changes and releases. Our test suite now contains more than 1,000 proprietary test cases, most of them multi-faceted — exercising multiple inputs and checking multiple outputs per case.
Exhaustive testing is not possible for software of any real complexity, so we take a risk-based approach: testing resources are concentrated on the areas where correctness matters most, particularly the numerical accuracy of statistical algorithms. Statistical functions are tested against other statistical packages, against hand-calculated and spreadsheet-computed reference results, and against public validation suites including the NIST Statistical Reference Datasets. Code coverage is measured at the branch/decision level so we can confirm all paths through the algorithms are exercised. Code reviews are used specifically to surface edge cases and special conditions that need to be tested.
We take this caveat seriously. Our testing strategy is designed to catch the errors that matter most, but we also rely on feedback from the diverse environments where Analyse-it is deployed to identify issues our internal testing cannot reproduce.
Towards the end of development, interim releases are shared with selected domain experts for feedback on installation, usability, feature implementation, and numerical correctness in real-world use. Feedback and bug reports are captured in the issue tracking system, prioritised, and either addressed in the current release or deferred to a future one. Automated exception reporting inside the product captures diagnostic information from runtime errors and relays it directly to the development team.
When development and testing are complete, a production release candidate is distributed to selected users. The highest-risk regression tests are re-run on the candidate across supported versions of Excel and Windows. Once the release candidate is stable, the software is released to the public.
After a major release, issues reported through customer support and the in-product bug reporting feature are captured in the issue tracking system, prioritised, and scheduled for maintenance releases as needed. Maintenance changes are recorded in source control, regression tests are updated and re-run, and documentation is updated in step with the code.
Statistical software is only useful if its results are correct. We verify the numerical accuracy of Analyse-it against the NIST Statistical Reference Datasets (StRD), the benchmark developed by NIST’s Statistical Engineering Division specifically for evaluating statistical software. NIST StRD datasets carry certified values accurate to 15 significant digits, and each tested result is scored by log relative error (LRE) — the number of significant digits of agreement with the certified value.
Tested against the NIST StRD, Analyse-it performs consistently among the best and outperforms several popular statistical packages. Full tables of results and comparisons with published benchmarks for other software are on our numerical accuracy page. You can download the NIST StRD validation workbooks and re-run the analyses on your own installation as part of your operational qualification.
Separately from our own testing, Analyse-it appears in the published methods of peer-reviewed papers we have verified one by one, each listed with the sentence naming it quoted from the paper itself. That speaks to scrutiny and long use in regulated laboratory work; it is the NIST results above that address numerical accuracy.
Every release of Analyse-it has a unique version number, and all user-visible changes are recorded in our release history. You can use the release history to:
If you need to remain on a previously validated version while evaluating a newer release, previous versions are always available. This supports the common pattern of running a validated production environment alongside a test environment where upgrades are assessed before being adopted.
21 CFR Part 11 places requirements on systems that manage electronic records and electronic signatures. It does not impose requirements on individual calculation tools used within such a system.
Analyse-it is a statistical analysis tool. It computes results and writes them as content into standard Excel workbooks on your computer. It does not provide electronic records management, audit trails, or electronic signatures of its own, nor does it need to — those functions belong to the quality management system that governs how the resulting Excel workbooks are stored, controlled, reviewed, and signed.
For Part 11 purposes, the controls that matter — access control, change control, audit trail, retention, signature binding — live in your document management system, your SOPs, and your IT infrastructure. Analyse-it’s outputs are standard .xlsx files that integrate into whatever document control system you already operate.
No off-the-shelf statistical software is “FDA-validated” as a product. The FDA requires the regulated user to validate software for its intended use. We provide the evidence of our development rigour and testing — this page, the NIST StRD benchmarks, and the release history — to support your validation activity.
Category 3 — non-configured, commercial off-the-shelf product. This is the lowest-risk category and requires the least validation effort.
CSA, finalised in September 2025, explicitly encourages manufacturers to leverage vendor documentation and to apply risk-based, proportionate assurance activities rather than exhaustive scripted testing. This page, our NIST StRD benchmarks, and the release history are exactly the vendor evidence CSA expects you to leverage. See the Computer Software Assurance section above.
We provide the resources most quality managers use to build their own validation file: this page, the NIST StRD validation workbooks, and the release history. Because validation scope is defined by your specific intended use, your quality team typically produces the IQ/OQ protocol itself, referencing our documentation as the vendor-supplied inputs. If there is something specific you need from us to support your validation, please get in touch.
Analyse-it is a calculation tool, not a records management system. Part 11 applies to the system that manages your electronic records and signatures — see the 21 CFR Part 11 section above.
No. All statistical computation happens locally inside Microsoft Excel on your machine. Your data is not transmitted, uploaded, or stored by Analyse-it. The only network communication the software performs is licence activation, update checks, and, if enabled, automated exception reporting — none of which involve your analysis data.
Review the release notes for the new version, assess whether any changes affect functions within your validation scope, re-run the operational checks that cover those functions, and document the outcome under your change control procedure.
Yes. Previous versions are always available. This is a common pattern: a validated version runs in production while a newer release is assessed in a test environment before being promoted.