How does a business analyst ensure that the requirements are at the appropriate level of quality?

How does a business analyst ensure that the requirements are at the appropriate level of quality?
Requirements that are well written, well organized, and easily translatable into solutions help develop the solution efficiently, with less reworking and confusion. Requirements that are inaccurate, incomplete, and poorly organized can quite literally generate solutions that fail to meet the business needs. It always pays to take time to understand the expected quality levels of the project team and organization.

The following table lists quality measures and ways to optimize them to ensure that the requirements meet the organization's needs.

Well written requirements Become familiar with the characteristics of a good requirement , and use peer reviews by other business analysts or discussions with quality assurance analysts to assess the requirements along the way.
Well structured requirements documentation Structure the requirements documentation for clarity, separating functional and non-functional requirements, business rules, etc.
Well elicited requirements Ensure that the right stakeholders are providing input and reviewing the requirements, and that the requirements elicitation/identification process isn't needlessly painful or overly simple for the stakeholders.
Well chosen requirements formats Use process-type diagrams, such as a business process model, to document processes. Use context diagrams to document context. Document any data requirements with a tool such as a data dictionary. And so on. Use the correct form for the type of requirement being documented, but don't allow the form to become more important than the function.
Well managed requirements Ensure that there's a Requirements Management Plan, and that the plan is adhered to consistently and reviewed for possible improvements.
Well traced requirements Ensure that the requirements are traced back to the highest levels of project vision and objectives. Make sure there are no "orphan" requirements, and be sure the requirements change process includes a review of traceability to assess how the changes impact other requirements.
Well defined requirements Ensure that data definitions are thorough and accurate. Ensure that there's a project glossary, and that consistent wording is used throughout the requirements documentation.

Also, note that the level of detail can vary during a project, without negatively impacting the quality of the requirements. Early in the project, you might go "inch-deep" into some requirements areas; but be aware that you'll need to go "mile-deep" in the riskier and higher-priority areas. As the project proceeds, you'll need additional detail about the requirements, to build a complete and accurate picture of the business needs.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.