COEPD – Center of Excellence for Professional Development Happy Learning
A good Requirements Specification should have all the important aspects such as consistency, accuracy and coherency.
Within a Requirements Specification individual requirements at the microscopic level should be accurate, clear, unambiguous and verifiable.
In many cases the requirements engineer has a correct understanding but fails to document this accurately in formal documentation.
Before formal requirement documentation techniques arrived requirements were stated in natural language as a common language between a user and implementer.
As annotation and modeling techniques evolved requirement specification became more precise and easy to understand, especially as information system became more complex.
At every stage of the requirements cycle a different document is being produced which describes the requirements in appropriate level of detail for e.g. Business users requirements are specified in Business requirements document, System users requirements are specified in System requirements document, Development requirements are specified in Software requirements specification.
Much has been talked about the attributes a requirements specification should have e.g. a requirement should be accurate, specific, traceable, unambiguous, complete, verifiable etc etc.. However these attributes seem very subjective and difficult to apply to every requirement statement written.
There is a need for a framework for a specific set of attributes that every requirement statement can be measured against.
Hence the SMART framework for a requirement is:
SMART to be:
S pecific
M easurable
A ttainable
R ealisable
T raceable.
This framework is derived from the objective setting in Management theory. Because requirements are driven by objectives or rather each requirement is an objective (A business objective, a user objective, a system objective). They are goals which are desired to be achieved.
In many time management courses and leadership courses, the acronym SMART is used to assist people in setting down good objectives.
A SMART objective is:
S pecific
M easurable
A ttainable
R ealisable
T ime bounded.
For personalized objective setting T stands for time bounded in that the objective must be achieved by a specified date. In the context of software requirements however the dates by which requirements must be achieved is usually specified in the Project Plan (and ultimately the contract). The Project Plan is not usually developed by the author(s) of the Requirements Specifications and can not be produced accurately until the SRS is completed. Consequently it would not be appropriate for a Requirements Engineer to specify time boundaries for individual requirements.
In addition, many requirements in a Requirements Specification are dependent on other requirements or are part of a higher level requirement. A common criticism of some requirements is that the original justification is lost.
It would be better for a Requirements Engineer to think of T as standing for Traceable. “If it is not possible to envisage how a particular requirement is related to other requirements and to know where it came from, then it is not a SMART requirement.
