Traditionally, requirements engineering paradigm has promoted the idea of separation of problem space from solution space when thinking about the requirements and design solutions. In this way, analysts do not bother to think of how, when they are focusing on what, and later on they look at the list of requirements and come up with an architecture design for the mess of requirements. It has been counted as good thing. However, for a reason I don’t know, always someone comes that says, oh no, you have all been so wrong.
I like this idea, and I’d like to find a way to prove it. I have convinced myself with reasons, like: if we gather a list of requirements without thinking of their feasibility, we have just developed a wish list, not more, not less. They are not software requirements that in the next phase a designer develop them. In addition, when we close eyes to solution space, we may guess that some requirements are in conflict, usually happens for privacy and security. However, the impact and interactions of requirements on each other, do not come from the nature of requirements, but come from the nature of solution that implements the requirements.