Cauvin on PM blog has this super-insightful post on writing software requirements. Lately, I've been more involved with this and so this specific point was really useful ... so I am sharing it.
So, imagine you are designing a solution that will save the user files and will have them available in case the user needs it. Sometimes it is called a "a backup solution," but I am intentionally not using this term (you'd see why later). "... Similarly, conventional requirements documentation for a backup service would include specifications such as:
The system shall enable the user to backup files.Or a use case such as:
Yet these specifications and use cases do not represent real requirements. No user wants to backup files [!]. They want to be able to restore files. Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.
A product manager who includes these design specifications in a requirements document is doing the company a disservice."
Think about it and the sheer ingenuity of this will dawn on you! And read his full post, of course.