On larger projects with many contractors and subcontractors, structuring and documenting the (iterative) communication between the "client" and the "contractor" is a challenge. This is largely the problem that the "V" model is designed to solve -- the client "owns" the top of the "V", and puts effort into understanding the problem that they want to solve (Systems Engineering and Modelling) -- the contractor integrates with that model to (iteratively) improve their understanding of the component that they are providing, particularly in terms of the yield curve for the KPIs that their component must deliver -- with that relationship recursing down (sub)contractual relationships until you get to the bottom of the "V". There really isn't that much difference in the fundamentals between software engineering and other disciplines, although the details of the interfaces and the impact of automation is, of course, more significant.
Comments
On larger projects with many contractors and subcontractors, structuring and documenting the (iterative) communication between the "client" and the "contractor" is a challenge. This is largely the problem that the "V" model is designed to solve -- the client "owns" the top of the "V", and puts effort into understanding the problem that they want to solve (Systems Engineering and Modelling) -- the contractor integrates with that model to (iteratively) improve their understanding of the component that they are providing, particularly in terms of the yield curve for the KPIs that their component must deliver -- with that relationship recursing down (sub)contractual relationships until you get to the bottom of the "V". There really isn't that much difference in the fundamentals between software engineering and other disciplines, although the details of the interfaces and the impact of automation is, of course, more significant.