Requirement Statement and Specification

Documents

Different levels of software requirements are documented in different documents. The two main documents produced during this phase are Requirement Statement and Requirement Specification. They are also called Requirement Definition and Functional Specification and are used to document user requirements and  functional requirements respectively.

Requirement Statement Characteristics
A good Requirements statement document must possess the following characteristics.

• Complete - Each requirement must fully describe the functionality to be delivered.
• Correct - Each requirement must accurately describe the functionality to be built.
• Feasible - It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment.

Necessary -Each requirement should document something that the customer really
need or something that is required for conformance to an external system requirement
or standard.

• Prioritized - An implementation priority must be assigned to each requirement, feature or use case to indicate how essential it is to a particular product release.
• Unambiguous - All readers of a requirement statement should arrive at a single, consistent interpretation of it.
• Verifiable – User should be able to devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly  implemented. 

Requirement Specification Characteristics

A good Requirements specification document should possess the following characteristics.

• Complete - No requirement or necessary information should be missing.
• Consistent – No requirement should conflict with other software or higher-level system or business requirements.
  Let us try to understand this with the help of some examples. The following set of (non-functional) requirements was stated for a particular embedded system.
• All programs must be written in Ada
• The program must fit in the memory of the embedded micro-controller
  These requirements conflicted with one another because the code generated by the Ada compiler was of a large footprint that could not fit into the micro-controller memory.
  Following is another set of (functional) requirements that conflicted with one another:

• System must monitor all temperatures in a chemical reactor.
• System should only monitor and log temperatures below -200 C and above 4000 C.
  In this case the two requirements clearly conflict with each other in stating what information needs to be monitored and stored.
• Modifiable - One must be able to revise the Software Requirement Specification when necessary and maintain a history of changes made to each requirement.
•  Traceable - One should be able to link each requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement.

Mixed level of Abstraction

It is important to recognize that all requirements in a requirement document are stated at a uniform level of abstraction. This difference in detail falsely implies the relative importance of these requirements and hence misguides all involved in the development process. The following set of requirements clearly demonstrates violation of this principle:

• The purpose of the system is to track the stock in a warehouse.
• When a loading clerk types in the withdraw command he or she will communicate the order number, the identity of the item to be removed, and the quantity removed. The system will respond with a confirmation that the removal is allowable.

Our next topic will be Relationship of Several Component of Software Requirements