This is so fundamentally at odds with my experience of software development I have to wonder where you're coming from. Most of the projects I've worked on didn't have prose descriptions of requirements. In the cases that did, the prose was quite out of sync with the actual business problem that needed solving.
Paid software development is about solving business problems by writing as little code as possible. It's rare enough for people to fully understand what the problem is, much less know the full solution in advance. This makes software development an inherently creative endeavor - you need to discover what the actual problem is, and create a solution for it.
[1] Eg. https://s-media-cache-ak0.pinimg.com/736x/ee/8e/f6/ee8ef6c2a...
Reactive and functional approach don't help you to deal with the essential complexity of your problem, but they do minimize incidental complexity, the primary source of which is the mutable state.
I had a feeling something was going astray when the examples were primarily about data access and I/O. Reactive is (at best) a framework for handling streams and events. CRUD events aren't a great place to start because you're only showing the happy path. What about sequencing? What about retry? What about conflict? I'm not questioning your concept; it's the application.
Reactive isn't a translation technique which is ultimately why these analogies fail. Sometimes I wish software engineers could have a Roy Fielding/REST moment where someone comes along and clarifies the purpose of software engineering by pointing out the fact that everything you need already exists. In lieu of that, I'm sure that people smarter than me will eventually abstract away the reactive boilerplate behind some language keywords because the alternative (i.e. more data access and service endpoint examples) is really tiresome.