You can believe the visionary has something pretty clear in his own mind, but you certainly don't have enough to start writing code. We should start by asking the visionary to expand on his vision of the product. We'll just let him talk about what he has in mind. This will tell us a lot about what he wants and will structure the rest of the discussion.
This is a game, or more accurately a toy. It starts off by asking you to set up your species, and how many fish of each species you want. When you start the game the fish are born and begin to interact; eating and reproducing with one another.
Each has rules about how to reproduce. For example, if two fish are within a certain distance of each other, and they are not starved, then they can reproduce. Every so many reproductions, there is a mutation; the children are just like the parents, but the rules have changed a bit.
Each fish moves a certain distance each turn, depending on how recently it has eaten and how old it is. For example, a young fish which hasn't recently eaten will move further than either an older fish or one that has just finished eating.
If fish don't eat they die. Some fish die of old age.
Each instance of a species will have the basic characteristics of that species, but the individual fish within a species may vary in their particulars.
This extended description lays the foundation for further analysis. He has told you more, but much of it is done in a hand-waving fashion, that is, it is very imprecise, for example, "...if two fish are within a certain distance..." and "...every so many reproductions...".
At this point you can engage in a structured interview. Ask questions that probe at those areas that are well understood and which need further clarification. Be sure to ask about platform considerations, performance and so forth. These questions will span the use cases, the systems analysis and the application analysis.
How does the user interact with the system?
Actually, there isn't much interaction. The user can create the species and vary their characteristics. In an advanced version, perhaps the customer can drag and drop the fish and sharks directly onto the game board. Then they set it going, and stand back.
What does it look like?
I think that depends on the platform. On Windows, I'd expect there to be a square that represents the world. In it the fish would appear as tiny dots or perhaps as small icons of a fish. Below the field would be a score report, showing information about the number of fish of each species there are right now, and the most and least there have been etc.
How does it end?
I'm not sure it ever ends. Maybe there is a button marked "End," or "Restart." At some point all the fish die out; I guess that's a pretty good end.
These questions tease out various aspects of the system and allow you to begin to formulate an idea of the overall architecture of the system. In a large project, this will quickly become overwhelming, as it is almost impossible to do an interview like this systematically. Use cases can help you structure your thinking. The use cases will make you think through the interactions with the system and they will begin to systematize your understanding of the requirements.