The Ultimate Guide to the SDLC

The Complete and Ready-To-Adapt System Development Life Cycle

  • Home
  • SDLC Principles
  • Articles
  • Table of Contents
  • Downloads
You are here: Home / Best Practice / Are Your Requirements Good or Just Good Enough?

Are Your Requirements Good or Just Good Enough?

By Victor M Font Jr Leave a Comment

Are Your Requirements Good Enough
Leonardo da Vinci [Public domain], via Wikimedia Commons
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.

[1] The Texas Project Delivery Framework is available from http://www.dir.state.tx.us/pubs/framework/extensions/

UltimateSDLC.com runs on the Genesis Framework

The Genesis Framework empowers you to quickly and easily build incredible websites with WordPress. Genesis provides the secure and search-engine-optimized foundation that takes WordPress to places you never thought it could go.

Check out the incredible features and the selection of designs. It's that simple—start using Genesis now!

Click here to download The Genesis Guide for Absolute Beginners (PDF - 1.4 MB)

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Buy Now, Instant Download

The Ultimate Guide to the SDLC front cover
PDF eBook

$49.99

Add to Cart

Download Free Preview

$0.00Free Download

UltimateSDLC.Com is Hosted on SiteGround

SiteGround Web Hosting

Testimonials

Thank You for Your Testimonial

“…The author has truly “hit the nail on the head.” Whether you are an academic student who is aspiring to be an IT professional one day, a trainee that has just started career, a business & quality analyst and manager that has years of IT SDLC project experience—a must read for an IT professional at all levels of IT journey.” —Sekhar Bommana PMP, ITIL, VP – … Read More

Consulting Services

I have the prescription for your IT ailments

Implementing a SDLC is not an easy task. In fact, it can take months or even years to develop the policies, processes, procedures, metrics and training to bring you the kind of results that lead to repeatable project successes, reduced rework and deliverables that meet or exceed stakeholder expectations. There are a number of factors that … Read More

Connect with the Author

  • Email
  • Facebook
  • LinkedIn
  • Pinterest
  • Twitter
  • YouTube

Copyright Notice

Copyright © 2010–2023 Victor M. Font Jr.
Unauthorized use and/or duplication of this material without express and written permission from this website’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Victor M. Font Jr. with appropriate and specific direction to the original content.

Recent Posts

  • Managing Scope Creep
  • Agile Manifesto
  • Adaptive Software Development
  • Incremental Commitment Model
  • Legend of the Chicken and Pig

Recent Comments

  • Gold on The Project Management Method and the SDLC
  • Phineas on Adaptive Software Development
  • Victor M Font Jr on US Vee Model
  • Jessica Tattersall on US Vee Model
  • Aditi on IT Governance and the SDLC – Part 1

Tags

Affiliates Agile Best Practice Business Analysis Checklist Commission Elicitation Good Requirements Hybrid Hyrid IT Governance Model Organizational Change Outsourcing Project Management Quality Assurance Requirements Elicitation Risk Management SDLC Thought Provoking Waterfall Waterfall Variant

Return to top of page

Copyright © 2010–2023 Victor M. Font Jr.

Privacy Policy | Terms of Service | Contact Author | Report Erratum | Sitemap