Requirements are to be classified in two large categories: specifications and issues.
A specification is the description of a whole new project, or a large new or redesigned subproject of an existing project. Of course three lines are not enough to contain a project specification. It may be as large as a several hundred or thousand pages, but sometimes a three pages document may be enough. However it has a first part that analyzes the preexisting situation, and a second part describing the demanded situation.
The preexisting situation is typically another software system that should be replaced, wholly or partially, by the new system, or a non-computerized procedure that the new system should automatize.
The demanded situation is described always using words, but such words may be accompanied by some drawn schema, some drawn screenshots or printouts, or by a software prototype (more on this later).
An issue is the description of a desired change of an existing and somewhat working system. It also has a first part that analyzes the unsatisfying aspects of the preexisting situation, and a second part describing the demanded situation regarding those aspects.
Here is an example of an issue.
Title: Total line of expenditure report
Previous situation: The total line of the expenditure report is sometimes written as the first line of a new page.
Desired situation: Every time a total line is to be written as the first line of a new page, split the previous page a line before, so to have the total line as the second line of its page.
Some people try to classify requirements in defects (a.k.a. bugs), requests for enhancements (RFE for short), or other classes. I don’t think it is a good idea, because it is sometimes controversial how to classify a requirement, and sometimes a single operation should be applied to all the issues.
A three-line issue is enough for a very short project involving a single developer. But with bigger projects or bigger teams a more structured issue handling is advisable.
First of all, the issues should be put in a (shared) database. Second, other fields should be added, like the state of the issue (NEW, APPROVED, UNDER WORK, UNDER TEST, TESTED, RELEASED, DISCARDED), the timestamps and the authors of the state changes.
There are many tools to handle software development issues. They are named “bug trackers” or “issue trackers”. Some work on a single platform, some are proprietary. The one I advice is Redmine, that is multi-platform, highly configurable, and open-source.
Some people holds that a good requirements specification should be written in a formal language, or using a formal analysis process (e.g. Object-Oriented Analysis). I think that sometimes those people really think about software design, and not requirements analysis, that is they are not talking about what to do, but about how to do it. However, formal methods for this are not a good idea, as the requirements (both the system specification and the issues) should be readable for approval by the customer and by the managers, and they shouldn’t be proficient in formal methods. Therefore the requirements should be written using words, tables, schemas, screenshots, and prototypes that are fully understandable also by the (managers of) the end-users, or by the managers of the software shop in case of a shrink-packaged product or an in-house tool.