15 Points to focus, while writing Requirements Specification

1. Requirement specification requires a simple and rational structure, with a version track. Traceability is one of the success factors for any requirement specification. For major specifications, Requirement Engineer may use a spreadsheet
   

2. Each requirement shall be recorded accurately with the prime objective of not loosing the specific characteristic of the requirement.
   

3. Ensure single interpretation for each requirement, recorded and shall be precise, easy to read, clear, short and explicit.
   

4. Use simple and natural language, across requirement specification. However, Requirements Engineer can not avoid domain specific terms, which customer follows to explain the business case or problems. Here, explain the term under glossary
   

5. Prime objective of Requirements Engineer would be to state, requirements and deliverable to customer without ambiguity.
   

6. Giving emphasis to ‘How’ may make Requirements Engineer and user, biased and this may even damage the actual requirements flow and scope of the design. However, Requirements Engineer can include ‘How’ with less emphasis on technology, tools and design.
   

7. Each requirement shall be recorded with a specific purpose and commitment. Better to use 'shall' in sentences, as this can indicate commitment.
   

8. Be objective, when write requirements and never assume or undermine anything as far as requirements are concerned.
   

9. Requirement engineer shall give focused attention towards the specification and ensure that the problem domain has been understood, completely and then recorded functional/non functional requirement, system performance and constraints.
   

10. Requirement Engineer shall use references, scenarios, diagrams and tables, wherever necessary to explain requirements, rationale and background.
    

11. The requirement specification shall be verifiable. To make it verifiable, ensure that each requirement statement has been written with utmost care and once the product is delivered, customer can associate a feature with the requirement and verify the same.
    

12. Requirement Engineer shall specify the function envisaged by the user with performance expectations for each and every requirement. However, avoid getting in to technology, tools or physical attributes of the product under design and cost

13. The requirements shall be testable. So ensure that there are some quantitative mechanisms to test the requirements, recorded. More specifically, there shall be a scope for writing one or more test cases for each of the requirements

14. Avoid the following, while writing requirements

> Refer Tables/figures, which are not part of the specification
> Refer telephone calls/correspondence, which is not in record
> Incomplete sentences, which ends with and/or, etc.
> Words like normally, wherever applicable, may be, nominal, approximate, peak, achievable, coincidence, latest
> Passive sentences
> Words, which can't be tested - usually, reasonable, highest, earliest, flexible, adequate, efficient, possible, faster, worst, often, acceptable, compatible
> Conflicting terms/characteristics
> Repeat a requirement, more than once in the specification
> Use of a pronoun (Eg: - it), without an explicit reference
> Logical inconsistency and conflicting business logic

15. As any product can be made with in certain budget with the available tools, technology and resources, care shall be given to consider all these aspects, while write a requirement specification