I see two good possible approaches to to this problem. However, it's important to realize two things. First, requirements engineering is hard work - turning an idea into a formal specification that is enough to build a system takes a lot of time, effort, and practice. Second, if you have good requirements (in any format, from a formal specification to less formal user stories and use cases), it will be significantly easier, cheaper, and faster to actually build the software (and build it right earlier).
If your friend is either going to be asking for numerous software tools to be built or intends on contracting them out, he should learn how to write software requirements, at least at the level of business objectives and concept of operations. The two leading books on software requirements engineering are by Karl Wiegers - Software Requirements (2nd Edition) and More About Software Requirements: Thorny Issues and Practical Advice. I would expect that most people he would hire would want some kind of document describing the system, at least at a level of business objectives or concept of operations, and these books go into that. They also go into the how and why of other aspects of requirements engineering that I would suspect a good developer would go through early in the project.
The second option would be to either hire someone with experience in software development and requirements engineering (and perhaps even some kind of systems engineering or system architecture) to understand the problem space and determine where software solutions are needed and where software solutions wouldn't be beneficial, write the documents, and perhaps even oversee or carry out the development effort. However, this would probably be more expensive and amount to hiring a full-time software developer for an extended period of time to develop not only the system requested, but the requirements and architecture needed as well.
Honestly, I don't think what your friend is experiencing is that uncommon for someone who doesn't understand the software development process. I also don't think the blame lies entirely on him, either. If the first software project didn't have good requirements, the developer(s) that it was outsourced to should have clarified, refined, and documented the requirements. Frankly, I'm not sure that you are the right person to get involved, either, if you aren't willing to put in the time or the effort to work with the non-technical user/customer and develop good technical specifications (this is a key role of anyone performing requirements engineering in any engineering discipline).
I think the optimal solution is really a combination of my two options. I think that your friend (and perhaps you, as well) should learn about what is involved in requirements engineering and the benefits that having solid requirements can bring to a project. You, as a software developer, should also become more familiar with requirements engineering and how to elicit, document, analyze, and manage requirements as appropriate for software projects - it's really a valuable skill for anyone doing work at any part in the software lifecycle.
Best Answer
By estimating how much money/time it will cost to do those hundreds of features with high quality. Very, very few clients will put their money where their mouth is.