Tip - Defining your Information Management requirements

I was having a discussion in email with someone about what their requirements were for information management and I suggested an approach for them to define their requirements. I developed the suggestion further in order to make this post.

 To a large extent, the typical approach is for users to take an ad hoc, features-based approach to stating their requirements. That is, looking at the features of an information management system (e.g., Evernote or InfoSelect or Gmail, amongst others) and saying "Look how useful that is" or "I don't like this" (e.g., a "ribbon" menu) or "I do like this" (e.g., the ribbon). This actually is not the most helpful way (to a developer) to go about providing or gathering requirements, since a like or a dislike does not necessarily define a requirement nor does it necessarily even identify a requirement. This is why attempting to build a requirements list by, for example, a straw pole (likes and dislikes) is usually doomed to failure. It is, in fact, irrational.
As WE Deming said, "Action that is not based on sound theory or best practice is irrational by definition".