IQAA: Changing Requirements

The whole conference I was at this week for me revolved around the requirements management process. Partly because many companies I've worked at had trouble with this part of the process; that is, they followed the process of creating a requirements document, then they shut it away in a drawer and never look at it again while developers and testers go along their merry way and code up a mishmash of the requirements, what they think the requirements might mean, and any customer requests that aren't too difficult and/or are from important customers.

But I think a main thrust of Dr. Hanna's talk was that the requirements document is very important. I'm used to this very static, dull requirements document, and so I kept wanting to raise my hand and say, "How can you do that when the requirements phase is already complete?" But I have to conclude that he doesn't think it is static at all, and that it has to be dynamic and updated continually. (It was interesting that he said several times that testing is a process, not a step in the process, but he never said requirements were too.)

The typical software company tends to communicate rather informally. Write up a vague requirements document, then have the developers implement it any ol' way that seems right. If they're good, or at least social, developers, they'll talk to customers or managers or somebody that can clarify the requirement. A lot of developers will just guess, though. (Combined with receiving fast feedback from a Customer, this is just fine, of course.) But this is why the developer/customer communications need to be with testers (in a typical software environment ) or part of the process (in a regulated environment or one with traceability requirements. When it is part of the process, the correct process, I think, is to modify the requirements doc based on the customer communication. This gives testing a chance to update their tests. Dr. Hanna came back many times to the diagram:

Requirement -> Test Scenario -> Test Case -> Script

So if the Requirements are up to date, the tests can be up to date as well.

I'm not sure that every attendee thought this was the emphasis, but I also went to a couple of talks on this topic.