There is no clean line between declarative knowledge and imperative knowledge. Frequently, a mixture of both kinds of knowledge are present.
Requirements seldom contain purely one kind of knowledge. Rather, a mixture of both kinds of knowledge are present. Some requirements are best modeled by declarative knowledge, while other requirements are best modeled by imperative knowledge.
Some requirement gathering techniques and tools emphasize one kind of knowledge over another. For example, The Fusion technique of D. Colemen et al defines the system operation schemes as declarative knowledge only, while the interaction graphs are defined as imperative knowledge only. This forced split becomes a hindrance for many real-world problems.
Another technique of Recursive-iterative development: `Essays on Object-Oriented Software Engineering', Volume 1 by E.V.Berard, 1993, combines both kinds of knowledge at each level of abstraction. As one abstraction is refined into another abstraction, the combination of declarative and imperative knowledge is replaced with another combination of declarative and imperative knowledge.
The technique of Eiffel attaches declarative knowledge in the form of pre-conditions, post-conditions, and invariants to imperative knowledge. The imperative knowledge is materialized as algorithms and data structures.
Functional programming environments, like Mathematica, are declarative in nature. The system and not the customer discovers the imperative steps to solve the problem.
Mathematics also contains the two kinds of knowledge. The axioms and theorems are examples of declarative knowledge, while the proof is an example of imperative knowledge. Both are needed.