When you first learn about software requirements, you also learn about the “what” versus “how” discussion.  People tell you in review meetings that you shouldn’t write how things are done, when you can write what is done, and they give you some abstract example, like: “The system notifies the user about the error” instead of “The system beeps and displays an alert sheet”.

In practice, it is extremely difficult to root out all “hows” from your requirements, without making them incomprehensible for a reader. I use to say: “If it’s important for the understanding to describe something on a low level, you should do this. You, as a writer, decide on what level your requirements need to be.” If there is a rule, it is better to be precise than abstract. Abstract requirements only lead to misunderstandings.

When you write requirements on a detailed level, you are also bound to take design decisions, or decisions that affects the architecture. This is not wrong. The Requirements Specification should contain actors, actions, objects and attributes. Actors are parts of the system, sometimes they are human beings, such as “the User”, “the Systems Administrator”, “the database server”, “the database client” and so on. Objects are the same as Actors, except that they are at the receiving end of an action. The Database Client can thus be both an Actor and an Object, depending on if it “acts” or “receives an action”. Objects can have attributes (or properties), such as “weight”, “size”, “color”, or “frequency”. The properties have values, such as “25 kg”, “2.15 m”, “Pantone Uncoated 2423”, or “234 Hz”. Even actions can have attributes, but more often they have conditions attached to them. For example:

         “If the user clicks the refresh button, the Server Admin updates the information
         in the DNS view.”

When you write requirements for a Billing System in a telecom application, there is no point pretending that it’s not a Billing System, only because you don’t want to take design decisions during the requirements phase. Everyone knows that a Billing System contains a General Ledger, a Rating Engine, a Database Server etcetera. This is not architectural decisions that should be taken six months into the project. This is (architectural) requirements that should be stated early.

You should dedicate a chapter to describe your Actors. If you introduce them early in the Requirements Specification, it is easier for a reader to understand the requirements later. This Actors chapter does not contain any formal requirements; it only describes the actor from a systems perspective and doesn’t have to be complete in any way, for example:

              “The General Ledger stores accounting information. Financial transactions
                that are performed in the system are recorded on specific accounts, which
                are stored in the General Ledger. The General Ledger need to be storage
                persistent.”

This is not a complete description of the General Ledger, but it tells the reader enough to understand the requirements later on. If you want, you can define “storage persistent” in the definitions chapter, as “Doesn’t loose its information during a power-out”.