User Requirements

User requirements include both functional as well as non-functional details. The details should only provide the external behavioral aspects of the system. Hence, it should not include its implementation details which may frustrate the nontechnical users. The details should be written in terms of diagrams, forms, tables etc., to a major extent. Apart from this, there may be certain other problems which may evolve due to the usage of natural language in writing these specifications.

Few of these problems are listed below

Problem 1: Requirements amalgamation

This problem usually arises when several requirements are clubbed together and are specified as one.

Problem 2: Lack of clarity

When the requirements are not specified in a precise and unambiguous way, then clarity is said to be lacking.

Problem 3: Requirements confusion

This problem usually arises whenever the developers do not specify a clear distinction between non-functional requirements, functional requirements, design information and system goals.

Moreover, while writing user requirements, one has to remember that it should not be included along with the details of the system requirements. The user requirements should be precise. If it covers large amount of data then the software developer cannot include solutions to the frequently occurring problems and it becomes difficult to read. Hence, it should provide only the essential facts, while avoiding the unnecessary details. Whenever any such details are provided, a supporting reason (behind its inclusion) should be associated. This reason describes its importance and it can be considered whenever suitable changes are made to the system.

Following are certain important, principle guidelines recommended to be followed while preparing the user requirements

(i) It is a good practice to highlight the useful information.
Highlighting can be done by either making the data italic, underline, bold or by changing its colour.

(ii) The user requirements documents should not get mixed up with the system using the information.

(iii) While writing requirements, it is good practice to follow standard notations throughout the document. For Example the requirements can be in bold format while reason of its inclusion in normal text.

(iv) Further, in order to make the document more realistic, the source from which the given reason is acquired can also be associated with a particular reason. This provides ease in considering the source when suitable changes are being made to these requirements.

(v) While specifying the requirements, there should be clear distinction between the mandatory and desirable requirements.

(vi) Computer jargons must be avoided to the possible extent.