- Define one requirement at a time – each requirement should be atomic. Don’t be tempted to use conjunctions like and, or, also, with and the like. This is particularly important because words like these can lead to developers and testers missing out on some of the requirements. One way to achieve this is by breaking the requirement down till it can be considered a discrete test case.
- Avoid using let-out clauses like but, except and if necessary.
- Each requirement must form a complete sentence with no buzzwords or acronyms.
- Each requirement must contain a subject (user/system) and a predicate (intended result, action or condition).
- Avoid describing how the system will do something. Only discuss what the system will do. Refrain from system design. Normally, if you catch yourself mentioning field names, programming language and software objects in the Requirements Specification Document, you’re in the wrong zone.
- Ensure That Requirements Support Your Overall Business Needs: Having a list of business requirements is certainly an integral part of your long journey toward project success. However, before celebrating, you need to be absolutely certain that those requirements support your organization’s overall business objectives.
- Deliver the Right Message to the Right People: The communication of your business requirements is nearly as important as the development of those requirements. To effectively communicate requirements to your stakeholders, you need to develop a communication plan that will determine who will communicate with your stakeholders, what they will say and when and how they will say it.
Friday, 25 July 2014
Tips to grow as a best Business Analyst by Quontra Solutions
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment