If you were building a house or a bridge then you would expect to pay for architecture and engineering work even before the finished construction could be specified and costed in detail. You might well start with a budget but you would have to sign contracts with at least some of your contractors and spend a significant amount without knowing the eventual price to any degree of certainty.
Building software is not like building a house or a bridge but one thing software does have in common with complex construction projects is that you cannot expect to agree a realistic price on day one. You can guess, you can take a risk, you can decide how much the work is worth to you, but that is about all.
When you contract for software development work you are not buying a product, you are buying the time and expertise of people who you want to collaborate with to solve a difficult problem. You can control risks and costs by requiring early and frequent delivery of software and source code. That way if things seem to be going sour you can walk away with minimum lost and at least some benefit retained (unlike construction where an abandoned project probably becomes a total write-off).
On the other hand, attempting to fix software development costs and scope early on can only reduce flexibility and will inevitably put limits on a contractor's ability to solve problems in the most creative and collaborative way. Fixing cost, time and the detailed scope of software development is very often counter-productive, expensive and some people argue it is also unprofessional and unethical.
PMBoK and Scrum try to be relevant to all kinds of industry and types of work - contracted or not. You shouldn't expect them to tell you how to negotiate a contract or run your business.