As Daniel has said - Kanban says "Start from where you are" - meaning, start with your current process, don't change anything. Simply visualize it and then gradually change it as the team identifies the need for improvements.
If your current process is "Backlog, Defining, Designing, Testing, Deploy" - you can start with that and use it to track each Requirement (or User Story or feature - whatever you use currently at the lowest level of your "scope definition" - the actual deliverables for your team). You can't just have the whole Project (depicted as a card) going through that process - as Daniel said, then you won't see anything progress; NOR can you have your typical project plan tasks flow through that process. (Tasks simply follow a "To do - Doing - Done process).
The idea in Lean/ Kanban is to track the "value addition" stages of your workflow - and apply it to each piece of value you are delivering to your customer, which, in this case, is software pieces (features or requirements). Think about each step in your dev process that adds incremental value to the deliverable - even if it does not involve a handoff from one person to another.
As an example, here is our workflow that we use for our own product development - and we use a TDD approach -
It's a fairly elaborate process but tracks each value addition step as a developer works through them on a single user story or enhancement or defect, the 3 typical deliverables our developers work on. The color coding identifies the type of work.
You can start with the high-level flow that you provided - and you can quickly "evolve" to a more granular flow where each of the stages you identified will have some sub-stages.
Also, remember, that Kanban helps you even out and improve your flow by providing intermediate buffer columns so that each stage of your workflow has enough work and that work is flowing smoothly. This ensures that - ideally - at no point do your team members get over-burdened or become idle. You do this by adding intermediate "Done" columns (Design (In-progress/ Done), as an example) and adding WIP (Work-in-progress) Limits on each column. Here are a couple of examples -
To learn more about the Kanban Method, you can read David Anderson's "Kanban: Successful Evolutionary Change for your Technology Business" - which you already referred to. You will also find many useful articles in our Kanban Guide here.
To answer your other question - there is no "pre-defined" process. You and your team have to decide what process you will use - based on your current development experience and practices - on your new project as well. If you have been only doing waterfall projects so far, then you start by using the same process again. If you have been doing a Scrum or an Iterative process, start with that. Kanban will gradually help you improve and evolve as you identify problems with your software delivery if any, and any process bottlenecks.
Finally, I also agree with Daniel - you can use the STATIK method (Systems Thinking Approach To Implement Kanban) to identify your process and the kind of work you do - I also use it in my Kanban training classes. However, it is a somewhat advanced topic. I would suggest getting a Kanban trainer/ coach to help you with that initially.