Asking for pseudocode, in my opinion, stems out of frustration that requirements are ambiguous and not clear enough.
I agree with Robert Harvey that properly written requirements would - should - nullify the need of having pseudocode at hand.
Writing pseudocode could be sort of a practical exercise for the management to make them realize how unprecise they have been.
Maybe a great exercise, but we are not in a position to teach them, and it smells of homework as punishment to me ("I will not be giving ambiguous guidelines, I will not be giving..."). Writing pseudocode enforces precision, but at the cost of imposing certain formality.
What pseudocode would that be, anyway?
Of the implementation they want you to deliver?
Or of the hypothetical unit test of this implementation?
This is a very important distinction.
This isn't really their job. They have no business in designing, or even knowing what's inside the blackbox, as long as the box does the trick. The same business logic could have very different algorithmic representations and it is up to the programmer to pick the one they like.
I agree! Now you can write your implementation any way you seem fit, as long as it passes their test. Like TDD / BDD.
So now we're in the ballpark.
Because a properly written test suite reads like a good spec.
In fact, some frameworks really blur the distinction between specs and a test. Take a look at Cucumber, for instance (mind you, I am in no way affiliated with the product).
1: Describe behaviour in plain text
2: Write a step definition in Ruby
3: Run and watch it fail (TBC)