I'll give you just the short answer. This is not a good place for a full answer to this question. Development method is a big topic, and a matter of discussion, often heated.
I want to emphasize only on a could of aspect. The schema you depicted is practically never the case. Following such a rigid scenario could be one of the biggest mistakes people make.
Very first item is probably
inception, not "requirements". This sequence is already overly simplified in terms of the set of items, but this is not the biggest problem. More importantly 1) those items are actually
overlap; even of you stage #5 there could be some requirement changes (#1), which is natural because by the end of the work people understand requirements better; being not ready for such change is one of the big mistakes; the name of the stage merely indicates where is the maximum of certain activity; 2) the stages actually comes in
iterative cycles, after each iteration, people get back to requirement, design and other cycles again and again, and finally, this process converge.
You can read some of those many books and articles on different development methods. But you should never loose your
sense of reality and critical thinking, which, in turn, requires a lot of experience. You should start understanding of your development methods from understanding of goals of your project. On top of that, you should take into account qualification and even the taste of the team members, cultural features, culture of your potential or actual customers, available tools and investment possibilities.
If you try to define your development methods not based on all these factors, it would be another big mistake.
I am sure that many, of not all, books or articles on the topic are somewhat related to pseudo-science, like alchemy. People have some experience based on the level of state of technology at the time they did some projects, the way they personally understood it, but later they tries to generalize it, with some absolutization of some principles which worked for them but are actually not universal.
Nevertheless, it you read those books properly, they can be useful for you.
They may teach you:
1) to take development method seriously, 2) to define some well-formulated and very fundamental principles and to follow them thoroughly and accurately.
But they may easily
mislead you into: 1) following some rigid principles read from the book, not from analysis of your current goals and situation, 2) thinking that this principles is "real" strict science and following the "formula" in a blind-folded (I would say, brain-folded :-)) way.
Be careful.
[EDIT]
See also my past answer:
Architecture diagram tips[
^].
Nevertheless, don't consider and of those recommendations as universal or absolute. Create your own method as you analyze your goals and discuss this with your team.
—SA
Submit an article or tip