User Requirements

 User Requirements

The user requirements for a system should describe the functional and non-functional requirements so that they are understandable by system users without detailed technical knowledge. They should only specify the external behavior of the system and should avoid, as far as possible, system design characteristics

Consequently, if you are writing user requirements, you should not use software jargon, structured notations, or formal notations, or describe the requirement by describing the system implementation. You should!d write user r requirements in simple language, with simple tables and forms and intuitive diagrams.

However, various problems can arise when requirements are written in natural language sentences in a text document:

1. Lack of clarity: It is sometimes difficult to use language in a precise and unambiguous way without making the document very and difficult to read.
2.  Requirements confusion: Functional requirements, non-functional requirements system goals, and design information may not be clearly distinguished.
3. Requirements amalgamation: Several different requirements may be expressed together as a single requirement. 

As an illustration of some of these problems, consider one of the requirements: for the library.

1. A conceptual, functional requirement states that the editing system should provide a grid. It presents a rationale for this.
2. A non-functional requirement giving detailed information about the grid units (centimeters or inches).
3. A non-functional user interface requirement that defines how the grid is switched on and off by the user.
4. Invent a standard format and ensure that all requirement definitions adhere to that format. Standardizing the format makes omissions less likely and requirements easier to check. The format I use shows the initial requirement in bold-face, including a statement of rationale with each user requirement and a reference to the more detailed system requirement specification. You may also include information on who proposed the requirement (the requirement source) so that you know whom to consult if the requirement has to be changed.
5. Use language consistently. You should always distinguish between mandatory and desirable requirements. Mandatory requirements are requirements that the system must support and are usually written using 'shall'. Desirable requirements are not essential and are written using 'should'.

•  Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.

• Avoid, as far as possible, the use of computer jargon. Inevitably, however, detailed technical terms will creep into the user requirements.

This requirement includes both conceptual and detailed information. It expresses the concept that there should be an accounting system as an inherent part of LIBSYS. However, it also includes the detail that the accounting system should support discounts for regular LIBSYS users. This detail would have been better left the system requirements specification.

It is good practice to separate user requirements from more Delaney system requirements in a requirements document. Otherwise, non-technical readers of the user requirements may be overwhelmed by details that are really only relevant for technicians

This example is taken from an actual requirements document for a CASE tool for editing software design models. The user must specify that a grid should be displayed so that entities may be accurately positioned in a diagram.

The first sentence mixes up three kinds of requirements. The requirement also gives some but not all initialization information. It defines that the grid is initially off. However, it does not define its units when turned on. It provides some detailed information--namely, that the user may toggle between units--but not the spacing between grid lines.

User requirements that include too much information constrain the freedom of the system developer to provide innovative solutions to user problems and are difficult tó understand. The user requirement should simply focus on the key facilities to be provided. I have rewritten the editor grid requirement (Figure 6. 10) to focus only on the essential system features.

Whenever possible, you should try to associate a rationale with each user requirement. The rationale should explain why the requirement has been included and is particularly useful when requirements are changed. For example, the rationale recognizes that an active grid where positioned objects automatically 'snap' to a grid line can be useful. However, this has been deliberately rejected in favor of manual positioning. If a change to this is proposed at some later stage, it will be clear that the use of a passive grid was deliberate rather than an implementation decision.

To minimize misunderstandings when writing user requirements, I recommend that you follow some simple guidelines:

The Robertsons (Robertson and Robertson, 1999), in their book that covers the VOLERE requirements engineering method, recommend that user requirements be initially written on cards, one requirement per card. They suggest a number of fields on each card, such as the requirements rationale, the dependencies on other requirements, the source of the requirements, supporting materials, and so on. This extends the format that I have used , and it can be used for both user and system requirements.