Verification of requirements in a closed system

Question

I'm on my first real software project following the whole SDLC and am a bit confused. We have a requirement that states something like "The battery will be monitored each second" which needs to be verified. This is something that can't really be checked in the system since it happens "inside", i.e. there's no output that would show that the battery was checked each second. It is my understanding that at this phase the verification is done on a closed system, so you can't just use a debugger to verify something like this.

Is this assumption wrong? Or can the requirement be considered to be ambiguously defined.

Answer 1

Have your system have log files that it can write to, which can be downloaded later from test versions of the device. (Make the logs circular, so that you'll always have the last X log lines, and limited memory requirements.) The requirement now becomes that postprocessing that log file shows that the battery was checked at least once during each second.

Also you should have a simulation of your hardware that you write your software against, which gives all sorts of additional information back to you. That simulation will be imperfect, but will give you the tools to write proper unit and integration tests that don't require physical devices to be built for every code change. Make sure that toolchain is there, it will pay off.

(Note, I'm not an embedded system developer, but I have friends who are. The advice that I'm giving is based on what they've told me worked for them for projects from monitoring heart pumps to launching rockets into orbit.)

Answer 2

There must be some output of the battery monitoring yes? So one possible way to verify would be to attach a test power supply via the battery terminals, changing the test power inputs and looking for a battery monitoring output change within one second.

Where that could get complicated is that battery reporting may be sampled at one second intervals but averaged (or other statistical processing) for reporting on a slower time scale.