I have a piece of code that performs self-test on various components of the board, like MCU, BLE, IMU, OLED, flash memory, and etc.
What I'm trying to make is a document that would represent what these tests cover, or when you run the IMU test and it says "PASS", what does that actually mean. Or going from another direction, if I want to test BLE/OLED/MCU, what set of tests I need to run to have confidence that it's all working as expected.
Now, I know how to represent this data in a text format or in some table but even when I try my best this information gets too convoluted, confusing and looks like someone just threw up a bunch of data and you need to make sense of it.
What I'm looking for is something like industry standard way of representing this information, or best practice that would allow someone to take a look at a document and say: "Yes, this BLE test ensures that my chip is soldered properly, crystal is present and oscillating, firmware is running fine but it doesn't test the actual BLE antenna and tuning/matching component". Or from bottom up, someone says "I wan't to test that IMU is working properly, so I need to run these set of tests and they will ensure that chip is soldered properly, GPIOs are working, and device is registering 1G along X/Y/Z axis"
Any suggestions, examples or pointers on what to look for would be very appreciated.
Best Answer
Then you have to think of your audience - who is the target audience? Could it be that one target audience requires different things than another i.e. if you are trying to sell this thing then, there might be this guy in a marketing department somewhere who thinks "we need one of these inside our product" so what would the document that meets his needs? If you are not trying to sell this wonderful thing then fine but you still need to think who your target audience is.
If you are just trying to impart detail to a softy you might format it totally different. You might need three or four entry point documents.
Start at the basic picture i.e. like a break down of a part number: -
Everyone with a bit of nous should understand the above and you can nest deeper functionality explanations on seperate pages.
If there are different modes of functionality like in this: -
And they produce a different breakdown of the part structure (above) then start with the state machine then go to the part breakdowns for each state.
NB the part breakdown is pretty much like what status registers represent: -
If this answer has hit the spot then, you need to pay me some consultancy money LOL. If this answer is way off the mark then that means that you need to learn to improve your question making skills LOL\$^2\$.