Design problems normally originate as some form of problem statement provided to the designer by someone else , the client or company management.
These problem statements , normally called a design brief can vary widely in their form and content.
An example of a design brief can be “ to create a system which can land on a moon “ to “create a fastening mechanism for a certain household application”
The design brief decides the nature of the problem.
Is it a new problem ?
Has anybody done it before?
Is there enough context within which to design?
All these questions go through the designers’ mind when the design brief is given. Sometimes this statement of requirement can be rather vague and also might change in due course of time. It’s a part and parcel of the product development process.
These design briefs are formed by just defining the problem at hand.
For example, the idea of forklift originated from the pain and difficulty of handling heavy packages and placing them at a high pedestal which were very physically intensive for humans.
The requirements from the brief form the input for the design effort and hence must be converted into functional specifications by the designer.
Understanding and formulating requirements hence is very important for design engineers to properly “get” what needs to be done . If the problem seems too far fetched or impossible to work for within the constraints then that has to be put forward by the design engineer after analysing the design brief.