How to Rework Poorly Defined Requirements

Poorly defined requirements are even more dangerous than no requirements because they offer the illusion that all is well during development. However, when user acceptance testing begins, requirements problems surface and the users rightly say, “I don’t care that the system test has passed, this isn’t what we need, and we won’t be signing off.” Steve Caseley reviews the actions he took to rework the requirements on two failed projects and the changes he made to get new projects off to the right start. Steve explores how statements such as “new reports must be balanced with the old reports” were re-written to identify quantifiable variances. He shows how other loosely defined requirements were reworked to provide clear mapping of measurable requirements to expected test results. Join Steve to gain knowledge and insight you need to refactor poor requirements-and to develop the requirements your team and customers need on your next project.