I'm trying to understand:
No matter the product--software or an outhouse--your project will generally follow these phases: requirements, design, build, test, deliver. Some products are iterative and you go through these phases over and over and other products are delivered once and done.
Your first part of the question is answered in the design phase. During this phase, your properly skilled team will do nothing but draw, analyze, problem solve, argue, draw again, analyze further, write, draw, and eventually arrive at a product design that meets most of the requirements established in the earlier phase. The exact approach one would take depends on the type of product and is too broad of scope to be answered here, i.e., you need to ask a more specific question.
Your second part of the question is answered through a PM process and control capability called change management. This process enables someone to escalate a change idea, and through governance, this idea is analyzed--which would mean a potential design--as well as assessed for cost and schedule impacts. If approved, requirements are adjusted, the design is adjusted, and then the team continues its build.
Tools are typically industry specific.
I don't think UML matters.
The design phase is when you arrive at the picture and how.
Common approaches are industry specific.
I think this question is super broad. Or I can say these questions. The first thing that comes to my mind are the guilds. In my last companies I've been working developers have meeting (weekly? biweekly? monthly?) separated per areas (backend, frontend, qa, architect, drupal ..) and discuss new things of interest, new discoveries, particular bugs / scenarios faced during development.. and often there are demos where they show what they experiment (unit tests, new libraries...) This is a very important moment for developers to share knowledge and business should give value to this time, even if it is not really dedicated to effective production.
Beside this, during the development time, developers should be independent and self organize moments of sharing knowledge, related to a specific implementation of a component, maybe involving multi teams, expertise should be explained by the owners of the knowledge.
Documentation of components is also very important and it should be written in the code itself, in README files, or in appropriate spaces (as Confluence or whatever)
At last, sometimes we adopted the 20% rule. That means that 20% of developers' time (Friday can be the best day) is used to "fight the debt" which means to do refactoring of code, or to reduce technical debt.
Your other questions might be answered by you and your colleagues, I can't tell you what you have to use. You should use what fit you the best. And the best way is to test, to try, to experiment. Good luck!
