System requirements and system specifications

I am putting effort in system delivery - making sure that the product developed really works, and helps!

Observing that software development processes are still clones of "hardware" system design (where one piece is designed in detail for a few months, and implemented in the next months), I have  struggled with one conception that contributes to lack of quality and effectiveness, and - very important - to collaboration between the participants:

The notion that the initial plan is complete and accurate, and deviations are accidents.
or
The idea that once we know the plan, we know the outcome.

The final detailed specifications of a system are changing even after delivery, and the capture of this information can help make a product great, by allowing good knowledge of the product.

This seems essential in complex system design, and in healthcare it is an absolute must.
It also seems essential in Agile development, where the focus is in delivering value time after time, and clinging to an initial plan is not a (good) option.

So, the delivery phase of a system should include documenting any relevant aspects that were not detailed upfront.
- How the screen actually looks like
- What is the impact of the technical choices in functional aspects (like performance constraints, etc.)
- What detailed findings are there that can provide additional info

...and yes,
- What have we learned that can trigger new requirements or ideas.

This seems much better than the exuberance of documents to guess what is going to be the outcome.

In short - it is impossible to know all the details upfront, but this doesn't mean that details are not important.