Often, we, as testers, are asked for the impossible. Take, for example, the task of certifying a piece of software which has no defined — or very loosely defined — requirements. I am not talking about the stories in Agile, but I am talking about the loose development style that typically starts in a meeting where someone says, “wouldn’t it be cool if..” and ends with a developer taking some time to write in the cool.
Requirements exist for a reason: they define the job. By the job I mean, the developer’s job, the marketer’s job, the customer’s job, and the QA department’s job. Without the requirements being written and debugged (i.e. agreement on goals) there can never be a true SDLC.
As a tester, and a believer in the fact that software should be created to the highest quality standards, I would encourage QA to get involved in the process. If there are representatives involved from the interested parties, Dev, Marketing, Mgmt, QA, and the customer, people’s needs are going to be met. Not only that, but the ability to meet real — not perceived — needs will be enabled at a rapid rate.
So you need to get educated as to the goals of each interested party in the chain. Know what development wants. Know what management wants. Know what your customers want. Once you know the needs you can help to craft a requirement document that satisfies those needs and insures successful deployment.