I am not sure if you are in a product world (software or other) or in IT (applications development/ maintenance) - but irrespective, here is how I would advise you to think of this.
Conventionally (in the traditional waterfall world), all planning happened in terms of projects, which would get funded and staffed. However, depending on corporate/ financial imperatives, it was easy to kill projects - and cause staff turnover.
Lean/ agile thinking encourages you to move away from project thinking to product (or application) thinking - where products/ applications get funded based on their overall longer-term importance in the organization. They provide you a longer-term planning and execution timeline - as well as staffing capability (typically over multiple years) as opposed to projects that can be very short to very long, and not always intentionally! (Software and IT projects are notorious for their horrendous cost, time and scope overruns!)
From an overall planning perspective, think of corporate objectives/ business milestones/OKRs (Org Key Results) at the top of your planning hierarchy. These may be planned for a year broken down into quarters and months. To successfully deliver on these OKRs, an organization must build/ implement/ launch products that help it meet those OKRs.
Think of these Products/ Applications as the key assets that need to be developed/ maintained/ implemented. Teams need to be dedicated to these products - a team should be dedicated to a product (of course a team might manage multiple products, but ideally, a product should not be split between multiple teams as far as possible. Lean/ Agile thought process highly encourages stable, self-organizing teams that can manage how they work and deliver their product deliverables, given a clear and unambiguous priority for those deliverables.
You might also have shared services (special skills teams) such as UI/ UX design, DB, Architects, Documentation, etc - which split their time supporting the dedicated product/ app teams. However, shared services are discouraged as much as possible to reduce dependencies across teams because they reduce the flow of work for any given team. (Imagine a new requirement's development work being held up due to non-availability of the design team). However, it is quite hard to reduce such dependencies to zero in my experience, in any sized organization.
Finally, you then have dev/ maintenance/ implementation work being done in the Lean/ Agile world in either short time buckets of Sprints and Releases, as in Scrum, or in a continuous manner, as in Kanban.
Scrum teams will deliver their product at the end of each Release. Kanban teams will typically build and deliver work continuously on to a staging server as each feature gets built, or each defect gets fixed, and make releases to a production environment or to an external customer.
So, the Sprint and the Release come closest to your project/ milestone definition. A release may take 8-10 weeks (4-5 sprints) or lesser. At our company, we do monthly releases - by teams that follow either Scrum or Kanban. The release cadence really depends on your business context and the cost/ overhead of making and deploying a release. Typical corporate IT may not be willing to take new product releases from an internal or an external (vendor) dev team - because the cost of testing and certifying a software release before it can be deployed into their production environment can be quite high.
The software/ product itself can be functionally decomposed into a Theme --> Epic --> Feature --> User Story hierarchy - those are your Requirements - the actual hierarchy/ nomenclature can vary from company to company. However, typically, each Sprint will complete a certain number of user stories; which roll up to a certain number of Features getting delivered in each Release.
It would be the job of the Product Management/ Product Owner organization to ensure that the Themes, Epics, and Features are identified, prioritized and detailed in time for each dev delivery cycle. And that they are aligned to those OKRs as well. This is typically taken care of between Portfolio Management and Product Management functions in an organization. They would also have some way of tracking "New Ideas" that might typically spawn an investigation leading to a new initiative/ dev effort.
Many Scrum teams create a task-list against each user story - and use those tasks to track their work and effort. However, many Scrum teams are moving away from effort tracking - the tasks simply work to encapsulate a standard process/ workflow they follow to build each user story.
A Kanban team, on the other hand, will typically visualize the workflow on a Kanban Board, where each column represents the next stage of development (value add) - and they track each user story's progress through this workflow. Many teams use both Scrum and Kanban together and may or may not define and track tasks at all.
So, hopefully, that gives you a good picture of what I am trying to communicate :) - and the hierarchy would look like this -
-- Themes/ Epics/ Features/ User Stories
--- Tasks/ Workflow stages
Release --> Sprints
-- Dedicated to products/ apps
-- Shared services teams
Projects/ Milestones (Optional - mostly in project services companies)
A company that is in the business of doing projects (including fixed cost/ fixed price projects might still do the traditional Projects and Milestones - but ideally, they should use the project plan/ milestones at a high level to guide incremental software/ product development, build sufficient feedback loops (sprint/ release demos) so that by the end of the project - and even for each milestone - they are delivering working software/ features - or sometime even documents/ prototypes - that allow the dev team and the customer be on the same page of what the customer needs and what is being built. Many System Integration/ IT Services do this and call it "Hybrid Agile". Of course, such delivery models are possible when there are mature trusting relationships between customer and delivery team/ service provider (or business and IT) - where each side is ready to collaborate and benefit from the flexibility that this model gives them both.
Based on everything you have mentioned, a combination of Portfolio/ Program/ Team level Kanban boards would be your best bet to capture and track all of these. At the team level, teams might use a Scrum or Kanban or Scrumban approach to building and delivering their work. You could have Kanban boards to track new ideas, OKRs, new initiatives, some of which would drill-down to program and team level boards where Epics, Features and User Stories would describe their implementation, while they get grouped into Sprints and Releases for their actual delivery.
Kanban tools are typically not meant for tracking project plans and milestones - so, if you have to do that, you'd need to do that in a traditional project management tools such as MS Project or many others.
For Portfolio Kanban tools, you could consider our tool - SwiftKanban, which has some great Enterprise/ Portfolio Kanban capabilities that match your requirements - or others such as Kanbanize and Leankit which are also very good, besides several others lesser ones such as JIRA Agile/ CA Agile (earlier Rally) and VersionOne.
Hope this helps!