Agreed, in theory. Though in practice the client... -especially- an internal client as my projects always were... Ends up changing the rules mid game over and over and over again.
What you are saying about internal clients is on target but I will suggest a different perspective. Business rules and requirements are usually very stable though many clients see new software as opportunity to add some “frills” they have always wanted. An analyst who doesn’t know the business has a hard time distinguishing between necessities and frills besides not knowing exactly what to ask. The client may also be speaking a different language (engineering vs. accounting for example) and the analyst needs to recognize that and learn the language. The analyst may have to drill down as well to the people who actually do the work instead of just talking to the department head.
I directed the development of a very complex work management system but the most difficult part was the accounting section for invoicing. Without belaboring the details I spent more time with the CFO and two of his assistants than on any other interviews. Before we started a single line of coding, the CFO and I were speaking the same language and I understood exactly what he needed. I was also able to question some of what he wanted pointing out some of the practical and logical flaws, which he agreed to change. In the end, he got what he wanted and for his assistants it worked better than what they had expected.
My point is that rules seldom change, but our understanding of the rules will change unless we put our effort into the work required of an analyst. I was fortunate to have a staff that learned to do that quickly and the payoff was on time and high quality software. Not everyone has a staff like that.