As an operational definition, good requirements are cohesive, complete, consistent, correct, feasible, modifiable, necessary, prioritized, reusable, testable, traceable, verifiable and unambiguous. If requirements aren’t captured to this high standard, rework or project failure is the natural consequence. No one will ever get good requirements that meet this standard by walking into a room and asking the customers “What are your requirements?” This is not a disciplined enough approach. Yet, it’s what many companies do. Good requirements are elicited. The word “elicit” means to “draw out” which means the competency of requirements elicitation necessitates a great degree of interaction, organization and customer involvement to draw good requirements out of the users.

To help you evaluate whether or not you are eliciting good requirements, The Ultimate Guide to the SDLC includes a comprehensive requirements checklist to serve as a guide for your Business and Quality Assurance Analysts.

The good requirements quality checklist is partially reproduced below. It is a quality guide to ensure requirements meet the operational definition of good requirements. The checklist is based on the Requirements Verification Checklist released to the public domain in May 2008 by the United States of America State of Texas Department of Information Resources as part of Version 1.1 of the Texas Project Delivery Framework.^[1] In the book, each characteristic of good requirements applicable to the quality inspection is listed in alphabetical order, defined and reinforced by supporting questions intended to direct a quality review.

1. Cohesive: A set of requirements is cohesive if it relates to only one thing. All requirements in a set or group support the overall purpose and scope of the system or component under discussion, whether that is a business process definition, business rule, information flow, data flow or so forth.
2. Complete: To be complete, all known relevant requirements are documented and all conditions under which a requirement applies are stated. A BRD is complete if, and only if, it includes the following elements:
3. Consistent: Consistency demands that the requirement can be met without causing conflict or contradiction with any of the other requirements. Requirement should be stated in a way to allow the widest possible selection of implementation options.
4. Correct: Requirements must accurately describe the functionality to be built. Only the source of the requirements, the customers, users or stakeholders, can determine their correctness.
5. Feasible: Feasibility means each requirement is implementable within the existing infrastructure, budget, timeline and resources available to the team. The business analyst needs to work with the project team to make these determinations.
6. Necessary & Prioritized: Requirements must be ranked for importance and/or stability. A necessary requirement is one that is essential to meet business goals and objectives. A priority is assigned to each functional requirement or feature to indicate how essential it is to a particular solution release. If all requirements are considered equally important, it is difficult for the project team to respond to budget cuts, schedule overruns, staff turnover or new requirements added during development. Ranking requirements for stability is in terms of the number of expected changes to the requirement. Stable requirements are ready to be developed.
7. Measurable, Testable & Verifiable: Verifiable means that the requirement states something that can be confirmed by examination, analysis, test or demonstration. A good requirement does not contain words that are not testable and measurable. If it is impossible to ensure that the requirement is met in the solution, it should be removed or revised.
8. Traceable: Requirements are traceable if their origin is known and the requirement can be referenced or located throughout the solution. The requirement should be traceable to a goal stated in the project charter, vision document, business case or other initiating document. Requirements are traceable backwards and forwards.
9. Unambiguous: Requirements must be clear, concise, simple and free from ambiguity. They must be stated without technical jargon, acronyms (unless defined) or other obscure verbiage. Requirements express objective facts, not subjective opinions. Vague requirements are often misunderstood resulting in rework and corrective actions during the design, development and testing phases. If the requirement can be interpreted in more than one way, it should be removed or clarified.

Download the Requirements Verification Checklist to use with your your requirements elicitation efforts.