1) For good requirement documentation we should define one requirement a time. Don’t use any conjunctions like AND,OR,ALSO,WITH and THE LIKE and also avoid using let out classes like but, except and if necessary. Because words like there can cause developers and testers to miss out on requirement. We can achieve this by slipting complex requirement till one can be considered a discrete
2) A clear definition of what needs to be solved or improved- When deciding whether to include or exclude new feature, functions or process in the project
3) BA should not express suggestions or possibilities. we can identity these with statements which include MIGHT,OUGHT,MAY,COULD etc
4) Avoid saying you want a system to handle all unexpected failures is wishful thinking since no system will ever be a 100% what you want it to be.
5) Avoid using long sentences or making reference to unreachable documents
6) BA should use Positive statement such as “The system shall” instead of “The system shall not”
7) Avoid using the requirements which are not yet defined.
8) Thorough interviewing and analysis techniques should assist in making this list as full and complete as possible.
9) It is important to identify all problems upfront so that you are across all possible issues and can start tackling these problems early on
10) Sign Off: All your documents need to have a sign-off page. It is important all requirement documentation is approved and signed off; again, this is to ensure understanding on both-ends, as well as accountability and traceability.