Right. I think this is how a lot of business requirements are specified, since they are frequently constructed by non-programmers. Taking a bunch of cases from a spec document generated by a domain expert and turning them into maintainable/readable procedural code takes a lot of creativity. I think it's easier to express case analysis like this in Prolog.
This is almost exactly like the descriptions I get from my team leader for getting results out of a database. He doesn't think in sets for SQL.