1. Eliminate ambiguity. If you can arrive at more than one understanding or conclusion, chances are so can a developer or tester.
2. When using terminology, don’t assume everyone has the same understanding. Get immediate confirmation to avoid misunderstandings. A glossary of terms and related aliases are very helpful.
3. Promote “plainspeak”, the use of common (English) language when describing business facts, rules, regulations, processes, data, etc. If it is necessary to document something in business or IT jargon then paraphrase its true meaning in plain English.
4. When business or IT terms are used to describe something, always confirm the definition (e.g., when we say “transfer” we mean …).
5. Don’t ask for permission, ask for forgiveness.
6. Understand cultural differences within or between business organization entities and IT. It will help in following other commandments.
7. Requirements should describe what something isn’t as well as what it is.
8. When eliciting requirements, ask clarifying questions to confirm the requirements are being clearly captured.
9. When eliciting requirements, it is important to identify the audience affected (e.g., line of business, products, plan types, etc.).
10. When documenting requirements, decisions or issue resolutions, it is equally important to document the “why” as much as the “who”, “what”, “when”, “where” and “how”. If you don’t, it is more likely that no one will remember later why we went down a certain path.
11. When defining requirements, remember that it has to be testable. If you can’t adequately test it then the requirement is not adequately defined.
12. There are no assumptions, only a current understanding of the facts. Use of assumptions only promotes growth of undesirable anatomical features.
13. When writing (or speaking), put yourself in the reader’s (or listener’s) shoes. Would they really understand what I’m trying to convey based solely on the words I’ve written or spoken? Is there an unrealized expectation that they audience has some level of implicit knowledge in order to understand the subject matter?
14. Treat your developers and technical support staff as you would like to be treated: as a trusted ally and good friend.
15. Understand that people requiring your services as a BA don’t always know what they want and/or are unable to effectively articulate their needs. That’s why God invented BAs.
16. As a trusted subject matter expert, people will usually believe what you say as fact, especially if you are good at clear communication. Being in this position of trust, there is an inherent risk that sometimes you may be wrong in your understanding (and are unaware[RC1] ). However, you are persuasive enough to convince everyone of this truth. You need to rely on others to be able to detect the conveyance of false truths before it’s too late.

Don’t forget to leave your comments below

Tim Ward is a Business Analyst with over 30 years of experience in the financial services market dealing with group retirement plans. He is also a member of the IIBA and received his CBAP certification in 2009.