Posts
Architecting a verification environment with a dynamically changing requirement is a real challenge, when the entire requirement is known upfront you can fit your problem statement perfectly in to methodology. But if you get requirements in bit and pieces then you make an architectural decision based on the know requirements, when more requirements trickle in you find that decision you did earlier was not right. Option you have on hand is to re-write the code and correct your mistake or patch up the code and deviate it from the methodology recommendations resulting in less reusability. This is a typical problem that happens when overall picture of the problem statement is not understood by the architect. Another problem is due to the attitude that let us get the basic stuff working first, then incrementally fit the requirements in to the basic architecture.Typical project flow when requirements are not know upfront will be like this ( Just for humor !!! ).
