Characteristics of a Good Software Requirements

Specification
A software requirements specification should be, meeting a specific need. clear, concise,
consistent and unambiguous. It must correctly specify all of the software requirements,
but not more. However the software requirement specification should not describe any of
the design or verification aspects, except where constrained by any of the CLIENT’s
requirements.
For a software requirements specification to be complete, it must have the following
properties:

Meeting a Specific Need:

A requirement is a basically a statement of something someone needs. The something is
a product or solution that performs a service or function. The someone may be a
company, a user, a customer, support, testers, or another product.

Clear
1. Description of all major requirements relating to functionality, performance,
design constraints and external interfaces.
2. Definition of the response of the software system to all reasonable situations.
3. Conformity to any software standards, detailing any sections which are not
appropriate.
4. Have full labelling and references of all tables and references, definitions of all
terms and units of measure.
5. Be fully defined, if there are sections in the software requirements specification
still to be defined, the software requirements specification is not complete.

Concise:
A good requirement should express a single thought. It should be concise and simple. The
more straightforward and plainly worded, the better. It should use short, simple sentences
with consistent terminology. If possible, specific names are to be decided for the solution
or product and deliverables and referred to them by name alone in the requirements –
Consistent language should be used. Subsystems should be defined and named and
referred to them only by those names (Acronyms can be used in order to keep them
short.). The less complex and more consistent everything is from requirement to
requirement, the better. Too many words and too many references breed inconsistency
and confusion.

Requirements should be stated positively whenever possible. It is easier to develop and

test a product that does something specific than one that does not do something specific.
It is extremely difficult, if not impossible, to test that something does not happen. This
type of testing is expensive.

Consistent
A software requirement specification is consistent if none of the requirements conflict.
There are a number of different types of confliction:
a. Multiple descriptors: This is where two or more words are used to reference the
same item, i.e. where the term cue and prompt are used interchangeably.
b. Opposing physical requirements: This is where the description of real world
objects clash, e.g. one requirement states that the warning indicator is orange and another
states that the indicator is red.
c. Opposing functional requirements - This is where functional characteristics
conflict, e.g. perform function X after both A and B has occurred, or perform function X
after A or B has occurred.

Unambiguous
This means that each requirement can have one and only one interpretation. If it is
unavoidable to use an ambiguous term in the requirements specification, then there
should be clarification text describing the context of the term.

Verifiable
A software requirement specification is verifiable if all of the requirements contained
within the specification are verifiable.

Modifiable:

The requirements are to be in such a way that it should facilitate changes whenever
needed.

Traceable:
The requirements should be traceable, i.e., if any one has to go back and check on any
requirement for verification, validation, or modification, it should be easy to access them.
So, a numbering of requirements or a code should be given to each and every requirement
as to trace it easily.

Ranked for importance

The requirement should be ranked or ordered by its importance in usage for client’s
business to function.