1.3 A Few General Principles

Like all other arts, the Science of Deduction and Analysis is one which can only be acquired by long and patient study, nor is life long enough to allow any mortal to attain the highest possible perfection in it.
-Sherlock Holmes: A Study in Scarlet,
Arthur Conan Doyle

This section discusses a few general principles to apply whenever specifying requirements. They will help you deliver good results and can help you decide whether or not to include something. This isn't a systematic set of principles; they're merely a few things that I wish to bring to your attention.

Specify the Problem, Not the Solution. Saying that requirements define "what, but not how" means that it's not the role of requirements to attempt to specify the solution or any part of it. This is an important distinction, and it is a rule not to be broken.
Specify the System, Not the Project. Requirements define what a system needs to do: they are a set of objectives. A project is the mobilizing of a team for a temporary duration to achieve those objectives. Requirements have no place saying how a system's objectives are to be achieved, which means saying nothing about a project to implement a solution (including milestone dates, team size, names of team members, costs, budget and methodologies). Also write every requirements specification to be timeless, to be equally valid for multiple systems that might be built in different ways at different times: the requirements could be put into a drawer and brought out in a year or two, or we might build a replacement system in a few years time.
Separate the Formal and Informal Parts. A requirements specification acts like a contract that defines what the builders or suppliers of a system must deliver. But a mass of contractually binding statements are far from enough for a reader to make proper sense of it: it needs background, context, flow, and structure. None of this extra material is contractually binding. It's invaluable to divide the specification into the binding (formal) and nonbinding (informal) parts. The requirements themselves constitute the formal part of a requirements specification: the official definition of what the system must do. Everything else is informal.
Avoid repetition. Express each item of information only once, as far as is practical. Repetition creates extra work and opens opportunities for inconsistencies.