The assessment is a workshop, not a calculation. What follows is the order that keeps it honest, and the places where programmes routinely skip a step and pay for it two years later.
1. Fix the level and the scope
Aircraft functions, or the functions allocated to one system. Write down which, because the two produce different conditions and different owners, and a document that drifts between them cannot be traced either way. Record the aircraft or product context the classifications will assume: category, operation, occupants, average flight length. The average flight length is a number the whole programme will use, and it is decided here or it is decided inconsistently.
2. Build the function list
From the function tree, not from the equipment list. Take it down to the level where a failure has an effect somebody can describe on the aircraft. Include the functions that only exist in some configurations, and the ones performed by the crew.
3. Generate candidate failure conditions mechanically
Cross every function with loss, partial loss, misleading, inadvertent and mistiming; then with the phases; then with annunciated and unannunciated. Do the crossing before the thinking. The reason is not thoroughness for its own sake: it is that inadvertent operation and misleading output are the rows a discussion-led assessment forgets, and they are usually the severe ones.
The crossing is single-function, so it cannot reach the conditions that need two functions to fail together. Those arrive by judgement, from the pairs where one function is what the crew falls back on when the other goes, and they are a large part of why an aircraft-level assessment is not the union of the system ones.
4. Merge to the conditions that are physically distinct
The candidate grid is deliberately over-generated. Merge the rows whose effect on the aircraft is the same, split the ones where a phase changes the outcome, and delete the combinations that cannot physically occur. This step is where the analysis actually happens, and the merge rationale is worth recording: a later reviewer's first question is always why a row is missing.
5. Write the effect, in the aeroplane's terms
For each surviving condition: what the aircraft does, what the crew sees, what they are left to do, and where it ends. Include the adverse operational and environmental conditions that are reasonably expected to be present, because a condition benign in daylight and calm air is not benign at night in turbulence.
Where the effect depends on a crew action, state the action as an assumption rather than burying it in the verb. The crew reverts to the standby indicator is an assumption about workload, about training, and about whether the standby is where they can see it, and it will become a requirement on three other documents.
6. Classify from the effect, and only from the effect
Read the effect column against the class definitions, and write the class. Then read it in the other direction: given this class, is the effect description strong enough to defend it to somebody who wants a different answer? Both directions matter, because the pressure on this column is chronic and always one way.
Where a classification is genuinely uncertain, record it as a range with the study that will settle it, rather than picking the convenient end. A row reading Major to Hazardous, pending the handling-qualities assessment is a real state of knowledge, and it is honest scheduling as well as honest engineering.
7. Attach the objective and the at-risk time
The class gives the probability band, and the average flight length converts it into a per-flight budget. If the condition is severe only in one phase, record the at-risk time with it, because that is what a supplier will need to be given a rate rather than a probability.
Attach the qualitative requirements at the same time: no single failure for catastrophic conditions, and the independence claims each one implies.
8. Assign the development assurance level
From the classification, through the functional failure set. One member and the level follows the class; several independent members and it can be shared out. Record which option was taken and what the independence rests on, because that argument is a claim about the development process, not about the hardware, and it will be examined as one.
9. Write the verification plan, per condition
Which fault tree, which test, which analysis, which similarity argument. A condition without a verification entry is a condition nobody has committed to demonstrating, and the certification plan is built from this column.
10. Re-run it when the design changes
The assessment is a living document with two triggers that always invalidate part of it. Allocating functions to systems creates conditions that did not exist while the function was abstract, particularly where one item now performs two functions of different severity. And integrating creates them again, because shared resources turn independent conditions into a common one. Both are ordinary events, and both are the reason a system FHA exists rather than only an aircraft one.