I saw myself doing this and I was wondering if other people work like this as well:
What I usually do when confronted with a software design problem is that I jot down "the ideal" solution, without taking into account feasibility or any other consideration. Then I peel away at it top-down, until I have the solution.
Is that a methodology that's popular and has a catchy name? If so, I would love to know so that I can learn more about it.
In one of my old analysis/design books (can't remember which, and no love from Google), they introduced the concept of a "tech-no-filter" where you think of the real goal, and think of the ideal solution. It's very, very much like what you're talking about. The end product may not have much resemblance to the ideal solution due to current technology, but knowing what the ideal is means that as new pieces become available you can easily judge how your current design can be updated to take advantage of them. Contrast that with only knowing the problem and solution in terms of what you can build today. Look around and find some software that has struggled to make a transition to new tech and you can see this in action. Keep thinking of the ideal!
When I design programs, I first design the user interface using paper prototyping. I test the UI prototype that the users can reach their goals with it. Having something concrete/visible to show to the users and clients makes it easier to explore the requirements and to find out what the users really need.
In the UI design (requirements analysis) phase, I always try to design the ideal solution. I don't take into consideration that how hard some feature would be to implement. Then when the design has stabilized enough to be implemented (usually it takes a week or two), we discuss with clients and programmers about how much it would take to implement the things and which things are the most important.
Because we first designed the ideal solution, we can see the whole picture of what is needed, and we can begin to adjust the scope of the project, so that first only the most important features are implemented. Also if some of the ideal UI designs would be too expensive to implement, we can make a compromised design which has slightly lower usability, but is much cheaper to implement. The UI designer is always the person who designs the compromise (i.e. not the programmers), so that it fulfills all the requirements and that it's usability will be good enough.
This is more or less what I do, in programming and in life. Usually, I think about how a user would need to use the new software. Where are their hands. What other things do they use to do the work (a telephone, another browser window). In what order will the information come to them, and how will that order affect the tools my software provides that they need.
Building software from the point of experience is the best way to go.
Develop a vision, set use cases, build feature list from those cases, prioritize in terms of value you will get for building them, then build according to that priority.
What this helps accomplish is building features that have high value all the time while moving towards the ideal solution where some features may only be used by a small group of users
In scientific/numerical computing your starting point is invariably some mathematical ideal, but then you have to compromise that ideal to get a practical usable solution.