Are you aware that “70 to 85% of bugs in software are due to incomplete or inaccurate functional requirements?”
"There's no sense in being precise when you don't even know what you're talking about." -John von Neumann
What would be the best use of QA engineer's time while the project is in an early stage?
Test the requirements itself, not the product...
by asking the right questions to uncover & challenge implicit assumptions in the requirements.It will ensure that the requirements
& consistent and are according to the customer’s needs.This could be the biggest
payoff at this stage.
I also think what's precisely distinguishes a QA engineer from a test engineer is that QA engineer prevent bugs in the first place whereas a test engineer just merely finds them after the fact.
I have seen time after time , in projects even in later stages, fundamental assumptions are either not fully correct/ or at least not understood/challenged as a team.
Many who join the project late , either do not bother or have the confidence/courage to analyze & challenge the fundamental assumptions in requirements systematically.
To make testing requirements more effective, you can use the approach called heuristics testing, or testing with a strategy that relies on past data about probabilities. This targeted type of testing often allows for more intelligent investigation of where any bugs or problems may occur, even in requirements testing.
This strategy helps determine what types of errors are likely and how common errors occur in certain parts of the code. It also helps to check requirements against an accumulated base of problems. Be sure to cover all these areas in your app:
Structure (what the product is): Is it one program or many? What physical parts come with it? Can I test it module by module?
Function (what the product does): What are its functions? What kind of error handling does it do? What kind of user interface does it have? Does it do anything that is not visible to the user? How does it interface with the operating system?
Data (what it processes): What kinds of input does it process? What does its output look like? What kinds of modes or states can it be in? Does it come packaged with preset data? Is any of its input sensitive to timing or sequencing?
Platform (what it depends on): What operating systems does it run on? Does the environment have to be configured in any special way? Does it depend on third-party components?
Operations (how it will be used): Who will use it? Where and how will they use it? What will they use it for? Are there certain things that users are more likely to do? Is there user data that would make the tests more realistic?
You can invent your own heuristics and apply them to the whole application as well as to requirements analysis.
Good requirements should be clear and precise, with no uncertainty or ambiguity; should be measurable in terms of specific values; should be testable and complete; and shouldn’t contain any contradictions.
Further Reading: https://www.softwaretestinghelp.com/how-to-test-software-requirements-specification-srs/