From my perspective (automotive product development), this is called 'system design' or even 'product development'. We start from a use case, idea, feature 'want', whatever, and we move both up and down from the idea to arrive at customer use models(up) or requirements (down).

The documents for this development start to look like hierarchies with many cross-dependencies (the solution starts to 'fall-out'). For example, if the 'want' were "I want to make routine repairs easier for customers" we'd work up to different customer use models such as "Customer is notified on head unit radio that timing belt routine maintenance is suggested" to functional objectives (or functional requirements) "Customer shall be notified of suggested maintenance 1000 miles, 500 miles, and 100 miles before timing belt suggested maintenance" to non-functional requirements "Head unit connected cell shall notify timing belt status every hour" to performance specifications "Connected cell shall meet 3G bandwidth specifications for xMbps when within xmile range of cell tower with x specification" that then get tested to our test flow requirements.

The interesting thing is this design follows a 'V' engineering model [1] and the documents and requirements do not always have the best correspondence. In fact, the user models can sometimes be captured in Microsoft Word whereas the technical specifications can be captured in DOORs. Also, the use case is not clearly delineated to a performance specification 100% of the time. In large organizations it's difficult to communicate requirements and development milestones if this correspondence isn't clearly drawn. e.g. An executive that manages user experience (UX) may not understand why technology X is in the vehicle and what it gives them. This can lead to communication issues.

So, I believe the IDE for ideas has a data structure that is hierarchical and the IDE resembles an FPGA IDE feature such as Xilinx ISE RTL schematic. In this RTL schematic, the designer can show a 'black box' such as 'My CPU Design'. The black box can be double-clicked to show black boxes that make up 'My CPU Design' such as Instruction Memory, Data Memory, a program counter, an ALU, etc... Furthermore the user can click Instruction Memory to see which FPGA elements make up Instruction Memory, etc.

In such a way, different team members in product development can see different levels of abstraction according to their own interests and responsibilities. The user model can be the top-level 'black box'. A manager can double-click the black box to see which features create the use case. The manager can further double-click the feature set to see which functional objectives create the features, etc. This would be possible all the way down to performance requirements and can even include data for 'validation' and 'verification' activities (e.g. This is the feature I wanted, are all the functional objectives that make up the feature set fully validated?).

Anyway, that would be my ideal IDE for ideas. The IDE would be cross-functional and many people could have input for multiple user models that drive the initial feature 'want'. This IDE could even help control costs of large systems "Which feature set is driving the most cost?".

[1] http://en.wikipedia.org/wiki/V-Model