How software behaviour belongs inside a product risk assessment

Software changes a product after sale, and that fact alone belongs at the top of the assessment. A plant sensor may leave the factory behaving one way and, months later, behave differently because an app update changed its thresholds, its alert sounds, or its watering schedule. An assessment written only for launch day will therefore be out of date before the first plant needs watering.

The assessor should list every software behaviour that affects safety or plant care in a practical sense: alerts when soil is dry, alerts when the battery runs low, schedules that turn watering on and off, and readings that tell a user whether to trust the sensor. Each behaviour gets a sequence, just as a physical hazard would.

Consider a watering schedule that fails silently. If an update resets the schedule and the app shows no clear warning, a plant may go unwatered for days while the user believes the system is working. The harm here is not a burn or a cut, but a failure of the product's core function, combined with a false sense of reassurance from the app.

False alerts create the opposite sequence. A sensor that cries dry soil too often teaches the user to ignore alerts, so a genuine dry period is missed. The assessment should trace both directions, missed alerts and false alerts, because both erode the trust that the product relies on to work.

Illustration: a startup imagines 80 sensors after an update and supposes that 30 of them, in round illustration terms, lose their watering schedule until the user opens the app again. Those figures, as presented in How software behaviour belongs inside a product risk assessment, are invented, not measured. Their value is in the question they raise: does the assessment already cover a schedule reset, and does the change log link that update to the assessment entry.

If the link is missing, the update process itself is part of the risk. A software change that no one connects to the assessment can quietly rewrite the product that was originally judged.

Updates should be assessed before release, not after complaints arrive. For each update, the developer should write what changes, what stays the same, and what could go wrong if the update fails halfway, is installed on an old phone, or interacts with an older sensor version still in use.

• List every alert, schedule, and reading the software controls.
• Trace missed alert and false alert sequences separately.
• Record each update in a change log linked to the assessment.
• Test the update on old and new sensor versions before release.

Many software assessments fail by treating the app as a separate product. The app and the sensor are one product in the user's home: the user trusts the app's reading, acts on its alert, and blames the sensor when the app misleads. Splitting the assessment into hardware and app files, with no link between them, hides that unity.

Another failure is to describe software in general terms, such as saying the app works correctly. Correctly for whom, under what network conditions, and after what update. Without those details, the assessment cannot be checked, and a future developer cannot tell whether a new update breaks an old assumption.

Finish by making the change log part of the assessment, not an afterthought. Every update entry should point to the assessment entry it affects, and every assessment entry that depends on software should point back to the log. That two way link is what keeps the assessment alive after launch.

When in doubt about an update, the developer should record the doubt, seek further input, and delay release until the sequence is understood. A delayed update is a minor inconvenience; an unexplained change to a product already in homes is a risk that cannot be undone by a later note. The team should also keep a simple list of which sensor versions received each update, so a problem found later can be traced to the versions actually in use, and a fix can be aimed at the right owners rather than broadcast blindly.