..

Very good question - a question that few ask!

Only data flow diagrams offer a lithmus test of completedness on essential requirements (non-implementation specific business oriented requirements are your essential requiremements).   The test:  data flows into processes that have no outputs and dataflows coming out of a process that go nowhere are glaringly obvious flags that essential requirements have been missed.

Tony

 Giti,

there is a chain of reasoning that leads from a precise set of statements for a problem to be solved and/or opportunity to be exploited and/or compliance to be maintained to a precise set of requirements (functional, non-functional, process and data).

Maintain the chain and you can prove the requirements are - to coin a phrase - required. It does not matter what tools, techniques or approaches you use so long as the chain of reasoning (the analysis) is preserved.

By the way, there is not one right set of requirements, there are many that can be proved this way. Of course, there are literally infinite more that are provably wrong. Hence the need to do the analysis if it is important to get it right with the minimum amount of time and effort but mean more thinking. There are other ways that are variations on trial and error - often dressed up as "pragmatism" - or "agile" as the latest fad is called. These will also work but takes longer and cost more effort but involve less thinking, more whiteboards and talking shops, and greater consultancy fees for the the shamans with the latest version of cat guts to divine with.

The structure of this analysis is here. 

Failure to follow logical analysis is fine - it's how 99% of humans conduct themselves 99% of the time and  we generally muddle on through, it's just not analysis and so you can't KNOW that the requirements are correct.

Hope that helps.

Guy