Before you pay anyone for a gap analysis — ours included — spend two hours with this checklist. It is organised by lifecycle area, it asks only questions you can answer from your own evidence, and it will tell you where a real gap analysis should concentrate, or whether you need one at all.

Answer honestly and in writing. The value is not the score; it is the specific items you could not answer.

1. Planning

# Ask yourself Red flag if...
1.1 Do the five plans (PSAC, SDP, SVP, SCMP, SQAP) exist, approved, for this programme — not templates from the last one? Plans are 'being updated' while development runs
1.2 Does the PSAC state the software level and where it came from? Nobody can point to the safety assessment behind the level
1.3 Do requirements, design and coding standards exist and match what the team actually does? The coding standard names a language version you no longer use
1.4 Are transition criteria defined — what must be true before design, code, test begin? Work starts when people are free, not when criteria are met
1.5 Has the SOI schedule been proposed and agreed? 'We'll contact the authority when we're ready'

2. Requirements

# Ask yourself Red flag if...
2.1 Do high-level requirements exist for every function, each uniquely identified? Requirements live in a spreadsheet nobody baselined
2.2 Can you distinguish requirements from design — and do low-level requirements exist as their own level? One flat list serves as both
2.3 Are derived requirements identified as such and fed back to the safety process? The term draws blank looks
2.4 Is every requirement verifiable as written? Requirements say 'shall be fast', 'shall be robust'
2.5 Were requirements reviewed against a checklist, with records? Review happened 'in the meeting'

3. Design and code

# Ask yourself Red flag if...
3.1 Does design data exist describing architecture and low-level behaviour? The code is the design
3.2 Does the code trace to low-level requirements, and were standards enforced? Static analysis runs but findings are not dispositioned
3.3 Is every compiler warning either resolved or explained? Warnings are suppressed wholesale
3.4 Are compiler, linker and their options under configuration control? Builds differ between machines

4. Verification

# Ask yourself Red flag if...
4.1 Does every test case trace to a requirement? Tests were written from the code
4.2 Do robustness cases exist — invalid inputs, boundary conditions? Only normal-range cases exist
4.3 Is structural coverage measured at the right criterion for your level, with gaps analysed? Coverage is a number with no analysis behind it
4.4 Were reviews and analyses done where the objectives require them, not just tests? 'Verification' means 'testing' in every sentence
4.5 Are verification results under CM, re-runnable, with independence where required? Results live in a folder called final_v2_fixed

5. Configuration management

# Ask yourself Red flag if...
5.1 Is every lifecycle artifact — not just code — under configuration control? Requirements versions exist only in email
5.2 Do baselines exist, and can you rebuild any of them? A rebuild of last year's release is an adventure
5.3 Is there a problem-reporting system whose reports are classified and dispositioned? Bugs are fixed silently, no record
5.4 Can you produce the Software Configuration Index for what you would ship today? The SCI is a job for later

6. Quality assurance and liaison

# Ask yourself Red flag if...
6.1 Has SQA audited actual conformance to the plans, with records? SQA reviews documents but never watches work
6.2 Does SQA have authority to withhold approval, and has it ever used it? SQA reports to the manager whose schedule it threatens
6.3 Is someone named as certification liaison, with time allocated? The authority relationship is 'handled by the customer'
6.4 Are you tracking open problem reports with the ship decision in mind? The open list is nobody's problem until SOI #4

Reading your result

Pattern What it means Sensible next step
Mostly yes, a few partials You are audit-ready or close; gaps are polish Run your own thread-pulls; consider a light pre-SOI review
Yes in development, no in planning/CM The classic strong-team-weak-process shape Fix plans and CM first; they are cheap and everything inherits them
Partial everywhere Evidence exists but would not survive sampling A focused gap analysis will pay for itself; scope it by this checklist
No in requirements or verification The expensive kind of gap — rework, not paperwork Get help before writing more code against unverifiable requirements
What the pattern of answers means — the pattern matters more than the count.

Frequently asked questions

How long should this self-assessment take?

Two to four hours for someone who knows the programme, answering from evidence rather than memory. If it takes much longer because artifacts are hard to find, that finding is itself the result.

When do we need a real gap analysis?

When the pattern is 'partial everywhere', when an SOI review is scheduled and the answers here are uncomfortable, or when you are inheriting or acquiring software whose history you do not fully trust. If this checklist comes back mostly yes, a full gap analysis may be more than you need.

Does this apply at every software level?

The areas apply at every level; the depth does not. At Level D several verification items shrink or disappear, and at Level A the independence questions bite harder. Use it directionally and let the Annex A tables for your level be the arbiter.

Can we use this for software that already flies?

Yes — it works as a health check on inherited or legacy software, where the usual discovery is strong code with thin evidence. The reading table above still applies; the 'rework' row just hurts more.

If you worked through this and the answers worry you, the next conversation is exactly what we do: an independent gap analysis scoped to where the noes actually are — get in touch.