Only Validated Requirements Are Considered In Design Options

Note that the statement "Only Validated Requirements Are Considered In Design Options" is found in a rather obscure area of the BABOK under the inputs into the Design Options task. (BABOK 7.5.3)

IN MY OPINION
The statement is incredibly short sited and largely incorrect. I understand the concept, that execution of design work on non-validated requirements has risks. What the statement does not reflect is that it can have strong benefits as well. 

 A bitter sweet picture for me - Bogie (on the left) passed a week later and our boy Tanner still misses him.

A bitter sweet picture for me - Bogie (on the left) passed a week later and our boy Tanner still misses him.

Designs can come into play as part of the requirements definition process due to things such as prototyping and building initial visualizations of the final product.  Sometimes, you need designs created in order to gather, document and even validate requirements. 

Designs, specifications and requirements can become so entwined that many stakeholders do not see the difference. This "can" be an issue because it reflects a break in the shared understanding of the individual components. However, the quote of "culture eats process for breakfast" comes to mind. In some cases, a business analyst needs to teach and sometimes they need to adapt.

If an organization puts design tasks before requirements (and many do), they are NOT doing it wrong … if the final product meets/exceeds stakeholder expectations. If the practice is adopted in the work group and it works for them, I wouldn't be so quick to criticize it. 

© 2018 Dwayne Wright